第三篇 · 做出东西 / 第 7 章
从想法到规格
你说了半天，AI 做出来的却不是你要的。 问题往往不在 AI，而在你脑子里那份还没说出口的规格。
读完这一章，你能
- 用六步检查链判断一个想法该不该开工，并写出一句话规格；
- 让 AI 像面试官一样一个问题一个问题地拷问你，并说出它为什么有效；
- 把拷问结论整理成一份含七段的规格文件
spec.md，其中写清“不做什么”。
午饭登记 · 当前状态：只有“给同事登记午饭”这个想法，还很模糊
- 必读：立项六步——开工前判断这个想法该不该做。
- 必读：拷问（让 AI 反过来问你）——把模糊变成决策。
- 必读：规格七段——把决策固化成一份
spec.md。 - 可选以后再看：研究与原型，光靠说话说不清时才做出来看。
- 可选工具安装：章末“把技能装上”，没装也能读本章。
第 6 章是简化版：用聊天框，一句句说，靠你自己把握节奏。
这一章和下一章是完整版：把同一套思路固化成几个可以反复调用的技能。
两者不冲突。你可以先用第 6 章走通一遍，再回来用这里的技能把自己的流程升级。
立项六步：这个想法该不该做
立项就是开工前先回答“该不该做、为谁做、做成什么样”，而不是先写代码。 下面这条六步检查链，管的是“该不该做”；这套方法论本身只管“怎么做出来”。
下面这些内容不来自这个方法论。 aihero 那套管的是“怎么做出来”，这一节管的是“该不该做”—— 两者是拼接关系，不是一体。
我特意挑的都是有出处、被反复验证过的做法（来源见 进阶页），而不是我自己的经验之谈。 本章末尾的诚实边界还会再说一次这件事。
六步，在开工之前走完
午饭登记是给同事用的内部工具，不需要验证“有人付钱”。 把第 2 步换成“找 5 个真的会每天用的同事”，把第 4 步换成“看他们第二天会不会自己回来填”。 其余四步照旧。
-
写清问题。一句话，不许提方案。
“我想做个记账 App”是方案。“我每个月月底对不上账，得花两小时翻流水”是问题。 只写问题。
原因很实在：一旦你先写下方案，后面所有“验证”都会变成给这个方案找理由。 这正是本章后面要讲的病根：AI 按你说的做了，但它还是错了。
-
找 10 个真的会遇到这问题的人聊。
不要找朋友、家人、同事。他们的工作是让你开心，不是告诉你真相。 这就是下面“妈咪测试”这个名字的来历——连你妈都会为了保护你的感受而撒谎。
聊的时候只问过去，不问将来。具体怎么问，见下面的对照表。
-
给他看最简的样品。
一页纸的说明、手画的草图、一段 30 秒的短视频——都行。 这个阶段不要写代码。你要验证的是“我理解的问题对不对”，不是“我做得出来吗”。
-
要钱。这是最硬的一关。
做一个要付费的早鸟名额或预购，看有没有人真的掏钱。 目标是 3 个人真的付了。
“想法挺好”和“到时候我一定支持”都不算数——那是礼貌，不是需求。 掏钱是唯一不会撒谎的信号。
-
查一下做不做得出来。
要接微信支付吗？要审核吗？要别人的账号数据吗？涉及这些的话， 先搞清楚规定上允不允许，再动手。
-
写一句话规格，功能不许超过 5 个。
句式是固定的：“帮 [谁] 做 [什么]，从而能 [得到什么]。”
写完之后找个目标用户念给他听，看他能不能准确复述回来。 复述不出来，说明这句话还没想清楚。
你的想法现在是“方案”还是“问题”？ 把“我想做个 X”改写成“谁在什么场景下、遇到了什么麻烦”，只写一句。
怎么问才不会听到假话
这一步有个专门的名字，叫“妈咪测试”（The Mom Test）。 核心规则一句话：你不许说你的想法，对方也就不许评价它。
一旦你说了方案，对方就会进入“鼓励你”的模式——然后你就收到了一堆空话。
会让你听到假话的问法
- “你会用这种工具吗？”（假设）
- “这个想法好不好？”（在讨夸奖）
- “你愿意为这个花多少钱？”（纯属瞎猜）
- “你觉得这个重要吗？”（在要观点）
这些问题的共同点：让人预测未来。而人对自己的未来预测得很差。
能问出真相的问法
- “你上次遇到这事是什么时候？说说当时的情况。”
- “你现在是怎么应付的？”
- “那件事里最麻烦的是哪一步？”
- “你现在为这事花多少时间 / 钱？”
共同点：把人锚在过去具体发生过的事。回忆比预测可靠得多。
“你现在是怎么应付的？”——这句是整套问法里最值钱的一句。
因为如果答案是“没怎么办，忍着”，那说明这事还不够疼，你的东西大概率不会被用。 如果答案是“我用 Excel 硬凑，每周花三小时”， 那你不但确认了问题真实，还顺便知道了该跟谁抢用户（Excel）。
怎么判断结果算不算数
| 强信号（值得做） | 弱信号（先别做） |
|---|---|
| 不用你提醒，他自己回来用第二次 | “这想法挺有意思的”——然后没有然后了 |
| 主动问“什么时候能用上” | 口头说好，但没注册、没留联系方式 |
| 真的付了钱，或者押了时间 | “我很喜欢，等我忙完这段” |
| 把这东西介绍给别人 | 只提了跟主题无关的功能要求 |
判断依据是行为，不是意见。 这一条其实和本章后面讲的“验收标准”是同一个道理—— 只认能亲眼看到的东西。
第一，找你妈（和朋友）问。 他们不是在撒谎，他们是在照顾你。所以他们的答案永远是“挺好的”。 这就是“妈咪测试”这个名字的全部意思。
第二，把“做出来了”当成“验证过了”。 AI 让动手变得极其便宜，所以这一点在现在特别危险—— 你很可能一周就做出一个能跑的东西，然后觉得“这么多人做不出来，我做出来了”。 能跑和有人要，是两件毫不相干的事。
这一节讲的都是可以手工走完的流程。如果你后来想把它升级成一套专业工具 （有一整套现成的技能，从列想法、找假设、排优先级到设计实验）， 我在进阶页里放了一份导航——包括装法和我自己的评价。
但建议你先用手工走一遍。不理解流程本身，工具只会让你更快地走错方向。
七阶段里，这一章管哪四段
这套方法论一共七个阶段。这一章讲前四个， 下一章讲后三个，最后把东西放到网上。
关于起点，官方文档里有一句话说得非常干脆：
“你不需要带着一份想好的方案来开始——把方案做出来，正是这次会话要做的事。”
“模糊不是你等待的理由，模糊正是这次会话要吃掉的东西。”
这两句话值得单独记住。它解决的是零基础的人最常见的一种自我怀疑： “我还没想清楚，是不是不该开始？”——不是。想不清楚是常态， 正确做法不是自己想，而是找个人一个问题一个问题地问你。
病根：你以为你想清楚了
要理解“拷问”为什么是整套方法论的第一步，得先看清楚它到底在治什么病。
下面这段是这套方法论里最锋利的一段话，我几乎原样翻译：
agent 写出来的东西正是你要求的，但它还是错的。通常的原因是： 你自己还没有完全想清楚你要什么。
你要建的那个东西，在你的脑子里还没有成形—— 你的提示词捕获了你已经想明白的部分，而对你想不明白的部分保持沉默。 agent 用它自己的假设填满了这些沉默，因为没有任何东西可供它对齐。
“没有任何东西出故障。”
最后那句话是重点。AI 没有出错，你也没有出错—— 只是你们俩脑子里那个“要建的东西”根本不是同一个东西，而这件事没人发现。
这带来一个非常隐蔽的后果：
直接让它写规格
它不会在你没做决策的地方停下来。
它替你选了默认值，然后写进去。
→ 文档看起来很完整，但“你的选择”和“它的猜测”混在一起，根本分不出来。你只能在很晚才发现——审查时，或者功能上线后以你没选过的方式处理了一个边界情况。
先拷问，再写规格
它必须问你，不许猜。
你想要什么，就答什么；答不上来，它会给你几个选项。
→ 规格里每一个决策都是你做过的。没有埋着的猜测。
用在代码上，这个差别是致命的。同一段逻辑， 在对话里澄清只要两分钟，写进代码再发现要两小时。
阶段一 · 拷问
拷问（grilling）就是让 AI 反过来，一个问题一个问题地问你， 直到你脑子里那个模糊的东西变成一串明确的决策。这是整套方法论的起点。
它不写代码，也不急着写文档。它只做一件事： 把那些你还没做的决定，一个一个问出来。
| 技能 | 什么时候用 | 产出一份文件吗 |
|---|---|---|
/grill-me |
通用场景，没有代码库也能用 | 不产出。它只把更清楚的想法留在你脑子里 |
/grill-with-docs |
你已经有一个项目目录时用（主干流程的正门） | 产出。边拷问边把术语和关键决策写进文件 |
看你手边有没有一个正在做的项目目录。有就用 /grill-with-docs，
没有就用 /grill-me。
这也是官方路由器的原话：区分这两个技能靠的是“你是不是在一个工作目录里”， 而不是口味问题。
它为什么长这样
这套拷问机制背后有一个理论来源，出自 Frederick P. Brooks 的《The Design of Design》， 叫 design tree（设计树）：
设计就是走遍这棵树上的每一个分支，把一个个依赖关系解掉。
所以拷问不是随机提问，而是沿着依赖关系一层层往下走。 作者本人的经验是：一次拷问通常会被问 16 个问题， 复杂的能到 30 到 50 个、持续半小时到 45 分钟。
拷问是怎么运作的
这部分细节最值得学，因为它解释了“为什么这种方式能问出东西来”。
机制里有四个设计，每一个都对应一种常见的失败：
-
一次只问一个决策
如果一口气甩你 20 个问题，你会草草答，等于没问。 一个一个来，你才真的会去想。
-
每个问题都附一个推荐答案
这是最贴心的设计。你不需要凭空想出一个方案， 只要说“行”或者“不对，我要的是……”。 认出对的答案，比想出答案容易得多。
-
事实它去查，决策你来定
这是分工的核心。“这个库支持什么”是事实，它去查；“我到底想要哪种”是决策，必须你答。 它绝不允许自己替你做决策——因为那正是上面说的“病根”。
-
在概念稳定之前，不写任何文档
这一点很反直觉：问完之前不落笔。 因为过早写成文件，只是把“没对齐”这件事固化得更持久而已。
它实际用什么格式问你
你在会话里看到的就是这个形状——题干下面单独一行推荐答案，
那两个符号（❓ 和 ➡️）是固定的：
❓ Q3：筛选状态存在哪里？ A. URL 查询参数 B. 本地存储 C. 服务端会话 ➡️ 推荐 A：可分享、可收藏、刷新不丢，而且不需要后端改动。 代价是 URL 会变长；如果将来状态组合变多，地址会不好看。 ❓ Q4：那“无结果”的时候显示什么？ A. 空白页 B. 一行文案 C. 文案 + 清除筛选的按钮 ➡️ 推荐 C：空白页会让人以为数据丢了。
这样的一来一回叫一轮。
它不是“一次把问题全倒出来”，而是一轮一轮走： 每一轮的问题，是拿你上一轮的答案重新算出来的。
所以问题会越问越尖——从“你想要什么”，慢慢变成 “那 X 和 Y 冲突的时候怎么办”。十来道题分三轮左右问完，是常态。
它走的是一棵设计树：每个答案剪掉一批分支、开出几枝新的。 真正值钱的产出是被剪掉的那些——它们是你本来会花一周去试的路线。 这张树形的图，见技能档案 · 四个底层原语。
官方记录的头号失败模式是这样的，值得原样引一遍：
对四十个问题连着答“同意、同意、同意”， 最后拿到一份“agent 写的、你点过头的”计划。
它感觉很有效率，因为它很长。但实际上什么都没有被决定， 而结果却带着一份它根本不配拥有的确定性。
这句话里最扎人的是最后半句。你点头点得越多，那份规格就越像真的—— 但它只是被重复了一遍，不是被想清楚了。
官方给的自检标准也很好记： “你会对某件事有异议。一场你全程零反驳的会话，是一场你本不需要的会话。”
如果你对 AI 的每个问题都回答“同意”，最后那份规格到底是谁写的？ 你能指出至少一处你真正做过选择的地方吗？
还有两个实操上的讲究：
- 在一个全新的对话里开始，不要叠在 agent 已经写好的一份计划上。
- 关掉 plan mode（计划模式）。 官方原话：计划模式会诱导 agent 冲向“产出一份计划”， 而“停留在一场追问里”恰恰是它的反面。
有些问题靠说话是解决不了的。比如“这个交互用起来什么感觉”、 “这个布局在真实数据量下还成立吗”——你诚实的回答只能是 “我不知道，我得看到它才行。”
到了这一步，讨论就开始原地打转。这时候要换招——进入下一个阶段。
我想做 XXX（用大白话讲就行，模糊也没关系）。 你先不要写任何代码，也不要写任何文档。 请你一个问题一个问题地问我，帮我把这件事想清楚。一次只问一个， 每个问题你都给我一个推荐答案，拿到我的回答再问下一个。
阶段二 · 研究（可选）
拷问的过程中，一定会冒出一些事实性问题—— “这个支付接口支持退款吗”“这个库最新版是什么行为”。这些不该占用你的对话。
这一步对应的技能是 /research。它的做法很有特点：
派一个后台 agent 去读资料，读完整理成一份带引用的 Markdown 文件
（Markdown 是一种用简单符号写格式的纯文本），
而你的对话继续往前走。
官方文档 / 源码 / 规范
它不满足于“某篇博客说这个 API 怎么用”，会一路追到拥有这个答案的那个源头。
你可以抽查
判断它有没有认真干活的方法很简单：随手点开两三个链接，看落点是不是官方文档，而不是别人写的二手介绍。
不占你的对话
它跑在后台，你继续干你的事。如果你坐在那儿盯着它读，说明这个委派没发生。
它产出的是一份“截至今天这个库是这样的”的文档。 官方立场很明确：研究文件是一次性的，用完就该清掉或归档。
原话大意是：这份文件记录的是它写下的那一天为真的事实， 所以过期的研究文件比没有更糟——它会污染后续的对话，把 agent 带偏。
这条对零基础的人尤其重要：不要让 AI 生成的资料在项目里无限堆积。
一个容易混的地方
研究出的是“事实”，拷问出的是“决策”。区分标准是它能存放多久：
| 产出的是 | 保质期 | 用哪个 | |
|---|---|---|---|
| 研究 | 事实 | 短。“这个库这周是什么行为” | /research |
| 拷问 | 决策 | 长。一个你要长期遵守的选择 | /grill-with-docs |
官方那句话很干脆：“如果你产出的是一个决策而不是一个事实，那你是在拷问，不是在研究。”
阶段三 · 原型（可选）
拷问走到死胡同的时候（“我得看到它才行”），就用这一步。
它对应的技能是 /prototype——一个只做原型、不写正式代码的技能。
它的定义非常窄，窄得几乎让人意外： 写一段用完就扔的代码，只为了回答一个问题。
问题排在第一位，它决定了后面一切长什么样。
一个回答了错误问题的原型，无论做得多漂亮，都是纯粹的浪费。
判断标准也很简单：你能不能用一句话说出这个原型是为了回答什么？ 而且这句话应该写在演示界面的最上方，不是只存在你脑子里。
你的问题属于哪一种，决定它长什么样
“这套逻辑 / 状态流转对不对？”
产出一个单独的 HTML 文件——双击就能打开，不需要装任何东西、不需要服务器。
页面上有一块状态面板，每点一下就重新渲染；有自由试玩的按钮，可以按任意顺序乱点；还有分页的引导剧本，每页一个场景，下面列着该按的按钮。
关键：界面上全部用业务语言标注，所以你可以直接发给一个不懂代码的人，让他自己感受这套逻辑。
“这东西该长什么样？”
产出一个页面上几个截然不同的版本，用底部浮条或者网址参数切换。
它们必须在结构上就不一样，而不是换个颜色。
官方原话：三个微调过的卡片网格是壁纸，不是原型。
而且要在真实数据、真实密度下看——在真空里评判一个方案，它永远看起来都挺好。
关于“扔掉”这个词，有个很有价值的澄清：
不是“写完就删”。它的意思是：写的时候不按正式代码的标准写—— 不写测试、不做错误处理（除了让它能跑）、不做抽象、不做持久化。 因为这些对你想要搞明白的那一件事毫无帮助。
留下来的有两样东西：答案（写进提交记录或决策文档，合进正式代码）， 和原型本身（放到一个单独的分支上，永远不合并进主干， 但也不删——它是“这个答案从哪来的”的证据）。
什么时候你已经不是在原型了
官方的判断标准很犀利：当你开始给它加固——加一个测试、接上真实数据库、 为“以后可能会用到的场景”做泛化——你就已经停止原型了。
还有一个必须点破的常见误会：
这不是原型，是演示版，只是披着同一个名字。 原型只针对一个问题，而“整个应用长什么样”不是一个问题。
完整应用原型没有天然的停止点，于是它会顺着惯性变成正式产品： 清理那一步永远不会发生，而用原型规则写出来的代码（没测试、没错误处理） 最终会跑到用户面前。
如果你真的需要销售演示，就把它明确当成演示版来做， 并且说清楚它哪一部分都不是正式产品。
阶段四 · 写规格
走到这里，概念已经稳定了，可以落笔了。这一步对应 /to-spec——
一个把对话整理成规格文件的技能。所谓规格（spec），
就是一份写清楚“要解决什么问题、做成什么样、明确不做什么”的文件。
它不提问。
官方说明写得很硬：“不要面试用户，只做综合整理。”
提问是拷问阶段的职责。每一步只干一件事—— 正是这种分工，让整个流程可预期。
所以下一步能不能写好，完全取决于上一步问得够不够。
规格里有什么
这是它的固定结构——七段，你可以直接拿来当检查表用：
| 章节 | 回答什么 |
|---|---|
| Problem Statement 问题陈述 | 到底要解决什么问题，为什么值得做 |
| Solution 方案 | 打算怎么解决 |
| User Stories 用户故事 | 一长串编号条目，格式固定： “作为一个 <角色>，我想要 <功能>，这样就能 <好处>。” |
| Implementation Decisions 实现决策 | 拷问阶段定下来的技术选择 |
| Testing Decisions 测试决策 | 哪些地方要测、怎么测 |
| Out of Scope 明确不做 | 这一次不做什么 |
| Further Notes 其他备注 | 不属于上面任何一段、但下一个人该知道的事 |
「实现决策」那一段，不许写文件路径，也不许贴代码。
理由很实用：路径会腐烂，行为不会。 写“在 OrderRepository 里加个方法”，三个月后就是错的； 写“按状态过滤订单集合”，永远是对的。
唯一的例外是原型阶段已经产出的代码片段——那种片段本来就是拿来直接用的。 完整的七段模板和一段真实样例，见 技能档案 · 主链五步。
一是“用户故事”的固定句式。 它逼你把三件事同时说清楚：谁用、要什么、为了得到什么好处。 尤其是最后那个“好处”——很多需求一说不出好处，就说明它其实不需要做。
二是“明确不做”被单列成章。 这不是客套。没有边界的方案，会让 AI 无限发挥， 而它发挥出来的每一样东西，最后都要你来验。
关于“PRD”这个词
如果你在别处看到这套方法提到 PRD（产品需求文档）， 它指的就是这一步的产物——但这个词已经被正式改名为 spec 了。
上游在 v1.1 把 to-prd 改成了 to-spec，
官方说法是“统一术语”——不是为了否定 PRD 这个概念，
而是让“spec”成为贯穿整条流水线的唯一用词。文件名也从 PRD.md 改成了 spec.md。
词典里对这几兄弟的关系说得很清楚：PRD 偏用户视角的“做什么、为什么”， 设计文档 / RFC 偏技术—— 但对 agent 来说，它们全都一样：都是“每个会话开始时读的那份持久化的意图声明”。
所以别纠结名字。要紧的是内容。
好，我们讨论得差不多了。请把上面这段对话整理成一份规格，存成 spec.md，
包含：要解决什么问题、方案是什么、用户故事（一条条编号，用“作为…我想要…以便…”的格式）、
定下来的实现决策、测试决策，以及明确不做什么。
午饭登记：一份填好的 spec.md
下面是午饭登记的规格样例。注意它没有写任何文件路径， 每条用户故事都说清了“谁、要什么、为什么”，最后一段还明确划了边界。
# 午饭登记 · spec
## 1. 问题陈述
团队每天午饭靠群接龙：名字会漏、菜会重复，组织者要手动数一遍。
值得做，因为每天都要发生一次，而且出错会直接点错菜。
## 2. 方案
一个手机能打开的网页：同事填姓名和菜名；组织者看当天列表、
删掉填错的、按日期回看。
## 3. 用户故事
1. 作为同事，我想填姓名和菜名并提交，以便不用在群里接龙。
2. 作为同事，我想提交后立刻在当天列表里看到自己，以便确认没漏。
3. 作为组织者，我想看当天所有登记，以便一次报给餐厅。
4. 作为组织者，我想删掉填错的记录，以便名单准确。
5. 作为组织者，我想按日期筛选，以便回看昨天吃了什么。
## 4. 实现决策
- 网页 + 一个后端服务 + 一个数据库；数据放在服务器上。
- 接口：取当天列表、新增一条、删除一条。
- 记录字段：id、name、dish、created_at。
## 5. 测试决策
- 姓名为空时不能提交，页面要提示“请填写姓名”。
- 同一天的列表按提交时间从早到晚排列。
- 删除一条后，列表立刻少一条，刷新后仍然少一条。
## 6. 明确不做
- 不做账号和登录。
- 不做在线支付。
- 不做菜单推荐。
- 不做多个团队。
- 不做历史统计图。
## 7. 其他备注
- 优先适配手机屏幕。
- 每天 11:30 截止，截止后不再接受新登记（先靠组织者口头提醒）。到这里，它从一个模糊的想法变成了一份能交给下一个人读的规格。 下一章要做的，是把这份规格拆成 5 张能单独演示的工单。
你的 spec 里“明确不做”写了几条？ 一条都没有，说明边界还没画；超过 5 个功能，说明这一版还想做得太大。
诚实边界：它不管什么
这一节很重要，因为我不想让你误以为这套方法论什么都能管。 我逐项核查过，下面这些在整套方法论里是完全不存在的：
| 你可能以为它有的东西 | 实际情况 |
|---|---|
| 该不该做这个产品 | ❌ 完全不管。它的起点假设“你已经有想法了”，从不追问想法本身值不值得 |
| 目标用户是谁、市场在哪 | ❌ 全仓库零命中。没有用户研究、竞品分析、定价、市场调研 |
| MVP（最小可用产品）/ 产品路线图 / 优先级排序 | ❌ 零命中。它只有“工单的依赖顺序”，那是排期，不是产品优先级判断 |
| BRD / 商业需求文档 | ❌ 零命中。这不是“被排除在外”，而是从未进入它的视野 |
| 把模糊想法变成明确决策 | ✅ 强项。拷问机制做得非常扎实 |
| 把决策固化成可交接的文档 | ✅ 有。/to-spec 的模板结构完整 |
它为什么要这样划界，官方有一句话解释得最直白。
有人问/domain-modeling能不能替你把模糊的想法变成领域语言，回答是：
“不能，而且也没有计划做一个这样的技能。 一套你自己都不理解的领域语言，写下来之后只会变成毫无意义的废话。”
“这个技能在你已经理解之后帮你做到精确， 但它不会凭空制造出你原本没有的概念。”
它假设理解必须来自你。工具只负责把你已经有的理解变得精确。
所以“这个产品该不该做、给谁做”这类问题，只能你自己回答， 或者去找真正懂那门生意的人聊。AI 在这里帮不了你，而且它不该假装能帮。
分两种，别混：
「该不该做」有办法。这一章开头的立项六步给了你一条 能手工走完的检查链——它不是这套方法论的，是另外的来源，我在那里标注清楚了。
「市场在哪、怎么赚钱」没有捷径。这类问题得去问真人、看真数据， 任何工具（包括 AI）都替不了。进阶页里列了几套公认的专业方法论， 但它们都假设你已经懂产品——不是给新手的。
可选：把技能装上（章末附录）
可选
这一节是纯操作，所以放在章末——它不该挡在你理解流程之前。
没装也能读本章，先理解流程；等你想照着敲 /grill-with-docs 这些命令时，再回来装。
这些技能需要付费的 Claude 账号（Pro / Max / Team 等）。 免费的 claude.ai 账号不含 Claude Code——点进去会直接跳升级页。
如果暂时不想付，第 6 章那套简化流程用免费聊天框也能走完， 只是没有下面这些命令。本章和下一章的技能可以先跳着看。
第一步：选一个能在项目文件夹里动手的工具
网页聊天框看不见你的文件，也存不住东西。 你需要一个能在你的项目文件夹里直接读写文件的 AI 工具。
桌面版和命令行版底层是同一个引擎，选哪个都能用。 零基础先选桌面版。
| 桌面版 | 命令行版（CLI） | |
|---|---|---|
| 长什么样 | 图形界面。装上后点窗口顶部的 Code 标签页 | 黑底白字的终端窗口 |
| 要装 Node.js 吗 | 不用，内置了 | 有的装法需要 |
| 适合谁 | 不熟悉命令行的人 | 想折腾、想自动化的人 |
第二步：桌面版（推荐）
去官网下载页下安装包，装上、登录，点窗口顶部的 Code 标签页， 再打开你的项目文件夹。就这样，不需要敲任何命令。
进阶：命令行版（CLI），不想折腾可以跳过
命令行版是在终端里敲命令。有的装法需要先装 Node.js。
macOS / Linux / WSL：这条命令从官方地址下载安装脚本并执行。
curl -fsSL https://claude.ai/install.sh | bashWindows PowerShell：这条命令下载安装脚本并立即运行。
irm https://claude.ai/install.ps1 | iexWindows 用 winget：这条命令从系统包管理器安装。
winget install Anthropic.ClaudeCode装完验证：第一条打印版本号，说明装上了； 第二条做体检，装得有问题它会告诉你。
claude --version
claude doctor第三步：装技能（两条路线，只选一条）
/grill-with-docs 这些命令不是自带就有的，
它们是别人写好的一套技能包。两条路线选一条，不要两条都装。
路线 A · 插件（推荐）
在 Claude Code 里敲这条命令，从官方市场安装。这条路线是只读的，上游更新会自动送达。
/plugin install mattpocock-skills想改行为，不能改技能文件，要写进你自己的 CLAUDE.md 里。
路线 B · skills.sh（想改文件才用）
这条命令把技能复制成你自己的文件，可以随便改；Codex 等工具也能用。
npx skills@latest add mattpocock/skills
安装时会让你勾选要哪些——务必勾上 setup-matt-pocock-skills。
上游更新不会自动来，要手动敲 npx skills@latest update。
官方文档专门警告过这件事：两条都装，你会得到每个技能两份。 到时候 AI 面前摆着两个同名技能，它调用哪一个你根本控制不了。
简单记：只想用，选 A；想改，选 B。
第四步：装完先跑一次 setup
这一步最容易漏，但漏了后面就走不通。它会问你三件事，然后写进你的项目配置。
/setup-matt-pocock-skillsissue tracker 在哪
issue tracker（工单系统）就是存放“待办事项和状态”的地方。 默认用 GitHub，也支持本地的 markdown 文件。
标签怎么叫
五个固定状态的名称（待评估 / 已确认 / 进行中……）。
文档放哪
项目说明和决策记录放在哪个目录。 ADR（架构决策记录，Architecture Decision Record） 是“为什么选了这个方案”的短文件，方便以后的人知道来龙去脉。 细节见 进阶：专业工具链。
/to-spec（把对话整理成规格文件的技能）、/to-tickets、/triage
这几个技能，都要读写你的 issue tracker——规格要发进去，票要建在里面，状态要更新。
它们不知道你的东西存在哪，除非你先告诉它们一次。
跳过 setup 就去敲 /to-tickets，你会发现它不知道往哪儿写。
第五步：确认装好了
回到你的项目目录，让 AI 干活，然后敲一个斜杠：
/
应该会弹出能用的命令列表。看到 /grill-with-docs、
/to-spec、/implement 这些，就说明装好了。
没看到？先确认你是在项目文件夹里启动的工具—— 技能是按目录加载的，回到桌面上敲是看不到的。
命令不用背。下一章讲每个技能时还会再说一次它怎么触发； 第 10 章的技能速查里也有一份能直接抄的清单。
三句话带走
- 开工前先被拷问：AI 不会在你没做决定的地方停下来，它会替你猜，而且不告诉你。
- 拷问的产物是决策，不是文档；文档只是把已经定下来的决策写下来。
- 一份好规格必须写清七段，尤其是“明确不做什么”——边界就是 AI 的活动范围。
自测：三个问题
有人说“我想做个午饭登记小程序”，你下一步先问什么？
先问“谁在什么场景下遇到什么麻烦”，而不是问“你想用什么技术”。 这句话是方案还是问题，决定了后面的验证有没有意义。 再往下，用妈咪测试问过去的行为：“你们现在午饭是怎么登记的？上次漏了谁？”
拷问时你连续回答“同意、同意、同意”，问题出在哪？
你没有在做决策，只是在点头。最后那份规格看着完整， 但里面全是 AI 的默认值，只是被你的“同意”盖了章。 一场全程零反驳的会话，是一场你本不需要的会话。
规格七段里，哪一段最容易被漏掉，为什么必须写？
“明确不做”（Out of Scope）。没有这一段，AI 会按自己的理解无限发挥， 而你最后要把它发挥出来的每一样东西都验一遍。 写清边界，等于提前告诉它“到这里停”。
动手 10 分钟
拿午饭登记练一次，只做三件事：
- 写一句问题陈述，不许提方案。
- 写一句话规格：“帮 [谁] 做 [什么]，从而能 [得到什么]。”
- 列 3 条“明确不做”。
然后把这三样发给 AI，让它像面试官一样问你 5 个问题。 回答时至少对一条说“不对，我要的是……”，看看规格会不会变。
如果你看到 X，大概率是 Y
- 一上来就说“帮我做个……” → 你在给方案，不是给问题。先写清谁遇到了什么麻烦。
- 拷问时全程点头 → 你在确认，不在决策。至少对一条说出“不对”，规格才是你的。
- 规格里出现了文件路径或代码 → 你把“怎么做”写进了“做什么”。改成可观察的行为。
- 装了技能却跳过 setup → 命令不知道你的 issue tracker 在哪，自然不知道往哪儿写。
- 还没问清就开始做原型 → 原型只回答一个问题。问题没定，做出来也只是好看。
规格写完了，事情才做了一半。下一章讲怎么把它拆成 5 张能单独演示的工单， 一张一张实现、审查，最后放到一个别人能打开的网址上。