Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That
TL;DR · AI 摘要
Anthropic团队通过Claude生成代码解释替代传统心理模型，重构代码审查流程，引发对AI主导开发的争议。
核心要点
- Claude生成代码解释替代开发者心理模型，节省认知负荷
- 代码审查流程中人类参与降至1人/PR，依赖AI生成的解释文档
- Issue自动关闭机制暴露AI生成内容与实际流程的冲突
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Anthropic代码审查实践
- 核心机制
- Claude生成解释文档替代心理模型
- AI主导代码审查流程
- 案例分析
- Issue自动关闭机制缺陷
- 6000+错误关闭案例
- 风险与挑战
- 系统故障时缺乏因果模型
- AI生成内容与实际流程冲突
金句 / Highlights
值得收藏与分享的关键句。
团队声明：'Nobody keeps a complete mental model of Claude Code'，Claude生成解释文档替代传统认知
代码审查目标：'Most PRs merge with at most one human in the loop'，人类参与度降至最低
Issue自动关闭机制导致6000+含复现步骤的issue被错误关闭，暴露AI生成内容与实际流程的冲突
Anthropic 表示无需对 Claude Code 保持心智模型。从业者正在验证这一点 - InfoQ
InfoQ 首页 News Anthropic 表示无需对 Claude Code 保持心智模型。从业者正在验证这一点
开发
InfoQ 认证高绩效团队计划（在线，11 月 17 日）：为团队构建更清晰的运作模型。
Anthropic 表示无需对 Claude Code 保持心智模型。从业者正在验证这一点
2026年10月29日 4分钟阅读
作者：
- Steef-Jan Wiggers
#### 关注我们
Youtube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 点赞
Bluesky
收听本文 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
Anthropic 已经公布了 Claude Code 团队如何进行代码审查的最新方式，因为 Claude 现在负责编写 Claude Code 的约 90%。引发最多质疑的不是这个百分比，而是团队声称不再需要心智模型的说法。
由 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 撰写的这篇文章，是 Anthropic 在其单体仓库从 5 月每天约 2500 次合并变更增加到 9 月超过 30000 次后，用内部系统取代 git 的后续说明。审查是接下来要解决的问题。目标是大多数拉取请求"最多只需一个人参与审查，这个人可以是作者，且不会增加回滚或事故次数"。
在理解方面，团队明确表示：
团队中没有人会完整地在脑海中保持 Claude Code 的心智模型，我们认为也没有人需要这样做。当有人想理解代码库的某部分时，他们会要求 Claude 为该部分编写一份解释。这只需要几分钟，且反映的是当前代码的状态。
这段话主导了 Hacker News 的讨论，其中评论者 jonahx 指出这种做法的代价：
如果这个系统出现故障，例如存在一个无人能解决的关键错误，现在将不再有人可以求助。没有人脑海中存在可以用来逐步调试的因果模型。新的信任模型是：我们信任 Claude 总是能够充分理解系统，以调试任何问题或进行任何合理的更改。
他还指出，许多大型遗留系统已经以这种方式运行。
一个有记录的案例在 Anthropic 自己的仓库中测试了这个解释声明。8 月，Claude Code 合作者 Boris Cherny 在一条带有 "Generated with Claude Code" 页脚的评论中，回应了关于问题自动关闭的长期投诉。它表示问题会在"长时间没有活动且缺少重现所需信息"时关闭，并且"没有任何问题仅通过计数来分类"。
仓库的 issue-lifecycle.ts 将 14 天设为过期，再加 14 天关闭，仅对获得 10 个或更多点赞的问题例外。开发者 marcindulak 统计发现，超过 6000 个被标记为包含重现步骤的问题仍然因"长时间不活跃"而被关闭。评论中建议的解决方案是重新打开问题，但被一个在关闭 7 天后锁定已关闭问题的工作流阻止。这个元问题现在也被锁定。
引发这个问题并错误诊断该仓库问题管理方式的回答，是由一个世界级模型生成的。
文章记录的失败案例是具体的。第一个失败情况只在双方都是机器时才会出现：
当作者是代理时，噪音成本更高。一个人可以在几秒钟内忽略一个细节问题，而代理则需要修复它，这意味着需要再次提交代码并再次进行审核。
团队写道：“有一份CLI PR在作者停止之前，经历了超过五十轮的审核和修复。” 默认情况下进行更多轮次的审核反而让情况变得更糟，因此他们设定了轮次上限。在r/ClaudeCode上，评论者ChemicalExcellent463报告称自己独立得出了相同的结论，在两次修复失败后停止了操作，因为重复失败意味着代理对代码的理解有误，而非持续编辑的那行代码有问题。
这些轮次发现的是第二次失败的问题：
当我们对审核者反复标记的代码运行git blame时，其中约59%的代码自审核者第一次审核以来就一直存在。审核者很少发现新漏洞，而是每次审核发现少量旧漏洞。
决定是否允许合并的依据是分类器选择的风险等级，其中“变更决定等级，而非作者”。低风险包括文档、复制内容和在标志后添加的更改，无需人工批准即可通过。中风险包括缓存、自动更新器和系统提示，需要一个人审核。两条规则划定了界限：“代理的批准永远不被视为人工审核”，以及“触发变更的人员被视为必需审核者之一”。
这一界限引发了一个帖子未回答的问题。Reddit评论者Oximy-Naman询问低风险是否涵盖作为文档发布的代理指令更改，因为这些更改“可以在不修改应用代码的情况下改变代理的行为”，但未收到回复。帖子未对CLAUDE.md文件进行分级，该文件是其自身审核者在每次审核时加载的。在合规性方面，Hacker News评论者gaal_dornick报告称，他们自己的SOC 2审核者要求所有变更在生产前必须由第二个人类审核；帖子未讨论审计要求。
目前缺少一个控制措施，团队也明确指出了这一点：
我们尚未建立当这些数字变化时收紧审批的熔断机制；这里的工程师希望在更多代码转向零人工合并之前实现这一点。
并非所有人都认为这是鲁莽的。评论者cheema33认为，大型组织从未有人拥有完整的模型，因此这是对现状的改进，而评论者markbao报告称每月花费数千美元用于AI审核，以替代消耗工程师多达三分之一时间的人工审核。
系统的一部分已公开发布。Claude Code的代码审查功能通常在团队和企业计划中提供，安全审查作为开源GitHub Action运行，其README中说明该工具“未针对提示注入攻击进行强化，仅应用于审查可信的PR”。
作者部分主容器
关于作者
章节标题
每个作者的主容器
#### Steef-Jan Wiggers
显示更多
显示更少
#### 本内容属于“文化与方法”主题
##### 相关主题：
- 开发
- 架构与设计
- 文化与方法
- 人工智能、机器学习与数据工程
- 代码审查
- Anthropic
- 相关编辑内容
- 相关赞助商
- 相关赞助商 2026年10月29日，东部时间下午1点 从Tokens到Features：为AI辅助工程构建成本归属架构 主讲人：Martin Reynolds - Harness的首席技术官，Barani Mohandoss - Trimble的云治理、FinOps与E-工具总监
InfoQ新闻通讯
每周二发送的InfoQ上周内容精选。加入超过250,000名资深开发者的社区。查看示例
我们保护您的隐私。