我是怎么管理 Coding Agent 的：把任务交出去，也把结果验回来

当 Coding Agent 能自己读代码、改文件、跑测试之后，我发现自己的工作里多了一部分"管理"：选择任务、交代背景、跟进偏差、检查结果，最后决定哪些改动可以交付。

这不要求我转去做管理岗，也不意味着智能体可以替代同事。它只是改变了我与工具协作的方式：让智能体知道目标和边界，给它验证工作的办法，同时保留我自己的判断。

下面这些做法适用于 Claude Code、Codex 等能够操作项目的智能体。命令名称因工具和版本而异，但交接、验证和审阅的问题是相通的。文中还会用一次 Seed 配表实验说明：即使流程执行得很完整，结果仍然可能有问题。

一、先给它验证工作的办法

我给智能体派任务时，最先想的一件事是：它怎么知道自己做对了？

如果只说"把登录问题修好"，它可能修改代码，看到没有明显报错，就报告完成。真正的验证工作随后落到我身上：自己启动项目、重复操作、查找边界情况。每次都这样，我就成了它的测试套件。

更好的交接方式，是把验收办法一起交给它。例如：

修复登录失败后的跳转问题。先找到项目现有的身份认证测试，运行与这次改动有关的用例；如果失败，检查原因并修复后重跑。完成时列出执行过的命令、结果和没有覆盖到的情况。

不同任务需要不同证据。代码改动可以看测试、构建和代码差异；界面改动需要实际打开页面，检查关键操作与不同尺寸下的截图；修改表格或其他数据文件时，要保留原件，核对候选文件和逐项差异。

我通常会把验证写成一个能反复执行的小循环：先让它运行检查，再根据失败信息定位问题，修改后重跑同一项检查。修复一个用例时，也要看它有没有破坏相邻行为；如果环境缺依赖、权限不足或测试本来就失败，应该把这些情况写进结果，而不是把"没跑起来"说成通过。

这些检查也可以接入智能体的工作过程：

• 直接要求。 在任务里说明要运行哪些检查、失败后怎么处理、最后提供什么证据。
• 设定持续目标。 在支持的 Claude Code 环境里，可以用 /goal 围绕明确条件继续工作；目标仍要具体到能检查，不能只写"把项目做好"。
• 设置自动门槛。 对确实不能跳过的要求，可以配置 Stop 钩子或其他自动检查；要确认门槛真的生效，也要设置停止条件，避免失败后无限循环。
• 安排独立审查。 换一个没有参与实现的上下文审查，或使用工具提供的 /code-review。我会先说明审查范围，比如只找正确性和边界问题，暂时不讨论代码风格。

以登录问题为例，测试检查的是既有断言是否通过，实际页面操作能补充"用户输入、提交、跳转"这一段体验；如果只检查首页能不能打开，就没有覆盖登录失败后的路径。检查什么，要跟这次任务的目标对应。

测试通过是证据，但证据有范围：测试只能覆盖已经写进用例的行为，截图也只能展示截取时的页面状态。它们能帮我减少重复检查，却不能替我决定产品取舍或发布风险。

二、把背景交代清楚，尤其是仓库里看不到的部分

智能体接到开发任务后，通常可以自己读取目录、代码和已有测试。我不会把它能查到的文件结构重新讲一遍，而是优先补充它看不到的背景：谁会用、为什么现在要做、有哪些既定决定，以及什么不能动。

比如，"让团队看板快一点"就很难直接验收。下面是一份更清楚的交接示例：

目标：让大组织的团队看板加载更快。

示例验收：1 万人及以上的组织，
p95 加载时间低于 2 秒。

原因：管理员每天都要使用这个页面。
约束：不修改数据库结构和 API 响应。
不做：界面重设计、整页缓存。
验证：运行项目实际存在的性能脚本，
记录相同测试条件下改动前后的结果。

这里的 p95 指按这次测量口径，95% 的观测耗时不高于该数值。示例里的组织规模和时间只是演示怎样写任务，不是实测成绩；实际项目还要明确测试环境、样本和测量方法。

