AI 平权 04|代码都是 AI 写的,我怎么确保自己没有失去控制?

代码越来越多都是 AI 写的以后，我怎么确保自己没有变成整个项目里最不懂代码的人？

这个问题我觉得比“哪个模型写代码最强”重要得多。

Vibe Coding 最爽的地方是什么？

你说：

给这里加一个导出功能。

AI 开始读代码。

改文件。

跑测试。

修 Bug。

十分钟以后：

已完成。

你打开网页一看。

确实能用了。

于是：

Commit。

下一个需求。

再过一个星期：

登录是 AI 写的。

数据库迁移是 AI 写的。

权限系统是 AI 写的。

缓存是 AI 写的。

部署脚本也是 AI 写的。

项目功能越来越丰富。

而你对项目的理解可能停留在：

反正它现在能跑。

这时候就出现了一个非常有意思的问题。

项目是你的。

需求是你提的。

钱也是你付的。

最后：

只有 AI 知道它是怎么工作的。

我觉得这才是 Vibe Coding 目前一个非常容易被忽略的风险。

一、AI 时代可能出现一种新的技术债：理解债

以前程序员经常说：

技术债。

代码先凑合写。

以后再重构。

测试先不补。

以后再补。

架构先这么搞。

以后再改。

债越欠越多。

Vibe Coding 以后，我觉得可能又多了一种东西：

理解债。

今天 AI 帮你做一个功能。

你看：

能跑。

于是过了。

明天又做一个。

还是：

能跑。

又过了。

每一次你都欠下一点：

这东西到底是怎么实现的？

刚开始完全没问题。

但是项目越来越大以后，这个债会慢慢积累。

最后可能出现一种非常奇怪的情况。

你知道产品有哪些功能。

你知道自己想做什么。

但是你不知道：

数据从哪里进。

经过了哪些模块。

为什么用了这个方案。

哪些地方最危险。

出了问题应该先看哪里。

甚至 AI 问你：

这个项目当前的认证流程是什么？

你：

你问我？

二、“我会不会写这段代码”已经不是最重要的问题了

这里先说一个我自己的观点。

我并不觉得 Vibe Coding 以后，每个人都必须重新去学：

变量。

循环。

设计模式。

数据结构。

然后直到能够自己从头写完整个项目，才“配”使用 AI。

那样其实又回去了。

如果 AI 能帮我们完成大量编码工作，当然应该用。

真正需要掌握的，不再一定是：

这 200 行代码我能不能一行一行手写出来？

而是：

我知不知道它为什么存在？

我知不知道它大概怎么工作？

我有没有办法验证它真的工作？

如果它坏了，我知不知道应该从哪里开始查？

我越来越觉得：

“拥有一个项目”和“亲手写下项目里的每一行代码”不是一回事。

真正的拥有感来自：

你能解释它。

你能判断它。

你能维护它。

三、所以我现在会给重要功能加一道“理解 Gate”

上一篇我们讲了：

代码写完以后，可以让 AI 开启：

对抗式审查。

想办法证明自己的实现会失败。

但通过 Review，还只是证明：

代码大概率没问题。

它没有证明：

你理解这段代码。

所以对于一些比较重要的改动，我现在很喜欢再加一道步骤：

让 AI 反过来教我。

Prompt 可以这样写：

这个功能已经完成。

在合并之前，我需要真正理解这次修改，而不是只知道“测试通过了”。

请严格基于本次 git diff、实际代码和已经执行的测试，为我生成一份 HTML 学习报告。

不要泛泛介绍项目，也不要把没有验证过的推测写成事实。

报告需要让我理解：

1. 这次解决了什么业务问题，用户实际看到什么变化；
2. 修改了哪些核心模块，以及这些模块之间是怎么连接的；
3. 关键的数据、请求或状态是怎么流转的；
4. 为什么选择当前实现，还有哪些合理的替代方案；
5. 当前实现最容易出问题的地方在哪里；
6. 已经通过什么测试验证，还有什么没有覆盖；
7. 如果这个功能明天突然坏了，我应该按照什么顺序排查；
8. 挑出真正值得我理解的关键代码进行解释，不需要逐行解释所有 diff。

