AI 写得越来越快,我们还解释得清自己的代码吗?

架构师（JiaGouX）

我们都是架构师！架构未来，你来不来？

Addy Osmani 写了一篇长文，讨论 Agent 干活之后，人怎样保持思考。

评论区里，有人请 Bot 翻译，有人让它总结，还有人希望它参考文章，优化自己的工作流。还有读者开了个玩笑：

Claude，把这里说的都落实一下，这样我就不用做了。

这句玩笑挺贴切。写代码、跑测试、读源码，Agent 都能帮忙。连怎样学习、怎样检查，也可以继续问它。

Addy 提到一个变化：模型越好，明显的错误越少，我们停下来追问的次数也在减少。上一条认真读，下一条略读，再下一条只扫一眼结构。每一步都很自然。

直到下一次需求变了，才发现代码虽然看过，测试也通过了，真要继续改，心里还是没底。

以前做一个功能，除了得到代码，人还可能在实现中学到一些东西。需求没想清楚，写到一半才发现；以为异常会让数据回滚，排错时发现不是；两个方案都能跑，讨论之后才知道为什么选其中一个。

把实现交给 Agent，这些麻烦可能一起被解决了。交付更快，人却未必经历了那几次“原来我想错了”。代码完成了，判断所需的经验未必一起留下来。

我觉得这比“代码是不是亲手写的”更值得聊。我们希望继续享受 Agent 的效率，也希望下一次条件变化时，仍然知道哪里可以改，哪里一动就会影响别人。这份把握，从哪里来？

几行代码，一项约定

Addy 举了一个假设：Agent 交回 600 行代码，结构合理、变量名清楚、测试也通过，审查者于是批准了。可其中也许改了事务里的执行顺序，或者翻转了某个边界条件的默认值。

审查者确实看过，只是注意力停在了自己已经想到的地方。

把事务顺序这个问题缩小一点。假设系统创建订单后，要发一条消息，通知另一个服务处理。Agent 整理函数时，把发送消息的代码挪了几行。

如果消息在数据库事务提交前就发出，接收方按消息里的编号查询，可能还查不到订单。换成提交后发送，接收方能依赖“订单已经提交”这个条件，但还有另一种情况：订单保存成功了，消息却没发出去。

正常情况下，两种顺序都可能跑通。出错时，差别才出现。

几行代码的位置，决定了另一个服务能相信什么，也决定了失败后还剩下什么没做完。审查到这里，才有机会讨论：这次能不能挪，挪完以后谁来处理失败。

如果需求只说“创建订单后通知下游”，提交前还是提交后发送、发送失败后接口返回什么，可能都没有说清。Agent 得把这些空白补上，代码才能运行。后来我们看到的是一份完整实现，未必会注意到，它已经替我们作过几次选择。

我们在《当 AI 完成了大部分代码，架构师何去何从？》里聊过，实现变快以后，系统边界和验证仍要有人负责。到了这次审查里，问题就很具体：订单服务改了，消费消息的服务可能一行没动，受影响的恰恰是它。

这也是我觉得架构分析有用的地方。模块图能告诉我们有哪些服务，沿着一次请求看下去，才能发现它们实际依赖了哪些条件。

这次要看哪些代码，也就有了依据。事务调整值得追到提交、发送和接收方；一段提示文案，通常用不着同样的阵仗。关注的范围，可以由两个问题来决定：有没有改变别人依赖的条件？出错以后，是否容易补救？

两个问题还答不上来时，可以先请 Agent 沿调用关系找：谁用了这次修改的结果，遇到失败会怎样继续。不必先读完整个仓库，但也不能只因为 diff 很短，就认定影响很小。

先预测，再核对

Addy 有个小习惯：稍复杂的任务交出去前，先想一下答案可能是什么。猜错没关系。

这个做法放在审查里也挺实用。先说出自己的预期，再看代码，比较容易发现哪一段没有想明白。

继续用刚才的假设。把提交后发送的实现简化成下面三步。这里约定，发送失败会抛出异常，外层会把异常转成接口错误响应：

如果原先的判断是“接口报错，订单应该也没创建成功”，顺着这三步看一遍，就会发现问题。

第一步已经提交了订单。第二步发送失败，第三步不会执行，接口因此报错。前面提交的数据却不会自动回滚。

于是，原先的判断就需要改成：这次请求虽然报错，订单可能已经存在。如果调用方据此重试，而系统没有处理重复请求，还可能再创建一笔订单。

