grill-me → superpowers → OpenSpec 三件套工作流如何让 AI 编码助手不再凭有限上下文猜测你的意图将「想清楚」焊进流程消灭需求蒸发与方法偏差。1 说加个认证到翻车只差三轮对话你说加个用户认证Claude Code 五分钟建好了 JWT 整套。但你要的是 OAuth 2.0 SSO第三轮重写时你发现——那条需求还躺在第一条聊天记录里AI 早忘了上下文。你只能再解释一遍然后在第四轮 AI 又掉进了另一个盲区。直到第五轮你忍不住想是不是我该先画个图这是每个深度用过 AI 编码助手的工程师都经历过的场景。AI 的能力在飞速迭代但核心瓶颈不是能不能写代码而是建不建得对。大部分返工的根本原因非常一致需求只活在聊天窗口的滚动条上方AI 凭有限的上下文推断你的意图。你的脑袋里有一张完整的蓝图但 AI 看到的只是每轮对话里那几百个 token 的断章取义。问题不止于提示词。好提示词能撑过一轮对话但撑不过三个新会话。当你的项目有五个模块、横跨十次对话时单靠提示词根本无法保证 AI 每次都记得你三天前说的那句话。这是一个工作流问题需要结构来承载。本文介绍一套三件套组合把想清楚这件事直接焊进流程grill-me先问清→ superpowers先找对→ OpenSpec后锁死。三个工具处在不同层级——grill-me 处理需求层面的模糊、superpowers 确保方法层面的正确、OpenSpec 提供产物层面的可审查。每一关都不依赖前一关的工具你可以单独用任意一个但叠加在一起时效果远超三者之和。下面这张图刻画了那个经典的恶性循环。一条需求从你口中说出来经过聊天记录、AI 推断、你纠正、新会话、再次推断最终翻车。这个循环每走完一轮就是半小时到两小时的无意义返工三件套的目标就是在第一条链条上插入三个关卡——需求到 grill-me 先澄清不掉进代码、方案到 superpowers 先找到对的技能再动手、编码前到 OpenSpec 先写 spec 确认一致性。每一次循环都被前置过滤拦截而不是在代码写完之后才发现错了。来源OpenSpec 官方定位 Why use a spec instead of just writing a detailed prompt?[1] — officialgrill-me / superpowers 取自本地 SKILL.md所属体系见 mattpocock/skills[2] — local/skill2 三个代价场景在亮方案之前先看清楚问题的三个典型形态。每个场景都对应一个真实的为什么三件套有必要的答案。场景① 需求蒸发——你说过的每一句话AI 下个会话就忘了问题往往不在你明不明确而在AI 记不记得。加个用户认证在不同人嘴里可能是完全不同的事情。有人想要 JWT 中间件五分钟装好有人要对接企业 AD、支持 SAML 2.0、多租户隔离。但问题在于你问清楚和写下来的内容只活在当前这个聊天窗口里。下一次新会话——无论是因为上下文占满还是换了个话题——所有那些你已经确认过的技术选型、否决过的走法都不见了。AI 只会从零开始推理给你一个全新的方案。场景② 凭记忆蛮干——模型靠参数里的模式匹配写代码不读你的方法论这是最隐蔽的代价。CLAUDE.md、AGENTS.md 就在仓库里但 AI 默认不会主动去读——模型训练数据里绝大多数代码样本都是先写实现再写测试所以当你告诉它用 TDD时它可能嘴上答应但第一条回复直接给了你实现代码。这不是 AI 的能力问题这是流程问题。模型没有内在动机去读项目的方法论文档除非你在工作流层面建立了必须先查技能再动手的铁律。场景③ 意图不可审查——代码可以 diff但为什么要这样改没有人知道这是最隐蔽也最昂贵的一个代价。周五下班前让 AI 改了五个文件周一回来你只能逐行看 diff 反推意图这段代码为什么删了这个变量改名是为了什么代码可以审查diff 能看到改了什么但意图不可审查不知道为什么改。当新人接手项目或者三个月后你自己回来看这些改动时只能从代码行为反推当初的决策逻辑。三个场景叠加一个中等规模功能从敲键盘到交付可能有 30% 到 50% 的时间花在了重新对齐而非真正编码上。下面这张对比图展示有无三件套时的流程差异3 原理三关分层工作流三件套不是平行使用三个工具而是分层过滤——每一关解决上一关输出中的不确定性把模糊需求逐步固化为可执行的规范。三层的介入时间点错开需求还在概念阶段时第一关介入方案确认后第二关介入开始编码前第三关介入。每一层只关心自己那一层的质量不管上下层的事。下面这张图展示了三层串联的整体架构3.1 第一关grill-me —— 澄清层核心动作沿设计树逐分支追问直到没有it depends的回答。每一轮的提问模板固定三步① 先给出你的推荐答案再提问 ② 问问题 ③ 等用户回答后再进入下一题。先给推荐答案是为了降低用户的思考负担——用户不需要从空白画布开始想方案而是从你给的答案出发确认或否决。如果某个问题可以通过阅读代码库回答——比如项目用了什么数据库——用 Read 或 Grep 自己查不去问用户。grill-me 的一个重要原则是不要浪费用户的注意力在机器能自答的事情上。会话结构AI 先列出方案中看到的顶层决策分支通常是 3 到 6 项。然后挑最基础的分支先走——因为其他分支常常依赖它的结果。每个分支内部按依赖序解决子决策先解决被依赖的问题。这是 grill-me 和普通人随意提问的最大区别——不是想到哪问到哪而是按决策依赖树有序推进。停止条件所有分支解决、没有遗留的it depends回答时结束。结束时 AI 用一段话总结所有关键决策让用户一次性确认没有遗漏。关键差异grill-me 是纯对话式追问方案还停留在概念阶段时使用eg. 我要加认证但还没有任何文档。grill-with-docs 锚定项目已有的领域模型如 CONTEXT.md 或 ADR决策实时写入文档项目已有领域模型时优先用后者。下面这张图用一个具体例子——加用户认证——展示了 grill-me 的决策树形态# grill-me 典型提问节奏## 第一步先给推荐答案再提问建议用 JWT refresh token 做认证这是最通用的方案兼容性好。# 第二步提问尽量封闭式不要开放式你是想要简单的 JWT还是企业级 OAuth 2.0 SSO# 第三步等待用户回答再进入下一分支# 用户回答: 先 JWT后续可能加 SSO→ 明白了先 JWT 后迁移 OAuth。用户模型方面用 Email 密码还是第三方集成# 第四步可用 Read/Grep 自答的问题不去问用户grep -r spring-security build.gradle# 确认已有 Spring Security → 进入下一分支3.2 第二关superpowers —— 方法层铁律原文只要你认为某技能有哪怕 1% 的可能适用就绝对必须调用它。如果技能适用于你的任务你没有选择必须使用它。这不可协商、不可选、你无法靠合理化绕开。这段话的语气很重是有意为之。工程师最常犯的错误就是我觉得这次不需要查技能——而这恰恰是方法偏差的根源。1% 规则不是为了绑架你每个操作都查一遍技能而是为了消除你觉得不需要这个过滤条件。当门槛降到 1%几乎每次任务都会查一次技能查完发现不适用也没关系——成本只是几秒钟的一次调用但防止的是可能浪费数小时的方法偏差。流程收到用户消息 → AI 问自己有技能适用吗 → 是则调用 Skill 工具 → 宣布Using [skill] to [purpose] → 建 todo → 严格遵循技能指示。技能优先级多个技能可能同时适用时Process 技能先于 Implementation 技能。Process 技能决定怎么思考——如 brainstorming 教你怎么发散收敛、debugging 教你怎么定位根因。Implementation 技能指导怎么执行——如 frontend-design 教你怎么布局组件、mcp-builder 教你怎么配工具。指令优先级用户显式指令CLAUDE.md、AGENTS.md、直接说的别用 TDD永远是最高优先级高于 superpowers 技能。superpowers 技能高于默认系统提示。红牌清单superpowers 定义了 11 种 STOPSIGNAL最典型的几个你的想法实际该怎么做这只是个简单问题问题也是任务查技能我先要更多上下文技能检查先于澄清问题我先探索代码库技能告诉你怎么探索先查技能我记得这个技能技能会演进读当前版本我先干这一件行动前先查技能这不算任务行动就是任务查技能技能太重了简单事会变复杂用技能保证不会漏下面这张图展示了 superpowers 的决策流程来源superpowers 全部 — 取自/Users/fei/.workbuddy/skills/using-superpowers/SKILL.md— local/skill铁律原文只要你认为某技能有哪怕 1% 的可能适用就绝对必须调用它 — 同上3.3 第三关OpenSpec —— 产物层核心思想写任何代码之前先让人和 AI 就要构建什么达成一致把意图锁在代码仓库里。这不是瀑布式的需求冻结——而是先对齐再动手的局部前置约束。你改一个功能只对那一个变更写 spec其他部分不动。改完之后 spec 和代码一起归档下次再改时从最新的 spec 出发。真相源与提议分离仓库内维护两套文档路径。specs/描述系统当前的行为——这是真相源任何人任何时候来读都知道系统现在应该实现什么功能。changes/描述提议的修改——这是变更提议文件夹在 spec 被确认前暂时存在。两者之间靠 delta 关系管理一个变更包含三类增量——ADDED新增需求、MODIFIED修改已有需求、REMOVED移除废弃需求。归档时 delta 合并回主 specs/而变更文件夹本身移到 changes/archive/ 作为历史记录。两个半边——这是新手最容易混淆的地方终端 CLIopenspec命令开头的操作。openspec init初始化项目。AI 对话 slash/opsx:...开头的命令说给 AI 助手听的不是敲在终端。完整五步迭代链/opsx:explore—— 无负担的思考伙伴。AI 读你的代码、权衡选项磨出一个方案但不动任何文件。/opsx:new—— 建 change 文件夹写入 proposal.md。包含 Why为什么做、What做什么、Scope范围——包含和不包含什么、Success criteria怎么验证成功。/opsx:fffast-forward—— 一次性生成三个规划产物specs/需求文档、design.md技术决策记录、tasks.md实现清单。/opsx:apply—— AI 按 tasks.md、design.md、specs 系统性实现代码。每完成一项更新进度确保按清单推进而非自由发挥。/opsx:archive—— 变更合并回主 spec。ADDED/MODIFIED/REMOVED 三类 delta 写回specs/历史记录移到changes/archive/。轻量特征无 API key、无 MCP 依赖、约 5 分钟安装、brownfield 友好、与 20 多种 AI 编码助手集成。下面这张图展示了 specs/ 与 changes/ 之间的 delta 关系# OpenSpec 完整命令链# 安装需要 Node.js 20.19.0npm install -g fission-ai/openspeclatestopenspec init# 在 AI 对话中依次执行五步注意以下命令敲在 AI 聊天框里不是终端/opsx:explore # 自由探索方案读代码、提问、磨想法/opsx:new # 建 proposalWhy / What / Scope / Success criteria/opsx:ff # fast-forward输出 specs/design/tasks 三个文档/opsx:apply # AI 按文档列表系统性实现/opsx:archive # delta 合并回主 spec历史存在 archive/# 快速决策参考# ✅ 新功能 → /opsx:new# ✅ 破坏性变更 → /opsx:new# ✅ 不确定 → /opsx:new更安全# ❌ bug fix → 直接改# ❌ typo / 注释 → 直接改4 案例给 App 加用户认证走通三关场景一个已有的 Spring Boot App需求是加用户认证。项目已经在跑了有现成的代码和配置你只想加一个功能而不破坏现有逻辑。第一关grill-me 确认范围AI 收到加用户认证后不写任何代码先沿决策树追问。grill-me 先给出推荐答案再提问建议 JWT refresh token 做认证——但先问你是要简单 JWT还是企业级 OAuth 2.0 SSO。用户确认要 OAuth 后继续追问提供商Google / GitHub 还是企业 IDP、用户模型邮箱密码还是 LDAP/AD、后端技术栈Spring Security 复用还是自定义 filter。能用 Read/Grep 自答的——比如项目用了什么框架——grill-me 直接 grep 出来。所有分支走完确认 OAuth 2.0 SSO JWT 兜底、LDAP/AD 集成、Spring Security 复用没有it depends。最终 AI 用一段话总结所有决策用户确认无误。这个澄清过程看起来多花了三五分钟但省掉了后续可能的三轮代码重写。第二关superpowers 调度方法1% 铁律触发——需求涉及写代码前先规划→ superpowers 检测到 OpenSpec 技能可能适用 → 宣布Using openspec-workflow to spec-driven develop the auth feature。Process 技能先于 Implementation先执行 brainstorming 技能规划认证方案的架构和备选路径再执行 openspec-workflow 技能指导实现。第三关OpenSpec 执行产物闭环从/opsx:explore开始——AI 读取项目现有的 SecurityConfig.java了解 Spring Security 的配置方式。/opsx:new建 change 文件夹oauth-sso写入 proposal.mdWhy企业客户要求 SSO 登录、WhatOAuth 2.0 SSO JWT 兜底、Scope不影响现有 API 的认证逻辑、Success criteria可同时支持 OAuth 登录和原有 JWT 登录。/opsx:ff输出 specs/auth/spec.md、design.md、tasks.md。/opsx:apply按 tasks 清单逐项编码。/opsx:archive归档。# ------- 第一关grill-me 澄清 ------- 建议用 JWT refresh token 做认证这是最通用的方案。 你是想要 OAuth 2.0 SSO还是简单的 JWT 就够用户: OAuth 2.0 SSO企业客户必须要这个 明白了。用户模型方面建议集成 LDAP/AD用户: 对公司已有 AD 后端框架方面我 grep 了一下项目发现已经在用 Spring Security — 复用它用户: 是 总结确认OAuth 2.0 SSO 对接企业 ADJWT 兜底做 token 格式Spring Security 复用。有遗漏吗用户: 没有开始吧# ------- 第二关superpowers 介入 -------Using openspec-workflow to spec-driven develop the auth featureTodo: [explore → new → ff → apply → archive]# ------- 第三关OpenSpec 执行 -------/opsx:explore# AI: 正在读取项目 security 配置...发现 SecurityConfig.java 只有基础配置。/opsx:new# 生成 changes/oauth-sso/proposal.md/opsx:ff# 生成: specs/auth/spec.md design.md tasks.md/opsx:apply# 逐项编码OAuth2 配置 → JWT 过滤器 → LDAP 集成 → 测试/opsx:archive# specs/auth/spec.md 更新为含 OAuth 的新需求# 变更历史: changes/archive/2026-07-25-oauth-sso/来源grill-me 对话 — 取自/Users/fei/.workbuddy/skills/grill-me/SKILL.md— local/skillsuperpowers 1% 铁律 — 取自/Users/fei/.workbuddy/skills/using-superpowers/SKILL.md— local/skillOpenSpec 命令序列 — [9]https://openspec.pro/workflow/[10] — official5 横向对比单用 OpenSpec vs 三件套三件套本质上是在 OpenSpec 的规范驱动之前加了两层心智过滤器——grill-me 确保你不会在错误的需求上写出完美的 specsuperpowers 确保你不会用错误的方法来执行正确的 spec。下面用统一评判维度做对比评判维度单用 OpenSpec三件套需求先对齐只有产物层对齐——spec 写什么流程就建什么但 spec 之前的模糊地带无人打理澄清层grill-me先用决策树扫盲区暴露所有隐藏假设让用户确认方法找对默认走 AI 自己的方法论——AI 天然倾向于先写代码再想superpowers 的 1% 铁律强制先查技能确保正确方法论优先执行返工率控制低——spec 锁住意图防止功能层面跑偏但挡不住需求误解和方法偏差更低——前两层覆盖了需求误解和方法偏差两道前置过滤新人上手需要自己悟工作节奏——我该先 explore 还是直接 new三关输入即落地框架——按顺序走就是最佳实践可审查性specs/ 当前状态——可以看系统现在是什么样同上 grill-me 的决策树对话可归档——可回溯为什么系统是这样一句结论单用 OpenSpec 已经能把AI 建不对的概率大幅降低——spec 锁住意图代码不会偏出轨道。但三件套叠加了两步前置过滤——先问清楚、先找对方法——把返工率从低推到极低。这里做的对比是工作流思维层面的对比。三件套不是 OpenSpec 的替代品而是以它为基座在前端补齐了缺少的两个环节。下面这张图直观展示了两种模式的路径差异6 最小实现用 OpenSpec 走完一个完整闭环本节让你亲手跑通一个完整的 spec-driven 闭环——从零安装到归档覆盖三个工具的核心思想。前提条件Node.js 版本不低于 20.19.0。在终端运行node -v确认版本。步骤 1安装与初始化# 确认 Node.js 版本node -v# 预期输出: v20.19.0 或更高版本# 全局安装 OpenSpec CLInpm install -g fission-ai/openspeclatest# 进入你的演示项目根目录初始化cd your-demo-projectopenspec init# 预期输出: 创建 openspec/ 目录结构并生成所选 AI 工具的集成文件步骤 2AI 对话中走通五步# ---------------------------------------------------------------# 进入 AI 助手对话Claude Code、Cursor、Copilot 等均可# 执行前先确认 superpowers 技能是否已加载1% 检查# ---------------------------------------------------------------# ① /opsx:explore — 无负担探索磨方案# AI 会读项目代码、提问澄清、探索选项。不要跳过这一步# 它等价于 grill-me 的问清楚阶段。/opsx:explore# ② /opsx:new — 建 proposal# 生成 changes/功能名/proposal.md包含四部分# - Why: 为什么要做这个变更# - What: 要做什么具体功能# - Scope: 变更范围包含什么、不包含什么# - Success criteria: 如何验证成功/opsx:new# ③ /opsx:ff — fast-forward 快速规划# 一次性产出三个文档# - specs/domain/spec.md# - design.md# - tasks.md/opsx:ff# ④ /opsx:apply — 按文档实现# AI 逐项执行 tasks.md每完成一项更新进度/opsx:apply# ⑤ /opsx:archive — 归档# delta 合并回主 spec临时文档变常驻知识/opsx:archive步骤 3验证成果# 查看当前规范文档ls -la specs/# 查看归档的历史变更ls -la changes/archive/# 预期: 有类似 2026-07-25-feature-name/ 的目录# 查看归档后的主 spec已包含新增需求cat specs/domain/spec.md# 预期: 包含本次变更的完整需求描述预期效果项目 specs/ 目录下有按能力组织的需求文档比如 specs/auth/spec.md 里描述了本次变更的完整功能定义。changes/archive/ 下有带日期目录的历史变更记录。这意味着本次变更的所有决策——Why为什么改、What改了什么、Scope改了多少范围、Success criteria怎么算改好了——全部存储在你的仓库中而不是活在某次 AI 对话的聊天记录里。不管是三个月后你自己回来看代码还是新接手项目的同事都能从仓库中找到每个决策的来龙去脉。不再需要逐行 diff 反推意图不再需要翻聊天记录找为什么。这就是三件套的最终成果需求不蒸发、方法不走偏、意图可审查。来源OpenSpec 安装命令[12] — official工作流命令序列[13] — official7 总结三件套的底层是一条三段式心智模型每次让 AI 助手开始工作时快速过一遍先问清grill-me→ 再找对superpowers→ 后锁死OpenSpec这三个阶段不是一个工具使用说明而是一个完整的思考框架。grill-me 的阶段问我们到底要建什么——把所有隐藏假设暴露出来。superpowers 的阶段问我们应该用什么方法来建——确保你用项目约定的正确流程。OpenSpec 的阶段问建成之后如何让别人知道我们为什么这么建——把意图锁在仓库里。三个工具各自解决一个具体问题grill-me 消灭需求蒸发superpowers 消灭方法论偏差OpenSpec 消灭意图不可审查叠加起来形成需求 → 方法 → 规范的完整链路。不是银弹——但在AI 编码助手总是建不对东西的场景下这是当前最轻量、最可上手的实操方案。你不需要一次性上全三个工具。从今天开始先加第一关下次让 AI 干活前先用三步追问确认需求方向。三工具同属开源社区生态。grill-me 和 superpowers 属于 mattpocock/skills[14] 体系OpenSpecMIT 许可[15]是 Fission-AI 的独立开源框架。需明确三件套是推荐工作流并非官方联合产品grill-me/superpowers 与 OpenSpec 分属不同开源社区体系各自独立演进使用时需关注版本与指令兼容。下面这张图概括了三件套的心智模型——三个先字串联起从需求到代码的完整思考链维度覆盖声明覆盖背景 / 痛点带代价场景/ 原理三关分层/ 案例加认证走通三关/ 代码OpenSpec 五步命令链 最小实现可跑通/ 横向对比单用 OpenSpec vs 三件套/ 总结省略边界说明按 2026-07-24 固化 SOP「移除《边界说明》」指令移除反杜撰的「非官方捆绑」已并入总结节趋势/演进素材缺独立趋势源合并到总结节以「生态定位」轻点不做独立节理由实战指导文核心是「三关工作流如何落地」每关需原理 图 代码四段式最后以可跑通的最小示例收束。