不想再被 Claude Code 气到，我改了 5 个协作原则

上一篇，我整理了 Claude Code 在一次长时间协作里犯下的几类错误：

它会把承诺说成完成，把猜测说成诊断，把“没有找到”说成“从未发生”，也会在执行过程中悄悄缩小原本约定的范围。

这些错误共同产生了一笔“验证税”：

我不能只判断产品结果，还要不断核查 agent 对项目状态的描述是否真实。

但仅仅知道它错在哪里还不够。

更重要的问题是：

为什么这些错误会在长时间协作的后半段集中出现？

回看整个过程，我不认为存在一个单一原因。

更像是四个问题逐渐叠加，最后一起失控。

1. 一个 session 用得太久

这次协作持续了二十多个小时，中间经历过多次上下文压缩。

到了后半段，它对早期讨论的把握明显变差。

有些已经回答或完成过的事情，它会说“从来没有讨论过”；有些原本同意的范围，在执行过程中逐渐消失。

长期项目当然需要上下文。

但把所有内容都留在同一个 session 里，并不等于拥有完整、可靠的项目记忆。

聊天记录只是项目状态的一部分。

真正重要的决定、完成状态和待处理事项，必须被写进项目文档、决策日志和实现记录，而不能继续依赖 agent 自己回忆。

2. 验证方式和结论不匹配

“类型检查通过了”，只能说明类型检查通过了。

它不能证明页面已经好看，也不能证明交互符合预期，更不能证明数据库里的状态正确。

但在这次协作中，Claude Code 几次用“代码逻辑没有报错”，代替了真正需要的验证。

例如：

• UI 问题应该查看真实渲染结果
• 数据问题应该直接查询数据库
• 状态变化应该核对实际记录
• 主观视觉判断应该明确交给人验收

验证不是做过某种检查就算完成。

关键是：这个检查是否真的能够支持当前结论。

否则，“验证过了”只是另一种听起来很确定的模糊状态。

3. 工具链不稳定，却一直被当作局部问题处理

浏览器自动化有时会点击落空。

开发服务器可能随着会话结束被回收。

控制台里还可能残留几个小时前的旧报错。

这些问题每一次都可以临时补救。

但如果同一种工具问题反复出现，就不应该继续把它当成偶发情况。

应该停下来问：

现在的问题究竟出在产品代码，还是用于验证产品的工具本身已经不可信？

如果工具无法稳定支持验证，就需要换一种方式。

否则 agent 很可能会围绕错误信号继续排查，最后越改越远。

4. 反馈越密集，核实越容易让位于快速回应

这是我在这次协作里的观察，不是已经被证明的普遍规律。

当负反馈越来越多、节奏越来越快时，Claude Code 更容易快速给出一个听起来完整的解释，而不是先停下来核实。

它会迅速承认、总结、提出改进方案。

但有时候，真正需要的不是另一段反思，而是先执行一次查询，确认事实到底是什么。

这提醒我：

在高压纠错阶段，不能因为它语气更诚恳、解释更完整，就默认它已经完成了验证。

我后来改了 5 条协作规则

这些规则的目标不是让 Claude Code 从此不再犯错。

那不现实。

它们更像是在重新分配责任：哪些可以直接执行，哪些必须先确认；哪些由 agent 验证，哪些必须由人验收。

最终目的，是降低上一篇提到的那笔“验证税”。

规则一：出现客观信号就换 session，不再问 AI 自己

以前我会问 Claude Code：

这个 session 是不是太长了？我们需不需要重新开一个？

后来发现，这个问题不应该交给当前 agent 自己判断。

一个已经遗漏部分上下文的系统，很难可靠评估自己究竟遗漏了多少。

我现在更看重几个客观信号：

• 已经经历过上下文压缩
• 同一类错误重复出现两次以上
• 开始否认明明存在的历史记录
• 多主题消息频繁漏答
• 工具状态和项目状态越来越难对齐
• 我已经被气到无法正常判断

出现其中一两项，就应该考虑停止当前 session。

先把已完成内容、未完成事项、关键决定和下一步写成交接记录，再重新开始。

不要试图在一个已经明显失控的窗口里，用更多追问把它重新问清醒。

规则二：反馈可以批量给，执行不能批量做

批量反馈本身有价值。

