企业官网建设流程全解析

GoalBuddy 是一款面向 Codex 和 Claude Code 的开源 /goal 伴侣工具，它最核心的设计理念叫"目标神谕先行"（Goal Oracle First）：在让 AI 开始干活之前，先定义一个可观察的信号，用来证明你的目标真的达成了。没有 Oracle，就不算严肃目标。这篇文章带你用最短的篇幅理解这个理念，并亲手为自己的目标写出第一个 Oracle。

为什么长任务需要一条"终点线"？

用过 AI 编码代理的开发者大概率遇到过这种情况：让 Agent 做一个大任务，几轮之后它汇报"完成了"——规划写好了、几个测试过了、代码看起来也像回事了。但你一验收发现，最初想要的结果其实还没有真正实现。

问题出在哪里？GoalBuddy 的官方文档用一句话点破了它：

Weak proof creates weak goals.（弱证明制造弱目标。）

当"完成"只能靠感觉判断时，AI 自然会在第一个看起来像完成的点上停下来：一次顺利的测试、一块干净的看板、一段像模像样的规划。这些都不是你真正要的结果。

GoalBuddy 给出的答案是：先立下终点线，再上路。这条终点线就是目标神谕（Goal Oracle）。

什么是 Goal Oracle？

GoalBuddy 对 Oracle 的定义非常简洁：

A goal oracle is the observable signal that tells the PM whether the original owner outcome is actually true yet. （目标神谕是一个可观察的信号，它告诉项目管理者：你最初想要的结果，此刻是否真的为真。）

它不是一种神秘的机制，而是一个可以被反复检查的事实。GoalBuddy 列出了 Oracle 常见的 8 种形态：

在 GoalBuddy 的核心契约 goalbuddy/SKILL.md 中，这条理念被写成整个系统的第一条不变量（invariant）：

Intent -> Oracle -> Surface -> Loop -> Proof

紧接着就是一句掷地有声的口号：No oracle, no serious goal.（没有神谕，就不算严肃目标。）

五步闭环：Oracle 如何贯穿整个执行过程

拆开上面的不变量，每一步都围绕 Oracle 展开：

1. Intent（意图）：把用户原始诉求翻译成一个可解释的结果。GoalBuddy 的 Intake Compiler（意图编译器）会特别提取两个字段——completion_proof（什么信号能证明完整目标完成）和goal oracle（持续给目标施压的活检查），还会逼你回答一个问题：likely misfire，即"/goal 可能会在错误的地方成功"——AI 最可能跑偏成什么样。
2. Oracle（神谕）：把上面提取到的信号正式记录下来，放在看板文件的显要位置（下文详述）。
3. Surface（工作面）：所有任务、进度、收据都落在仓库内的state.yaml看板上，工作可见、可暂停、可恢复。
4. Loop（循环）：Scout 侦察证据、Judge 挑选最大安全切片、Worker 执行并留收据，PM 持续推进。
5. Proof（证明）：每个阶段的收据都要和 Oracle 对表。弱证据不能收尾，直到最终审计把全部收据映射回 Oracle 为止。

GoalBuddy 如何机制化地强制"神谕先行"？

理念停留在口号层面没有约束力。GoalBuddy 的巧妙之处在于：Oracle 被固化进模板、规则和退出闸门，想"糊弄过去"在机制上做不到。

Oracle 是看板模板的一等公民

GoalBuddy 的看板模板 goalbuddy/templates/state.yaml 中，oracle与goal.title平级，包含三个字段：

oracle: signal: "<证明所有者结果已为真的活检查、走查、产物、指标或决策>" cadence: "每个 Worker 工作包完成后 + 最终审计时" final_proof: "<允许 full_outcome_complete: true 之前必须收到的收据证据>"

• signal：神谕本体，即那个可观察信号；
• cadence：检查节奏，保证 Oracle 不是写完就忘，而是每个工作包之后都要对表；
• final_proof：终局证据清单，收不了齐就不许宣布完成。

