我们有代码审查。我们需要意图审查。

上个月，我目睹了克劳德代码（Claude Code）自信地重建了一个我的团队在三周前就已弃用的雷迪斯（Redis）队列。

该代码仓库中包含 redis.go 文件，四处散落的待办事项（TODOs），以及在 docker-compose.yml 中配置的 redis。克劳德看到了所有这些，并合理地希望完成这个看起来只构建了一半的功能。

问题在于：我们已经决定不再使用雷迪斯。复制延迟一直导致重复的计费事件，团队因此决定将其移除。这一决策存在于一个斯拉克（Slack）讨论线程、几条拉取请求（PR）评论以及三位工程师的脑海中。

代码搜索看到了雷迪斯文件。但它看不到这一决策。

这是我不断遇到的一种特定故障模式，而且我越是审视它，就越觉得我们在人工智能辅助的工作流程中缺失了整个审查层面。

我们有代码审查。我们需要意图审查。

问题不在于人工智能写了什么

大多数关于人工智能编程的讨论都集中在输出上：它是否产生了良好的代码？架构是否合理？测试是否通过？

但我所描述的故障模式是不同的。智能体并非在编写糟糕的代码。它是基于错误的历史前提在编写合理的代码。

想想资深工程师在接触不熟悉的代码时的行为方式。他们不会仅仅阅读函数签名就开始打字。他们会：

这并不是因为资深工程师比人工智能智能体更聪明。而是因为他们对不熟悉的代码抱有谦逊态度。他们吃过足够多的亏，知道看起来像累赘的东西有时是承载负荷的关键，而看起来像半成品的功能有时是明确被弃用的方案。

人工智能智能体没有这种谦逊。它们被优化为倾向于认同，而非质疑。如果代码看起来只完成了一半，那么倾向于认同的做法就是完成它。如果待办事项看起来合理，那么倾向于认同的做法就是处理它。智能体选择扩展而非质疑。

这对于全新开发的代码来说运作良好。但在任何存在时间超过几周的代码库中，它就会严重失效。

当我描述这个问题时，人们通常会指出现有的工具。这些工具各自发挥着真正的作用，但没有一个能完全解决我所说的意图审查问题。

AGENTS.md / CLAUDE.md — 这些适用于你可以预见的那些“不要做”的事项。一旦你知道雷迪斯已停用，你可以写下“不要使用雷迪斯”。但是，下周你将做出的决策呢？或者你的同事昨天做出的决策呢？AGENTS.md 仅涵盖你已经记录下来的过去。新的决策不会自动写入文件中。

架构决策记录（ADRs）/ 征求意见稿（RFCs） — 过于繁重，以至于大多数团队在第一个季度后就停止维护它们。即使得到维护，它们也是为人类读者编写的，而不是为在代码更改前进行上下文查询的智能体编写的。

维基（Wiki）/ Notion / Confluence — 文档与代码脱节。六个月前的维基页面仍然写着“我们使用雷迪斯”。智能体不会像查询代码那样自然地查询维基，即使它们这样做了，找到的也是一个自由形式的页面，其中并未将决策、风险与被拒绝的备选方案结构化区分。

拉取请求描述 — 埋没在吉特哈布（GitHub）中。理论上可搜索，实践中被忽略。智能体不会主动拉取相关代码区域的拉取请求描述。

智能体

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。