一篇关于「AI 大量代写代码之后，自己写代码的能力会弱化，所以要把学习重心上移到框架层」的实践记录。讲四件事：为什么该学的是框架层而不是细节 API、怎么系统学框架、怎么指挥 AI 搭出坚固的架子，以及底座扎实之后 AI 写业务为什么更稳。
一、承认一个不舒服的事实：写的手感会弱化
现在我的日常开发，大部分代码不是自己敲的，而是「需求 → 派卡 → AI 写 → 我来验收」。这个流程效率很高，但有一个副作用我观察了很久，也跟不少同行聊过：手写代码的能力，确实在钝化。
具体来说，弱化发生在三个地方：
- 语法和 API 的记忆在衰减。 以前闭着眼睛能写的 API，现在会习惯性去问 AI；不是不会，是”想不起来”，大脑的检索路径被”问一下就有答案”替代了。
- 调试直觉在变钝。 以前定位 bug 靠的是对代码的熟悉和手感，现在下意识就是”把报错丢给 AI”。定位问题的肌肉记忆，用进废退。
- 对代码的”所有权感”在下降。 不是我亲手写的代码，出了问题第一反应是”看看 AI 写的什么”，而不是”我哪写错了”。
但我要先说清楚：对抗这个趋势是徒劳的。 AI 写代码是回不去的方向，回到”全部手写”既不现实也没必要。所以真正的问题不是”怎么让写的能力不退化”，而是——
写的能力被 AI 分摊了，人的功夫应该重新分配——下到 AI 取代不了的地方。
那下到哪里？我的答案是：框架层。
二、答案不是细节 API，是「框架层」
先说清楚什么叫”框架层”。它不是指某个具体框架（SwiftUI、RxSwift 这种），而是指那些**”搭一次、用一年”的东西**：网络层、数据层、状态管理、模块化边界、生命周期、错误处理骨架，以及日志、错误码、监控、回滚这些基础设施。业务代码天天变，这些底座几乎不变。
为什么学习重心要上移到这一层？三个理由：
- 细节 API 是 AI 的主场，人学不过它。 某个 API 怎么调、参数是什么，AI 秒回，人背不过它。花时间记 API，是拿人的短处拼 AI 的长处，性价比最低。
- 框架决策，AI 做不了。 网络层怎么封装、数据流怎么走、模块怎么切，这些决策依赖你的业务现实、历史包袱、演进方向——AI 不拥有这些，它只能生成”看起来合理”的方案。框架怎么定，必须人来定。
- 框架是杠杆最大的一层。 改一行框架代码，影响所有业务；框架决策错了，AI 写的所有业务都要返工。功夫下在这一层，收益最大。
一句话：AI 负责写业务，人负责把业务脚下的底座搭好。底座不牢，AI 写再多业务也是沙上建塔。
三、学框架要「系统」，不能零散
“学框架”最大的坑是零散学：收藏一堆 API 清单、抄一份别人的架构图、看一堆碎片文章——学完还是不知道自己的项目该怎么搭。
系统学的标准是：能画出框架的完整地图。 分层有哪些、依赖往哪个方向流、数据怎么走、生命周期怎么管理、扩展点留在哪里，以及每一个设计决策的”为什么”。
怎么系统学？我有一套四层读法，专门用来”读框架”而不是”看代码”：
| 层次 | 状态 | 一句话判据 | 达不到的代价 |
|---|---|---|---|
| L1 语法层 | 看得懂 | 能说出每一行在做什么 | 只能看懂，不会用 |
| L2 语义层 | 知道它在做什么 | 能画出它的数据流、状态、谁持有谁 | 一改就崩 |
| L3 意图层 | 知道为什么这么设计 | 能说出设计动机、权衡、踩过的坑 | 只会抄，不会裁 |
| L4 批判层 | 知道哪里能更好 | 能指出复杂度、耦合、隐患 | 被烂框架拖着走 |
举个例子，iOS 里一行 [weak self]：L1 知道它是弱引用；L2 知道如果不写，闭包持有 self 会形成循环引用、对象释放不掉；L3 知道这是团队踩过内存泄漏的坑之后立下的规矩，所以”看到有闭包的地方就条件反射检查 self”；L4 会进一步想——这里到底需不需要持有 self，能不能干脆用值捕获，从根上避免这个问题。
系统学的关键：每学一个框架，都要追问到”为什么”这一层。 为什么这么分层？为什么依赖往这边流？为什么留这个扩展点？把”为什么”问透，框架地图才画得出来。而 AI 写的代码天然缺这一层——它没有”意图”，不知道这个项目为什么这么设计。这个空缺，正好是需要人来补的。
四、懂了框架，才知道怎么指挥 AI 搭架子
学框架不是为了自己重写一遍，是为了能指挥 AI 搭出坚固的架子。你心里有框架地图，才能给 AI 下对的指令。
我每次派卡，都会把框架约束写死在卡里：分层、接口、数据流、状态机、错误处理约定、业务边界、基础设施。AI 的自由度只留给实现细节——它在格子间里干活，不会把墙拆了。
那怎么知道 AI 搭的架子坚不坚固？AI 搭架子有四个典型毛病（都是踩过的）：
- 没有业务约束锚点。 它不知道”金额不能为负””状态不能回跳””这个接口必须幂等”。架构通用、漂亮、没有灵魂，约束全靠实现阶段临时找补——找补出来的，就是一个个隐蔽 bug。
- 抽象位置错。 它优化的是”代码美感”（比如 DRY），不是”业务边界”。该收敛的重复逻辑散落各处，不该统一的硬统一成一套，改一处牵动全身。
- 只设计当下，不设计演进。 它没见过这个系统三个月后长什么样。所以要么没留变化点（加需求就伤筋动骨），要么留了一堆用不上的扩展点（过度设计，架子比内容还重）。
- 基础设施缺席。 AI 默认世界是干净的：日志、错误码、监控、回滚、权限、幂等，它一概不主动建。没有这些，架子就是空的——本地能跑，一上线就塌。
校验方法就一句话：拿业务约束逐条审它的设计。 它没提幂等？没画状态机边界？没设计失败路径？三条审下来，架子牢不牢就清楚了。
五、底座扎实，AI 写业务才稳
把底座搭好，收益在”AI 写业务”这一步兑现：约束清晰、边界明确、基础设施齐备，AI 的自由度就小，出错面就小，写出来的业务就稳、返工就少。
反过来就是最坑的情况：没有底座，AI 写的业务代码就是”看起来是房子”的空架子——架构图很漂亮，跑起来就塌。这不是 AI 的错，是架子没搭。
所以我对 AI 时代工程师的理解是：AI 负责写业务，人负责搭底座。 底座不是搭给代码看的，是搭给 AI 用的——架子越坚固，AI 的自由度越小，产出越可靠。
顺带回应一个细节：前面说”不用了解细节 API”——我的准确表述是不用背 API，但要知道去哪里查、怎么验证。读代码读到 L2 时，某个 API 的语义边界（线程安全吗？释放资源吗？）决定了你能不能判断对错，这时候”查证能力”比”记忆能力”值钱。
六、一套每天可以练的清单
光知道”该学框架层”没用，得落到日常。我的做法是下面几条，按优先级排：
- 给自己项目画框架地图。 一张图画清楚：分层、依赖方向、数据流、生命周期、扩展点。画不出来的地方，就是你的知识漏洞——去补它。这是最重要的一条。
- 每周系统读一条框架链路。 挑一个框架（或你项目的一个底座模块），从入口读到出口，用四层读法，读到能说出”为什么这么设计”为止。
- 逆向猜实现。 拿到框架接口，先不看实现，自己猜它内部怎么写的、会踩什么坑，再打开源码对答案。猜错的地方，就是你理解体系的漏洞。
- Feynman 输出。 把读懂的一个框架决策讲给 AI 听（或者写成两三句话），讲到它挑不出毛病，才算真懂。讲不出来的地方，就是没读透的地方。
- 把”指挥 AI 搭架子”当日常练习。 每次派卡都写清框架约束；每次验收都拿四病过一遍：约束锚点？抽象位置？演进设计？基础设施？
- 每天 30 分钟读陌生代码，写三句话。 读完写下：它在做什么 / 为什么这么写 / 哪里可以更好。这是底座知识的日常积累，有产出才叫读。
- 读你项目里最老、最绕的那段代码。 它是你项目的”考古现场”，藏着最多的历史决策和踩坑记录，读它比读任何教科书都值。
七、写在最后
写这篇不是劝你别用 AI——恰恰相反，AI 是我现在效率的来源。我想说的是学习重心的转移：
AI 写业务会越来越快，人的功夫要下在业务脚下的底座上。系统学框架，指挥 AI 搭出坚固的架子，AI 写业务才扎实。
之前写过一篇《AI 时代，比开发经验更重要的三件事》，讲细心、负责、钻研。这篇算是续篇，把”功夫具体下在哪”说清楚了：框架层。用 AI 的快，补自己的慢；用底座的稳，托住业务的快。
大概率会继续在实践中更新这套练法，欢迎拍砖。
你怎么看待 AI 时代的”框架层”学习？欢迎留言讨论。