如果连我自己也不确定需求，我会先让智能体提问，把答案整理成规格说明；等目标、范围和未决问题清楚了，再开始实现。需要访问问题追踪系统或监控数据时，也要说明入口和权限，不能默认它知道团队里的约定。

三、同一个问题纠正两次，就考虑把经验留下来

项目里总有些容易反复说的事：测试命令在哪儿、某个目录为什么不能改、一个看似奇怪的实现背后有什么业务约束。

如果我每次开新会话都手动交代，早晚会有一次忘记。值得长期保留的信息，可以整理进项目的 CLAUDE.md、AGENTS.md，或当前工具支持的项目说明；重复执行的工作流，也可以做成共享技能。

我通常只记录四类内容：

1. 项目中实际可用的验证命令和前提。
2. 代码里容易被误解的约定。
3. 仓库中看不出的重要决定。
4. 已经反复出现、值得避免的具体错误。

比如，团队连续两次发现智能体修改了自动生成文件，我不会只追加一句"下次小心"，而会先确认生成入口和正确修改位置，再把这两个事实写进项目说明。下一次它读到的就是一条可操作的约定，而不只是一次会话里的纠正。

记录也要定期清理。模型、工具和项目都在变化，一条适合旧环境的规则，放久了可能只剩下额外负担。规则越长，越需要判断它是否仍在解决真实问题。

四、一般约定留给它判断，不能违反的底线要能执行

我会区分两类要求。

"尽量沿用项目现有写法"适合写在说明或技能里，让智能体结合当前代码判断；"不允许覆盖生产数据"则需要权限、沙箱、保护分支或自动检查等更可靠的约束。

如果一条重要要求反复写在说明里，却还是会被忽略，我会考虑能否把它变成真正可执行的门槛。反过来，如果一个钩子只是在强制个人偏好，让每个简单任务都必须绕远路，也该重新评估是否需要。

这里没有哪一种机制可以无条件兜底。权限规则、沙箱和钩子都依赖配置；设好之后，还要检查它们在当前环境里是否真的会生效。

五、复杂任务先看计划，再让它动手

改一个按钮文案，没必要先写几页方案。但如果任务涉及多个模块、共享接口或难以回退的数据，我会先让智能体列出计划：准备读什么、改哪里、怎么验证、哪些地方仍有疑问。

审计划时，我重点看范围有没有膨胀、假设有没有证据、任务之间是否真的独立。必要时，我会让没有参与规划的会话再审一次，专门找遗漏的前提和风险。

审阅时可以具体问："这个方案依赖哪些尚未验证的假设？""最小修改需要碰哪些文件？""测试能否覆盖失败路径？"计划不是越长越好；如果一份方案把无关重构、新依赖也带进来，就要回到原始目标，先删掉不必要的工作。

Claude Code 的 /batch 可以把大型改动拆成独立单元，先展示计划，再在批准后使用隔离的工作树并行处理。工作树可以理解为同一仓库的独立工作副本。它有助于减少互相覆盖，但不能自动解决所有依赖：如果几个任务都要改同一个接口，仍然需要先约定接口和合并顺序。

例如，要同时改前端、接口和数据处理逻辑，三个任务可能都依赖同一份响应格式。此时先讨论字段名、错误处理和兼容要求，再拆开实现，比让三个会话各自猜测更容易合并。反过来，如果只是两个互不关联的文案修改，就没必要为了并行额外设计复杂流程。

并行的前提是任务能分开，而我也有能力审完每一份结果。

六、尽早纠偏；反复纠正无效时，重写任务

智能体刚开始执行时，我会留意它有没有读错文件、误解目标，或提前触碰边界。方向明显不对，就尽早中断，重新说明；等它完成一大堆改动之后再处理，返工范围往往更大。

同一问题纠正两次还没有改善时，我会停下来检查任务说明：是不是缺少背景？约束是否互相冲突？有没有给出正确示例？整理好这些信息后，必要时用新的会话重新交接。

