/goal 的本质：不是 Autonomy，是 Ralph Wiggum Loop + 产品设计
Claude Code 的 /goal 命令让人感觉进入了 agentic coding 的新时代。你给 agent 一个目标，它持续工作，同时独立的 evaluator 或长运行 harness 检查目标是否满足。Agent 计划、编辑、运行测试、修复失败、更新状态、继续前进——直到目标达成或循环达到边界。
George 认为这听起来像 autonomy，但更好理解为 Ralph Wiggum loop 加上产品设计包装。
Ralph Wiggum loop 的粗糙版本：把 agent 放进 bash loop，每次给相同的 repo context，让它读 spec 和实现计划，挑下一个未完成任务，完成它，写或运行测试，测试通过才标记完成，然后重新开始。
关键发现：有用的部分不是更聪明的模型，而是每次运行开始时的 fresh context。
不依赖一个 bloated chat 通过 compaction 记住一切，loop 重新加载 durable files：spec、plan、task list、test suite、status notes。对话可以腐烂，但 source of truth 保持在对话之外。
这就是 /goal 的核心思想：loop 的好坏取决于它重新加载的 plan、tests、acceptance criteria 和留下的 evidence。
对 PM 工作的具体改变
需求开始更像 target states 而非 prose
这推动 PM 工作超越「写足够细节让工程师理解意图」，走向「定义 done 到 agent 能持续尝试、harness 能检查证据、人类能判断结果是否 product-correct」。
这比正常 ticket 的 bar 高得多。但 setup 和 planning 变得更加重要。
当你坐在 Claude 旁边逐轮 steering 时
plan 可以松散，因为你的注意力填补了 gaps。你注意到 agent 何时误读意图，抓住 awkward implementation，阻止 wrong abstraction 被 cement 进 repo。
当你离开时
spec 必须做更多工作。Ralph 强制这一点，因为每次迭代都是 fresh agent instance。它不携带上次 correction 的记忆，不记得 60,000 tokens 前 buried 的 nuance。它读你给它的文件，基于它们行动，下一轮从同一个 durable source 开始。
这使得 spec 和 plan 成为 product surface。
好 Loop 的组成部分
一个 good Ralph loop 通常包含：
- Spec：解释目标行为
- Implementation plan：有序任务
- Acceptance criteria：可检查
- Tests / validation commands：证明进展
- Status file：记录改了什么、什么通过了、什么仍然 risky
Claude Code /goal 分离了「做工作」和「判断工作是否完成」。工作 agent 必须在对话中 surface evidence，因为 evaluator 从它能看到的判断：test output、lint output、changed files、queue state 或其他 observable proof。
Codex 的长周期示例指向相同结构。Loop 依赖 externalised intent：spec files、plan files、runbooks、validation commands、status logs 和 periodic proof。
Loop 需要一个它能 inspect 的 target。
坏 Goal vs 好 Goal
坏 Goal：读起来像愿望
/goal improve onboarding
Agent 可以做点什么：重命名按钮、添加 checklist、改 copy、简化屏幕、创建测试、做一个看起来合理的 PR。
但 goal 本身没有给 agent 任何方式知道 onboarding 是否 improved。所以 agent 开始优化最容易证明的东西：UI 更干净因为截图看起来更干净，测试通过因为测试通过，步骤减少因为更少步骤听起来更好。
这不意味着产品变好了。
同样的失败出现在 PM 需求中：
- make activation easier
- reduce friction
- improve the dashboard
- clean up the settings experience
- make search smarter
人类会通过对话 rescue 这些 ticket。Agent 在无人值守时更差——它们会持续将 vagueness 转化为 implementation。
这就是长运行 agent 危险的地方：一次性错误很烦人，loop 可以花 40 轮让错误的东西更内部一致。
好 Goal：给 loop 终点线、证明方法和边界
/goal implement the new onboarding checklist from docs/onboarding-spec.md. All acceptance criteria in the spec must pass. npm test -- onboarding exits 0. npm run lint exits 0. No files outside app/onboarding, components/onboarding, or test/onboarding are changed. Stop after 20 turns with a status report if any criterion remains blocked.
这不是完美的 product requirement，仍然依赖 spec 质量。但它给了 agent 更接近 evaluable condition 的东西。
让 product intent 在 spec 中更锐利：
The checklist is done when:
- first-time users see three setup steps after account creation
- each step has a visible complete/incomplete state
- completing a step persists after refresh
- users can skip the checklist and return to it later
- existing users do not see the checklist unless they have no completed setup steps
- analytics emits onboarding_checklist_viewed, onboarding_step_completed, and onboarding_checklist_dismissed
- the empty state links to the checklist when no setup steps are complete
配对这些 criteria 与 evidence：
Validation evidence required:
- unit tests for persisted step state
- integration test for first-time user visibility
- regression test for existing users
- browser smoke test for completing, refreshing, and dismissing the checklist
- screenshot or DOM evidence for the empty state link
- event capture test or mocked analytics assertion for each event
现在 /goal 有东西可用了。Loop 可以运行 tests、展示 output、inspect changed files、报告哪些 criteria 仍 blocked。Evaluator 可以判断 transcript，因为 transcript 包含 proof 而非 vibes。
PM 需要内化的区别：prompt 要求 effort，contract 定义 effort 停止的条件。
最佳实践：观察前几次迭代
不要：写 giant spec、启动 loop、合上笔记本、希望机器人做产品开发。
要：启动 loop，观察它如何处理你的指令。
- 如果它误解 target → 停止、edit spec、restart
- 如果它写了 bless wrong behavior 的 bad test → 停止、fix validation protocol、restart
- 如果它 touch 无关 files → 停止、add scope boundaries、restart
- 如果它反复问同一个问题 → 停止。Spec 可能有 ambiguity，人类一直在 silently resolving
前几次 loops 是 calibration。它们教你 agent 如何解释 plan。
这看起来像是「不信任 agent」，但恰恰相反：观察前几次迭代是让后续无人值守工作 less stupid 的方式。
Loop 在 spec survive contact with model 之后变得有用。
/goal 最适合的场景
1. 迁移工作
/goal migrate all imports from legacyAuth to authClient in app/auth. No legacyAuth imports remain in app/auth. npm test -- auth exits 0. npm run typecheck exits 0. Stop after 15 turns if any usage is ambiguous.
2. 清理 Backlog
/goal resolve every failing test marked [TODO]-regression. Each fix must include the smallest relevant production change. do not delete tests. After each fix, update docs/status-auth-regressions.md with cause, files changed, and validation output.
3. 文件拆分
/goal split app/components/AccountSettings.tsx into modules under 250 lines. Behavior must stay the same. existing tests must pass. No new component should mix billing, profile, and notification concerns.
4. Brute-force 测试
Ralph 在持续尝试 attack vectors、checkout paths、login flows、search cases、forms、permissions、edge states 和 unhappy paths 直到 queue 为空时很强。
5. 探索模式
期望应该不同——goal 应该产生 learning，不是 production code：
/goal explore three viable approaches for making project search faster. For each approach, create a short note with expected complexity, risks, files touched, and how we would validate it. Do not edit production code. stop after producing docs/search-speed-options.md
危险版本：要求探索 loop 默默变成 production loop。
PM 的新技能清单
Agentic coding 不消除产品思考。它更快惩罚模糊的产品思考。
Ticket 不再足够。更有用的 artifact 是 executable definition of done。
PM 必须更擅长写：
- Observable behavior：可观察的行为
- Negative cases：反面案例
- Scope boundaries：范围边界
- Validation evidence：验证证据
- Stop conditions：停止条件
- Status-report expectations：状态报告预期
- Customer-facing success criteria：面向客户的成功标准
弱需求 vs 强需求
弱：
Users should be able to manage notifications more easily.
强（agent-ready）：
Users can turn product updates, billing alerts, and research reminders on or off independently. Each preference persists after refresh. The default state matches the existing notification behavior for current users. Users who turn off billing alerts see a warning explaining which emails cannot be disabled for legal or account-security reasons. The settings page passes existing accessibility checks. The work is done when the notification preferences tests pass, the browser smoke test shows persistence after refresh, and no billing email logic is modified outside the documented preference gate.
这仍然是产品工作。它决定了「manage notifications」意味着什么，命名了 billing-alert edge case，为当前用户保留了 backward compatibility，命名了 proof，阻止 agent wandering 进无关的 email logic。
停止给 Agent 的指令类型
不要给形容词
make it better / cleaner / easier / smarter
替换为 observable states：
Reduce the empty-state decision path from four visible actions to two. Keep "Import CSV" and "Create manually." Move advanced import settings behind the existing disclosure component. Add a regression test that the empty state still exposes both setup paths.
不要给 vibes
polish the onboarding flow
命名 product behavior：
After signup, users should land on the setup checklist. They should see the first incomplete step expanded. Completing the workspace-profile step should mark it complete without a full-page refresh. If the API call fails, the step should return to incomplete and show the existing toast error pattern.
不要给伪装成产品目标的实现偏好
Refactor settings into a cleaner architecture.
命名 refactor 必须缓解的 pain：
Split settings so billing, profile, and notification changes can be tested independently. Each module should own its form state, validation, and save action. Existing settings behavior must not change. The work is done when each module has its own test file and the current settings regression suite passes.
这是 delegating effort 和 delegating an outcome 的区别。
Status File：JIRA Epic 的重新想象
如果 agent 长时间运行，你需要一个地方记录发生了什么，不依赖 chat memory。
Status file 应该说：
- 什么改了
- 哪些 checks 通过了
- 哪些 checks 失败了
- agent 做了什么决定
- 什么仍然 risky
- 人类接下来应该 inspect 什么
这就是 durable memory layer。
也是避免 context rot 的方式。每轮 fresh turn 可以 reload spec 和 status，而不是试图从 decaying conversation 中重建项目。
核心规则
Define done, prove done, and keep the proof outside the chat.
工具是新的，但标准一直是旧的。
有 good tests 和 crisp acceptance criteria 的团队会获得更有用的 loops。有 mushy requirements 的团队会得到更长、更快的 mush，burn 掉他们的 tokens。
资源
- PM OS：George 构建的产品工作操作系统，V2 即将发布，带 improved memory、agents 和 skill workflows
- Shaping Skills：Ryan Singer (ex-Basecamp) 的 shaping 方法论
- /grill-me：Matt Pocock 的 viral skill，确保 requirements 不 suck