夜雨聆风如果你已经熟练使用 /goal，那 /supergoal 可能会让你的效率再上一个台阶。
/goal让 Claude 自己跑，但你得先想清楚"怎么跑"。/supergoal把这步也替你干了——侦察代码、拆解阶段、自我批评、预检环境，最后给你一条可以直接粘贴的/goal。它解决了/goal的最大痛点
/goal的痛点
官方的/goal 命令上线那天，整个开发者社区都在欢呼："终于不用一步步点了！
"但用了两天之后，大家的欢呼变成了吐槽："条件写不清楚就跑偏"、"遇到错误就卡住等人救"、"同一个目标我改了三遍才跑通"。
然后有个叫 Robert Courson 的开发者默默发了一个插件，说了句："让我来。"这个插件，就是 /supergoal。
问题不在 /goal。问题在你必须自己把任务拆清楚、把边界画明白、把风险想周全——你大概率会漏，因为你自己都还没开始干。
这就是/goal的痛点，也是/supergoal 要解决的事。
/supergoal 是什么？
一句话：/supergoal 是给 Claude Code 装了一个"会做规划的大脑"的插件，是套在 /goal 外面的一层"规划+自愈+审计"脚手架。
它不是 Anthropic 官方出的功能，而是社区开发者 Robert Courson 开源的一个插件。
它不替代 /goal。执行层面还是 /goal 在跑。但 /supergoal 替你把 /goal 之前那摊"想清楚怎么跑"的活全干了。
你可以这样理解：
/goal 是一辆车，你告诉它目的地，它自己开过去。但 你得先把路线规划好 ——走哪条路、在哪里拐弯、遇到堵车怎么办，全得你提前想好。
/supergoal 则是一个代驾加导航的组合。你只需要说"我要去北京"，它自己打开地图、查路况、规划路线、避开拥堵，然后把车开到目的地。你要做的，只是在出发前看一眼它的路线，确认没问题就行。
| 直接用 /goal | |
| 用 /supergoal |
两者的执行能力一模一样——都是靠 /goal 的循环机制跑完全程。区别只在一件事：谁来想"怎么跑"。
/supergoal 会做这些事：
自动侦察你的代码库和项目环境 读取你的历史偏好（你用过的技术栈、踩过的坑、代码风格） 把任务拆成若干个阶段，每个阶段都有明确的验收标准 识别前三大风险，提前规避 自己审查计划，发现模糊或错误当场改 先跑一次预检（build、lint、test），确保基线环境干净 最后打印一条打磨好的 /goal 命令，你粘贴一次，剩下的自动跑完
执行过程中它还多了一层保护：跑歪了会自己修，修三次修不好才会停住叫你。
跑完还会自己做最终审计——对照原始需求，逐项检查每个交付物是不是真的落地了。
它是怎么做到的？拆开看
/supergoal 的工作流程分两大块：规划阶段（你在旁边看着）和执行阶段（你去干别的）。
规划阶段：一句话 → 可执行计划
你说："/supergoal 帮我做一个把照片转成ASCII艺术的Expo应用。"
然后它开始干活：
Step 0 — 加载记忆： 先找你的历史记忆目录，看看有没有以前留下的偏好、项目事实、踩过的坑。找不到也能跑，只是不会复用旧经验。
Step 1 — 调研需求： 它会判断这是新项目还是老项目。新项目会问你几个问题（什么平台？用什么技术栈？有什么设计要求？），最多问4个一批，问完为止。老项目因为有代码在那，基本不问——代码本身已经回答了大半。
Step 2 — 侦察代码库： 并行扫描整个项目目录，快速掌握现有架构、依赖关系、技术栈。这一步的结果会写进 context.md 和 repo-map.md。
Step 3 — 风险分析： 识别前三大的风险和依赖关系。比如"第三方API文档不完整，可能需要试错"或者"现有测试覆盖率低，重构时有回退风险"。
Step 4 — 拆解任务： 不是固定拆3步或5步。小改动可能就两个阶段；完整的全栈项目可能拆成8到12个阶段。阶段数量看任务本身，不看模板。
Step 5 — 写出完整计划： 把所有东西写到 .supergoal/ 目录里。你会看到 ROADMAP.md（完整路线）、STATE.md（当前状态）、THINKING.md（风险与决策记录）、以及每个阶段独立的 phase-N.md（工作规格）。
Step 6 — 自我批评： 这是关键一步：它自己检查一遍计划。验收标准能不能验证？阶段有没有塞太多东西？有没有模糊的表述？发现问题当场改。
Step 6.5 — 预检： 在正式开始之前，先把 build、lint、test 这些必须过的命令跑一遍。确保基线环境是干净的。环境有问题先修，别等跑起来再发现。
Step 7 — 交棒： 打印一条可以直接粘贴的 /goal 命令。你复制，粘贴，接下来全是自动化。
执行阶段：自动跑，歪了自己修
/goal 最让人头疼的就是：一旦遇到错误就直接停住，等着你去救。你半夜三点收到一条"执行失败"的消息，真的会很想砸电脑。
/supergoal 加了一层智能容错协议，三档处理：
第一次失败——自动注入探测信息，重试一次。比如某个依赖没装，它自己发现、自己装上再试。
第二次失败——生成专门的修复 spec（phase-N.fix.md），针对性解决问题。相当于它给自己写了一份"排障手册"。
第三次失败——触发正式移交：系统停下来，把完整的探测历史和失败原因交给你，等你介入决策。
绝大多数小问题，它都能自己搞定。那些真正卡住的、需要你判断的，才会交到你手上。
最终审计：跑完自己验
很多人担心 AI 自动跑出来的东西质量没保证。/supergoal 在最后有一道严格的审计关卡：
它会回头读最早的 ROADMAP，重新跑 build、lint、test 这些命令，逐项检查每个验收标准是否真的达到。
更狠的是，它会用开始前记录的"基线引用"跟当前工作区做完整对比——不只查 Git 提交，暂存区、未暂存、未追踪文件都算进去。
新增的 console.log、临时 TODO、死 import 都会被检测到。这就补上了一个常见漏洞：AI 在对话里说"完成了"，但文件里没有对应改动。
审计不通过，它还会自己写修复方案来改，最多修 3 轮。全部通过后，才会打印 SUPERGOAL_RUN_COMPLETE。
记忆回写：越用越聪明
每个阶段结束时，/supergoal 会做一次"非显而易见的知识"检查。
如果这个阶段学到了什么下次类似任务能用到的东西——某个 API 的坑、你的代码风格偏好、项目级别的特殊要求——它会写进记忆目录。
下次你再跑类似任务，Stage 0 加载记忆的时候就会直接读到这些经验。跑多了它自然就知道你项目的脾气了。
安装：三条命令
前提：你需要先装好 Claude Code（Anthropic 出的命令行 AI 编程工具，在终端里跟 AI 对话来写代码）。版本需要 v2.1.139 或更高，终端输入 claude --version 查看。当前 /supergoal 版本是 v0.7.0。
Claude Code 里三条命令搞定安装：
/plugin marketplace add https://github.com/robzilla1738/supergoal.git/plugin install supergoal@supergoal/reload-pluginsGitHub 仓库地址：https://github.com/robzilla1738/supergoal
装完之后怎么用？就三步：在 Claude Code 终端里输入 /supergoal，后面跟你的需求描述。然后等它规划完，它给你一条 /goal 命令。你粘贴执行，完事。
建议第一次从小任务试起，比如 /supergoal 帮我给这个项目加上 README 和单元测试，看它怎么问问题、怎么切阶段、怎么写验收项。
五个实战场景
场景一：从零搭建一个完整应用
/supergoal 用 React + TypeScript + Tailwind 做一个个人博客系统，支持 Markdown 写作、标签分类、RSS输出你不需要自己去想目录结构、组件拆分、路由设计、状态管理。它会在侦察阶段搞清楚你的环境，然后给你一份完整的 ROADMAP。
场景二：跨模块大重构
/supergoal 把项目里所有API调用从 axios 改成 fetch，更新所有调用方，保证现有功能不受影响这种事自己手动改，光排查调用方就能找一上午。让 /supergoal 先做规划、识别风险、拆阶段，然后 /goal 自动执行。
场景三：全项目安全审计
/supergoal 扫描整个项目的依赖漏洞、硬编码密钥、不安全配置，生成修复方案它会识别风险、推荐最佳实践，然后逐项修复。每个阶段都会写memory，下次类似任务直接复用经验。
场景四：整理研究资料
/supergoal 将 papers/ 目录下所有PDF整合成一份文献综述，按方法论分类，标注每篇的核心发现和局限研究生们注意——这个能省你一周。它会把文件夹先侦察一遍，拆分任务，逐批处理，最后验证所有论文的关键信息都没丢。
场景五：升级框架版本
/supergoal 把项目从 Next.js 13 升级到 Next.js 14，处理所有 breaking changes，所有测试通过这个场景的风险点特别多：API变更、配置迁移、废弃特性。自己做很容易漏。用 /supergoal 它在规划阶段就把风险识别出来了。
什么时候该用？什么时候别用？
该用的场景
✅ 全新项目开发 从零搭一个应用。你自己未必想清楚了所有技术选型和架构细节，它帮你理。
✅ 大型重构 跨多个文件、涉及架构调整。自己拆任务容易漏，它不会。
✅ 有明确验收标准的复杂任务 比如"升级框架版本后所有测试通过"、"修复所有已知安全漏洞"。终点清晰，但过程繁琐。
✅ 批量处理 一次性改几十上百个文件。没人想一个一个手动改。
别用的场景
❌ 小修小补 改个bug、加个小按钮、调个样式——直接用 /goal。杀鸡不用牛刀。
❌ 你自己都不确定要什么 如果你的需求还在探索阶段，先花点时间想清楚，别急着让它规划。
❌ 单文件改动 改一个文件，写 /goal 条件也就30秒的事。启动 /supergoal 的规划流程反而更慢。
几个要注意的点
1. /supergoal 不替代 /goal，它依赖 /goal
/supergoal 做的是规划，执行还是 /goal 的循环。所以你的 Claude Code 版本必须支持 /goal，而且要开着 Auto mode——不然每轮内部还是会弹确认框，自动化的意义就打折了。
2. 两个 /supergoal 不要同时跑
每次运行会创建独立的 .supergoal/<run-id>/ 目录，规划阶段互不冲突。但执行阶段两个 /goal 同时在同一个工作区改代码会互相覆盖——这点和操作系统一样，同一份文件不能两个进程同时在写。
真要并行，用 git worktree 分两个工作区。
3. 复杂项目先从小范围试水
第一次用别直接扔一个全栈项目。先找个小任务试试——比如"给设置页加一个导出按钮"。看它怎么侦察、怎么拆阶段、怎么写验收标准、预检过不过。跑通一次你就有数了。
4. 主观性的质量标准它判断不了
"界面好不好看"、"用户体验优不优化"——这种没法自动验证。最终审计里超过30%的检查项是主观性的，它会弹一个警告让你人工审查。UI/UX的东西，还是得你自己把关。
写在最后
/supergoal 解决了一个很具体的问题：你让AI干活之前，得先替它想清楚怎么干。
这不是AI不行，是工作方式的问题。/goal 本身不弱——它只是需要有人把条件写好。但 "写条件" 这件事，往往就是整个任务里最费脑子的部分。
/supergoal 把 "想怎么干" 这摊事也自动化了。
以前用 /goal，最费时间的不是等待执行，是你坐在那里想条件怎么写、任务怎么拆、约束怎么加。
现在你只管说一句话，它替你把规划做完、把坑踩过、把环境检好，最后给你一条可以直接用的命令。
小修小补直接 /goal 就够了。但下次遇到那种 "知道终点在哪、但过程很复杂" 的任务，试试 /supergoal。
如果这篇文章对你有帮助，欢迎关注、点赞、转发。你的每一次关注、点赞，都是我继续写下去的动力。你的每一次转发，都可能帮到另一个正在苦苦寻找答案的人。