这段推演不复杂，却把一句“已优化订单创建逻辑，测试全部通过”里看不出的差别找了出来：接口返回的结果，和系统已经发生的变化，可能并不一致。

这时再看测试，问题也会具体一些。

原帖评论里的 Dave 和 Alex 都提醒，实现和测试可能共用一个错误前提。Dave 建议，至少有一项检查直接来自需求。

假设系统约定“订单提交后才能发通知”，测试就得能观察到这个先后关系。只是把发送函数换成模拟对象，确认它被调用过一次，检查到的是调用次数，还没有检查调用时订单是否已经提交。

沿着这个例子，可以进一步安排两项检查：

• 在测试环境里，让发送调用在消息发出前抛错，同时检查接口响应和数据库记录。它们能帮助核对：接口报错时，订单是否已经存在。
• 如果需求约定“同一请求重试不能重复创建订单”，就用同一请求标识再次调用，检查最终是否仍只有一笔订单。预期来自这条约定，不能看实现做了什么，就把什么写成预期。

这两项检查仍没有证明消息一定能送达。它们回答的是“失败后订单还在不在”和“这次重试会不会重复创建”。知道它们没覆盖什么，才知道下一步还要查什么。

测试仍然可以让 Agent 写。自己需要弄清的是：预期依据哪条规则确定，实际检查的又是什么。换一个 Agent 审查，也值得看它有没有追问这些前提。

这一段可以请 Agent 帮忙：沿实际代码，从入口走到状态变化和外部调用，把相关文件找出来，再挑一个失败条件核对。这样每次追问都有位置可找，不必从通读整个仓库开始。

Simon Willison 分享过类似的源码讲解做法。他让 Agent 做完一个 SwiftUI 应用后，新开会话读取源码，按顺序生成讲解，还要求代码片段直接从文件提取，留下命令和输出，方便对照。

到了这里，对这次修改的理解就有了具体内容：找得到提交位置，说得清发送失败后的状态，知道重试检查证明了什么，还有哪些情况没看。下次需求变化，可以从这些依据继续，而不只记得一句“当时测试过了”。

人不必独自完成查找、讲解和检查。值得亲自参与的，是先说出一个判断，再看看证据会不会让自己改变主意。只顺着讲解点头，很难发现哪一段只是听起来合理。

新人怎么练判断

讲到这里，还绕不过评论区另一个问题：如果初级开发者从来不先动手写代码，那份判断力怎么培养？

有经验的人看到一次重试，可能会想到重复扣款；看到一个异步调用，可能会追问取消后谁来清理。这些问题，往往来自以前写过、改过、排查过的东西。

新人还没有这些经历。把实现全部交出去，再让他来判断结果是否可靠，这份工作其实很难。

这也给“人负责判断”补了一个前提：判断需要有机会练出来。资深工程师可以借用过去的经验，新人还得在眼前的工作里，积累第一批关于“这样改会发生什么”的认识。

Anthropic 今年 1 月做过一项实验：52 名有 Python 使用经验、此前没用过异步编程库 Trio 的工程师，分组完成编程任务，再脱离 AI 接受测验。AI 组平均得分率为 50%，手写组为 67%，排错题差距最大；完成任务的用时差异未达到统计显著。

这测的是侧栏编程助手辅助学习陌生库后的短期理解，不能用来断言长期使用 Agent 会怎样。不过，拿到一份能工作的代码，和自己学会处理其中的问题，确实需要分开看。

所以，留给新人的工作，可以小到一处错误处理，但最好能让他作一次选择、看到一次后果。

拿前面的订单例子，先让他写下发送失败后对接口和数据的预期，再尝试补出对应测试。结果与预期不同时，沿代码找到原因。卡住了，可以请 Agent 指出相关文件、解释事务行为，随后由他重新说明：哪一步想错了，为什么需要修改判断。

如果这部分已经看懂，可以再一起选一小段实现，例如输入校验或一项状态转换。把约定说清楚，让他尝试实现，再用正常和失败用例核对。Agent 可以给线索、解释报错，最后再帮助检查遗漏。这样既能借助工具，也有一段需要自己作决定、动手修改的过程。

我们在《如何用 Claude Code 搭建自己的 AI 学习系统》里，也聊过练习、测验和错误记录。放到日常开发里，一次小修改就可以带来这样的反馈：先想会发生什么，再看哪里猜错了，留下这次改正的原因。