对涉及代码事实的结论，请尽量指出对应文件或代码位置。

如果某个结论只是推测，请明确标记为“推测”，不要伪装成已经验证的事实。

然后：

让它给我上课。

四、然后让 AI 考我

这一步是我觉得特别好玩的。

报告最下面：

根据这次修改真正需要理解的原理，给我出 5 道单选题。

不要考变量名、文件名、函数名等死记硬背内容。

重点考：

• 为什么这样设计
• 数据怎么流转
• 哪些边界条件最重要
• 某个模块出问题会产生什么后果
• 为什么没有采用另一种方案

暂时不要给答案。

我回答以后再批改，并针对答错的内容重新解释。

我甚至可以给自己定一个非常幼稚但有效的规则：

5 道全部答对，才允许自己 Merge。

当然，这不是什么真正意义上的安全机制。

AI 出的题本身也可能有问题。

所以：

答对 5 道题 ≠ 代码绝对安全。

它只是一个：

“我真的理解了吗？”

的检查点。

但是这个检查点非常有用。

因为“我看懂了”这个东西特别容易产生错觉。

一份两千字的技术报告：

你从头看到尾。

不断点头。

嗯。

嗯。

原来如此。

我懂了。

然后把报告关掉。

五分钟以后：

什么都说不出来。

一考试：

立刻暴露。

五、比考试更有效的一步：你反过来讲给 AI 听

如果这个功能真的很重要，我还会再多做一步。

我会自己总结：

我现在对这个功能的理解是：

用户点击 XXX 后，请求先到 A，然后经过 B 做权限检查，再由 C 写入数据库。

这里选择 XXX 而没有选择 YYY，是因为……

最容易出问题的地方应该是……

如果线上出现 XXX，我第一步应该检查……

请严格根据当前代码检查我的理解。

哪些地方正确？

哪些地方不完整？

哪些地方是错误的？

不要因为我的描述听起来合理就默认同意我。

这个步骤其实就是学习里非常经典的一件事：

你能不能把它讲出来。

AI 写。

AI 再解释。

你一直只是：

接收者。

但当你开始尝试：

重新描述整个系统。

很多之前模模糊糊的东西，会立刻暴露出来。

我觉得这时候 AI 最好的角色反而不是程序员。

而是：

一个随时可以纠正你的老师。

六、Merge 以前，我至少想回答三个问题

现在对一个 AI 完成的重要功能，我不要求自己能默写代码。

但我希望自己至少能说清三件事。

第一：它到底改了什么？

不是：

加了个登录。

而是：

用户登录以后，身份从哪里验证，状态保存在哪里，后续请求怎么知道这个用户已经登录。

第二：为什么要这样改？

不是：

AI 这么写的。

而是：

这个实现利用了项目已经存在的认证机制，没有额外引入一套状态管理，所以改动更小。

第三：如果它坏了，我先去哪看？

这是我最看重的。

因为只要你知道：

请求从哪里进。

最关键的状态在哪里。

哪几个模块连接在一起。

日志和测试在哪里。

你就没有完全失去项目。

哪怕真正修 Bug 的还是 AI。

你也知道：

它现在正在修什么。

七、但还有一个更麻烦的问题：下一个会话又忘了

前面解决的是：

人怎么理解 AI 写的代码。

接下来还有另一半。

AI 怎么记住我们已经学到的东西。

这个问题其实上一篇 Trellis 已经提过。

一个项目真正重要的信息，不应该只活在聊天窗口里。

比如：

我们曾经试过方案 A。

失败了。

为什么失败？

最后正确方案是什么？

以后遇到相似问题应该先检查哪里？

这个项目有哪些特殊限制？

我明确讨厌什么 UI 风格？

哪些东西我已经强调三遍了？

如果这些东西永远只存在：

2026 年 7 月 18 日的某个聊天窗口第 83 条消息。

那实际上和没记住差不多。

