[{"data":1,"prerenderedAt":221},["ShallowReactive",2],{"blog-post-/zh/blogs/what-ai-code-can-change":3},{"id":4,"title":5,"body":6,"description":203,"extension":204,"meta":205,"navigation":216,"ogImage":207,"path":217,"seo":218,"stem":219,"__hash__":220},"zh/blogs/zh/29.what-ai-code-can-change.md","AI 写的代码要不要读？先问它有权改变什么",{"type":7,"value":8,"toc":196},"minimal",[9,21,29,38,47,55,58,61,64,67,72,77,80,83,86,89,92,95,98,101,108,111,115,118,125,128,131,134,137,165,171,174,177,180,184,187,190,193],[10,11,12,13,20],"p",{},"最近，",[14,15,19],"a",{"href":16,"rel":17},"https://www.youtube.com/watch?v=Hh3AmV46epI",[18],"nofollow","一场关于 AI 写的代码到底要不要读的争论","引起了我的好奇。",[10,22,23,24],{},"Mitchell Hashimoto 的回答只有四个词：",[14,25,28],{"href":26,"rel":27},"https://x.com/mitchellh/status/2072738025344565262",[18],"“I read the code.”",[10,30,31,32,37],{},"当时，他刚",[14,33,36],{"href":34,"rel":35},"https://x.com/mitchellh/status/2072715852944957531",[18],"介绍了一套多模型协作流程","：一个模型做计划，一个写代码，再由另一个判断结果。但最后的质量关，仍然是他自己读源码。",[10,39,40,41,46],{},"他后来把边界说得更清楚：代码只留在自己手里是一回事，",[14,42,45],{"href":43,"rel":44},"https://x.com/mitchellh/status/2067970516951150721",[18],"交给别人维护又是另一回事","。",[10,48,49,50],{},"Uncle Bob 的做法几乎相反。他不读 agent 生成的实现，而是把精力放到规格、单元测试、Gherkin 验收测试、变异测试、质量指标、QA 和最终验证上。他对工程师角色的定义也很直接：",[14,51,54],{"href":52,"rel":53},"https://x.com/unclebobmartin/status/2080257779395154409",[18],"“I am the engineer because I am accountable.”",[10,56,57],{},"讨论很快呈现出两种主张。",[10,59,60],{},"一派认为，不读源码，出了问题怎么维护、怎么排查？另一派反问，如果每一行都要重新读一遍，AI 带来的效率在哪里？",[10,62,63],{},"两边都有道理。Mitchell 把人的理解放在实现里；Uncle Bob 把大量判断前移到规格和证据中。他们都认为结果必须由人负责，真正的分歧是：承担责任，到底需要多深的源码理解？",[10,65,66],{},"这不是一个纯粹的哲学问题。它也是我工作中面对的实际取舍。",[68,69],"youtube-embed",{"title":70,"videoId":71},"Should You Read AI-Generated Code?","S-cNWJhWaTU",[73,74,76],"h2",{"id":75},"一进入关键系统问题就变了","一进入关键系统，问题就变了",[10,78,79],{},"我不会读完 AI 生成的每一行代码。",[10,81,82],{},"AI 让实现变快了，但人的注意力没有同步增加。真正的挑战，是哪些代码可以只看结果，哪些必须理解到底。",[10,84,85],{},"如果是私有原型、一次性分析，或者随时可以丢弃的脚本，我通常看结果、跑测试，确认没有明显问题就继续。影响范围有限，恢复也很简单。",[10,87,88],{},"但只要 AI 动到关键系统或 system of record（权威记录系统），我的审查方式就会改变。",[10,90,91],{},"关键系统之所以重要，是因为失败后果严重。System of record 之所以重要，是因为其他人和系统会把它的数据当成事实。两者经常重叠，但风险来源不同。",[10,93,94],{},"五行权限判断、余额更新、客户状态修改或数据迁移，可能比一千行原型界面更值得深读。Diff 大小，并不能代表后果大小。",[10,96,97],{},"同一段数据清洗逻辑，如果只处理复制出来的 CSV，结果错了可以丢掉重来；如果它直接写入 system of record，错误就可能进入报表、权限、客户沟通和自动流程。",[10,99,100],{},"回滚代码或许能阻止下一次错误写入，却未必能恢复已经被改坏的数据、下游副本、审计记录，以及基于错误状态做出的决定。",[10,102,103],{},[104,105],"img",{"alt":106,"src":107},"代码已经撤回，但权威记录里的错误状态仍然传播到了三个下游记录","/blogs-img/2026-08-02-ai-code-01.webp",[10,109,110],{},"我没有一个戏剧性的事故故事。这恰恰是重点：边界应该设在事故发生之前。",[73,112,114],{"id":113},"我的观点审查深度应该跟着权威走","我的观点：审查深度应该跟着权威走",[10,116,117],{},"“AI 写的代码要不要读？”这个问题问错了。",[10,119,120,121],{},"我真正关心的是：",[122,123,124],"strong",{},"这段代码有权改变什么？",[10,126,127],{},"审查深度不应该由谁写了代码、改了多少行决定，而应该由这项修改的权威、后果由谁承担，以及出错后能否发现和恢复来决定。",[10,129,130],{},"读源码和跑测试都重要，但它们会以不同方式失效。阅读能帮助人建立维护系统所需的心智模型，却不能证明代码正确；测试可以反复检查已经写进去的预期，却不能保证我们一开始就问对了问题。如果实现、测试和审查都来自同一份 AI context，它们还可能重复同一个错误假设。",[10,132,133],{},"少读源码还有一项代价：团队可能逐渐失去共同的系统模型。所以，进入生产和关键路径的修改，不能只靠测试证据。",[10,135,136],{},"所以，我把审查分成四层：",[138,139,140,147,153,159],"ul",{},[141,142,143,146],"li",{},[122,144,145],{},"结果："," 私有、可丢弃、容易恢复的工作，确认结果即可。",[141,148,149,152],{},[122,150,151],{},"证据："," 一旦有人或流程依赖输出，就要检查测试、日志、CI，以及采用不同方法或 context 的验证。",[141,154,155,158],{},[122,156,157],{},"系统模型："," 修改进入生产或影响权威状态，必须有人能解释数据流、业务不变量、错误传播、可观测性和恢复方案。",[141,160,161,164],{},[122,162,163],{},"关键路径："," 涉及权限、资金、隐私、删除、迁移、安全或 system-of-record 写入，必须理解相关源码路径。",[10,166,167],{},[104,168],{"alt":169,"src":170},"修改越接近权威状态，审查就从结果逐层深入到证据、系统模型和关键路径","/blogs-img/2026-08-02-ai-code-02.webp",[10,172,173],{},"这四层是累积的。读过关键路径不能代替测试，测试全绿也不能代替对状态变化的理解。",[10,175,176],{},"对我来说，system-of-record 修改最低从“系统模型”开始；关键写入路径通常必须下沉到源码。",[10,178,179],{},"我的发布规则很简单：没有明确负责人，没有审过关键写入路径，没有写清业务不变量，也没有可信的对账与恢复方案，就不发布。",[73,181,183],{"id":182},"真正的-ownership是对状态变化负责","真正的 ownership，是对状态变化负责",[10,185,186],{},"AI 降低了实现成本，却没有降低后果的成本。",[10,188,189],{},"我们不可能用同样强度读完每一行生成代码，也不能让没人理解的代码变成下一个人的问题。真正需要决定的，是人的理解必须在哪些地方最深。",[10,191,192],{},"我不必理解 AI 写出的每一行。但只要它能够改写业务认定的事实，或者制造业务无法接受的后果，就必须有人说得清：状态如何变化、哪些不变量必须成立、它可能怎样失败，以及如何恢复事实。",[10,194,195],{},"接受一项 AI 生成的修改之前，我现在会问：如果所有测试都是绿的，但现实仍然错了，谁能解释原因，并把事实恢复回来？",{"title":197,"searchDepth":198,"depth":198,"links":199},"",2,[200,201,202],{"id":75,"depth":198,"text":76},{"id":113,"depth":198,"text":114},{"id":182,"depth":198,"text":183},"判断 AI 生成代码该审多深，不应只看作者或 diff 大小，而要看它有权改变什么，以及出错后能否恢复事实。","md",{"date":206,"image":207,"alt":208,"category":209,"tags":210,"youtube":215,"published":216},"2nd Aug 2026","/blogs-img/2026-08-02-ai-code-cover.webp","一只手把尚未定案的代码纸带送过权威边界，使它成为业务信任的记录","ai-native-systems",[211,212,213,214],"AI 编程","代码审查","权威记录系统","工程责任","https://youtu.be/S-cNWJhWaTU",true,"/blogs/zh/what-ai-code-can-change",{"title":5,"description":203},"blogs/zh/29.what-ai-code-can-change","oTsX4Zv9yadERpqP71QL_3n6k19DFf-l11kDLiiWXHA",1785818887372]