你有没有过这样的经历？

让AI帮你写个小工具，吭哧吭哧搞了两个小时，AI突然来一句"任务已完成"，你一看，好家伙，功能只写了一半，一个错误也没处理。

或者，重构一个老项目，刚跑起来感觉还挺顺，结果第二天一看，不知道啥时候它已经停在某个地方不动了。

就是这种感觉，太特么常见了。

今天逛github，我看到一个有意思的项目，叫Goal-Driven，直译过来就是"目标驱动"。开发者lidangzzz已经用这套方法让AI帮他完成了：C++写的TypeScript编译器、Rust写的SQLite。

我看完他的文档之后，真的被这个思路打动了。不是说他用了什么黑科技，而是他的方法有让我们意识到了该怎么跟AI协作——你得让AI知道，它没资格说"任务完成"。

Goal-Driven这套方法论长这样：

目标（Goal）：我要做什么，比如"用C++写一个能正确转译TypeScript到JavaScript的编译器"。

成功标准（Criteria）：怎么算做完了？"必须成功编译2000个涵盖TypeScript语法特性的测试文件，并且在Node.js上运行结果和官方tsc输出一致"。就这种程度的标准，不是"差不多能用"。

子智能体（Subagent）：负责埋头干活的那个，就是Claude Code、Codex或者OpenClaw。它能把大任务拆成小任务，自己给自己分配子任务，层层拆解直到每个小任务都能执行。

主智能体（Master Agent）：这是关键，它不干活，它负责监工。每隔五分钟检查一下子智能体是否还在活跃。如果子智能体变得不活跃、声称完成、或进入空闲状态，主智能体就掏出Criteria来验收。没通过？重启一个新的子智能体，继续干。

伪代码就这几行：

创建子智能体来完成目标while (标准没达到) {    每五分钟检查一次子智能体的活跃状态    如果子智能体不活跃了，或者声称搞完了，或者空闲了        检查当前结果是否达到标准        没达到？重启一个新的子智能体接着干        达到了？收工，结束}

你别笑，就这个while循环，它解决了一个根本问题——AI不知道什么时候该停，什么程度才算真正的停。

说了这么多，你最关心的肯定是——这东西到底怎么用？

第一步：去GitHub把提示词模板拿下来。

项目地址是 https://github.com/lidangzzz/goal-driven ，README里有完整的提示词模板。你需要做的，就是把模板复制到你的文本编辑器里。

第二步：填目标。

在Goal那行，把你的目标写进去。记住，目标要具体、要明确。不要写"帮我写一个好用的编译器"，要写"用C++编写一个TypeScript编译器，能够正确地将TypeScript转译为JavaScript，包括完整的文档和单元测试"。

差别在哪？前者是个模糊的方向，后者是一个清晰的产出物。

第三步：填成功标准。

这是在Criteria那行，这是整个方法论最核心的部分。标准必须满足三个条件：

一是可量化，能明确判断对不对，比如"2000个测试文件全部通过"而不是"测试覆盖率足够高"。

二是可执行，AI能实际去验证这个标准，比如"在Node.js上运行输出结果一致"。

三是足够严格，不是"差不多能跑"，而是"完全符合预期"。

文档里给的例子是这样的：

Criteria: 确保TypeScript编译器成功编译并生成2,000个涵盖尽可能多TypeScript语法特性的综合测试用例文件。确认C++ TypeScript编译器能正确将代码转译为JavaScript。然后，在Node.js上运行此编译器的输出和官方tsc转译器的输出，并验证两个生成的JavaScript文件产生相同的输出。

这个标准有效在哪？它说清楚了：多少个测试用例（2000个）、怎么验证正确性（和tsc对比输出）、在什么环境验证（Node.js）。

第四步：选一个支持多智能体的工具运行。

文档里推荐了三个：Claude Code、Codex、OpenClaw。你用哪个都行，核心是你得有一个能创建子智能体的环境。

第五步：启动，然后等待。

这就是最反直觉的地方——你把任务丢给AI之后，不要中途干预，不要问"做到哪了"，不要给额外指令。你就让它跑，主智能体会自动管理子智能体，每五分钟检查一次活跃状态，如果子智能体停了或者声称完成了，主智能体会验收，没达到标准就重启继续干。

整个过程除非你自己手动停止，否则AI会一直跑下去。

有几个坑我得提前跟你说清楚。

第一个，时间和成本。复杂任务可能需要投入很长时间，原项目说这个方法的目的就是让你的多智能体系统能够持续投入超过300小时不间断地工作。按现在的API价格，这账单，肯定也是非常长的。文档里也直接说了——"请确保你的AI智能体的API计划或订阅余额充足"。

第二个，标准制定本身有门槛。制定一个真正能验收的标准，有时候比写代码本身还难。你得对要做的事情有足够深的理解，才能说出"做到什么程度就算成了"。

第三个，AI的"假装在工作"问题。子智能体可能看起来很忙，但其实是原地打转。主智能体的五分钟检查机制能一定程度上缓解，但没法完全杜绝。

所以我说，这套方法不是"丢给AI就不用管了"。人是参与在里面的——制定标准的人，验收标准的人，还是得是你。

说真的，我看到这个项目的时候，第一个念头就是：

我们可能一直在用错误的方式使用AI。

以前我们总觉得，AI是个工具，用它就得"指挥"它。但Goal-Driven给了一种新的思路——不是指挥它，而是给它一个目标，让它自己跑，你去验收。

这事儿说起来简单，做起来其实挺反直觉的。我们人类习惯了"分配任务"的思维方式——你去做A，然后做B，然后做C。

但AI协作的正确姿势可能是，我要达到X效果，你想办法。不管你用什么方式，跑到X就算结束。