Zeroshot：让写代码的 AI 不能给自己打分，用独立评审与有界修复循环交付代码

它要解决的问题

AI 编码代理最常见的毛病，不是写不出代码，而是写完之后自己宣布「已经好了」。同一个模型既负责实现，又负责验收，等于让考生给自己判卷。

Zeroshot 的核心主张只有一句话：写代码的代理，不应该是决定代码能不能用的那一个。项目团队在自述里说，他们做这个工具，是因为受够了被代理「煤气灯式」地误导，明明是坏代码，却被告知可以交付。

核心架构：显式的多代理图

Zeroshot 把一个软件目标变成一张显式的多代理图。图中有一个代理负责实现，若干个独立代理负责评审。评审不通过，任务就进入一个有上限的修复循环。只有图里设定的全部检查都通过，成果才会被交付。实现代码的代理永远不能批准自己的工作，这是整个设计的硬约束。

定位同样关键。Zeroshot 不替代 Claude Code、Codex 或 GitHub Copilot，而是把其中之一当作 worker 和 reviewer 来运行。也就是说，它不是又一个编码模型，而是套在现有编码代理外面的编排层与问责层。用户可以使用内置的图，也可以自带拓扑：增加评审者、测试和修复循环，再把这套配置保存为 profile，留给下一个任务复用。

工作机制与使用流程

安装只需一条命令：npm install -g @the-open-engine-company/zeroshot。安装器要求 Node.js 18 或更高版本，并为 Linux x64/arm64、macOS x64/arm64 或 Windows x64 安装一个经过校验的原生二进制。它还会在用户级别，为 Codex、GitHub Copilot 和 Claude Code 安装同一个 Zeroshot skill。 本地执行时，用户需要先安装并登录 Codex、Claude Code 或 GitHub Copilot 之一。Zeroshot 可以直接复用该工具已有的登录状态，包括订阅制会话。 运行一个任务需要两个 JSON 文件。input.json 描述任务，例如「给 status 命令增加 JSON 输出，并补上针对性的测试」。runtime.json 指定运行时：harness（如 codex）、provider（如 openai）、model 和 effort（如 high）。随后执行 zeroshot run，并指定 --template software-change 与 --uniform-runtime-config runtime.json。从参数名可以看出，这个选项让图中的各个代理共用同一份运行时配置。加上 --validate-only，可以先检查图、运行时配置和输入是否合法，而不真正启动。

有一个必须记住的事实：worker 会直接修改当前的 Git 工作树。因此官方建议，在一个专门为该任务准备的干净工作树里启动。

为什么独立评审是合理的工程选择

以下是我们的分析，不是项目自己公布的数据。第一，实现者和验收者角色分离，可以打破自我确认的闭环：写代码的上下文里已经带着「我这样做是对的」的假设，换一个没有这段历史的代理来看，更容易发现遗漏。

第二，修复循环被设了上限，这在工程上很重要。没有上限的「评审、修复、再评审」可能无限消耗额度，有上限则把成本和时间变成可预期的量。第三，把拓扑当成可配置的数据，而不是写死的流程，团队就能按任务风险调整：改一行文档用轻图，改支付逻辑用多评审者加测试的重图。

性能与成本

需要说清楚：我们读到的材料里没有公开的基准测试数字，所以无法给出通过率、缺陷拦截率或延迟的提升幅度。README 里的视频标注为脚本化演示，只能算示意，不能当作证据。

可以确定的是成本结构：多个代理意味着更多的模型调用和更长的墙钟时间。本地运行如果复用订阅登录，边际成本会落在订阅额度上。云端版本 Zeroshot Cloud 的定价，请查看官网 zeroshot.sh。

对开发者与企业的影响

对个人开发者，Zeroshot 把「让另一个代理再看一遍」这个手工习惯，变成一条可重复执行的命令。对团队，它提供了一个与具体模型厂商解耦的验收层：底层可以是 Codex，也可以是 Claude Code 或 Copilot。

项目采用 MIT 许可，通过 npm 分发，仓库带有构建、覆盖率和文档的持续集成标记，说明它按正式软件的方式维护。项目还声称有来自多家大型科技公司的工程师加星，这是项目方的自述，我们没有独立核实。

与常见做法的对比

目前多数团队的做法，是让同一个代理在一次对话里写完代码、跑完测试，再自己总结「全部通过」。这种流程的问题在于，验收标准、实现过程和最终结论都出自同一个上下文，错误很容易被一并带过。另一种常见做法是人工逐行审查，可靠但耗时，也难以随任务数量扩展。

Zeroshot 走的是中间路线：把审查这一步交给独立的代理，并把整个流程写成图，让每一步的输入、输出和通过条件都清楚可查。人仍然可以在最后把关，但不必再从零开始检查每一处改动。这套流程能否真正省下人力，还要看后续公开的数据。

局限与挑战

第一，没有公开基准，价值主张目前主要靠设计逻辑支撑。第二，独立评审的价值取决于独立程度。如果评审者与实现者用同一个模型家族，它们可能共享同样的盲区。

第三，有上限的修复循环意味着任务可能在上限内仍未通过，使用者要为这种结果设计后续处理。第四，worker 直接改写当前工作树，没有干净的起点就有风险。第五，v8 是硬性的接口切换，用原生二进制取代了 Node.js 运行时，旧版本的用户需要迁移。

未来走向

如果项目方后续公布可复现的基准，例如在同一批任务上对比单代理与带评审图的通过率和总成本，这类工具的价值就能被量化。

另一个值得关注的方向是 profile 的共享：团队把针对不同风险等级调好的图沉淀下来，会逐渐形成一套组织内的交付标准。无论如何，「写的人不能自己验收」这条原则，已经成为 AI 辅助编程里越来越难回避的工程底线。