过去三周，我深度使用 AI 编程做真实项目开发，原本以为至少能把项目提前三四天做完，最后却并没有。真正吞掉时间的，不是写代码，而是审代码、审方案、纠偏理解、补回归和补边界。走到这一步我才意识到，AI 先放大的，不只是产能，还会带来新的理解债务。
这个月的项目开发，原定 3 月 25 日截止。
我一开始的预期其实很明确。
既然已经在深度使用 AI 编程，而且这三周里它确实承担了大量真实工作，那这个周期按理说应该能被压缩出来一点，别说一周，至少提前三四天把 功能 和 UI 页面开发做完，我当时觉得是很正常的判断。
因为从表面上看，AI真的很强。
这段时间里，我做了 30 个 UI页面。
简单页面，AI 基本可以一把过，复杂一点的页面，它也常常能先做出七八成，剩下的再继续调。
你很容易在这个阶段形成一个直觉：
既然生成速度已经这么快了，项目结束时间也应该跟着提前。
但真实结果不是这样。
最后并没有提前，时间就是刚刚好，不多不少。
也就是说，AI 没有直接帮我把项目周期挤出来。
我这周末认真复盘总结后发现，真正吞掉时间的，并不是写代码本身，而是另外一堆以前没有这么显性的工作：
- 审 AI 写的代码
- 审 AI 给的实现方案
- 确认它有没有理解偏
- 确认它有没有过度修改
- 确认它有没有顺手改到旧逻辑
- 补每轮改动后的检查清单
- 补不改动的范围
- 补交接和状态
而且这个过程，不是偶尔发生一次，是一页一页、一轮一轮地重复发生。
所以我慢慢确定，问题根本不在于“AI 写得够不够快”，而在于另一件事：
AI 先放大的，不是产能，而是理解债务。
1. AI 自动化得最快的，其实不是交付，而是生成
如果只看表面现象，AI 的确像一个更强的编码器。
你给它设计稿、给它需求、给它页面结构，它能很快吐出一版代码实现。
很多以前要自己搭半天的页面，现在它先铺出来，速度确实是肉眼可见地上去了。
但项目开发真正变多的地方，不会只停在生成这一段。
真实工作里，后面还有很多同样重要、却没有同步被自动化掉的环节：
- 这段代码到底有没有理解错误
- 它和旧页面、旧组件怎么接
- 它有没有过度修改
- 它有没有顺手把原来的边界带坏
- 现在功能看起来是对的，以后改的时候会不会不好维护
也就是说，AI 优先自动化的，是“先给你一个结果”。
可项目交付真正难的，很多时候不是“有没有结果”，而是：
这个结果我敢不敢接，能不能接，后面还能不能自己继续改。
所以你最后的工作并没有变少，它只是被重新分配了。
以前可能更多是：
- 自己想
- 自己写
- 自己改
现在慢慢变成：
- 先让 AI 想
- 先让 AI 写
- 再由你来判断它想得对不对
- 再由你来判断它写得对不对
- 最后还是由你来承担后续维护和出事后的责任
这也是为什么很多人会有一种很矛盾的感觉：
明明东西做得更快了，但人并没有更轻松。
因为真正先变多的，往往不是产出，而是后面的检查和确认。
这两个月我又连续看到几组很新的公开材料，和我的感受几乎是一致的。
一组是 METR 在 2025 年 7 月发的研究。他们找的是熟悉自己代码仓库的资深开源开发者，参与者主观上觉得，AI 应该能让自己更快，但最后客观结果反而慢了19%，那真正被拉长的原因，不只是写代码那一段，而是提示、等待、审查和清理输出这些环节。
另一组是 2026 年 2 月连续出来的两篇内容。Siddhant Khare 写了一篇很有代表性的文章，里面有一句话我印象很深：用了 AI 之后，工程师很容易从“创建者”慢慢变成“审查员”。几乎同一时间，HBR 也发了一篇研究文章，结论也差不多：AI 不一定先减少工作，很多时候反而会把工作节奏推得更快、范围拉得更宽、一天里的工作时间拖得更长。
所以后来我越来越觉得，这件事不是我这三周用 AI 编程时的偶发感受，而是一个正在变得越来越普遍的结构性问题。
2. 我后来发现，我最怕的不是代码质量，而是自己没真正看懂
一开始我也以为，我最担心的是代码质量。
但后来我发现，不完全是。
因为在我这种工作流里，AI 产出的代码质量，至少在很多 UI 页面和中小任务上，并不差。
尤其是项目里已经有不少记忆文档、协作文档、边界约束和当前任务文档以后，它写出来的东西很多时候不是不能用，反而经常是“看起来已经差不多了”。
真正让我不踏实的，是另一件事。
就是这段代码功能能跑，页面也对，交互也大体跑通了，可我自己没有真正把它转化成自己的理解。
这才是最麻烦的。
因为这类风险不会像明显的 bug 一样立刻炸出来。
今天看起来没问题，今天这轮需求也能交付。
但如果两周以后，这段代码又轮到你来维护，你发现自己其实并没有真正看懂：
- 它为什么这么写
- 它和旧逻辑怎么接
- 它最容易坏在哪里
- 下次继续改第一步该改哪里
那这段代码就会开始“反噬”你。
所以我后来更愿意把这个问题定义成：
不是代码质量债务，而是理解债务。
这类债务最危险的地方在于，它不会阻止你当下交付，它只会让你在以后的维护里越来越没底。
3. 这类理解债务，为什么在 AI 编程里特别容易长出来
我后来反复想，问题到底是怎么长出来的。
最后我发现，关键不是 AI 太强，也不是我用得太多，而是我的默认工作流本身就容易把我推到一个位置上：
AI 先开始想，我再去审。
过去这三周，我很常见的方式是：
- 先把问题和需求给 AI
- 让它仔细分析，先出详细方案
- 我确认大方向没问题以后，再让它开始改代码或者写代码
这套方式当然有效率上的好处。
但它会带来一个很隐蔽的副作用：
你会慢慢从“第一建模者”，变成“高级审查员”。
这时候最容易退化的，不是手速，而是代码判断直觉。
比如：
- 看到一段实现时，能不能很快感觉出哪里不对
- 能不能预判这段代码以后最容易坏在哪里
- 能不能在没有现成答案的情况下，自己先把问题拆开
这些能力，平时很少会被单独拿出来说，但一旦它们开始变弱，你会非常快地感受到那种不踏实。
我自己这几周就已经开始明显碰到这种感觉了。
不是说 AI 已经把我架空了，而是如果我不主动把边界重新拿回来，这条路确实会把我慢慢推向一个状态：
- 越来越多的代码是 AI 先给的
- 自己先独立搭建代码框架的时间越来越少
- 最后只剩下表面验收和责任兜底
这才是我真正后怕的地方。
4. 真正的解法，不是少用 AI，而是给 AI 产出加一道“接管门”
我这几天反复想，最后确定了一件事：
问题不是要不要少用 AI。
因为对于真实项目开发来说，AI 带来的产能提升是客观存在的。
它能帮你更快搭页面，更快出第一版，更快把很多体力活往前推。
真正需要重新定义的，不是“用不用”，而是：
生成之后，到底怎么算完成。
我后来给自己压出了一条很简单，但我觉得非常重要的规则：
我不能解释清楚并继续改下去的代码，不合并。
这句话看起来很朴素，但它其实是在保护一件更重要的东西：
不是保护代码格式，不是保护过程感，而是保护你的理解权和维护权。
我后来把这条规则又拆成了一个更容易执行的检查口。
对于高维护风险页面，功能验证通过以后，不是立刻合并，而是还要过一层“接管门”。
至少要能回答这三个问题：
- 如果下次还要继续改，我第一步会改哪里？
- 这段代码最容易改坏哪里？
- 它和旧逻辑到底是怎么接起来的？
如果这三件事答不出来，那就说明这轮代码还没有真正进入我的掌控范围。
这时候问题就不再是“功能是不是已经对了”，而是：
这段代码现在到底是不是已经变成了我的代码。
我后来慢慢看清，这个问题比“代码能不能跑”更重要。
因为很多时候，真正会把人慢慢架空的，不是一个明显的错误结果，而是一种熟悉感的错觉：
- 文件我都看过了
- AI 解释得也很顺
- 页面也跑起来了
但真到下次要继续改的时候，你还是发虚。
那就说明你拥有的只是熟悉感，不是维护权。
5. 我现在更愿意让 AI 交“维护说明书”，而不是只交代码
我后来还想明白了一件事。
以前最容易本能追求的是：
- AI 先给方案
- AI 先写代码
- AI 再解释一遍
- 最后我点头确认
但这条路其实有个很大的问题。
它很容易让你得到一份更流畅的自证，而不是真正更强的理解。
所以我现在更认同的方向是：
AI 当然可以继续负责产能，但它不能只交代码，还得交一份让我能接手的“维护说明书”。
这份说明书至少要回答四件事：
- 这轮到底只改了什么，明确没改什么
- 主入口和主要状态流在哪里
- 和旧逻辑的连接点在哪里
- 最容易改坏的三个地方是什么
这样做的目的，不是多一份文档感，而是把 AI 生成出来的复杂度，压缩成我自己可以继续维护的视图。
我现在更愿意把力气补在这里，而不是继续追求“怎么让 AI 再多写一点”：
怎么把它已经写出来的东西，重新组织成我能维护的样子。
6. 所以以后更值钱的，不只是写得快，而是判断得准、维护得住、最后能收拢
我现在再回头看这三周，已经不会把它理解成一次单纯的“AI 效率实验”了。
它更像是在提醒我：
AI 时代，真正值得保住的，不是你到底手写了多少行代码，而是下面这些东西是不是还牢牢在你手里：
- 问题是谁先定义的
- 边界是谁先钉死的
- 风险是谁在预判
- 结果是谁真正接管的
只要这些还在你手里，你就没有被架空。
你只是把一部分执行工作交给了更强的AI。
但如果这些东西慢慢都转移给 AI，那就算你每天还坐在电脑前工作，最后也可能只剩下表面验收。
这也是为什么我现在会觉得，AI 真正带来的，除了效率红利，也会有新的债务。
包括：
- 审核债务
- 理解债务
- 回归债务
- 维护债务
但反过来讲，这件事也没有那么悲观。
因为一旦你意识到问题真正长在这里，解法就不会再是两个极端：
- 要么完全依赖 AI
- 要么完全拒绝 AI
更成熟的方向反而是：
继续用 AI，但重新拿回节奏、边界和最终判断。
让 AI 负责产能，让人保住理解权。
7. 我现在对这件事最核心的判断
我现在对这三周最核心的判断是：
AI 编程真正吞掉时间的，往往不是生成，而是你有没有把生成结果真正转化成自己的理解。
所以以后真正要防的，不只是代码写错，而是理解债务悄悄堆起来。
这也是为什么我现在更确信，一个程序员在 AI 时代更值钱的部分，已经不只是“写得快”。
更值钱的是：
- 你能不能更早看出哪里有风险
- 你能不能把边界钉住
- 你能不能把 AI 的结果变成自己真正能维护的代码
- 你能不能把项目收得住
这几件事一旦保住，AI 才可能不只是更快，也是真的更稳。
但如果这几件事不保，AI 给你的就不只是产能，也会留下理解债务。
