17 分钟视频里的 11 条建议其实是 5 层护栏:上下文管理、事件级保障、会话卫生、并发与迭代硬边界、独立评审。附可以直接抄的钩子配置、交接文模板、规则审计 prompt 和评审 Agent prompt。
Cole Medin 上周发了一期视频《11 Tiny Coding Agent Fixes With A Stupid Amount Of Payoff》(原视频链接),17 分钟给了 11 条让 Claude Code、Cursor、Codex 这类编码 Agent 更靠谱的做法。视频本身有中文自动字幕可看,我不想再逐条翻译一遍——那对已经看过的读者是浪费,对没看过的读者不如直接去看原片。
真正值得写的,是把这 11 条重新排一次。先说例外:原视频第 8 条讲的是"目前 orchestrator 协调多个 Agent 还不够可靠、别急着上",那是一个反面结论(先别做这件事),不构成一层可落地的护栏,我没有把它编进结构。所以下文按剩下的 10 条来重排——它们并不是 10 个平行的技巧,而是一套"确定性护栏"里的 5 个层次:上下文管理 → 事件级保障 → 会话卫生 → 并发与迭代的硬边界 → 独立评审。看清楚这个结构,你就能判断自己团队现在缺哪一层,而不是被清单淹没。
下面每一层我都会给出可以直接抄的模板:规则审计 prompt、hooks 的最小配置骨架、交接文的字段清单、评审 Agent 的启动 prompt。这也是这篇文章相对 Cole 原视频要加的东西——他讲了"为什么",落地的"怎么做"要自己补。
Cole 的第 1、2、5 条,本质是同一件事的两面:给 Agent 写的规则,跟给人写的文档不同。人可以在模糊里补全,Agent 不行。
先说节流。他引用 Anthropic 的官方建议:全局规则最好控制在 200 行以内。我自己的经验线是 300 行封顶。超过就要拆——不是拆到别的文件里全局加载,而是拆成"处理这类任务时才读的上下文文件"。原因是模型的注意力是有限的稀缺资源,塞得越多,具体命令越容易被淹没。那些"Don't repeat yourself""Keep it simple"式的口号写在全局规则里,属于纯纯的负载,2026 年的模型不需要你教它这些。
再说防漂移。他引用的那份研究说,四分之一带 AI 层的仓库里,规则文件已经和代码库对不上号——引用了被删掉的目录、被换掉的数据库、被重命名的模块。这个问题不会自愈,只会越攒越多。Cole 说他有个 skill 专门跑规则漂移审计,视频里没给出完整 prompt,我用起来发现真正管用的版本大概是这样:
你是仓库审计员。任务:把 CLAUDE.md / AGENTS.md 里的每一条规则,
拆成"事实主张"清单(每条一行,标注出处:规则文件第几行)。
然后对每条事实主张,去代码库里找证据:
- 提到的文件路径是否存在?
- 提到的命令是否能在 package.json / Makefile / CI 里找到?
- 提到的目录组织是否与当前仓库结构一致?
- 提到的技术栈(如"我们用 Prisma")是否与实际依赖匹配?
输出三类:仍成立 / 已漂移 / 无法核实。已漂移的给出最小修补建议。
只输出这三类,不要输出"看起来还行"这种主观判断。
把这个 prompt 存成 slash 命令或 skill,每周跑一次,比等它出问题再修便宜得多。
这是 Cole 讲得最漂亮的一条,也是最容易被忽视的一条。核心命题只有一句:大模型是概率的,钩子是确定的。

