AI 写的代码你看不懂,敢上线吗?

这里想想Apple 把 Virtualization Framework 封装得很彻底,你不需要懂 Hypervisor、不懂 virtio,也能做出一个能跑的虚拟机。代价是,等你想往下追问"为什么慢"的时候,下面那几层你一层都不熟。

类似的情况最近碰到不止一次了。做别的项目,也会走到同一个节点:AI 懂的比我多,但上线的按钮在我手里,出了问题也是我负责。那这个按钮凭什么按?我想起了这个图。

这个时代，我相信不是我一个人有这个感觉。Clutch 在 2025 年调查了 800 名软件从业者,59% 的开发者承认在用自己没完全搞懂的 AI 代码。围绕这件事,大概有两种态度。

一种是不懂就不上线。有人把这比作签一份没读过的合同,出事时责任还是你的。还有一个更具体的检验办法:删掉一行代码,如果你无法预测会发生什么,就说明你不懂这段代码,不该合并。

另一种态度是,"懂"这个要求本来就有弹性。你没读过 React 协调算法的源码,也没研究过 TCP 重传的实现,软件开发一直建立在一堆你不懂的抽象上,AI 只是又加了一层。我用 Virtualization Framework 就是这样,苹果把 Hypervisor 藏起来,我从没觉得有问题。直到有了性能问题。

这两种说法各有道理,但都不能直接拿来用。第一种在 agent 时代成本太高——如果每行都要看懂,很多时候自己写更快;第二种忽略了一个区别:框架的抽象层有人背书,AI 生成的代码没有。

几个值得读的观点

这个话题上,有几个人的文章值得认真看。

vibe coding 这个词是 Andrej Karpathy 在 2025 年 2 月提出来的,原话是"完全交给感觉,拥抱指数增长,忘记代码的存在"。这条推特火了之后,很多人把所有 AI 辅助编程都叫 vibe coding。

Simon Willison(Django 联合作者)不同意这种用法。他的划分是:如果 LLM 写了你的每一行代码,但你 review 了、测试了、理解了,那不叫 vibe coding,那是把 LLM 当打字助手。他给自己定的规矩是不提交任何自己无法解释的代码。后来他又写了一篇讲 vibe engineering,列了用 agent 做生产开发时工程师实际在干的事:研究方案、定架构、写规范、定义成功标准、管理 agent、做 code review。这个清单里没有"逐行看懂实现",但有"定义成功标准"。

Martin Fowler 走的是工具路线。他提出 harness engineering:既然人看不过来 agent 的每一步,就在 agent 周围搭一圈自动化的"传感器"——linter、依赖规则、变异测试、架构适应度检查,再用另一个 LLM 做语义层面的评审。他自己实验下来的结论是,这些东西确实能提高对产出的信心,但没法把人完全移出循环,而且他提醒,指标全绿也可能只是一种虚假的安全感。

Armin Ronacher(Flask 作者)关注的是另一个层面。他在《The Tower Keeps Rising》里说,agent 让每个工程师都能并行大量产出,绕过了过去靠 PR、评审、接口讨论维持的团队共识。以前"没人知道某个子系统为什么存在"是代码库出问题的信号,现在它正在变成常态。

这几个人立场不完全一样,但有个共同点:都没有要求逐行看懂,也都没有放弃人的审查,而是把审查的对象从实现细节挪到了别的地方——意图、标准、护栏。

我现在的做法

回到我的问题:面对一堆看不懂的 VirGL 术语,怎么决定要不要继续、要不要合并。目前我按三条来。

第一条,实现可以不懂,意图必须懂。我不懂 EGL 注入的细节,但我要能用自己的话说出:它在解决什么问题,为什么走这条路,还有什么别的路没走。说不出来就问 AI,问到能说出来为止。问的时候尽量不顺着它的讲解听,而是反问:不这么做会怎样?这个方案最可能在哪一步失败?讲解经不经得起反问,是判断它有没有真想清楚的一个信号。实际用下来,agent 的一句"这一轮验证的是从能协商到能渲染的关键一步",我虽然不懂协商的细节,但这个阶段划分我懂,做"继续"的判断够用了。

第二条,验收标准必须用我懂的语言写。我不懂 VirGL,但"重启十次画面都正常""原有的 2D 测试不能挂""启动时间不能涨"这些我懂。把它们写成测试,让机器盯住我看不懂的部分。这基本就是 Fowler 传感器思路的简化版。判断"什么算对"比判断"怎么做到"需要的知识少得多,而前者正好是拿着上线权限的人该做的事。还有个小技巧:让 agent 先自己提验收标准,我来审标准。它提标准的方式,经常能暴露它对任务的实际理解程度。

第三条,留出几块必须逐行看的区域。安全边界、不可逆的数据操作、对外的接口——这几块我逐行看,看不懂就先去学,学懂了再合并。其他的胶水代码和底层细节,靠前两条卡住。哪些地方深管、哪些地方放手,得是主动选的,不能是被代码量推着走的。

最后

框架的抽象能一层层叠上去,是因为每层都有人负责:苹果对 Virtualization Framework 的正确性负责,React 团队对协调算法负责。AI 生成的代码没有这个背书,签收的是你自己。所以要做的不是看懂一切,而是换个位置:从写代码的人,变成验收的人。（大家都是 QA）

另外,那些看不懂的术语我也不会没有扔掉。我会让 AI 拿这个项目当教材,把 capset 和 EGL 讲了一遍。因为例子是自己项目里的,学起来比直接啃文档快很多。AI 确实让人离代码更远了,但用它把距离补回来,也比以前容易。最近我发现，不管是 Codex、Claude 还是 Kimi，这几个 coding agent 在制作 PDF 上都非常擅长，现在做的也越来越漂亮，大家可以试一试。把自己不懂的或者想学习的内容制作成 PDF，然后在自己有空的时候去看，我觉得这是一个非常轻松的一个学习方式。我还会把 pdf 发到kindle。

参考链接

1. Simon Willison, Not all AI-assisted programming is vibe coding (but vibe coding rocks)(2025.3),内含 Karpathy 的 vibe coding 原始推文全文: https://simonwillison.net/2025/Mar/19/vibe-coding/
2. Simon Willison, Vibe engineering(2025.10): https://simonw.substack.com/p/vibe-engineering
3. Martin Fowler, Harness engineering for coding agent users(2026.4): https://martinfowler.com/articles/harness-engineering.html
4. Martin Fowler, Maintainability sensors for coding agents(2026.5): https://martinfowler.com/articles/sensors-for-coding-agents.html
5. Armin Ronacher, Agentic Coding Recommendations(2025.6): https://lucumr.pocoo.org/2025/6/12/agentic-coding/
6. Armin Ronacher, The Tower Keeps Rising(2026.7): https://lucumr.pocoo.org/
7. Clutch, Blind Trust in AI: Most Devs Use AI-Generated Code They Don't Understand(2025 调查,n=800): https://clutch.co/resources/devs-use-ai-generated-code-they-dont-understand
8. Fernando Brito Ferreira, We're Shipping More Code Than Ever. We Understand Less of It.: https://dev.to/fbritoferreira/were-shipping-more-code-than-ever-we-understand-less-of-it-93n
9. HackerNoon, How to Understand the Systems Your AI Coding Agent Builds: https://hackernoon.com/how-to-understand-the-systems-your-ai-coding-agent-builds