"两次"是提醒我换个方式思考的经验做法，并非所有情况都必须机械地重新开始。

在支持的环境中，Claude Code 的 /rewind 可以恢复部分已跟踪的文件编辑或对话。但只由 Bash 修改过的文件、其他会话或子智能体的改动，不一定会跟着恢复；外部系统里的操作更不能假设能够撤销。检查点适合快速回退，版本控制和备份仍然需要。

七、工作可以委派，判断不能一起交出去

智能体能写代码、跟进审查意见、运行测试，但它无法替我承担上线之后的产品和安全责任。审阅结果时，我会问自己：如果这次改动出问题，我能否解释它改了什么、为什么改，以及怎么处理后果？

执行过程中，它可以自己处理"改哪里、重跑哪条检查"这类细节；我需要掌握的是更外层的目标、约束、证据和审批。这个分工并不要求我盯住每次工具调用，却要求我在接收结果时真正读懂关键差异。

下面这次配表实验让我对"流程完成"和"结果正确"的区别有了更具体的认识。

我准备了一份 40 行商品、11 列的原创配置表，给 Seed 一句指令：

把所有库存低于 10 的商品标记为"需要补货"；咖啡类商品价格上调 5%；其他单元格不要改。

实验一共运行 15 次：10 次使用配表技能，其中 lite 和 pro 各 5 次；另 5 次使用 lite，不加载这套配表技能。随后，我根据保留的会话和文件，用独立脚本逐格核对。

10 次技能流程都生成了候选副本并保留工作文件；不加载该技能的 5 次都直接修改了实验工作文件，其中两次另留了备份。实验使用的母表没有被修改。

技能流程会先检查表格，再进行预览、生成候选文件、输出差异并校验。正式实验前的一次连通性预试还出现过另一种情况：Bash 工具的权限请求失败，智能体仍按指令回复了完成标记。这只是一次预试，不能据此概括模型的普遍表现，但足以说明要核对工具返回和实际产物。

但在 10 次技能流程中，有 5 次把"需要补货"写进了原有的"上架状态"列，覆盖了"在售"或"已下架"。流程让改动更容易审查，却没有替我把含糊的业务要求解释正确。

例如，在 skill-pro-03 这次运行中，商品 90001 的价格从 68 改到 71.4，符合调价要求；同一行的状态却从"在售"变成了"需要补货"。

实验里还有一个容易忽略的细节：一次技能流程为了遵循"写审计备注"的默认约定，修改了咖啡商品的备注列；但原指令明确说了"其他单元格不要改"。这说明工具自带的默认流程也可能与当前任务冲突，不能只因为它来自技能就直接放行。

没有加载该技能的一次运行也覆盖了两条原有备注。两种情况都说明，审阅时需要看到改动前后的具体值，不能只凭"使用了技能"或"没有使用技能"来判断哪个结果可靠。

这里还有两个限制：每种配置只运行了 5 次，不能把比例当成其他项目的错误概率；"标记写入备注列"是这次核对所采用的口径，如果业务要求另建一列，正确答案也要随之改变。

回到代码审查也是一样。假设智能体调研竞品之后，准备了一大批新功能：测试全绿，只说明已有测试通过；这些功能是否有人需要、是否引入多余配置、我能否长期维护，仍然要逐项判断。把改动拆小，也是在控制我每次需要理解和承担的范围。

这次实验使用了开源 ai-config-table-skill，实验设计和更多核对结果在这里。如果要把类似任务用于真实业务，我会在开始前明确标记写入哪一列、怎样处理已有备注、价格按什么规则取整，再让智能体先生成副本和差异。

八、让任务无人值守之前，先写清五件事

让智能体在后台运行，不等于把一句需求丢给它就离开。启动前，我会把下面五个问题写下来：

1. 完成条件： 什么结果算完成？
2. 自行验证： 用哪些测试或检查证明结果，证据保存在哪里？
3. 操作范围： 可以访问和修改哪些文件、分支或环境？
4. 运行护栏： 反复失败、时间或费用达到上限时怎么办？
5. 交付审批： 最终结果交给谁，哪些操作需要人来决定？

