大脑三明治：先思考、再交给工具、最后再思考

The Brain Sandwich — terriblesoftware.org · 9 小时前 · 💡 观点 / 杂谈

当编程助手深度进入日常开发之后，一个被反复提起的担忧是：工程师会不会把自己的判断力也一并外包出去。作者在一次与团队核心工程师 Emily 的一对一沟通中聊到这个话题，两人吐槽了评审量暴涨、岗位职责变化，以及有人干脆完全不思考、把整件工作丢给工具的现象，坊间甚至给这种做法起了个戏称叫 Meat Proxy。真正促使作者写下这篇文章的，是 Emily 用来应对这一问题的简单框架——大脑三明治：面对任何任务，先用自己的大脑理解，再交给工具实现，最后再回到自己的大脑收尾。第一步的关键在于动手前先读代码、摸清上下文，不要求写出完整实现方案，但必须对方向有大致判断；如果跳过这一步，工具给出的方案会形成锚定效应，把注意力引向错误的方向，甚至让人去解决一个从一开始就不存在的问题。第二步可以毫无心理负担地全权委托，因为此时人已经具备评估能力，拿到结果能立刻分辨它是正确的、过度设计的，还是答非所问。第三步是在把成果交给同事评审之前，先让这份工作变得可评审：通读改动、判断引入的复杂度在当前场景下是否划算、把合并请求的描述写清楚。作者给出的经验法则是，如果自己都讲不明白改了什么、为什么改，那就不该请别人来看。文章的核心结论是，充分使用这类工具与保持工程能力并不矛盾，前提是保留前后两段人类思考，把中间的执行环节放心交出去。

核心信息

「大脑三明治」把一次任务切成三段：先由人理解现状与目标，再让代理完成实现，最后由人整理与审查。第一段不追求完整方案，只求方向感；第二段强调可以彻底放权，不必有心理负担；第三段要求通读 diff、评估复杂度收益、补好合并请求说明。三段顺序不能颠倒，因为人的判断必须出现在委托之前和交付之前，否则评估能力就没有立足点。
跳过前置思考会带来两类具体风险：代理的方案会先入为主地锚定思路，把人推向并非最优的实现路径；更严重的是，它可能让人投入精力去解决一个原本并不存在的问题，也就是把「能不能做」误当成「该不该做」。作者认为，只有在人已经掌握上下文之后，工具给出的结果才可能被正确判断为合适、过度或跑偏，这也是框架第一步不可省略的原因。
收尾阶段有明确的验收标准：能说清改动内容和改动理由，才算达到可评审状态。这一步还包括判断新增复杂度在当前场景下是否值得，以及把合并请求描述写到别人能看懂。文章同时记录了一个行业戏称——把整件工作交给代理的做法被称为 Meat Proxy，它正是这个框架想要避免的极端形态。

💡 为什么值得读: 它给出的不是又一个工具清单，而是一条能立刻套用的三段时间分配规则，帮你同时拿到速度与判断力。

✍️ 小编看法: 这个框架真正的价值不在工具层面，而在流程层面。多数团队在引入编程代理时，讨论的是选哪家、买多少额度、怎么接入仓库，却很少规定人应该在什么时刻介入。大脑三明治把介入点固定在委托之前和交付之前，相当于给自动化装了两个闸门。它重要的原因是，代码产出速度提升之后，压力并不会消失，只会顺着流水线转移到评审环节。如果提交者自己没读懂改动，那么理解成本就由评审者承担，团队整体反而更慢。被忽略的代价还有技能层面的复利损失：长期不做前置判断的人，会逐渐丧失对系统边界的直觉，等到出问题时才发现自己只能依赖工具给出的解释。机会则在于把这套个人习惯变成团队规范，比如要求动手前写下问题陈述、约束条件与验收标准，交付前检查复杂度预算与描述质量。这样一来，前置思考变成可检查的文档，收尾检查变成可度量的评审返工率。对读者的意义是，写代码这件事正在从生产行为变成编辑行为，价值会向问题定义与结果判断两端集中。下一步值得观察的是，团队能否用评审返工率、缺陷归因到需求理解错误的比例等指标，证明这种前后夹击的流程确实比单纯提速更划算。

🏷️ AI, software engineering, code review, career