配套的章程模板 goalbuddy/templates/goal.md 也设有专门的 "Goal Oracle" 章节，并明文规定：PM 必须持续把任务收据与 Oracle 对比，规划做得漂亮、切片测试通过、看板看起来很干净，都不算数。

三条不给捷径留门的规则

在 goalbuddy/templates/state.yaml 的rules区块中，有几条布尔规则是默认写死的：

也就是说，"看起来干了很多活"在 GoalBuddy 的判定体系里，和"目标达成了"是两码事。

T999 最终审计与机器退出闸门

每块 GoalBuddy 看板都会预置一个 T999 任务：由 Judge 角色做最终审计，逐项核对"收据 + 验证结果 + Oracle"，并输出full_outcome_complete: true | false。执行契约 goalbuddy/references/goal-execution.md 对此的表述毫不含糊：

Never complete because work looks substantial. （绝不要仅仅因为工作量看起来很大就宣布完成。）

而在 PM 准备结束本轮对话之前，还必须跑一个机器可校验的退出闸门 goalbuddy/scripts/check-can-stop.mjs：退出码非 0，就意味着还有安全可做的事或证据缺口，PM 必须继续干。神谕不只是写在文档里，它最终变成一个可以返回退出码的检查——这正是"严肃"二字的含义。

实战指南：三步为你的目标写出 Oracle

理解了机制，下面是可直接套用的三步法。

第 1 步：先写"什么为真"，再写任务清单

拿到任何目标，第一句话不是"我要做什么"，而是：

什么可观察的信号出现时，我能确信这件事真的成了？

试着回答"重构认证模块"这个目标：

• ❌ 弱证明："代码重构完成、CI 通过"——CI 通过只说明没改坏，不说明重构达成了目的；
• ✅ 强证明："原认证路径的 12 个回归测试全绿，且新增会话过期场景有独立测试覆盖"。

强证明的特征是可检查、可重复、指向原始结果，而不是指向过程。

第 2 步：为 Oracle 选择类型和检查节奏

从前面表中的 8 种形态里选一个（或组合），并给它定一个 cadence：

oracle: signal: "npm test -- test/auth 全绿，且会话过期场景有独立用例" cadence: "每个 Worker 工作包完成后重跑，最终审计时走查一遍真实登录流程" final_proof: "Worker 收据列出全绿命令 + Judge 审计收据映射回本 signal"

注意 cadence 的价值：Oracle 每被检查一次，就等于给"提前收工"的冲动一次拦截机会。

第 3 步：把"可能跑偏的样子"也写下来

这是 GoalBuddy Intake Compiler 里最容易被忽略、却最能防事故的一步：likely_misfire。继续上面的例子：

可能的跑偏：AI 把"重构"做成了"加了一堆包装函数和契约文件"，测试都绿，但认证路径的行为根本没变。

把它写进 goalbuddy/templates/goal.md 的 Intake Summary，Judge 在挑任务时就会主动回避这种"安全但无进展"的切片。GoalBuddy 的切片策略（最大安全有用切片）和这一步是配套的：任务可以小，但必须改变行为，而不是只加包装。

在本地实时看板上，看着 Oracle 一步步兑现

GoalBuddy 默认会启动一个本地实时看板（Live Board），让state.yaml的每一次变化都变成卡片上的实况：当前激活任务、进行中的工作包、受阻项、已完成项和收据状态一目了然。你不需要在聊天记录里翻找进度，而是像盯一块冲刺看板一样，看着任务从 Todo 流向 Completed——而最终能否标绿，取决于 Oracle 的裁决。

写在最后

GoalBuddy 的整套设计——意图编译、Scout/Judge/Worker 分工、收据制度、退出闸门——本质上都在服务同一个信念：

AI 的执行力已经过剩，稀缺的是"什么才算真正完成"的定义权。

把这个定义权留给自己，用 Oracle 把"完成"从一个模糊的感觉变成一条可反复核验的终点线，AI 长任务才真正从"看起来做完了"走向"确实做成了"。这就是 GoalBuddy 的核心理念：没有 Oracle，就不算严肃目标。