键盘这次不在你手边，在它那边。
举个常见的例子：agent 提交了改动，只留一句「已修复」。你打开 diff 会发现，它顺手重构了两个文件、加了一个配置项，还把原本失败的那条测试断言改成了通过。测试是绿的。
这不太像偷懒。更常见的情况是：它不知道什么算完成，而你从来没把「完成」写下来。你把判断权留给了它，它就自己编了一个判断标准，然后按那个标准宣布成功。
上一篇把带初级开发者这件事拆成三步：先分清卡在哪，再决定给多少帮助，最后确认他能接上下一步。搬到 agent 上，前两步基本不变，第三步得换：它不记得这次的判断，所以要它当场交出证据，再靠沉淀把判断留下来。照搬的话，结果往往就是上面这类 diff。
三个前提变了
它这次学到的东西留不到下一轮，除非你写下来。 人的经验能跨任务迁移，一次讲清的分层约定，下次遇到同类问题会用上。多数编码 agent 在会话结束后不保留这次的判断。你不把结论外化成规则、测试或示例，它下次会以同样的方式再犯一次，而你再解释一次。
它不会累到主动开口求助。 人卡住会痛，会来打断你；agent 卡住往往自信地继续。等它开口说「我需要更多上下文」，通常已经晚了一步。
它的「理解」不可观察。 你没法靠观察判断它是否明白，只能从 diff、命令和输出推断。所以验收标准必须前置，而不是事后争论。
第一步：分清它是哪一种卡住
三类卡点，处理方式完全不同：
| 卡点 | 常见表现 | 你该先做什么 |
|---|---|---|
| 目标歧义 | 做了个合理但你不想要的东西；范围超出任务本身 | 写清验收标准，再让它动手 |
| 上下文缺失 | 用错 API、重复实现已有的工具函数、忽略项目约定 | 给文件路径和同类实现 |
| 假设错了 | 反复改同一处、越改越大、把症状当成位置 | 一起看证据，换假设 |
先分清这三类，再动手改 prompt。混在一起的典型后果是：你以为它在理解上出问题，于是补了一大段背景说明；其实它只是不知道哪条命令算通过。
判断依据不是它的自述，而是四样可查的东西：
- 它读了哪些文件（工具调用记录）
- diff 覆盖了几个文件、几处改动
- 它跑了什么命令、输出了什么
- 它说的「通过」对应哪一条断言
原文给人类的四个起始问题——你想让它发生什么、现在实际发生什么、哪一部分不清楚、你需要的是背景还是视角——在这里要换一种用法。你当然可以直接问它，但它给的是自述，不是证据。这四个问题更像是你查 diff 时的四个视角。
一个假设场景：agent 说「修好了」，diff 里却改了测试断言。第一反应不该是「它在作弊」，而是「它不知道验收标准由谁定义」。这是目标歧义，不是能力问题。补一句「测试文件不许改」，往往比补一段解释更有效。
目标歧义时，先写验收标准
「你再试几次」对 agent 基本无效。它不会累，往往只会在同一个方向上更自信。
验收标准要写成可执行的三段：跑哪条命令、期望看到什么、哪些文件不许动。少任何一段，它都有空间自己补全。
第二步：决定给什么
目标清楚之后，帮助的强度可以选。四种给法：
| 做法 | 能给什么 | 容易怎么走坏 |
|---|---|---|
| 追问澄清 | 让它先复述任务和验收标准 | 复述得很漂亮，执行照旧 |
| 给定位 | 省掉它自己找文件的往返 | 变成照我说的改，它不再判断 |
| 给答案 | 消掉一个具体的信息缺口 | 跳过它本可以自己读出的结论 |
| 给示例 | 最省事的一种对齐方式 | 示例被当成模式复制到全库 |
没有人规定不能直接给答案。缺一条具体的 API 用法时，说清楚比让它翻三遍源码快得多。要留意的是：给答案跳过的那段推理，是不是这次本来想让它的判断自己长出来。
给示例要带边界。 对人类，演示一遍是学习机会；对 agent，示例往往会被当成模式。你给的一个示例，它可能理解成「所有相似位置都该这样改」。所以给示例时一起给范围：只改这个类、只改这一处、其他位置保持原样。
上下文不是越多越好。 人会自动过滤无关信息，agent 通常不会。把整个目录、全部历史对话倒进去，关键那条约束反而被稀释。给上下文的原则是：只给会改变它判断的东西。
任务拉长之后，早期说过的约束同样会被稀释。定期重述关键约束，比一次性补一大段说明有效。
第三步：让它自己交出证据
不要手改它的 diff。这句有两层理由：一是你手改之后，它下一轮基于你的改动继续推，并不知道你改了什么、为什么改；二是你的判断留在你脑子里，没写下来，下次还得再改一遍。改动紧急时该救火还是救火，差别在于事后有没有把原因写下来。
这不等于放任。前提是你必须能读懂它的 diff。看不懂，多半是你这边还没建立判断，不是它没修好。
收尾要它交四样东西：
- 改了什么，范围多大
- 为什么这么改，对应哪条需求或约束
- 用什么命令验证的
- 还有什么没覆盖
说不出来，就是没理解，回到第二步补依据；说得出来，也要真跑一遍命令。
这里的判断标准和带人不一样。带人时，「懂了」看他能不能解释；带 agent 时，「懂了」看它能不能产出可复现的验证。措辞漂亮不算证据。
什么算这次带成功了
带人成功的标志是他下次能自己做。带 agent 不是这样：多数 agent 下一轮不记得这次的判断。
所以成功的标志换成：这次的判断被沉淀下来了。三种沉淀方式：
- 规则：写进 AGENTS.md、项目约定，或代码注释里的约束
- 测试：把这次的失败场景写成测试，下次它必然撞上
- 示例：留一个模板或参考实现，下次照着做
三种都是文件，不是记忆。这是 agent 版的「成长」——成长发生在仓库里，不在模型里。
边界
你也不知道要什么的时候。 先自己探明目标，再交给它。让它替你定义目标，你会得到一个合理的错误答案，而且很难在 diff 里看出哪里错了。
高风险改动。 数据迁移、批量删除、权限变更这类操作，直接介入，别让它试。原文也划了这条边界：风险高、时间紧时直接介入，并说清这次只是处理眼前这件事，不是在立默认模式。
下次它说「修好了」
先别回 prompt，先看三样证据：diff 覆盖了哪些文件、范围有没有超出任务；它跑了什么命令、验证是真的还是自述的；它读了哪些文件、上下文够不够。
看完再决定给什么。多数时候你需要补的不是解释，而是验收标准。
然后确认最后一件事：这次的判断落进了哪个文件——AGENTS.md、测试还是示例。落不进去，下次还得重来一遍。
如果你也在把编码 agent 接进日常工作，Aide Hub 会继续写 agent 协作、开发工具与软件工程实践。
参考
- How to Help Junior Developers Without Doing Their Work — 原文，Nick Cosentino，Dev Leader。三步框架来自这篇；三处前提差异与 agent 场景下的具体做法是本文的迁移与补充。