多敲一遍代码，却没有想过为什么这样写，未必能留下多少东西。反过来，一段不长的错误处理，也可能带出对状态、重试和清理过程的理解。

带新人的同事也有事情可做：一起选定范围，确认测试预期确实符合需求，再对着结果讨论。否则，人和 Agent 完全可能沿着同一个误解，把实现和测试都做完。几百行 PR 很难逐一讲透，一个能复现的小问题则容易讨论清楚。

赶交付时，可以多委托。如果还希望新人通过这次工作积累经验，排期里就需要算上那段尝试和排错。代码完成了，人有没有学到东西，还得另外看。

把取舍留下来

前面的讨论有个前提：相关依据还找得到。

代码能告诉我们，消息发送失败以后，系统现在会做什么。业务为什么允许通知延迟，为什么当时接受了某种失败，这些理由却未必写在实现里。

如果没有记录，Agent 也许能给出一个合理的解释，但那未必是当初作决定的原因。下一次需求变化时，我们就很难分辨：原来的条件变了，还是过去根本漏想了。

所以，除了代码和测试，值得留下来的还有几句不长的话：当时想保证什么，为什么选这个做法，哪些问题还没处理。

沿用订单例子，如果已经核对过发送失败后的接口响应和数据，审查记录就可以写：已核对“发送失败时订单仍然存在”；重复请求是否会再次创建还没有确认；接下来需要对照接口的重试约定。相关实现和测试位置也一起留下。它未必是一份完整设计文档，却能让接手的人知道，哪些是已有依据，哪些还只是猜测。

业务是否允许通知延迟，是否可以接受偶尔漏通知，则需要另行确认。Agent 可以比较方案、说明代价，但单从当前实现里，推不出团队愿意接受哪一种后果。

这也是按需恢复理解的条件。复杂系统的细节很难一直记在脑中，Agent 可以帮忙查入口、追调用，把眼前这部分重新讲清楚。低风险、用完即丢的工作，也可以充分委托。需要仔细看的，仍然是那些会改变其他人依赖条件的决定。

原文谈到，即使模型以后更擅长检查，人仍要对交付结果负责。我觉得，责任要有相应的条件：有时间看证据，有机会承认自己不懂，也能在后果没想清楚时暂停。否则，只让人留在最后点一下批准，并没有增加多少判断。

这段工作要花时间。Addy 提到，如果 Agent 交回的结果已经多到来不及认真处理，再开一个会话也解决不了积压。可以请它协助筛选、补充检查，剩下需要讨论的取舍，还是得留出时间。

回到开头那句玩笑，翻译、整理、讲解，甚至提问，都可以继续交给 Claude。它能帮我们少翻很多文件，也能让一次猜错更快得到纠正。在需要自己继续维护的地方，除了拿到代码，也可以留下一些把握：这次凭什么接受这个结果，哪些后果已经想清楚，哪些还没有。

下次再改到这里，能找到相关实现，知道当初为什么这样选，也知道哪种变化需要重新讨论，就不必从那句“测试都过了，应该没问题吧”重新开始。

参考资料

• Addy Osmani，Critical thinking when agents do the work（https://x.com/addyosmani/status/2117512471930167377）
• 原帖评论：Emanuele（@EmanueleUngaro_）、Dave（@Dave_Joe_9377）、Alex Torres（@alextorres_dev）、Mitttt（@404Miten）（https://x.com/addyosmani/status/2117512471930167377）
• Anthropic，How AI assistance impacts the formation of coding skills，2026-01-29（https://www.anthropic.com/research/AI-assistance-coding-skills）
• Judy Hanwen Shen、Alex Tamkin，How AI Impacts Skill Formation，arXiv:2601.20245（https://arxiv.org/abs/2601.20245）
• Simon Willison，Linear walkthroughs（https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/）
• Present: A Code Walkthrough（https://github.com/simonw/present/blob/main/walkthrough.md）

如喜欢本文，请点击右上角，把文章分享到朋友圈

如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：

• 当 AI 完成了大部分代码，架构师何去何从？
• Claude Code 团队是如何做 code review 的
• 自产自销：如何让 Agent 自己写自己查？
• 如何用 Claude Code 搭建自己的 AI 学习系统
• 2026 年 AI Coding 最佳实践综述
• Loop Engineering，应该赞成还是反对？

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：admin@137x.com