所以我现在越来越喜欢另外一个思路：

让项目自己携带经验。

八、一次比较重要的开发结束以后，让 AI 做一次项目复盘

比如一个复杂功能终于做完。

中间：

试错了三次。

踩了两个坑。

发现了一个项目里很奇怪的历史设计。

你还纠正了 AI 两次。

这时候不要：

好了，下一项。

可以直接让它：

对本次任务进行一次项目级复盘。

只使用你当前实际能够访问的材料，例如：

当前会话、可访问的历史会话、执行日志、Git 历史、代码 diff、项目文档和测试结果。

如果某类材料无法访问，请明确说明，不要假装已经读取。

重点提炼三类信息：

执行经验：
哪些方案尝试过但失败了？为什么失败？最终正确做法是什么？以后遇到类似问题应该优先检查什么？

稳定偏好：
从现有证据中总结我反复表现出来的 UI、产品、交互、代码复杂度和技术选型偏好。

一次性的临时要求不要自动推断成长期偏好。

可执行规则：
把真正值得长期保留的经验改写成 Agent 下一次可以直接遵守的行为规则。

不要记录无意义的过程流水账，也不要把整段聊天原样保存。

这里我觉得有一句特别重要：

不要记录故事。

记录：

规律。

九、什么叫“记录故事”，什么叫“留下规律”？

比如：

2026 年 8 月 15 日，用户让我增加一个日期组件，第一次使用了 flatpickr，后来发现用户不喜欢，于是删除……

这个东西以后有什么用？

基本没有。

它只是在记日记。

真正值得留下的是：

新增第三方依赖以前，优先检查浏览器原生能力、标准库和项目已有依赖能否满足需求。

这才是规则。

再比如：

用户上次说这个卡片不好看。

没什么价值。

应该提炼成：

UI 默认避免为了装饰而大量使用独立卡片；优先通过排版、间距和层级建立信息结构。

再比如：

上一次修 Bug 的时候改了 14 个文件，最后发现真正的问题只有一个状态判断。

应该变成：

修复 Bug 时优先寻找最小根因；没有明确必要时，不重构与问题无关的模块。

这就是我理解的：

把经验变成资产。

十、但是千万不要把所有东西都塞进一个“超级 Prompt”

这里又会出现另一个经典问题。

发现项目需要记忆以后：

好！

那我们把所有历史经验全部写进 AGENTS.md！

然后：

AGENTS.md：

两万字。

每次 AI 打开项目：

先读一本《资治通鉴》。

这显然又走向了另一个极端。

我更喜欢把知识分层。

大概类似：

AGENTS.md│├── 真正每一次任务都必须遵守的规则├── 最重要的开发和验证方式└── 指向更详细的项目知识    │    └── docs/        ├── development-lessons.md        ├── product-principles.md        ├── ui-guidelines.md        └── architecture-notes.md

也就是说：

最重要的规则放门口。

更详细的经验放里面。

做 UI：

去读 UI Guidelines。

改数据库：

去看 Architecture Notes。

遇到历史坑：

去查 Development Lessons。

而不是每次：

我要改一个按钮颜色。

AI：

好的，请允许我先阅读公司发展史。

十一、而且“长期记忆”必须允许遗忘

这一点我觉得特别重要。

AI 特别容易把：

你说过一次的话。

理解成：

你一生的信仰。

比如某一次为了赶时间你说：

先别写测试。

AI 复盘：

用户偏好不写测试。

完蛋。

所以当 AI 总结偏好和规则的时候，我会特别要求：

只有具有重复证据、明确长期价值、未来仍然可能影响决策的信息，才应该升级为长期规则。

单次任务约束、临时妥协、特殊场景决定，不要自动升级为永久偏好。

如果无法判断它是不是长期规则，就先记录在任务复盘里，不要进入全局规则。

记忆的价值从来不是：

记得越多越好。

而是：

以后需要的时候，能拿到正确的东西。

十二、整套流程合起来，其实就是一个闭环

如果把我现在比较理想的 Vibe Coding 工作流画出来，大概是：