这五项可以直接放进后台任务说明。例如："只处理指定目录中的三个文件；每个文件保留修改前后差异；完成后运行现有检查；连续失败达到预设次数就停止并报告；结果先交给我审阅。"文件范围、次数和检查命令都应替换为实际值。

第一次运行新流程时，我倾向于先选少量样本。例如一项批量修改可以先处理三个文件，检查输入、输出和失败处理，再决定是否扩大。遇到关键前提不明、碰到操作边界或反复失败时，应保留现场并停下来，而不是不停重试。

九、并行越多，越要算上协调和审查的成本

同时开多个会话看上去很快，但每个会话都可能带来状态跟踪、接口协调、合并冲突和结果审阅。我把这部分额外投入称为"编排税"。

如果两个会话互不相关，一个负责查找失败测试，另一个整理独立模块的文档，我可以并行等待；如果它们都在改同一处状态管理，就需要先解决共享边界。是否值得并行，取决于任务依赖和审查容量。

没有一个适合所有人的并行数量。如果待审改动持续积压，或我已经说不清各个任务之间的依赖，就说明当前的验证能力跟不上了。比起盲目增加会话，更有用的是先把测试、状态汇总和独立审查安排好，让注意力集中在需要作决定的地方。

衡量产出时也要成对看：交付周期可以和返工、回退一起观察。只看 AI 写了多少行代码或生成了多少 PR，容易把活动量当成实际价值。

十、实现变便宜以后，更要决定哪些事情不做

智能体可以很快把一个想法变成代码，但这不意味着每个想法都值得进入产品。每多一个功能，后面就多一份审查、安全、支持和维护工作。

启动前，我会先问：谁需要它？怎么判断成功？什么情况下应该停止？如果这些问题还没有答案，就先澄清或暂缓；同时限制正在进行的任务，把审查时间留给最重要的改动。

十一、管理智能体和管理人，边界在哪里？

这个类比对我有帮助，但我不会因此把智能体当作一位真正的工程师。

管理人涉及激励、冲突、职业发展和长期信任；能同时运行几个智能体，并不能说明我已经具备管理同样人数的能力。智能体也可能非常自信地接受错误前提，所以我会要求它提出反例和疑点，再用独立证据核对。

记忆同样有边界。笔记能否跨设备或团队共享，取决于工具和配置；重要的项目知识仍应放在团队能够查看和维护的位置。模型更新后，原来的优劣势和限制也可能变化，旧规则需要重新检查。

当智能体接手部分入门任务，初级开发者仍需要练习和反馈。人与人的协作、讨论和成长，不能被一排后台会话替代。

一张可以直接复制的任务卡

如果只想先尝试一项改动，可以把下面这段填好后交给智能体：

任务目标：
为【谁】解决【什么问题】，期望【可观察的结果】。

必要背景：
【仓库里看不到的业务原因、已有决定和限制】

修改边界：
允许修改【范围】；不要修改【文件、数据或行为】。
本次不做【明确排除的事项】。

执行与验证：
先检查现有实现，列出计划和疑问，再做最小必要修改。
运行项目中适用的【测试 / 构建 / 脚本】，提供命令和结果。
展示关键差异；无法验证的部分要说明原因。

交付：
列出完成内容、验证结果、剩余风险，以及需要我决定的事项。

独立审查时，我还会补充一句："只检查这次改动的正确性和边界条件；发现问题时说明文件位置、触发条件和证据，不确定的地方明确标出。"这样审阅范围更清楚，也方便我决定哪些意见需要处理。

具体命令要换成项目里真实存在、当前环境能够运行的命令。界面任务再补页面操作和多尺寸截图；文件或数据任务再补原件保护和逐项差异。

我越来越重视的，是在交出任务之前就说清楚"做到什么程度"，在收到结果之后看证据、读改动、作决定。这些动作不需要管理头衔，但它们决定了智能体产生的结果能不能放心交付。