企业官网建设流程全解析

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] — official；grill-me / superpowers 取自本地 SKILL.md，所属体系见 mattpocock/skills[2] — local/skill

2 三个代价场景

在亮方案之前，先看清楚问题的三个典型形态。每个场景都对应一个真实的"为什么三件套有必要"的答案。

场景① 需求蒸发——你说过的每一句话，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/ 作为历史记录。

两个半边——这是新手最容易混淆的地方：

• 终端 CLI：openspec命令开头的操作。openspec init初始化项目。

• AI 对话 slash：/opsx:...开头的命令，说给 AI 助手听的，不是敲在终端。

完整五步迭代链：

1. /opsx:explore—— 无负担的思考伙伴。AI 读你的代码、权衡选项，磨出一个方案，但不动任何文件。

2. /opsx:new—— 建 change 文件夹，写入 proposal.md。包含 Why（为什么做）、What（做什么）、Scope（范围——包含和不包含什么）、Success criteria（怎么验证成功）。

3. /opsx:ff（fast-forward）—— 一次性生成三个规划产物：specs/（需求文档）、design.md（技术决策记录）、tasks.md（实现清单）。

4. /opsx:apply—— AI 按 tasks.md、design.md、specs 系统性实现代码。每完成一项更新进度，确保按清单推进而非自由发挥。

5. /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.0）
npm install -g @fission-ai/openspec@latest
openspec init

# 在 AI 对话中依次执行五步（注意：以下命令敲在 AI 聊天框里，不是终端）
/opsx:explore # 自由探索方案，读代码、提问、磨想法
/opsx:new # 建 proposal（Why / 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.md：Why（企业客户要求 SSO 登录）、What（OAuth 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 对接企业 AD，JWT 兜底做 token 格式，Spring Security 复用。有遗漏吗？"
用户: "没有，开始吧"

# ------- 第二关：superpowers 介入 -------

Using openspec-workflow to spec-driven develop the auth feature
Todo: [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/skill；superpowers 1% 铁律 — 取自/Users/fei/.workbuddy/skills/using-superpowers/SKILL.md— local/skill；OpenSpec 命令序列 — [9]https://openspec.pro/workflow/[10] — official

5 横向对比：单用 OpenSpec vs 三件套

三件套本质上是在 OpenSpec 的规范驱动之前加了两层心智过滤器——grill-me 确保你不会在错误的需求上写出完美的 spec，superpowers 确保你不会用错误的方法来执行正确的 spec。下面用统一评判维度做对比：

一句结论：单用 OpenSpec 已经能把"AI 建不对"的概率大幅降低——spec 锁住意图，代码不会偏出轨道。但三件套叠加了两步前置过滤——先问清楚、先找对方法——把返工率从"低"推到"极低"。

这里做的对比是工作流思维层面的对比。三件套不是 OpenSpec 的替代品，而是以它为基座在前端补齐了缺少的两个环节。

下面这张图直观展示了两种模式的路径差异：

6 最小实现：用 OpenSpec 走完一个完整闭环

本节让你亲手跑通一个完整的 spec-driven 闭环——从零安装到归档，覆盖三个工具的核心思想。

前提条件：Node.js 版本不低于 20.19.0。在终端运行node -v确认版本。

步骤 1：安装与初始化

# 确认 Node.js 版本
node -v
# 预期输出: v20.19.0 或更高版本

# 全局安装 OpenSpec CLI
npm install -g @fission-ai/openspec@latest

# 进入你的演示项目根目录，初始化
cd your-demo-project
openspec init
# 预期输出: 创建 openspec/ 目录结构，并生成所选 AI 工具的集成文件

步骤 2：AI 对话中走通五步

# ---------------------------------------------------------------
# 进入 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] — official

7 总结

三件套的底层是一条三段式心智模型，每次让 AI 助手开始工作时快速过一遍：

先问清（grill-me）→ 再找对（superpowers）→ 后锁死（OpenSpec）

这三个阶段不是一个工具使用说明，而是一个完整的思考框架。grill-me 的阶段问"我们到底要建什么？"——把所有隐藏假设暴露出来。superpowers 的阶段问"我们应该用什么方法来建？"——确保你用项目约定的正确流程。OpenSpec 的阶段问"建成之后如何让别人知道我们为什么这么建？"——把意图锁在仓库里。

三个工具各自解决一个具体问题：

• grill-me 消灭"需求蒸发"

• superpowers 消灭"方法论偏差"

• OpenSpec 消灭"意图不可审查"

叠加起来，形成"需求 → 方法 → 规范"的完整链路。不是银弹——但在"AI 编码助手总是建不对东西"的场景下，这是当前最轻量、最可上手的实操方案。你不需要一次性上全三个工具。从今天开始，先加第一关：下次让 AI 干活前，先用三步追问确认需求方向。

三工具同属开源社区生态。grill-me 和 superpowers 属于 mattpocock/skills[14] 体系，OpenSpec（MIT 许可[15]）是 Fission-AI 的独立开源框架。

需明确：三件套是推荐工作流，并非官方联合产品；grill-me/superpowers 与 OpenSpec 分属不同开源社区体系，各自独立演进，使用时需关注版本与指令兼容。

下面这张图概括了三件套的心智模型——三个"先"字串联起从需求到代码的完整思考链：

维度覆盖声明

• 覆盖：背景 / 痛点（带代价场景）/ 原理（三关分层）/ 案例（加认证走通三关）/ 代码（OpenSpec 五步命令链 + 最小实现可跑通）/ 横向对比（单用 OpenSpec vs 三件套）/ 总结

• 省略：边界说明（按 2026-07-24 固化 SOP「移除《边界说明》」指令移除；反杜撰的「非官方捆绑」已并入总结节）；趋势/演进（素材缺独立趋势源，合并到总结节以「生态定位」轻点，不做独立节）

• 理由：实战指导文，核心是「三关工作流如何落地」，每关需原理 + 图 + 代码四段式，最后以可跑通的最小示例收束。