第 9 章 · AI 写的代码，你凭什么敢用
你能解释这段代码在做什么吗？
代码能跑不等于你懂了；判断力的缺口要到出问题那天才暴露。
- 这一章回答
- 你能解释这段代码在做什么吗？
- 你会做出来
- 对关键代码的一次复述检验结果
东西能跑，这件事本身不构成「我懂了」的证据。
机制
东西能跑，但说不清为什么这么写；报错时只能再问一遍，无法判断给的答案对不对。
代码能跑起来会被误当成理解。这个误判的代价是延迟的：平时看不出来，等到某个模型也答不好的问题出现——一个只在你的数据上出现的 bug、一个需要在两个方案之间取舍的决定——缺口才暴露。那时你连从哪里查都不知道。
这不是反对用 AI。AI 写的代码和同事写的代码没有本质区别：你都要能看懂才敢合进去。区别只在于同事会拒绝你的追问，模型不会。
用自己的话说清一段代码在做什么，说不清就不要用。
它检验的不是代码对不对——那是测试的事——而是你对它的掌握程度。
三条是关键，两条是加分
关键的三条：说得出它在做什么、说得出它需要什么输入以及输入不对时会怎样、知道它出错时从哪里查。
这三条任意一条答不上，这段代码在出问题那天会变成一堵墙。
加分的两条：说得出为什么是这个做法而不是另一个、知道改相邻需求时该动哪几行。答不上不影响现在用，但等你真要改它的时候会变成麻烦。
正确的追问方式
不要让模型「再解释一遍」——它会用不同的话复述，你会误以为自己懂了。
让它反过来问你：「针对这段代码向我提五个问题，检验我是否真的理解。我答错了再告诉我正确答案。」答错的地方就是你的真实缺口。
现实案例
模型给了一个处理日期的函数，能跑，他直接用了。
两周后出现一个 bug：跨月的稿件显示在错误的分组里。他问模型，模型给了一段新代码，也能跑，但另一个场景又错了。来回五次之后他发现自己完全不知道该信哪一版——因为他从一开始就不知道第一版在做什么。
最后他让模型逐行解释那个函数，花了 20 分钟。里面有一个时区转换，在他的测试数据里从来没触发过。
这 20 分钟如果花在第三天，能省掉后面两周的五次来回。
动手试
挑一段模型给你的、现在正在用的代码，逐条回答。
判定为「先别用」时，正确的动作不是删掉它重写，而是让模型逐行解释，直到那三条关键的你自己说得出来为止。通常 20 分钟。
你的行动
对你项目里最关键的那一段 AI 生成的代码做一次复述检验，把结果记下来。
答不上的那几条，用「向我提五个问题」的方式补上。
顺便记一条决定：你为什么用这个做法。这会直接变成下一章的素材。
检查标准
- 我对关键代码做过一次复述检验
- 三条关键项我都答得上
- 答不上的部分我已经补过了，不是跳过
- 我知道这段代码出错时从哪里开始查
容易搞错的地方
它会换一种说法复述，你会把「听懂了解释」误当成「理解了代码」。
让它提问，不要让它讲解。答错的地方才是真实缺口。
「这段代码在做什么」答不上，还能补。「为什么要做这个功能」「为什么这个用户值得服务」答不上，而答案是模型给的——那是整个项目建在沙子上。
Verify 阶段会专门检查这一类。
本章自测
- 为什么「代码能跑」不是理解的证据？
- 关键的三条分别是什么，为什么是这三条？
- 为什么不该让模型「再解释一遍」？