从想法到上线
第 2 章 · 用 Skills 澄清需求：一轮 grilling 追问
盘点本地可用的 Skills，用 grill-me / grilling 方法把需求说明背后的隐藏决定一个个拍板，画出完整的决策树。
这一章解决什么问题
第 1 章的一页需求说明仍然藏着大量没做的决定：「只给我自己用」——那要不要登录？「手机电脑都能看」——那数据存在哪？「只看未掌握的词」——「掌握」由谁定义、怎么标记？这些决定不拍板，AI 写代码时就只能替你猜，猜错一个，后面全要返工。
这一章教两件事：
- 盘点你本地有哪些 Skills，以及什么时候值得调用一个；
- 用 grill-me / grilling 的方法（一种「拷问式需求追问」），让 AI 按轮次把所有待决定的问题摆上台面，你逐个拍板，最后形成一棵决策树。
开始前你要有什么
- 第 1 章的一页需求说明
- 一个可用的 AI 编程工具会话
- （可选）知道自己的 Skills 装在哪——下一节就教
分工：人判断什么，AI 做什么
| 人负责（判断） | AI / Skills 负责（加工） |
|---|---|
| 回答每一个问题（用你的真实情况） | 把问题按依赖关系排成轮次：先问不依赖别人的，再问被答案解锁的 |
| 接受或拒绝 AI 的推荐答案 | 每题附一个推荐答案和理由，供你参考 |
| 承认「不知道」而不是随口编 | 查得到的事实（文档、环境）自己去查，不来烦你 |
| 拍板「就这么定」 | 追问到没有任何问题还能问（frontier 为空）为止 |
grilling 的一条关键纪律：决定是你的，事实是 AI 的。 「词要不要存云端」是决定，问你；「Supabase 免费档现在什么额度」是事实，让 AI 自己去查。
怎么做
第 1 步：盘点本地可用的 Skills（约 5 分钟）
Skills 是装在本地、给 AI 附加的「工作方法包」。看一眼你有什么，两种办法：
# 办法一：直接看安装目录（本教程编写时实机验证过这两个目录）
ls ~/.claude/skills ~/.agents/skills 2>/dev/null# 办法二：直接问你的 AI 工具
你本地装了哪些 skills？各自适合什么场景？用一句话列出来。编写时参照环境里能看到 100 多个 skill，但做产品常用的是一小撮，按用途分：
| 用途 | 常见 Skill（名字可能不同） | 什么时候用 |
|---|---|---|
| 拷问需求、把隐藏决定问出来 | grill-me / grilling | 动手写代码之前，需求会决定架构时 |
| 把讨论沉淀成规格文档 | to-spec | 追问结束、要写 PRD 时（第 3 章） |
| 把规格拆成任务 | to-tickets | PRD 定稿、要开工时（第 5 章） |
| 换个角度重构问题本身 | reframe-product-need 之类 | 感觉需求方向不对、又说不出哪不对时 |
选择标准只有一条：看它的工作方法是不是你现在需要的。调用前让 AI 念一下这个 skill 的说明（「grilling 是怎么工作的？」），确认它做的事和你想做的事一致，再进正题。
第 2 步：发起一轮 grilling（约 20 分钟）
把你第 1 章的需求说明原样贴给 AI，加上一句调用：
/grill-me
这是我的需求说明（粘贴第 1 章的一页说明）。
请用 grilling 的方式追问我：按轮次提问，每轮只问现在能回答的问题，
每题给出你的推荐答案和理由；我回答后再进入下一轮。（没有这个 skill 的话，把这段话里的方法描述直接发给 AI 也一样有效——方法比名字重要。）
AI 会回来第一批问题，形态大概是这样（以下问题与回答都是教学假设，示范形态用；请用你的真实情况回答）：
Q1 · 给谁用
需求说「先只给我自己」。第一版要不要支持多个账号？
A. 只要一个账号（我自己的） B. 要多账号，给同学也注册用
➡️ 推荐 A：两周试用是唯一目标，多账号带来登录和权限复杂度，
但你还没有「别人要用」的任何证据（呼应你第 1 章的假设清单）。
Q2 · 单词数据从哪来
词是手动录入，还是接词典接口自动带出释义？
A. 手动录入（单词+我自己写释义） B. 接词典 API 自动补全
➡️ 推荐 A：手动录入恰好是你「复习法」的一部分（写释义=第一次加工）；
接 API 要注册第三方服务、处理密钥和失败情况，两周试用用不上。
Q3 · 「复习」到底做什么
「只看未掌握的词」这个需求，第一版做成什么程度？
A. 给每个词一个「未掌握/已掌握」状态，列表能按状态筛选
B. 做间隔重复算法（类似 Anki，自动安排每天该复习哪些）
➡️ 推荐 A：B 的算法设计本身就是一个产品；
你的验收标准（a/b/c 三条）里没有任何一条需要算法才成立。第 3 步：逐题拍板，注意每个答案的连锁反应（约 15 分钟）
回答时盯三件事：
- 推荐理由成立吗？ Q3 推荐 A 的核心理由是「你的验收标准里没有一条需要算法」——拿你第 1 章的产物对照，而不是觉得「推荐听起来专业」就接受。
- 这个答案解锁/关闭了哪些后续问题？ 下面这棵树里，D1（单账号）没定之前，D6（权限）根本没法问。
- 取舍你接受吗？ 选 A 就放弃了「自动补释义」的爽感，选 B 就要处理第三方服务的失败情况——没有全都要，只有先要哪个。
全部追问结束后，把结果整理成决策树。案例的最终形态是这样（每条答案都是教学假设）：
生词本第一版怎么做
│
├── D1 给谁用？ → 先只给我自己，但要独立账号（一人一号）
│ 影响：不做「分享/协作/班级」，但账号不可省——它是数据归属的前提
│
├── D2 词从哪来？ → 手动录入：单词 + 我自己的释义；例句、来源可选填
│ 影响：不接任何第三方接口；释义是必填（强迫第一次加工）
│
├── D3 复习第一版做什么？ → 只做「状态标记 + 按状态筛选」
│ 影响：不做间隔重复算法；「掌握/未掌握」是两个固定状态，不自定义
│
├── D4 数据存哪？（依赖 D1、D5）→ 云端数据库，不用浏览器本地存储
│ 为什么：D5 要求换设备可见，本地存储换浏览器就没了
│ 影响：项目从「纯静态页」升级为「前端+后端+数据库」（第 6 章主角）
│
├── D5 在什么设备用？ → 手机和电脑都要用
│ 影响：页面必须响应式；数据必须云端（与 D4 互锁）
│
├── D6 别人能不能看到我的词？（依赖 D1）→ 不能
│ 影响：必须登录才能看任何词；每个词归属账号；接口要按账号过滤（AC8）
│
└── D7 你能投入多少维护？ → 会用 AI 编程工具跟做；托管越省心越好，免费额度够用
影响：第 4 章选型排除「自建服务器」，偏向托管数据库+一体化平台第 4 步：让 AI 输出决策表并停止（约 5 分钟）
把以上所有已拍板的决定整理成决策表：每行 = 编号、决定、理由、
放弃了什么（取舍）、影响后续哪些环节。已经没有还能问的问题时，
明确告诉我「没有待决定的问题了」，不要再发起新一轮。判断 grilling 输出有没有用的三个标准：
- 好问题：答案会改变你后面要做什么，且现在就能回答。坏问题：答不答都不影响（删）；或者要查外部事实才能答（让 AI 自己查去）。
- 好推荐：理由引用了你的需求和验收标准。坏推荐：理由是「一般都这么做」「很多人用」。
- 好停止：AI 主动说「没有能问的了」。一直问个不停，说明范围没锁住——限定它「只追问影响数据保存、页面数量和账号的决定」。
产物与检查
产物：决策表（附更新过的需求说明）。检查表：
- 每个决定都有编号、决定、理由、放弃的取舍
- 依赖关系清楚：先拍板的决定确实是后面问题的前提
- 每条示例答案都知道是假设还是要落到你自己头上的真实情况
- 有「没有待决定的问题了」的收尾，而不是问一半就去写代码
不满意或失败时怎么调整
- 问题太发散（问到你审美偏好去了）：限定范围——「只追问会改变页面数量、数据结构或是否需要账号的决定」。
- 推荐答案和你的直觉相反：别硬选推荐。把你的想法作为答案回给它，让它列出你这么选要多做什么——多做的事你接受，就按你的来。拍板的是你，AI 的推荐只是替你把代价算给你看。
- 某个决定实在拿不准：选可逆的那个，并在决策表里标注「两周期满复核」。比如 D3 先做状态筛选，两周后真觉得不够，再加算法不迟；反过来先做算法再删，沉没成本大得多。
交给下一章什么
- 决策表 D1–D7——第 3 章 PRD 的骨架：每个 D 都会落进 PRD 的某个部分（D4/D6 变成数据需求和权限要求，D3 变成功能范围，D5 变成页面要求）；
- 第 1 章的假设清单——其中「我会坚持录入」这类假设不因为 PRD 写完而变成事实，它们要等第 8 章上线后的两周试用才能验证。
案例进度：D1–D7 全部拍板。下一章把这些决定固化成一份 8 条验收条件的 PRD。