奏鸣曲式和英语学习app有什么共同点
最近发现奏鸣曲式其实很符合人的记忆规律。
动辄长达七八分钟的交响曲，协奏曲，即使听众记不住每个小节，至少也能让人对它的母题印象深刻，为什么？因为它的主结构框架，呈示部，发展部和再现部，做到了让一段动机甚至主题换着花样地被听众接收。而这正是结合AI的语言学习应用擅长也应该做的。
类比到这类应用里，其框架至少也应该由三部分组成。呈示部在古典音乐里呈现主题，在app里就应该是呈现要学习的知识点。但是绝大多数业余人士制作的应用也就止步于此了。把信息用好看的方式呈现出来，只起到一个筛选信息的作用，但用户接收信息以后如何处理能让用户吸收，这些应用是不管的。他们没想清楚的是，如果只有这个环节，那么为什么用户不直接找装帧更加精美的单词书看呢？
这里就需要第二个环节，发展部了。在音乐里，发展部会对主题进行模进、对位等变化，来让主题听起来更有趣。放在语言学习app里，这才是真正开始让用户产生对信息的思考的地方。产生思考很重要，但思考也有不同强度。我的方案是，通过认知任务让用户产生较强程度的思考，但这种思考只依赖用户已有的认知框架。比如说，呈现了一个关于fit这个单词的知识，说
“fit 是形容词时，当“健壮的、健康的”讲，通常用来形容人，尤其指经常锻炼、体能好的人，强调的是身体强健、有耐力，而不只是没有生病。”
然后给一个例句。
这个知识不难理解，但想要记住，不能只是让用户阅读起来理解，所以可以给用户一个不同于例句的含fit的句子，然后问用户，这个句子里的fit是不是这里的意思或者用得对不对。这样才能真正让用户主动思考。而换个语境和形式，就像是音乐中发展部的那些手法。
接下来，就是把正确的知识再现的环节，但就如音乐中的再现部不是简单地把呈示部再原样演一遍，app里也必须有所变化。具体来说，可以设计各种包含这个义项的语境，让用户在更多不同的场景和任务中反复接触。比如根据用户的兴趣生成一篇fit这个词反复出现的阅读文章，然后由AI带着做精读（精读也是一个高度流程化但又考验教师功底的事情），以及把这个词放在听力任务，口语任务里，让用户全方位熟悉这个词的这个用法。这样一遍下来，想记不住都难，而且会顺带积累许多取回记忆所需要的线索。这些线索本身可能也是另一些需要掌握的知识点，就这样以点带面地高效积累语言知识，而且是从识别到运用。
mini
80％的代码都是AI写的，公司为什么还需要你？
这个问题越来越高频
先说一个事实：2026 年的技术面试，已经和两年前完全不一样了。
两年前面试问的是："手写一个 Promise"、"说说 React Fiber 原理"、"浏览器渲染流程是什么"。
现在面试官默认你会用 AI。他们真正想知道的是：在 AI 能写代码的时代，你的不可替代性是什么？
我在技术社群里问了一圈，今年至少有三种问法：
"AI 能写 80% 的代码了，你的价值在哪？"
"如果我给你一个实习生 + Claude Code，能替代你吗？"
"你和 AI 的分工是什么？"
本质上是同一个问题。答不好，直接挂。
大多数人的回答，都踩了坑
我收集了一些常见回答，面试官听完基本都不满意：
❌ 回答一："AI 写的代码质量不行，还是需要人来写"
这个回答在 2024 年还行。2026 年不行了。
Claude Code 和 Codex 生成的代码质量已经相当高，大部分 CRUD 接口、表单组件、工具函数，AI 写得比很多初级开发者还好。你说"AI 代码质量不行"，面试官心里想的是：那是不是说明你的水平和 AI 差不多？
❌ 回答二："AI 不理解业务需求"
面试官会追问："那产品经理把需求写清楚，AI 不就能理解了？"
你会发现自己很难反驳。因为事实是——大部分需求确实可以用自然语言描述清楚，AI 确实能根据描述生成代码。
❌ 回答三："总需要有人来做 Code Review"
这个回答把自己定位成了"AI 的质检员"。面试官会想：质检员的工资不需要两万。
我后来怎么回答的
被问了四次之后，我想明白了一件事：这个问题考的不是你对 AI 的态度，而是你对自己价值的认知。
我现在的回答分三层：
第一层：AI 写的是代码，人做的是决策
"AI 能写 80% 的代码，但它写不了那 20% 的决策。"
举个具体的例子。上个月我们做一个电商活动页，需求是"用户下单后展示倒计时"。
AI 可以完美地写出一个倒计时组件。但它不会问你这些问题：
倒计时结束后，用户页面还停着怎么办？自动刷新还是弹窗提示？
如果用户修改本地时间，倒计时会不会被绕过？
高并发下，几万人同时倒计时归零，后端扛得住吗？前端要不要做请求排队？
这个倒计时需要和服务端时间同步吗？客户端时间不准怎么办？
这些问题，每一个都可能导致线上事故。AI 不会主动想到它们，因为 AI 只解决"你提出的问题"，不解决"你没想到的问题"。
高级开发者的价值不是写代码，是知道哪些代码不该写、哪些场景会出事、哪些决策会影响未来半年的维护成本。
第二层：AI 能写一个文件，人能设计一个系统
"AI 是一个极其优秀的执行者，但它没有系统视角。"
让 Claude Code 写一个用户注册接口，它能写得很好。但让它设计整个用户系统，它不知道：
注册和登录要不要拆成两个微服务？
用户数据怎么分库分表？按 user_id hash 还是按注册时间 range？
Session 用 JWT 还是 Redis？各有什么取舍？
未来要接第三方登录（微信、Google），现在的表结构要不要预留扩展字段？
这些是架构决策，需要结合业务规模、团队能力、技术栈现状、未来规划来综合判断。
AI 可以给你列出 5 种方案，但它不知道哪种方案适合你的公司。这个判断，只有人能做。
我面试时说了一句话，面试官听完点了头：
"AI 让写代码的门槛降低了，但让做正确决策的门槛提高了。因为现在代码生成太快了，做错了决策会比以前更快地变成一大堆技术债。"
第三层：AI 不能对结果负责
"出了线上事故，AI 不会被 oncall 叫起来。"
这一层听起来像玩笑，但它是最本质的。
代码部署到线上，半夜三点告警了。需要有人：
判断影响范围
决定要不要回滚
协调前端后端运维多方排查
在半小时内给出修复方案
事后写复盘报告，推动流程改进
这些事情，每一件都需要判断力、沟通能力、责任心。AI 可以帮你查日志、分析堆栈，但它做不了决策，扛不了责任。
公司花两万月薪招你，不是在买你写代码的时间，是在买你的判断力和责任心。
面试官真正想听到的
总结一下。这个问题的正确答案结构是：
层次 核心观点 一句话
执行层 AI 写代码，人做决策 AI 解决你提出的问题，但不会发现你没想到的问题
架构层 AI 写文件，人设计系统 AI 能列方案，但不知道哪个适合你的公司
责任层 AI 不能被叫起来修 bug 公司买的不是代码，是判断力和责任心
最后补一个加分动作：给一个真实案例。
不要泛泛而谈"AI 不行"。讲一个你亲身经历的场景：
"上个月 AI 帮我写了一个数据导出功能，跑得很好。但我 review 的时候发现它没有做分页——10 万条数据一次性加载，在测试环境没问题，到生产环境直接 OOM。这种问题 AI 不会意识到，因为它不知道你的生产数据量有多大。"
一个具体案例胜过十句正确的废话。
AI 时代前端的核心竞争力
如果你还在纠结"要不要学 AI"，这个问题本身就问错了。AI 是工具，不是竞争对手。
真正应该问的是：什么能力是 AI 越强，人越值钱的？
系统设计能力 — AI 生成代码越快，做错设计的成本越高
业务理解能力 — 理解需求背后的"为什么"，而不只是"做什么"
跨团队协作 — 协调前后端、产品、设计，这不是写代码能解决的
线上兜底能力 — 出了事能扛住、能查出来、能修好、能防住下次
这四项能力，AI 越强，越稀缺。
最后
下次面试再被问"AI 能写代码了你还有什么用"，不要慌。
这个问题不是在质疑你，而是在给你一个展示高阶思维的机会。能把这个问题答好的人，恰恰是 AI 时代最值钱的人。
你面试时被问过类似的问题吗？你是怎么回答的？评论区聊聊。
【test】最近看到很多人发帖说想转行AI
非常理解这种焦虑，但是我其实觉得AI很难说是一个“行当”。
这就好像我们有时候选择骑自行车出门，但没人会因此就说自己转行“自行车”。
而且我的体感是，AI给我带来的思维方式转变之一，就是AI让我不再把自己限定在某一个“行当”。自从有了AI，我其实一直在努力从前AI时代的第三产业社会分工系统里挣脱出来。都说“隔行如隔山”，这话在宏观上依旧成立，但在微观局部，有些山已经没有以前那么难跨越了。
我真的遇到过不会骑自行车，或者从小到大没坐过地铁不会坐地铁的人。我很诧异，直到我意识到每个人的成长环境决定了他们需要掌握的一套技能，即便是像骑车和坐地铁这般在我看来就如同空气和水一般可以看作在日常生活中理所应当存在的事情：对于从小就有司机接送的富贵人家来说，这两种交通工具确实不是必须会的。
AI也是如此。在我看来它就是一个能把我从某个愿望带向实现的工具。它存在的意义就是消解专业壁垒，让我有实现过去因为这些专业壁垒而无法实现的愿望的可能性。当然，仅仅是可能性，但打开的也已经是“让神流血”这种级别的可能性了。原本不可选中的巨大困难亮起了血条，那它无论看起来多么不可战胜，最终还是可以用主体性和韧性打败的。
那么最重要的问题就不再是要不要学AI，而是究竟有什么愿望想实现。其实无论有没有AI，这个问题都重要，只不过现在空前地重要了。就像有司机接送的人不会骑车一样，如果你没有愿望，没有需求，那么不会用AI也是符合常理的。如果有明确的愿景，那么AI就会变得和自行车、地铁一样被当作默认应该发挥作用的东西。要思考的仅仅是我要到哪里去，骑哪条路/坐几号线，而不是怎么骑车/如何坐地铁。