Cole Medin 最近发布一期视频，正中笔者用 Claude Code 或 Codex 时的积习。这位专注 Coding Agent 实战的工程师，参考 arXiv 研究总结出 11 个小窍门，小投入、高回报。每一个窍门都有可参考的arXiv的来源，值得学习。

arXiv 引用与文章中用到的Skills 放在结尾，按需直接下翻。

Claude Code、Codex 这类 Coding Agent，如今已是不少开发者案头离不开的帮手。项目从零起步、旧代码逐行重构，开发者越来越习惯先把手头的工作交给它们。用久了，那股说不上来的不对劲，会越来越明显。

规则明明越写越多，Agent 却总在某个意想不到的拐角跑偏；对话一拖长，早先敲定的路径和数字被忘得干净；进展推不动时，把整段会话搬给更大的模型，层出不穷的错误也照旧顺着惯性往下滚。

回头看，根子不在模型，而在更不起眼的地方，是工作流里那些被默认忽略的小环节。Cole Medin 的 11 条改动，动的正是这些角落。改动每一条都不大，叠加起来，却能让 Coding Agent 的整体表现上一个台阶。下文按六组依次整理，Tip 顺序与原视频一致，方便按编号对照。

一、给 Agent 定规则，写具体才能防过时

Tip 1 写具体，给 Agent 一份施工图而非一段散文

写给 Agent 的说明，和写给人看的文档是两回事。人读到「把数据库代码组织得井井有条」，能自行判断怎么套用到任何代码库；Agent 没有这种推理的余地，越是笼统的话，它越容易猜错。所以规则里要写死文件路径、数字、具体命令，比如「所有 SQL 必须放在 database 文件夹」。Cole Medin 的第一条原则是，规划任何任务时，首要目标是减少 Agent 的假设空间。

给 Agent 写说明的标准，是具体得像一张施工图。

Tip 2 规则会过时，约四分之一仓库的规则已经过期

规则写得越具体，越容易过时。代码库演进、目录改名、数据库被替换，规则却停在原地。Cole Medin 称之为 rule drift（规则漂移），并引用研究，带 AI 层规则的仓库里，约有四分之一规则已过期。最糟的情况是规则引用一个早已删除的文件或目录，Agent 一边工作一边困惑规则为什么和代码对不上。

对策是定期审计。Cole Medin 自建了一个 /rules-check-drift 技能，让 Agent 对比规则与代码库现状，找出不一致的地方。偶尔跑一次，能省掉后面一大片麻烦。

二、会话续接，别依赖 /compact

Tip 3 别用 /compact，压缩后只剩约一成的细节

几乎每个 Coding Agent 都有类似 /compact 的会话压缩功能，把臃肿对话碾成一小段摘要，腾出上下文继续工作。问题在于，摘要由模型自己决定写什么，而研究表明完整对话里只有约 10% 的具体细节能存活。丢失的往往是最该记住的路径、数字和命令。

Cole Medin 的建议是干脆避开 /compact，一次只给 Agent 一小批工作，让它根本走不到需要压缩的地步。真把会话拖得太长，就手写一份交接文档，开新会话继续。

方式	细节保留	可控性
/compact	约 10%	几乎不可控，看不到摘要内容
手写交接文档	接近 100%	完全可见、可编辑

三、规则与上下文做减法，重要的交给 hook

Tip 4 重要的规则放进 hook，该发生的必然发生

规则是概率性的，LLM 不是每次都会照做；hook（钩子）是确定性的，由事件触发、必然执行。凡是「每次都必须发生」的保证，比如每次写完代码必须跑测试，就属于 hook 的领地。

用规则写「写完代码记得跑测试」，Agent 可能忘记，或者声称跑完了，测试实际还是红的。用 hook 在 Agent 声称完成时强制跑一遍测试，全绿才算结束，有失败就路由回 Agent 修复。判断标准就一条，只要规则里写出了「某事件之后必须怎样」，就该把它做成 hook。

Tip 5 写少点，两百行以内的规则胜过千行规则文件

规则不是越多越保险。模型越强，越不需要在规则里塞基础常识。那种「怎么写 PR」「怎么做代码评审」「别重复自己」的通用原则，如今放进全局规则反而碍事，只会让上下文变臃肿。

Anthropic 的官方建议是规则控制在 200 行以内，Cole Medin 本人通常压到 300 行以内。全局规则只该留下对当前项目永远成立的约束和约定，其余内容要么删除，要么挪到按需读取的上下文文件里。

四、资源与会话要节制，少开 subagent，被污染的会话直接重开

Tip 6 速率限制的元凶，往往藏在并行 subagent 里

很多开发者困惑，为什么用量额度消失得飞快。Cole Medin 几乎可以断定，至少一部分原因，是并行开了太多 subagent（子 Agent），token 消耗比想象中大得多。Claude Code 里用 /usage，按 W 键切到每周视图，就能看清每一笔用量去向。Cole Medin 的记录里，39% 的用量来自同时运行四个以上会话，而他平时根本不这么做。

并行 subagent 擅长保护主 Agent 的上下文，但用量额度快到上限时，就该有意识限制 fan-out。别让 Agent 在开发者没有要求的情况下悄悄拉起几十个子任务。

Tip 7 会话被污染就直接重开，别换模型

任务中途 Agent 频频出错，常见反应是在会话里切换成更大的模型续写。Cole Medin 明确反对，这个对话已经被污染了。LLM 是预测机器，错误会在对话里累积，换更大的模型无法清除已经沉淀下来的偏见和错误，只会接着错下去。