提出需求   ↓AI 规划   ↓AI 实现   ↓运行测试   ↓对抗式审查   ↓AI 根据 diff 给我讲明白   ↓我答题 / 反向讲解   ↓确认自己理解关键路径   ↓Merge   ↓项目复盘   ↓提炼可复用规则   ↓写回项目知识   ↓下一次 AI 自动继承

注意这里最大的变化。

以前我们的循环是：

Prompt↓代码↓下一个 Prompt

现在变成：

Prompt↓代码↓验证↓理解↓沉淀↓下一次做得更好

我觉得这才是一个项目真正开始：

越做越聪明。

而不是：

越做越大。

十三、完全不会编程的人，真的需要理解这么多吗？

我觉得：

需要。

但不是你想象的那种需要。

你不一定要知道：

某一行 TypeScript 为什么要这样写。

某个泛型到底怎么推导。

这个 React Hook 底层究竟发生了什么。

AI 完全可以帮你处理大量实现细节。

但是至少你应该逐渐知道：

业务层：

这个功能为什么存在？

系统层：

它大概经过哪些东西？

风险层：

什么地方坏掉的代价最大？

验证层：

我们为什么相信它现在是对的？

如果这四件事你都不知道：

那你拥有的可能不是一个项目。

更像是：

一个暂时还在正常工作的黑盒。

十四、最危险的不是 AI 犯错，而是你已经失去了判断它有没有犯错的能力

AI 写错代码：

其实没那么可怕。

测试能发现一部分。

Review 能发现一部分。

用户也可能发现。

真正让我觉得危险的是另外一种状态：

AI：

已解决。

你：

好。

AI：

这是最佳方案。

你：

好。

AI：

需要新增这 6 个依赖。

你：

好。

AI：

我重构了整个模块。

你：

好。

到最后：

你已经没有任何能力判断：

“这个方案合理吗？”

这才是真正意义上的失控。

所以所谓“保持控制”，不是：

每一行都必须我自己写。

而是：

我永远保留理解、质疑和验证的能力。

十五、我现在对 Vibe Coding 的理解也在发生变化

刚开始：

AI 帮我写代码。

后来：

AI 帮我完成项目。

再后来我觉得：

都不太准确。

更像是：

我负责定义方向、做判断和承担结果，AI 负责完成大量具体工作。

AI 可以写得比我快。

可以知道比我多。

甚至在很多技术问题上判断比我准确。

这都没关系。

但最终有几样东西应该一直留在人手里：

为什么要做。

什么才算完成。

哪些风险可以接受。

结果到底值不值得相信。

以及：

这个项目最终要变成什么。

写在最后

我觉得 Vibe Coding 很容易让人产生两个极端。

一个极端是：

AI 写的东西我不信，我还是全部自己来。

那其实浪费了 AI 最大的价值。

另一个极端是：

我什么都不需要懂，反正 AI 会。

我觉得这同样危险。

我现在更喜欢中间这一条路：

代码可以让 AI 写。

但理解不能完全外包。

重复劳动可以交给 AI。

但判断不能完全外包。

历史经验可以让 AI 帮你记录。

但什么值得成为长期规则，最终还得由你决定。

以前学习编程，我们追求的是：

我能不能自己把它写出来？

到了 Vibe Coding 时代，可能还要增加一个新的能力：

别人——甚至 AI——把它写出来以后，我有没有能力真正拥有它？

我觉得这才是“AI 平权”真正有意思的下一步。

不是让普通人拥有越来越多自己看不懂的代码。

而是：

让以前没有能力做软件的人，也逐渐拥有理解、判断和掌控软件的能力。

如果你也正在用 AI 做越来越大的项目，可以关注这个系列。

我会继续把自己真正使用 ChatGPT、Claude Code、Codex 和各种 Agent 时留下来的工作流、踩坑和有效方法慢慢整理下来。

不是为了让所有人重新成为程序员。

而是为了：

用了 AI 以后，我们能做的事情越来越多，同时仍然知道自己到底在做什么。