用桌面看板审查编程Agent计划与改动

同时开几个 coding agent，代码可能写得更快，审查却容易跟不上：哪个任务正在做、改动是否偏离要求、哪些代码还没看，很快就散落在不同终端里。Coppice 作者遇到的正是这个问题，于是做了一个本地桌面看板，把任务、计划和代码差异集中起来。

它的核心设计是两道人为关卡：先批准计划，再审查 diff，而且接受改动与合并分开。对已经在用 CLI agent 的程序员，这篇短文提供了一个值得参考的工作流，但还没有证明它能减少多少错误。

多开几个 agent，为什么反而更难审查

作者开发 Coppice 的起点，是自己同时在多个终端运行编程 agent 的经历。他发现自己越来越难追踪每个 agent 在做什么，有些错误在他看到之前就已经落进了代码里。

问题出在人的注意力没有跟着任务数量一起增加。多个 agent 可以同时推进，审查者却需要不断切换上下文：这个任务原本要解决什么、采用了哪个方案、眼前这份改动是否符合预期。

Coppice 的应对方式，是用一个本地桌面看板驱动已有的 CLI agent。原文列举了 Claude Code、Codex、Cursor、OpenCode，用户在其中充当管理者。

看板在这里承担的不只是展示进度的作用，还控制任务能否继续推进。作者强调，没有用户参与批准，任务不会自行启动。

两道关卡分别拦住什么

第一道关卡放在执行计划上。

用户先写一张任务单，也可以批准 agent 提议的任务，再由 PM agent 起草计划。这里的 PM agent 可以理解为负责拆解任务、提出执行方案的角色。计划进入 Plan Review 后，Coppice 会让任务停在那里，直到用户同意。

这一步让审查提前发生。对于可能理解错需求的 agent，在它开始大幅改代码之前纠正方向，通常比看完一大份 diff 再返工更容易。

第二道关卡放在代码改动上。

每份 diff，也就是代码变更差异，都会等待用户在应用内的 diff 编辑器中审查。用户留下的评论会回传给 agent，让它继续修改。

Accept 不会触发 Merge，合并是另一个独立动作。

这个区分很实用。认可一份改动，与决定现在把它合进去，是两个不同的判断。Coppice 在交互上把它们拆开，给用户保留了最后的合并控制权。

原文还说明，应用运行在用户自己的机器上，内置数据库，不需要 Coppice 账号，也没有第二份订阅。这里说的是 Coppice 自身的使用方式，不能据此推断底层 agent 的模型调用免费，或所有数据都不会离开本机。

我的判断

我赞同把计划审查和代码审查拆开。前者检查「准备怎么做」，后者检查「实际做成了什么」。尤其是多个 agent 同时工作时，只在最后集中看代码，很容易丢掉需求与实现之间的对应关系。

不过，这篇原文更接近产品介绍。作者给出了个人痛点和产品流程，没有提供错误率、审查耗时、任务吞吐量等对照数据。因此，Coppice 能让审查更有效，目前仍是作者的经验判断。

它也有一个前提：用户愿意并且有时间认真处理两道关卡。如果计划只是机械点通过，diff 也只扫一眼，看板无法替人完成判断；任务较多时，人工审批还可能成为新的等待点。

与终端配合 Git、PR 审查相比，Coppice 的吸引力是把 agent 调度和反馈收进同一个界面。原文没有说清多 agent 如何隔离工作目录、如何处理冲突，以及 Merge 前能否强制检查测试结果。已有成熟 PR 流程的团队，需要先确认它怎样接入现有流程。

能拿来做什么

• 同时使用多个 CLI agent 时，可以先统一记录任务、当前计划和待审改动，减少靠终端窗口位置记进度的负担。
• 让 agent 修改前端交互或 Node 业务逻辑前，先审查它准备改哪些位置、如何验证，再决定是否进入实现阶段。
• 审查 diff 时，把修改意见回传给 agent，并明确区分「接受这份改动」和「允许合并」，避免一次点击承担两种决策。
• 评估 Coppice 时，拿一个熟悉的小任务走完计划批准、评论反馈、接受和合并流程，重点检查它能否接上现有 Git 与测试习惯。