Hooks: Guarantees, Not Suggestions。图片来源:Cole Medin / YouTube(视频约 6 分 15 秒)
图里的对比非常直白。同样一句话 "After you finish implementing, run the tests":
判断一条规则要不要转成钩子,问自己三个问题:它必须每次都发生吗?它能被写成代码判定成功/失败吗?失败之后应该阻止 Agent 说"我完成了"吗? 三个都是"是",就该转。
Claude Code 的 hooks 配置骨架大致是这样(放在 ~/.claude/settings.json 或 .claude/settings.json):
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "cd $CLAUDE_PROJECT_DIR && pnpm test --run || (echo 'TESTS FAILED - do not claim done' && exit 2)"
}
]
}
]
}
}
exit 2 会把标准错误里的内容以"这次回合还没结束"的形式回喂给 Agent,让它自己去修。这就是那张图右下角绿色路径的实现方式。
再列几类明显适合改成钩子的规则:格式化(PreToolUse 触发 prettier / ruff)、危险命令拦截(PreToolUse 匹配 rm -rf 直接 exit 2)、提交前测试(Stop 触发)、生成的秘密扫描(PostToolUse 触发 gitleaks)。国内团队用 Cursor 的话,等价机制是它的 + tasks / commands,思路一致:把不能靠自觉的事情,用外部命令锁死。
免费获取企业 AI 成熟度诊断报告,发现转型机会
.cursorrules/compact 是记忆漏斗,交接文才是重启方式Cole 的第 3 条和第 7 条其实讲的是同一件事:长对话累积的偏差和幻觉,靠"重新开一段对话"比"继续在原对话里挣扎"更省事。

/compact 前后对比:约 90% 的具体细节丢失,且模型不会告诉你丢了什么,只会自信地重构。图片来源:Cole Medin / YouTube(视频约 4 分 20 秒)
这里有条实证:/compact 之后,大约只有 10% 的具体细节被保留下来。他视频里给的例子——"这个函数在 URL 坏了的时候会返回什么"、"路由的精确前缀"、"哪些测试其实存在"——这些都是压缩摘要抓不住的,但恰好是让接下来的实现不出错的关键。更麻烦的是模型不会告诉你它丢了什么,它会自信地重构一个版本继续往下走。
同样的逻辑也适用于"污染对话":Agent 一旦开始连续犯错,切换到更大的模型不会救你——原对话里的错误模式已经作为"上下文"被下一步预测继承了。大模型是预测机器,它看到前面五步都是错的,最可能预测的第六步也是错的,哪怕它现在换成了 Opus。
所以正确的动作不是 /compact,也不是升模,而是写一份交接文,重开一段对话。交接文可以直接抄这个骨架:
## Handoff: <任务简称>
## 目标
一句话:这个任务最终要交付什么。
## 已完成
- 具体做了什么(引用 commit hash / 文件路径 / 测试名)
- 关键决策点:为什么选了 A 不选 B
## 未完成
- 还剩什么、按什么顺序做
## 已知陷阱
- 试过但走不通的路(避免下一段对话再踩)
- 环境里的暗雷(例如"pnpm test 会启动 mock server,端口 3001 冲突要先 kill")
## 需要保留的字面量
- 具体的类型定义、错误消息原文、外部 API 的确切 shape
(这一段是 /compact 会丢的东西,必须显式列出)
最后这一段是关键。/compact 会丢的正是这些"具体字面量"——精确的类型、原始报错、外部接口的确切 shape。你手写的时候会知道要留下它们,压缩算法不会。
Cole 的第 6 条和第 10 条是同一类:"你以为多多益善的地方,其实要设上限"。