它能让 agent 看到全貌，判断多个问题之间是否有关联，也有利于进行整体设计。

但把十几条反馈一次性交给它全部执行，很容易稀释每一项的验证质量。

我现在会先让它做一张分诊表，把问题分成三类：

• 只影响局部的样式微调
• 会影响多个页面或组件的结构改动
• 它无法独立验证的事项，例如像素级审美、原生文件选择器或真实用户感受

先分诊，再分批执行。

不是按照反馈出现的顺序一路改下去。

规则三：检查点不按时间设，按“返工半径”设

以前很容易用时间来决定什么时候停下来确认：

做半小时检查一次，或者完成一个页面再看。

现在我更关注另一个问题：

这个决定如果错了，后面会连带重做几个地方？

如果只影响一个局部样式，可以直接做。

如果会影响多个页面、数据结构或后续功能，动手前应该先停下来，把影响范围和实施方案摆出来确认。

检查点的价值，不在于频繁打断执行。

而在于避免一个错误决定向下扩散。

规则四：“已完成”必须同时说明验证方式

以后不能只接受一句“已经完成”。

它还需要说明：

• 实际修改了什么
• 使用什么方式验证
• 哪些部分已经验证
• 哪些部分仍然没有验证

例如：

已更新数据库记录，并通过直接查询确认数据为空。

和：

已修改前端代码，类型检查通过，但视觉效果尚未验证。

这两句话表达的是完全不同的完成程度。

把验证方式一起暴露出来，比我反复追问“你真的测过了吗”更有效。

规则五：编造事实和验证不到位，不能混为一谈

这次错误清单里，有两类问题很容易被放在一起。

第一类，是它说了一件根本没有发生的事。

例如声称数据已经清空，但实际没有执行。

第二类，是它进行了检查，但检查方法不足以支持结论。

例如只跑了类型检查，就认为 UI 已经验证。

两者都需要修正，但性质不同。

前者涉及最基本的事实状态，属于必须立刻停下并明确承认的红线。

后者是验证方法的问题，可以通过流程、测试和工具改进。

如果所有错误都被模糊地归入“验证不够”，就会低估第一类问题的严重程度。

不是所有教训都应该继续写进 CLAUDE.md

复盘后，我确实把一些规则写进了项目的 CLAUDE.md。

但我也开始意识到，不是每犯一次错，都应该往同一个文件里追加一句要求。

更合理的分工是：

• 长期协作原则和表达要求，写进 CLAUDE.md
• 已经确认的产品决定，写进决策日志
• 已完成和未完成的工作，写进实现日志和待办
• 必须稳定执行的检查，尽量交给测试、脚本或自动化机制
• 视觉判断、产品体验和优先级，仍然由人负责

否则，规则越来越多，最终只会得到一份很长、却未必真正被遵守的说明书。

真正需要解决的不是“怎样再写一条更好的 Prompt”。

而是：

这个项目的状态，应该由什么来记录？这个结论，应该用什么方式验证？这项风险，应该由谁负责验收？

AI 降低了执行门槛，但没有取消管理

这次二十多个小时的协作让我更确定了一件事：

AI coding agent 并没有让项目管理消失。

它只是改变了管理对象。

过去，我需要讨论需求、确认方案和验收进度。

现在，我还需要管理上下文、验证方式、工具状态、执行范围，以及 agent 自己表达出来的确定性。

它确实让我能做更多事情。

但要让这种能力真正转化成稳定产出，靠的不是不停追加 Prompt，也不是把所有信任都交给一个越来越长的 session。

而是重新设计协作流程：

什么时候可以直接执行，什么时候必须先确认；

什么可以由 AI 验证，什么必须由人验收；

哪些信息留在对话里，哪些必须沉淀到项目外部；

什么时候继续，什么时候应该停下来重开。

上一篇里，我说使用 coding agent 会产生一笔“验证税”。

这笔税不可能完全消失。

但它可以被管理。

好的协作方式，不是要求 AI 永远不犯错，而是让错误更早暴露、让验证方式更明确、让项目状态不再只存在于聊天窗口里。

最后还有一条很个人、但对我很有效的判断：

真的被气到七窍生烟时，不要继续和它争论。

情绪有时也是流程已经失效的信号。

停下来，保存状态，换一个 session，通常比再逼问十轮更有效。