正确做法是先写一份交接文档，写明「已完成什么、卡在哪里」，随后果断结束当前会话，开新会话让它读文档继续。用干净会话起步，远好过让旧会话的错误层层叠加。

五、协作与审批，主 Agent 当分发者，写作者不审自己的成果

Tip 8 别用协调者框架，主 Agent 当分发者就够了

这是全文唯一的争议观点。市面上不少「团队领导」式框架，让多个 Agent 互相通信、共享任务清单、往一个邮箱投递消息。Cole Medin 直言这些不可靠，Claude 自带的 agent teams 也长期停留在实验阶段，原因就在这里。

要并行扩展工作，让主 Agent 当纯分发者就够了，用普通语言描述需求，它把工作流派给后台 Agent 各自执行。没有 Agent 之间的花哨通信，也没有层层监控，可靠性反而更高。

Tip 9 写作者不审自己的成果，换个视角评审 PR

写代码的 Agent 会在实现中积累偏见和假设。让它自查成果，答复几乎总是「很好」，因为它看不见自己的盲区。Cole Medin 把这条列作所有 AI 编码工作流的硬规则。

让写作者自己跑测试、迭代修问题，仍然有价值。但最终评审，要换一个全新会话，给它交接文档说明刚建了什么，让它以新视角评审 PR（拉取请求）或未提交的改动。写代码的人和审批代码的人，必须是两个会话。

六、迭代与验证，适可而止，验证前置

Tip 10 过度迭代反而让质量变差，更早的答案往往更好

让 Agent 反复改，质量不一定提升。它会在某一轮找到最佳答案，之后每被逼着改一次，就为了迎合提出需求的一方而硬找出「可改之处」，结果越改越糟，这是 LLM 的 sycophancy（谄媚倾向）在作祟。Cole Medin 自己也踩过这个坑，额度快重置、token 还剩一堆时，习惯性要求「再迭代几轮让它完美」。

研究数据很直观，强迫 Agent 跑十到二十次，85% 的情况下，最后一轮之前的某一次迭代反而更好。 更多迭代不等于更好的代码，学会在合适的地方收手，本身就是一种能力。

Tip 11 把验证当系统，而非步骤

最常见的做法是让 Agent 先写码，测试当作事后的补丁，写到一半才想起补几个单元测试，或者随手「点开页面看看效果」就算数。Cole Medin 反复强调，验证必须前置，在写任何代码之前，就该规划好整套验证体系。

写码前要规划四块内容。

• Agent 检查自己工作的工具

• 单测与集成测试的书写约定

• 之后人工测试的方式

• Agent 寻找边界用例的规则

写码前先想清楚怎么验证，是让编码工作流更可靠的做法之一。

小结，一张能照着做的清单

把 11 条串起来看，主线只有两条，减少 Agent 的假设与用确定性机制兜底。落到能立刻照做的动作上，值得逐条核对的有六点。

• 规则写具体

  ，也写精简，防过时

• 承重交给 hook

  ，该必然发生就必然发生

• 控制并行

  ，少开 subagent，盯着 /usage

• 会话保持干净

  ，被污染的直接重开，别让错误越积越多

• 审批交给新视角

  ，写作者不审自己的成果

• 迭代适可而止

  ，验证前置到写码之前

值得先试起来的一条，打开项目文件夹，把规则文件过一遍，凡是引用已删除文件、已改名目录、被替换组件的内容，当场删掉或更新。这一步不需要任何新工具，几分钟就能做完，却是让 Agent 不再跑偏的起点。

本文参考视频为 Cole Medin 的《11 Tiny Coding Agent Fixes With A Stupid Amount Of Payoff》，即《11 个微小的编码 Agent 修复，带来巨大回报》。

参考资料，研究出处

正文里的数据都有出处。Cole Medin 在视频简介里逐条列了引用的 arXiv 论文，整理成下表，方便按需深挖。请使用https://arxiv.org/abs/前缀跟表格中的编辑进行访问。

支撑哪条	研究在说什么	arXiv
Tip 1 写给 Agent	面向 Agent 写具体指令的效果	2608.20195
Tip 2 规则会过时	约四分之一仓库的 AI 规则已过期	2606.09090
Tip 3 别用 /compact	压缩后只剩约 10% 的具体细节	2608.22752
Tip 3 补充	压缩还会侵蚀安全约束	2606.22528
Tip 5 上下文做减法	少上下文优于多上下文	2606.10209
Tip 5 补充	没有 AI 配置的项目，复杂度增长约一倍	2608.25241
Tip 7 别中途升级模型	中途换更大模型只挽回不到一半差距	2608.24358
Tip 8 别用协调者	给协调者命名并不会让结果更好	2608.16801
Tip 10 别过度迭代	85% 的案例里，前一轮已有更好答案	2607.24604
Tip 11 验证前置	Agent 的可靠性究竟来自哪里	2607.17044

正文 Tip 2 提到的规则审计技能，开源在 Cole Medin 的 skills 仓库，地址 github.com/coleam00/skills。技能目录为 .claude/skills/rules-check-drift，安装后以 /rules-check-drift 触发，运行时会对比 CLAUDE.md 与代码库现状，找出已经过时的规则条目。

如果这篇笔记对实践有启发，建议收藏，下次调整编码工作流时照着核对一遍。

#AI编程 #CodingAgent #ClaudeCode #AI工作流 #AI效率 #编码Agent #效率工具 #编程工具 #代码评审 #开发效率