Cole 自己账户的 /usage 输出:39% 的周额度消耗来自"同时开 4 个以上会话"的时段。图片来源:Cole Medin / YouTube(视频约 10 分 32 秒)
第一个硬边界是并发子 Agent 的上限。Claude Code 的 /usage 会告诉你额度到底花在哪儿了。Cole 自己的账户上,39% 的额度是"同时开着 4 个以上会话"时烧掉的——不是这些会话都在干重要的事,而是并行开销本身在吃 token。这里还有一个更容易踩的坑:Claude Code 在你没明确要求的情况下,会自动 spawn 好几个 subagent 去"做深入研究"。如果你的 prompt 是"帮我分析一下这个仓库",很可能它已经在你不知道的情况下起了十来个 subagent。
限并发比想象中重要。国内做 AI 编码工具集成的团队,尤其是把 Claude API 转卖或者做企业版的,几乎都在 rate limit 上被打过。原因不是用户滥用,而是默认行为里的"并行 fan-out"过于激进。给自己团队的实用规则:主 Agent 只做一件事时不允许 spawn subagent;需要 fan-out 的场景(例如跨仓库搜索)明确指定 subagent 数量上限,别放任它自己决定。
第二个硬边界是迭代次数。Cole 引用的那份研究强制编码 Agent 迭代 10-20 次,结果 85% 的场合里,最后一次迭代之前的版本反而更好。这里发生的事是"讨好性优化":大模型倾向于满足用户的请求,你说"再改改让它完美",它就一定会找出点东西来改——哪怕改了之后更差。这是所谓的 sycophancy,实测在国内几家主流大模型上都能复现。
给自己一条硬线:同一段代码,同一个 Agent,最多迭代 3 次。超过这个数还不满意,说明问题在设计不在实现——回到规划阶段,或者干脆按护栏 5 那样,起一段新对话让另一个身份来审。
第 9 条是最短也最狠的一条:永远不要让作者审核作品。
这条为什么值得单列一层?因为它是前面 4 层护栏都护不住的地方。规则、钩子、交接文、迭代上限,全部是"帮 Agent 少犯错"的机制;作者审自己是"确认 Agent 有没有犯错"的机制,前者是过程质量,后者是终局质量,两回事。
作者身份的 Agent 会在实现过程中累积假设——它选择了某个技术路线、忽略了某个 edge case、用某种方式解读了模糊需求。让它自己回头审,它会自动补全这些假设,把"我以为的"当"事实"再看一遍,然后告诉你"没问题"。这个偏差不是模型能力问题,是位置问题:站在实现者位置上就看不到实现者的盲区。
落地非常简单:写完之后开一段新对话,把这次改动作为 diff 或 handoff 提交给它,让它以"reviewer"身份看。评审 Agent 的启动 prompt 我常用这个:
你是这段代码的独立评审员。你没有参与它的实现,只能看到 diff 和实现者留下的 handoff。
你的任务不是找语法错,而是找:
1. Handoff 里没提到、但代码里暗含的假设("这里默认输入是 UTF-8"这类)
2. Edge case 覆盖:null / 空数组 / 超长输入 / 并发调用 / 权限不足
3. 实现和 handoff 声称的目标是否一致
4. 有没有绕过测试或断言的"就地修复"痕迹
每一条都要给出 diff 的具体行号。不要总结,不要夸奖,只列问题。
关键在于最后一句"不要总结、不要夸奖"。默认状态下 LLM 的评审会有大量礼貌性总结,那些内容让报告看着更"完整",但对决策没用,还稀释了真问题的信号。
Cole 的最后一条是把这整套护栏拉回起点:在写第一行代码之前,先把验证框架规划好。
不是"实现完了记得加单元测试",而是从需求开始就想清楚:什么样的输出算对?Agent 自查用哪些工具?集成测试怎么组织?我要在哪一步亲自跑一遍?我希望 Agent 在哪些边界情况上主动打上问号?
如果这套东西是在实现完了之后才补的,它就永远只是"补丁"。作者会围绕已经写好的实现去凑测试,Agent 会围绕通过测试去改代码,绕不回"最初到底要什么"。而把验证框架前置到规划阶段,前面五层护栏才有意义——规则文件里写的是它,钩子里跑的是它,交接文里保留的是它,评审 Agent 依据的还是它。
11 条建议里最容易被当成套话的一条,其实是把整套东西串起来的骨头。这也是为什么我不建议把这 11 条当清单来记——把它拆成 5 层护栏加 1 根骨头,你才会知道自己下一步该修哪一层。
关注公众号

扫码关注,获取最新 AI 资讯
3 步完成企业诊断,获取专属转型建议
已有 200+ 企业完成诊断