一个装在本地的 PRD skill,把"好需求"拆成四条不可协商的约束:动笔前先审讯、形容词换成数字、五段结构锁死、范围之外写明不做。
约 140 行的 SKILL.md,通篇没有一句"建议"——只有命令式约束:动笔前必须审讯需求、形容词必须换成数字、五段结构顺序锁死、范围之外必须写明不做。它不教 AI 怎么写得更多,它逼你想得更清楚。
翻开这份 skill,你会撞见一件反直觉的事:整个流程分三步,而真正"动笔写 PRD"是最后一步。前两步——审讯需求、划定范围——才是它认定决定成败的地方。
我们都以为 PRD 写不好,是因为不知道该写哪些章节。但被评审打回的文档,十有八九章节齐全——问题出在每个章节都填了字,填的却是废话。这个 skill 把矛头对准了三种动笔前就埋下的雷:假设上下文直接开写、用形容词冒充需求、范围没有边界。
它的应对不是给你更花哨的模板,而是把"写"这个动作,刻意排到了流程的最后一格。在那之前,你得先过两道关。
"Before writing a single line of the PRD, you MUST interrogate the user to fill knowledge gaps. Do not assume context." —— 写下第一行之前,先把信息缺口问完,不要假设上下文。把"写"排在第三步,是这份 skill 的第一性选择。
一份模板能规定 PRD "长什么样",却规定不了它"对不对"。你可以把五个章节都填满,依旧交出一份没法验收的需求。skill 赌的是另一头:与其多给格式,不如多设约束,用约束逼出质量。
最锋利的一刀落在措辞上。skill 明令避免 "fast / easy / intuitive" 这类词,要求把每一个形容词换成一个可测的数字。同一条需求,信息量可以从 0 个验收点,跳到 3 个硬指标。
| 维度 | 模糊写法 · 会被打回 | 可测写法 · 能验收 | 谁说了算 |
|---|---|---|---|
| 搜索性能 | "要快、结果要相关" | 10k 记录内 200ms 返回;Precision@10 ≥ 85% | 基准测试 |
| 界面质量 | "现代、好用" | 遵循 Vercel / Next.js 设计系统;Lighthouse 可访问性 = 100 | 跑分工具 |
| 本质区别 | 0 个数字 · 靠主观感觉 | 3 个阈值 · 靠机器判定 | — |
"把每个形容词都换成一个数字,
剩下的,才是真正的需求。"
这份 skill 的每一条约束,都精确对应一种常见的死法。把约束倒过来读,就是一张"PRD 怎么死的"验尸报告。
没问清就动笔,整份文档建立在猜测的背景上,方向一旦错,后面全错。skill 的对策是 Phase 1 强制审讯,外加一条硬规则:技术栈没定就如实标 TBD,绝不替需求方臆测("Don't hallucinate constraints")。
"要快、要稳、要好用"——读着顺,测不了。没有可验收的数字,开发和验收只能靠吵架。skill 用"可测量标准"这一条,把形容词逐个翻译成阈值。
需求方说"顺便把那个也做了吧",时间线就这么被蚕食。skill 要求每份 PRD 显式写出 Non-Goals——明确"这次不做什么",用边界保护交付。
三种死法里,"假设上下文"最致命,因为它在最前面——错在源头,后面写得再漂亮也是错的。这也是为什么 skill 把"审讯"摆在第一步,而不是当成可选项:Discovery 不是礼貌性寒暄,是止损。
Strict Schema 是这份 skill 的硬核:五个章节,顺序固定,"You MUST follow this exact structure"。但比"有哪五段"更值得看的,是每一段在防哪一种偷懒。
| # | PRD 章节 | 强制写什么 | 防住哪种偷懒 |
|---|---|---|---|
| 1 | Executive Summary | 问题陈述 + 方案 + 3-5 个可测 KPI | 不知道"成功"长什么样 |
| 2 | UX & Functionality | Persona + User Story + 验收标准 + Non-Goals | 范围蔓延 |
| 3 | AI System Requirements | Tool Requirements + Evaluation Strategy | AI 功能"没法测好坏" |
| 4 | Technical Specifications | 架构 + 集成点 + 安全 / 隐私 | 做到一半发现没接口 |
| 5 | Risks & Roadmap | 分期 MVP → v1.1 → v2.0 + 技术风险 | 一口吃成胖子 |
这是它比一般 PRD 模板前卫的地方:第 3 节 AI System Requirements 专门要求写明用什么工具 / API,以及——最关键的——Evaluation Strategy:怎么衡量输出质量与准确率。在 2026 年做 AI 功能,"怎么评估好坏"如果不在写 PRD 阶段就定义,上线后只能凭感觉。skill 自带的示例直接把它落地:智能搜索功能,用 50 个常见开发者问题做基准,90% 必须命中预期引用。
"For AI systems, specify how to test and validate output quality. Never write a PRD without asking at least 2 clarifying questions first." — prd skill · Implementation Guidelines (DO / DON'T)
skill 再严,也要你配合对。它的产出质量,几乎完全取决于你给它的输入有多具体。下面这张表是它的"输入—反应—产出"对照:
| 你给它的输入 | 它的反应 | 你拿到的东西 |
|---|---|---|
| 只甩一句话需求 | 触发 Discovery,反问问题 / 指标 / 约束 | 几个澄清问题(别嫌烦,这步在省返工) |
| 背景齐全但没定技术栈 | 标 TBD,拒绝臆测 | PRD + 一串待确认项 |
| 背景 + 约束 + 验收期望 | 直接进入 Drafting | 五段完整、KPI 可测的 PRD |
| AI 功能需求 | 追加第 3 节 Evaluation | 含评估方案的 PRD |
你给的约束越具体,它臆测越少;你把验收标准说清楚,它的产出就越接近"能直接进开发"。它不会替你拍板——它只会把你没想清的地方,明明白白标出来。
这个 skill 不产生灵感,它产生纪律。它把资深产品经理脑子里那套"动笔前先想清楚"的隐性习惯,固化成了机器每次都执行的显式约束——而且不会因为今天赶时间就跳过。
一份 140 行、13 处硬约束、0 句"建议"的 skill,本质上是一张"PRD 不许偷懒"的清单。它的价值不在帮你多写,而在每一次都逼你把模糊处补成数字、把范围补上边界、把"怎么算成功"提前定义。
Q1 · 模板只给章节标题,它给的是"每节不许写废话"的验收口径——前者是骨架,后者是肌肉。
Q2 · 那两个问题省下的,是评审被打回重写的半天。Discovery 是投资,不是成本。
Q3 · 靠一条硬规则:形容词一律换成可测阈值(200ms / 85% / 100 分),写不出数字的需求会被当场标出。
Q4 · 有。第 3 节 AI System Requirements 强制写 Tool Requirements + Evaluation Strategy,逼你在起草阶段就定义"怎么算成功"。
Q5 · 五段结构是硬性的,但每段可长可短——小改动里 User Story 写一条、其余从简也合规。它强制的是"五个维度都被想过",不是"每段都写满"。(注:它不做"简单需求自动砍章节",要精简得自己裁。)
Q6 · 强在固定流程 + 硬约束(先审讯、可测量、Non-Goals);边界是它依赖你给真实信息——你不给约束,它只会标 TBD,不会替你拍板。
把它当一副"带审讯的脚手架":跟着五段走,它问什么你答什么,自然就补齐了你还没意识到要想的维度。
关键纪律:别跳过它的提问。那几个问题,就是老手脑子里的隐性 checklist。
把它当一个"专门抬杠的同事",治的就是你"想当然"的毛病。你越熟,越容易省掉 Discovery,而它不让你省。
关键纪律:它标 TBD 的地方,往往就是你其实还没想清楚的地方——别急着填掉,先想清楚。
重点用第 3 节。逼自己在写 PRD 阶段就定义评估方案:用什么基准、多少样本、通过率多少(skill 示例:50 题 / 90% 命中)。
关键纪律:"怎么测好坏"必须写进 PRD,不能留到上线后再补。
| # | 做法 | 为什么 |
|---|---|---|
| 1 | 动笔前先回答它的 Discovery 三问(问题 / 指标 / 约束) | 否则后面全建立在猜测上 |
| 2 | 把每个形容词翻译成数字再交给它 | "快 / 易用"它会要求你量化 |
| 3 | 没定的技术栈如实说"未定",让它标 TBD | 别诱导它臆测约束 |
| 4 | 每个 User Story 都配验收标准(AC) | 没 AC 的故事等于没定义"完成" |
| 5 | 主动写 Non-Goals | 用边界挡住范围蔓延,保护时间线 |
| 6 | AI 功能必须填第 3 节的 Evaluation Strategy | 没评估方案的 AI 功能没法验收 |
| 7 | 先要草稿,再逐节给反馈 | skill 的 DO:iterate,别指望一稿到位 |
| 8 | Executive Summary 写 3-5 个可测 KPI | 这是该节的硬要求 |
| 9 | 异常 / 边界当成需求写,别留口头约定 | "可验收"才算写完 |
| 10 | 产出后拿去对验收标准,缺数字就回炉 | 它的全部价值,就是逼出那些数字 |
"给 AI 更清晰的边界,
它就还你更靠谱的 PRD。"
· 本文唯一事实来源(所有约束、数字、示例) · ~/.claude/skills/prd/SKILL.md(本机,MIT License)
· Claude Code · Agent Skills 机制 · docs.claude.com/en/docs/claude-code/skills
· Anthropic · Agent Skills 介绍 · anthropic.com/news/agent-skills
· 可测量验收标准参考 · SMART criteria(通用工程实践,非 skill 内引用)
· 关联阅读 · guyu_design(谷雨销售系统)PRD skill 设计分享 · 团队内部文档