网硕互联帮助中心从一句模糊需求，到一份能开工的规格，到底怎么一步一步定下来？这篇我不打算先从方法论讲起，直接装现成的 superpowers，真跑一遍 brainstorming，把每一步真实对话记录给你看。
先抛我的反直觉判断：brainstorming 最值钱的不是它会问，是它不让写代码。会问问题的 AI 一抓一大把，「不许在没想清楚之前动手」的 AI 少得多——后者才是从「模糊」到「规格」的真正推手。
superpowers 与 brainstorming 速览
先把这工具说清楚。superpowers 是 obra（Jesse Vincent，前 Anthropic 员工）写的开源 Claude Code 插件，MIT 协议。2025 年 10 月开源，2026 年初进了 Anthropic 官方插件市场，/plugin install superpowers@claude-plugins-official 一条命令就装，GitHub 上已经十几万 stars。它的核心哲学一句话：Process over Prompt——流程比提示词重要。插件打包了 14 个技能，brainstorming 是入口，后面依次是 writing-plans、subagent-driven-development、test-driven-development 一整条链。
brainstorming 的名字有误导性。它不帮你发散找灵感，它干的是把一句模糊需求，逼成一份能开工的设计文档。逼的过程靠两道东西：一份九步清单，和一道硬闸。
前面写了一篇博文拆解superpowers，有需求的同学可以查阅：【】
硬闸：不批准设计，不写一行代码
技能源文件开头是一段 <HARD-GATE>，原文照抄：
Do not invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
翻译过来就一句话：没提交设计、你没点头，一行代码都不许写。而且「不管你觉得项目多简单」。技能里专门立了一个反模式叫「This Is Too Simple To Need A Design」——它说「简单」项目恰恰是未经检验的假设造成最多浪费的地方，设计可以短到几句话，但必须呈现、必须批准。
为什么非得写成「闸」而不是「建议」？作者 Jesse Vincent 在一篇博客里把 Rule 和 Gate 分开了：Rule 有绕行的余地，就像「过马路记得看路」，你可以说「我赶时间这次算了」；Gate 没有，必须左看、右看、再左看，然后才能迈步。他做了个实验，让 Claude 复盘自己为什么跳过设计直接写代码，模型的回答很诚实：技能里说「用 200-300 字呈现设计」，对一个 todo list 来说这太荒谬了，所以我认为整个设计流程是多余的，直接开始写了。建议性的语言会被 LLM 自我合理化然后忽略，闸不给你这个选项。
九步清单
注意终态只有一格：移交 writing-plans。技能里写死「不许调用 frontend-design、不许调用 mcp-builder，唯一能调的下一个技能是 writing-plans」——这条链是设计→计划→实现的单向道，不许跳步。
真实会话记录
下面是完整记录，这是真实会话记录（子代理按 superpowers v6.2.0 brainstorming 技能完整跑过一遍），不是凭空示例。先交代它怎么跑的，免得你以为是我编的：我本地实装了 superpowers v6.2.0（缓存目录里就是这份技能），在一个最小可跑的「内部运营后台」仓库里（Express + better-sqlite3，9 个文件、3 个 commit），同时扮演需求方和遵循技能的工程师，把九步流程完整跑了一遍。设计文档真实落盘到 docs/superpowers/specs/ 并提交了 git——你看到的 commit 历史是真的。
载体沿用系列里的权限管理系统：一个电商团队的内部运营后台，现状是「只要登录，谁都能看到所有功能、改所有数据」。
开场：一句模糊需求
需求方：我想给运营后台加一套权限控制。现在只要登录了，谁都能看到所有功能、能改所有东西。你帮我弄个权限系统吧。
注意这句需求的形状：三个模糊点叠在一起——「权限控制」指什么范围，「谁」是谁，「能改所有东西」哪部分是痛点。大多数 vibe coding 场景，这句话下一秒就被丢给 AI 开始写了。
第 1 步 探索项目上下文：AI 先看你的代码，不急着问
工程师没有先回话，先去读仓库。
工程师：按 brainstorming 流程，我先把项目现状摸一遍，不急着问。 （读 README、git log、requireAuth、路由挂载、前端菜单） 工程师：摸完了，我确认几个事实：Express + better-sqlite3，登录是硬编码一个 admin 账号，auth 只有 login/logout；所有接口只挂 requireAuth——它只挡「登录了没」；前端菜单写死全量渲染；README 自己列了已知问题：没有角色、没有权限、没有审计。三个 commit：init、商品 CRUD、报表接口。
这一步和大多数人（包括我自己）的习惯相反：先看，再问。为什么？因为问题要问在点子上，得先知道现状里哪些是真缺、哪些是已有。「权限系统」四个字，如果我不看仓库就直接问「你要 ABAC 还是 RBAC」，那是拿模板问话，问一百句也问不到这个项目的痛处。技能里明确要求「explore current structure before proposing changes, follow existing patterns」——后面我提方案，就是顺着这个 repo 现有的中间件模式长出来的，而不是另起炉灶。
这里对应一句我常讲的工程常识：AI 的第一步不是问你要什么，是先去看你的代码。 问出来的需求是二手信息，代码里写着的现状是一手信息，一手信息永远先看。
第 2-3 步 逐个澄清需求：一次一个问题
技能规定一次只问一个问题。这是它最反直觉、也最容易被误读成「慢」的地方。七轮问答记录如下。
工程师（问 1，对齐成功标准）：开工前先对齐「成功」长什么样。我给你两个版本选：A「不该看的人绝对进不去」，B「大家日常用着不别扭，别天天来找你解锁」。真冲突的时候，你押哪头？
需求方：都要。但真出冲突，我选安全。团队就十几个账号，宁可严一点，也别哪天老板发现外包能看到报表。
工程师（问 2，列角色）：这系统里都有谁会用到？我先猜一版你补：管理员、运营、只读的老板和财务。还缺谁？
需求方：再加一个供应商吧——外包的几个人要看商品数据，但不能让他们改。哦对，财务也能看报表，就是只读那种。
工程师（问 3，圈范围粒度）：要管的资源我列一下你确认：商品管理、订单查看、数据报表、账号管理、系统设置。哪些要细粒度控制，哪些只要「看/不看」？
需求方：报表和设置肯定要严。商品……其实平时就我和另一个运营在改，先「编辑/只读」两档就够，别搞太细。账号管理只有管理员能碰。订单——先只读吧，反正现在订单也只有查看。
工程师（问 4，切边界）：认证这块这次动吗？现在是硬编码一个账号。我建议这次别碰登录，专心做授权——多账号是下一期的事。你认可吗？
需求方：认可，先别动登录。这次就把「谁能看谁能改」管住。
工程师（问 5，定语义）：一个人能挂多个角色吗？比如既是运营又是财务。如果挂了两个，权限是并集（两份都能干）还是取最严？
需求方：理论上该支持挂多个。并集还是最严……我还真没想过，你觉得呢？
工程师：我推荐并集。角色本质是「把一组权限打包」，一个人拿两份包自然都能用；取最严会让「加角色」反而「权限变少」，很反直觉。具体定案我写进设计文档，你过目时最后拍板。
工程师（问 6，探边界）：有个边界得问：角色以后可能被删（比如「供应商」这个角色不要了）。删的时候还挂在上面的人怎么处理？A 禁止删，B 级联清除绑定，C 挂回一个默认角色。
需求方：A 吧……嗯，其实 C 也说得通。但 A 更稳，删之前得先知道谁还在里面。选 A。
工程师（问 7，查审计）：权限这类操作要不要留痕？谁给谁挂了角色、谁改了权限配置。我默认建议留，成本很低，出事能查。
需求方：要。这也算安全的一部分。老板会问「谁改的」，我总得答得上来。
七轮问题，覆盖目的、角色、范围、边界、语义、审计。逐题看一遍，每个问题背后都堵着一个「AI 会自己猜」的地方：不问成功标准，它默认「灵活优先」；不问角色，它不知道有供应商这种外包；不问并集，它写死单角色；不问删除策略，它自己选一种删法。一次一个问题不是慢，是防止 AI 自嗨——抛一串问题让人答，人大概率挑好答的答两句，剩下的坑留着给 AI 发挥；一次一个问题，逼每个坑都过一遍你的脑子。
还有个细节值得说：问 5 里需求方回答「你觉得呢」，工程师给了推荐但没当场拍板，而是说「写进设计文档，你过目时拍板」。这符合技能的纪律——澄清阶段只探信息，决策放进设计文档让用户在过审关正式确认。别小看这个「留一手」，它把「随便聊聊」和「正式确认」分开了。
第 4 步 提 2-3 个方案：带取舍，给推荐
澄清完，工程师没有直接开写，先给方案。注意技能的要求是「Lead with your recommended option」——先亮推荐，再讲取舍，不是把三个方案摊平让你挑。
工程师：方案 A（我推荐）——RBAC 三层模型：权限点 + 角色 + 用户挂角色。权限点拆到模块级（products:read、products:edit、reports:view…），角色是权限点的集合，用户挂角色。标准做法，以后加「供应商只读+报表」这种组合，改配置就行，不用改代码。代价是多四张表、多一个角色管理界面。 方案 B——角色直写：只建一张角色表，每个角色有哪些权限写死在代码里。最快，但你这系统明天就要加「供应商只读」这种组合，得改代码，每次加权限都发版。 方案 C——ABAC 属性策略：用策略引擎按用户属性、资源属性动态判定。最灵活，但对十几个人的小系统是过度设计，维护成本远高于收益，我不会选。 我推荐 A。顺带砍三样 YAGNI：不做行级数据权限（只到模块权限点）、不做基于时间的临时授权、不做用户组。
需求方：就 A。C 听起来就重，B 太僵。
这一步的价值，是把「第一个想到的方案」和「想清楚之后的方案」分开。vibe coding 最大的坑就是 AI 拿到需求第一个冒出来的方案通常不是最优——它总倾向「最省事能跑」，而「最省事能跑」往往把后续扩展的路堵死。技能强制你至少想两个替代方案，逼出真实取舍。YAGNI 那刀也很关键：方案 A 天然的诱惑是把权限做得很全，砍掉行级权限、临时授权，这个权限系统才压得住——规格的密度要和系统复杂度匹配，这是我早前反复说的，这里技能把它做进了流程。
第 5 步 呈现设计分节确认：每节点头才进下一节
方案定了，工程师按「架构→组件→数据流→错误处理→测试」五节把设计拆开，一节一节确认，不一次甩一整篇。
工程师（架构）：沿用现有中间件模式，requireAuth 之上加一个 authorize('权限点') 中间件。新增四张表：permissions、roles、role_permissions、user_roles。前端菜单走 /api/me/menus 按权限过滤。链路：请求 → requireAuth(401) → authorize('products:edit')(403) → handler。这节对吗？
需求方：对，继续。
工程师（组件）：新增 authorize.js、permissions.js（角色/权限管理 API）、me.js（菜单接口）；改 db.js、auth.js、products/reports 路由、index.html。文件清单就是上面的表。可以吗？ 需求方：可以。不过菜单过滤要真做——没权限的入口直接不显示，别点进去才弹 403。
工程师：记下了。菜单隐藏是体验层，API 403 是最后防线，两层都做。
工程师（数据流）：登录时把权限集返回前端渲染菜单；鉴权中间件每次请求实时查库复核，不做会话级权限缓存——这样停用权限点能立即生效。确认？ 需求方：这个「每次查库」会不会慢？
工程师：这规模四张表 join 一次在毫秒级，不值得为它引入缓存复杂度。真到瓶颈再说。
工程师（错误处理）：未登录 401、无权限 403、默认拒绝——权限点不存在、或用户没有任何角色，一律 403。确认？ 需求方：默认拒绝这个好，安全优先。
工程师（测试）：authorize 单测（有权限放行、无权限 403、权限点不存在 403、多角色并集），供应商集成用例（GET 商品 200、POST 商品 403），角色删除被拒，菜单过滤。够吗？
需求方：够。
分节确认有两次真实的「人」介入：菜单过滤要真做、每次查库会不会慢。这两处如果一次甩整篇设计，大概率被一句「设计没问题」带过，然后实现时 AI 按自己理解做——菜单过滤做了个寂寞、或者偷偷加了缓存。分节确认不是仪式感，是给每个容易含糊的点留一个正式的开口。
数据流那节，我画成图长这样，比文字直观：
第 6 步 写设计文档：落盘 docs/superpowers/specs/ 并提交
设计全部确认完，工程师把规格写成文档，落到 docs/superpowers/specs/2026-08-12-permission-system-design.md 并提交。设计文档全文如下，一字未删。
# 权限系统设计文档（RBAC 三层模型）
– 日期：2026-08-12
– 状态：v1.0 用户已过审，移交 writing-plans
– 载体：ops-console（内部运营后台，Express + better-sqlite3）
## 背景与问题
当前系统只有登录态校验（`requireAuth` 只挡「登录了没」）。任何登录用户都能看到全部菜单、改所有数据，没有角色、没有权限点、没有审计。README 已明确这是已知问题，本次把它修掉。
## 目标与非目标
目标：
– 每个受保护操作按权限点判定，无权限返回 403
– 用户可挂多个角色，权限取并集
– 角色是权限点的集合，管理员可自定义
– 菜单按权限过滤，没权限的入口不显示
– 权限变更留审计日志
非目标（YAGNI）：
– 不做多账号与登录重做（保持硬编码 admin，登录属于下一期）
– 不做行级数据权限（只到模块权限点）
– 不做基于时间的临时授权
– 不做用户组
## 用户故事
– US-1 作为运营，我想登录后只看到我能用的功能，这样不会误入没权限的模块
– US-2 作为供应商，我想只看商品、不能改，这样我能跟进商品数据但动不了库存（订单属于核心数据，供应商不开放）
– US-3 作为管理员，我想把「运营」这类权限打包成角色，这样给新人授权一次就够
– US-4 作为老板，我想知道谁改过权限配置，这样出事能追责
## 设计决策（DD）
– DD-1 角色=权限点集合，用户挂角色（RBAC 三层）。放弃 ABAC：团队十几人，属性策略是过度设计。
– DD-2 多角色取并集。角色语义是「打包一组权限」，一个人拿两份包自然都能用；取最严会让加角色反而权限变少，反直觉。
– DD-3 删除仍被引用的角色 → 禁止删除，返回「先改绑用户」。比级联清除安全，符合需求方「宁可严一点」的偏好。
– DD-4 停用权限点后立即生效：鉴权每次请求实时查库计算，不做会话级权限缓存（内存只在单次请求内）。成本低，且权限变更即时可见。
– DD-5 默认拒绝（fail-closed）：权限点不存在、未配置、或用户无任何角色 → 一律 403。
– DD-6 审计只追加、不删除、不修改。
## 权限点目录
| 权限点 | 含义 | 管理员 | 运营 | 供应商 | 只读 |
| — | — | — | — | — | — |
| `products:read` | 看商品列表/详情 | ✓ | ✓ | ✓ | ✓ |
| `products:edit` | 增删改商品 | ✓ | ✓ | – | – |
| `orders:read` | 看订单 | ✓ | ✓ | – | ✓ |
| `reports:view` | 看数据报表 | ✓ | ✓ | – | ✓ |
| `users:manage` | 账号与角色分配 | ✓ | – | – | – |
| `settings:edit` | 改系统设置 | ✓ | – | – | – |
内置四个角色：管理员（全权限点）、运营（products:read/edit、orders:read、reports:view）、供应商（products:read）、只读（products:read、orders:read、reports:view）。
## 架构
沿用现有 Express 中间件模式，新增一个 `authorize(permission)` 中间件，替换只挡登录态的 `requireAuth`。
请求 → requireAuth(401) → authorize('products:edit')(403) → handler
前端菜单接口 `/api/me/menus` 返回带权限标记的菜单，前端按权限渲染；API 层仍是最后防线，菜单隐藏只是体验，不替代 403。
## 组件
新增 / 修改：
| 文件 | 动作 | 职责 |
| — | — | — |
| `src/db.js` | 改 | 新增 `permissions`、`roles`、`role_permissions`、`user_roles` 四张表并 seed 内置角色 |
| `src/middleware/authorize.js` | 新增 | 按权限点校验，查用户角色 → 权限点并集 |
| `src/middleware/requireAuth.js` | 改 | 保留，返回当前用户信息 |
| `src/routes/auth.js` | 改 | 登录后返回用户角色与权限集 |
| `src/routes/permissions.js` | 新增 | 管理员管理角色、角色-权限点绑定、用户-角色绑定的 API |
| `src/routes/me.js` | 新增 | `/api/me/menus` 菜单与权限查询 |
| `src/routes/products.js` / `reports.js` | 改 | 路由级挂 `authorize('products:edit')` 等 |
| `public/index.html` | 改 | 菜单按权限过滤渲染 |
## 数据流
登录 → 服务端查 `user_roles` + `role_permissions` 得权限并集 → 返回给前端（供渲染菜单）→ 前端调 `/api/me/menus` 拿菜单 → 每次受保护请求走 `authorize` 实时查库复核。
> 注意：登录响应里的权限集只给前端渲染菜单用；鉴权中间件每次请求实时查库，不把登录时的权限副本当鉴权依据，否则「停用权限点立即生效」就失效了。
## 错误处理
– 未登录：401 `{ error: '未登录' }`
– 已登录但无权限：403 `{ error: '没有权限' }`
– 权限点不存在 / 用户无任何角色：403（默认拒绝）
– 删除被引用的角色：409 `{ error: '该角色仍绑定 N 个用户，请先改绑' }`
## 测试
– 单测 `authorize`：有权限放行 / 无权限 403 / 权限点不存在 403 / 多角色并集
– 集成：供应商 GET /api/products 200、POST /api/products 403、GET /api/reports/summary 403（供应商无报表与订单）
– 边界：停用权限点后下次请求立即失效；删除被引用角色被拒；`/api/me/menus` 只含有权菜单
## 边界用例（决策记录）
– EC-1 角色分配后何时生效：立即生效（DD-4）。
– EC-2 给不存在用户分配角色：返回 400 明确错误，不静默忽略。
– EC-3 删除仍绑定用户的角色：禁止，返回 409 提示先改绑（DD-3）。
– EC-4 管理员是否绕过权限点：不引入特殊绕过逻辑。管理员通过「拥有全部权限点」实现，鉴权路径只有一条，避免两套判断分叉。
– EC-5 两个管理员并发改同一用户角色：后写覆盖（last-write-wins），两次都记审计。
– EC-6 停用权限点后已打开的页面：前端下次请求拉 `/api/me/menus` 时按最新权限重算，不做服务端推送。
## 审计
对以下操作写 `audit_logs`：分配/移除用户角色、创建/修改/删除角色、修改角色权限点、停用权限点。记录操作人、动作、目标、时间。只追加。
## 移交说明
本设计经用户过审后，移交 `writing-plans` 拆实施计划。任务粒度 2-5 分钟级，按「写 FAILING 测试 → 最小实现 → 通过 → 提交」推进。
这份文档的章节结构长这样：
把这份文档和我早前自建的 requirements.md 摆在一起，能看到同一套骨架：背景、目标/非目标、用户故事、决策记录、边界用例。区别在于自建 spec 是我自己按四件套写的，这篇是技能在对话后自动产出的——结构是别人设计好的，但每一格里填的都是我们刚才七轮对话逼出来的真决策。 那些「✓ / -」的格子，没有问 5、问 6、问 7，AI 填不出对的。
第 7 步 自检：占位符、矛盾、范围、歧义
写完文档，工程师没有直接甩给用户，先自己以「第一次进项目的人」的视角重读一遍。四查：占位符、内部一致性、范围、歧义。真实跑的时候抓出两处，当场修掉：
工程师：占位符——没有 TBD/TODO，过。 一致性——「数据流」里写「登录时把权限集存进 session」，后面又写「鉴权不读 session」，这两句摆一起，实现的人会问「那存它干嘛」。
修：改成「登录响应返回权限集给前端渲染菜单；鉴权每次实时查库」。 歧义——EC-4 原稿写「管理员绕过权限点检查」，但权限点表里管理员本来就全有，「绕过」等于多一条判断路径，两套逻辑容易打架。
修：管理员就靠「拥有全部权限点」实现，鉴权只有一条路。 范围——单计划可承载，无需拆子系统。修完重新提交。
这两处都是真实的、当场抓出来的问题，不是走形式。注意第一处的本质：我自己写的文档里自相矛盾，写的时候没察觉，换个视角重读才看见。自检的价值就是「换双眼睛」——写的时候你有上下文，读的时候你要假设自己什么都没有。
第 8 步 用户过审：人读文档，点头才算数
自检通过后，工程师把文档交给用户。
工程师：规格已写到 docs/superpowers/specs/2026-08-12-permission-system-design.md 并提交。请你过目，看完告诉我有没有要改的，然后我们再进 writing-plans 拆实施计划。
需求方（读完）：看了。一处要收紧：供应商别给订单查看。订单是核心数据，外包别碰。
工程师：收到。改权限点表（供应商 orders:read 打 ×）、US-2、角色汇总、测试用例四处，重新提交。
需求方：行了，就按这个。
这一步是整条流程里最容易被跳过的，也是我认为最值钱的一道闸。规格不是 AI 写给你看的，是你要点头它才能往下走。 7 轮对话里你已经把「供应商只看商品」说了，但「供应商看不了订单」这句你没说——因为你不觉得那是需要声明的事，直到你亲眼看到权限点表里那一排 ✓，你才意识到外包能碰订单。这就是为什么文档必须给人读一遍：AI 对话里的共识是一闪而过的，落成文档的表格才会逼你逐格确认。
第 9 步 移交 writing-plans：终态，唯一出口
用户点头，工程师收尾。
工程师：设计定稿已提交。按流程，下一步调用 writing-plans 技能，把这份 spec 拆成每个任务 2-5 分钟、绑验收测试的实施计划清单。
需求方：好，开始吧。
九步走完。规格定了：一份 RBAC 三层模型的设计文档，落盘、提交、过审。接下来它会被 writing-plans 拆成任务清单，走 TDD 实现——那是系列 005/006 已经讲过的格，本篇不展开。
复盘：这套流程每一步在防什么
把九步摊开，每一格都在防一种 AI 协作里的具体崩法。
防 AI 自嗨，靠硬闸。第 2 章那段 Rules vs Gates 的故事是整篇的题眼——Claude 不是不会设计，是它会「觉得这太简单不需要设计」，然后跳过。闸不给你这个判断的余地。这是超出一个「好提示词」能力的地方：提示词求的是模型「愿意」遵守，闸规定它「不许」不遵守。
防范围失控，靠逐题澄清。一次一个问题，把目的、角色、范围、边界、语义、审计逐个钉死。范围失控从来不是「需求太多」，是「每个词都有三种理解而没人对齐」。
防拍脑袋，靠 2-3 方案 + YAGNI。方案 B 和 C 的价值不在被选，在于它们逼你确认 A 为什么对：B 让你看到「改代码发版」的代价，C 让你看到「过度设计」的代价。没有对照组，A 只是「AI 的第一个想法」；有对照组，A 才变成「选出来的方案」。
防自说自话，靠用户过审。第 8 步那个「供应商别碰订单」，是整场会话里我（作为需求方）唯一一次真正改口的地方——但正是这一改，证明文档值得写。AI 对话里的共识不留痕，文档里的表格留痕。
但这套流程有明确的适用边界。社区的声音我检索核实过，反面的很实在：有开发者吐槽「哪怕最小任务也要半天、Claude 不停拉起子代理」，一个中等功能原生 30 分钟，套上完整 superpowers 流程能干到 2-3 小时、token 消耗翻倍；有人把它比作「杀鸡用牛刀」，卸载回去用 Claude Code 原生的 /plan。有个评论说得刻薄但真实：「如果你觉得工作完成得太快、token 花得太少，那你一定要装这个 skill。」数据侧，subagent 模式每次派发光固定开销就有约 5-8K token，单行改动根本不值。多数社区的共识是：保留 brainstorming + writing-plans 两步（前置的「早期准备」最值钱），砍掉重型的执行/评审/子代理阶段；小改动直接用原生 /plan，别过这套流程。
我的判断：brainstorming 的适用边界是「复杂度够你愿意付一次澄清成本」。改个文案、加个字段，别跑；要新起一个模块、动到权限这种横切逻辑，值得跑。判断标准一句话：如果需求里藏着的歧义可能让实现返工一次以上，就跑；否则直接干。
结论：把「需求→规格」这条路踩实
回到开头那句：brainstorming 最值钱的不是它会问，是它不让写代码。走完这九步，你应该能看到这句话的分量——brainstorming 不是让你「想清楚」，是让 AI「不许没想清楚就动手」。 七轮问题、三套方案、五节设计、一版自检、一次过审，绕这么大一圈，产出不过是一份几百行的 markdown。但它把「我以为我讲清楚了」戳破了，把「AI 会自己猜」的地方一个个堵上了。最便宜的 bug，是代码还不存在时就被删掉的那个——这句话我早前说过，这篇用一个真实会话再证了一遍。
下篇我打算接着跑下一场真实会话：writing-plans 怎么把这份规格，拆成每个任务 2-5 分钟、绑验收测试的实施清单——规格到代码的关键一跳。关注不迷路。
你装 superpowers 之后，第一步跑的是哪个技能？卡在哪一步——是嫌问题多，还是不知道什么时候该跑？评论区说说。想让哪一步展开、或者想换个需求再跑一遍 brainstorming 的，也评论区告诉我，我记下来可能就成下一篇。
收个尾。如果你只让我留一句：提示词问「怎么干」，spec 问「要什么」——而 brainstorming 做的是第三件事：在你和 AI 之间立一道闸，谁没想清楚，谁都不许动手。 这比任何提示词都值钱。
评论前必须登录！
注册