让 AI 别急着写 PRD：我做的需求分析 Skill 会「顶嘴」

让 AI 写 PRD 是件很容易的事。难的是让它在不该写的时候闭嘴。

一、一个每天都在发生的翻车现场

B 端产品经理的日常，大概长这样：

业务方在群里甩一句：「你们预约这块能不能加个导出。」 客户抱怨：「订单老撞单，你看看怎么改一下。」

这时候你有两个选择，都很糟。

选一：直接开写。 让 AI 半小时出一份 PRD，章节完整、格式漂亮、看着很专业。但里面每一条都是猜的——客户到底被什么影响、这问题多久发生一次、他们现在怎么应对、有没有线下土办法兜着，你一样都不知道。评审会上开发问「这个功能为什么存在」，你只能答「业务方提的」。真到上线，客户说「我要的不是这个」。

选二：先不写。 但你也不知道该问什么。问「您觉得这个功能应该怎么做」——客户答不上来，他不是产品经理；问「您有什么需求」——客户给你讲一遍他的脑回路。最后变成你一个人闷头想，想出来的东西没人拍板。

问题的本质不是 AI 不够聪明，是「写文档」这个动作太顺滑了。

你随口一提需求，AI 立刻就能给你一份看起来很专业的东西——这个顺滑感是陷阱。因为它跳过了整段最耗时、也最容易做错的工序：把方案还原成问题。

而这段工序没法用「提示词写得更好一点」解决，因为它是流程约束问题，不是表达能力问题。

所以我做的不是「一段更好的提示词」，而是一道会报错的闸门。

二、方法论的核心：先把「方案」翻译成「问题」

这套 skill 的底层，有两句被我反复强调的话：

需求 = 预期 − 现状。

我们才是解决方案专家，客户只是问题专家。

客户提上来的永远是方案级需求——加个导出、做个筛选、支持批量操作。这句话里藏着的信息是：他们已经替你想过解决方案了。而方案背后的东西全是空白：

• 这个问题有多真？是真的发生过，还是"我记得上次好像……"？
• 多久发生一次？一天三次还是一年三次？频率直接决定要不要做。
• 现在怎么应对？有没有人拿 Excel、拿微信群、拿嘴硬扛着？这决定了你要做的是"从 0 造新能力"还是"把既有的土办法搬进系统"。
• 谁最受影响？提需求的人不一定是被影响最重的人，更不一定有拍板权。

把这四件事问清楚了，你手上的方案很可能自己就变了——或者客户自己就否掉了。

这就是 skill 干的第一件事：不让 AI 替你想，逼 AI 让客户把话说清楚。

三、三个机制

机制一：阶段闸门——强制「先访谈，后分析」

skill 里最硬的一条铁律：

在收到用户对第一轮问题的答复之前，只能产出两份文件：《需求澄清问题清单》和《访谈记录与假设登记册》。其他任何需求产物都不得写出。

注意我特意写了「任何」和「其他」。因为真实场景里，AI 有一百种方式绕过这条规则：

• 把功能清单叫「附：本次要做的」
• 在登记册里加个「附录：初步流程」
• 在文档开头写「以下为分析底稿，供讨论」

这些招数在流程文档层面完全合规——你禁的明明是「功能清单」，我交的是「附：本次要做的」。所以 skill 的做法不是靠措辞去堵，而是换一层去堵：闸门管的是内容形态，不是标题措辞，也不是文件数量。

我把闸门做成了一张阶段表：

这里有两个设计我觉得特别值得说：

① G1 → G2 的分界是「用户对问题的答复」，不是「用户说了什么」。

用户自己在需求里附的信息（「就这三块」「两周上线」）算 A-xx（来源：用户原话），但不构成闸门推进。因为用户没有回答任何一个 Q-xx——那不叫访谈，那叫单方面投喂。分不清这两者，闸门就是个摆设。

② 进 G2 不需要等所有问题都答完。

核心问题（谁提的、谁的什么问题、现在怎么应对、多久一次、必答三问）答完 5 项以上就能进。没答的问题，对应内容一路保留 S-xx 标注带到验收标准和测试用例里。

这条很重要，因为「等全部答完」是不现实的——那等于永不产出。带着不确定性前进，并把不确定性显式地带着走，才是可执行的姿势。

机制二：编号体系——让「哪条是猜的」变成可机器检查的事实

光有闸门不够。闸门只管「什么时候能写」，写完之后还得管「写出来的东西靠不靠谱」。

我的做法是给整条链编一套号：

编号本身不稀奇，规矩才稀奇：

1. 每个前缀全局唯一，不得复用。 已被占用就换（比如阻力点用 RN-xx 而不是蹭 S-xx）。
2. S-xx 必须写清两件事：怎么验证、验证不成立会怎样。 两列缺一不可，空着等于没写。
3. 每一行进入分析文档的需求，都必须引用至少一个 A-xx；无 A-xx 支撑的，必须显式标 S-xx。

第 3 条是整套东西的收敛点。分析文档里出现没有来源的条目，就是把假设伪装成了事实。

而 S-xx 那两列，是我认为整个设计里最反直觉、也最值钱的地方：

写假设的时候顺手想一句「如果我猜错了会怎样」，你会发现自己对某些问题其实一无所知——那这些地方就该在文档里明确标成待验证，而不是混在正文里当结论。

还有一个容易忽略的边界：S-xx 只能记「我们相信什么、怎么验证、不成立会怎样」，不能记分析结论。

• 写 S-03「审批可能是单级审批」——✅ 可验证、有后果，是假设。
• 写 S-03「审批流应设计为单级节点，状态机含草稿/待审/通过/驳回四态」——❌ 这是分析结论，属于 G2/G3 产物。

判据很干净：这条假设的答案是"是/否"还是"一套结构"？ 是"是/否"→ 留在 S-xx；是一套结构 → 它就是分析结论，不能出现在 G1。

机制三：自检脚本——把规范变成 CI

方法论写进文档，AI 该忘还是会忘。文档里的"应该"，只有变成脚本里的"报错"，才真的有效。

所以这个 skill 带了一个 1250 行、零外部依赖（纯 Python 标准库）的检查脚本：

python3 scripts/check_artifacts.py <产物目录> --stage G1   # 闸门自检
python3 scripts/check_artifacts.py <产物目录> --stage G2   # 编号闭合 + 溯源 + 假设合规
python3 scripts/check_artifacts.py <产物目录> --stage G3   # 全部检查（加撞号与措辞一致性）

下面这些输出，全部是我实跑出来的真实结果，不是示例。

四、实跑：它真的会拦住你

4.1 合规的 G1 产物 → 通过

两份文件：一份 5 个问题的澄清清单，一份登记册（含 A-01、S-01、S-02、T-01）：

$ python3 scripts/check_artifacts.py /tmp/reqdemo --stage G1
检查目录：/tmp/reqdemo
阶段：G1    文件数：2    已定义编号：9
--------------------------------------------------------------
✓ 全部检查通过

4.2 违规的 G1 产物 → 4 个错误，全中

我故意在登记册里加了一节「附：本次要做的」，里面是一张流程表 + 一句强断言：

$ python3 scripts/check_artifacts.py /tmp/reqbad --stage G1
检查目录：/tmp/reqbad
阶段：G1    文件数：2    已定义编号：10
--------------------------------------------------------------
发现 4 个错误：
  ✗ G1 闸门：体检预约系统_访谈记录与假设登记册.md 的表格表头出现分析结论特征词『步骤』（闸门管内容不管文件数量）
  ✗ G1 闸门：体检预约系统_访谈记录与假设登记册.md 出现分析结论编号 FP-01（G1 阶段只允许 Q/A/S/T 四类编号）
  ✗ G1 闸门：体检预约系统_访谈记录与假设登记册.md 出现分析结论编号 US-02（G1 阶段只允许 Q/A/S/T 四类编号）
  ✗ G1 闸门：体检预约系统_访谈记录与假设登记册.md 出现分析结论断言『系统应(?!需求)』（G1 只允许问题、答复、编号化假设、术语定义）

注意这个案例的意义：文件数量是 2（合法的两份），标题叫「附：本次要做的」（不在禁用词表里），但内容形态是分析结论——所以 4 条规则同时命中。

这就是「闸门管内容，不管文件数量」的意思。改名没用，藏进附录也没用。

4.3 G2：溯源缺失 → 悬空引用 + 无来源条目

功能需求清单里 F-02 的「来源」栏我留空了：

$ python3 scripts/check_artifacts.py /tmp/reqg2 --stage G2
阶段：G2    文件数：1    已定义编号：3
--------------------------------------------------------------
发现 3 个错误：
  ✗ 悬空引用：A-01 被引用但无定义 —— 体检预约系统_功能需求清单.md
  ✗ 悬空引用：S-01 被引用但无定义 —— 体检预约系统_功能需求清单.md
  ✗ 溯源缺失：F-02 无 A-xx / S-xx 标注 —— 体检预约系统_功能需求清单.md

「悬空引用」和「溯源缺失」是两个独立维度：前者是引用了但没定义，后者是压根没引用任何来源。

4.4 G3：编号撞号 → 这个设计我做了很久

同一个 S-01，在两份产物里指代了两件不相干的事：

$ python3 scripts/check_artifacts.py /tmp/reqg3 --stage G3
阶段：G3    文件数：2    已定义编号：1
--------------------------------------------------------------
发现 1 个错误：
  ✗ 编号撞号：S-01 在两套互不相干的编号族系里指代了不同事物
      『支撑类流程』 —— 业务流程列表.md（流程族）  ≠  『现状不存在人工控制』 —— 访谈记录与假设登记册.md（假设族）

这个检查一开始是错的，而且错得很典型，值得单独讲。

第一版实现：把每条记录的前缀集合算出来，凡是同一前缀出现在不同文件里就报撞号。结果误报满天飞——因为 S-01 在访谈记录里定义一次，在功能需求清单里被引用一次，这是完全正常的引用，不是撞号。

改成"只统计定义处"之后，还是错。因为真正的撞号不是"出现了几次"，而是"这个编号在两套不相干的体系里指代了两件事"——判断需要语义。

最终的实现方式是：看编号「待在哪一栏」，不看它叫什么名字。

• 表格里的记录 → 看它落在哪一列（该列表头的语义：假设 / 术语 / 事实 / 流程 / 规则 / 需求 / 追溯…）
• 标题、列表里的记录 → 看它属于哪个上级章节（标题下的语义角色）

这一步很关键，因为不能拿条目自己的名字定族系。比如 ### Q-05（频率与场景规律） 里的「场景」是这条问题的名字，不是栏目——拿它定族系会把访谈族的问题误判成场景族，报出一堆假撞号。

还有一个坑：撞号和引用必须分开。 同一个编号在多份产物里出现本身不是问题——需求规格说明书、优先级评估、变更分析表都会复述上游编号，那是引用。引用允许用简称、允许换措辞，但不得改变所指。

所以现在的判定是：

汇总型产物的豁免是我特意加的——需求规格说明书按设计就要把上游全部编号抄一遍，那是引用，不该报错。

五、几个我踩过的坑，写进了 skill

坑 1：溯源不该覆盖所有东西

一开始我对所有产物都要求「必须引用 A-xx」。结果 BR-xx 业务规则被判成溯源缺失——但业务规则是分析产物，它是"基于 A-01 和 A-03 分析得出的规则"，引用上游事实即可，要求它直达 A-xx 是把"经分析推出的结论"错判成"没有出处"。

最终边界：溯源只强制覆盖「需求条目」——F-xx / NFR-xx / AC-xx / MR-xx。BR-xx、US-xx、PC-xx、CP-xx、QS-xx 属于分析产物，引用上游即可。

坑 2：S-xx 登记表的两列不是装饰

我一开始只检查「有没有 S-xx」，后来发现 AI 会写「验证方式：待确认」「验证不成立的后果：无」。这跟没写一样。所以脚本现在会逐条检查这两列存在且非空（状态为"已关闭"时允许后果写 —）。

坑 3：英语环境全漏检

有一版脚本只认中文表头（"步骤""责任人"）和中文断言（"该系统应包含"）。拿英文产物一跑，一个错都没报——整份文档直接通过。所以后来把标题、表头、断言、角色识别、S-xx 两列、清单识别全部做了双语化，连英文清单条目的长度上限都单独放宽到 60 字符。

坑 4：疑问句豁免失效

有一版规则是「以问号结尾的条目不算功能清单」。但句子中间出现问号、结尾是句号的情况很常见，导致合法的问题清单被当成功能清单误报。修法是先判断整句结尾是否为 ？/?，而且只对问题清单生效——别的文档里带问号的行不代表豁免。

六、AI 在这个流程里到底扮演什么角色

这是我想讲清楚的一点，因为它决定了大家该怎么用这个工具。

AI 不扮演需求分析师，AI 扮演那支一直追问、还自带检查表的笔。

一个具体的对照：

如果直接写 PRD，你会得到一个「时段容量配置管理」模块：字段设计、页面原型、接口列表、默认值、权限控制。很完整，全是猜的。

用这个 skill，第一轮产出的是一份问题清单，5 个问题，每个都带三样东西：

客户答完话，才进入分析阶段，产出干系人档案、业务流程、业务场景、问题卡片、管控点、领域模型、功能清单、验收标准——每一条都挂着来源。

整个过程里，AI 始终在提问和整理，没替你编过一条业务事实。

七、你会拿到哪些产物

底层是 17 项分析任务、13 类产物、四条主线：

价值需求主线   目标场景 ─→ 干系人关注点 ─→ 干系人阻力点

详细需求主线
  功能需求   业务支持 ── 业务流程 ── 业务场景 ── 场景分析
             管理支持 ── 管控点 ── 业务报表
             维护支持 ── 维护场景
  数据需求   范围与关系（领域建模）── 构成与推演（业务数据分析）
  非功能需求 关键质量属性 ── 质量场景 ＋ 约束

日常的小变更（改个字段、加个筛选）不用全套走一遍，有单独的变更模板。

编号体系还解决了一件事：变更影响面

所有产物用同一套编号串起来，任何一条结论都能回溯到出处。

评审通过了三个月，客户加一句「顺便把 X 也导出来」——你能立刻查到要连带改哪几条验收标准、哪几个测试用例，而不是靠记忆翻文档。

这是我用下来最值的地方。

八、适合什么，不适合什么

适合：

• B 端系统的新系统建设、流程优化、客户投诉驱动的改进
• 需求方自己也说不清要什么的时候
• 需求要过评审、要能对开发讲清楚「为什么做」
• 长期项目，需求会反复变，需要能追溯影响面

不太适合：

• 纯 C 端增长玩法（AB 实验、埋点、留存策略）
• 已经有成熟 PRD、只想要排版或翻译的
• 老板已经拍好方案、只需要你落成文档的

最后一条要展开说一句：那闸门会挡你——但这种情况通常正是最需要闸门的。 方案被拍死的时候，更需要有人问一句「这个数凭什么这么定」「如果不加会怎样」。

九、怎么装

# 方式一：通用 skills 安装器（推荐）
npx skills add yangdavip/effective-requirements-analysis-skill

# 方式二：手动 clone
# 注意仓库根目录是 skills/ 子目录布局，skill 本体在 skills/effective-requirements-analysis/ 这一层
git clone --depth 1 https://github.com/yangdavip/effective-requirements-analysis-skill.git /tmp/era
cp -R /tmp/era/skills/effective-requirements-analysis \
  ~/.skills-manager/skills/effective-requirements-analysis

ln -s ~/.skills-manager/skills/effective-requirements-analysis \
  ~/.workbuddy/skills/effective-requirements-analysis      # WorkBuddy
ln -s ~/.skills-manager/skills/effective-requirements-analysis \
  ~/.aspirecode/skills/effective-requirements-analysis       # AspireCode
ln -s ~/.skills-manager/skills/effective-requirements-analysis \
  ~/.dsh/skills/effective-requirements-analysis             # DeepSeek Harness
ln -s ~/.skills-manager/skills/effective-requirements-analysis \
  ~/.config/opencode/skills/effective-requirements-analysis  # opencode
ln -s ~/.skills-manager/skills/effective-requirements-analysis \
  ~/.agents/skills/effective-requirements-analysis           # 通用 agents

Claude Code 用户：

/plugin marketplace add yangdavip/effective-requirements-analysis-skill

脚本只用 Python 标准库，零外部依赖。

仓库结构：

effective-requirements-analysis/
├── skills/effective-requirements-analysis/
│   ├── SKILL.md                      # 方法论主体：阶段闸门、编号体系、提问规范、17 项分析任务
│   ├── references/
│   │   ├── interview-playbook.md     # 提问技巧库
│   │   ├── task-playbook.md          # 17 项分析任务与剪裁表
│   │   └── artifacts.md              # 全套产物模板
│   ├── templates/
│   │   ├── srs-outline.md            # 需求规格说明书骨架
│   │   └── daily-change.md           # 日常变更型需求模板
│   └── scripts/
│       └── check_artifacts.py        # 三阶段自检脚本（1250 行，零依赖）
├── .claude-plugin/marketplace.json   # Claude Code 插件市场封装
├── README.md
└── LICENSE                           # MIT

因为仓库根目录用了 skills/ 子目录布局，安装到 harness 时请指向 skills/effective-requirements-analysis 这一层。

装完之后，直接用日常语言提需求就行：

体检预约系统最近老撞单，前台说在系统里给每个时段加个人数上限就行了，帮我把这个需求理清楚。

skill 会：

1. 问你 5–8 个问题，同时把已知事实和待验证假设登记好
2. 你回答 → 它把答复落成 A-xx，把还问不出来的落成 S-xx
3. 进入分析，产出全套文档，每条标着来源
4. 每个阶段跑一次自检，把不干净的地方挡下来

在你回答第一个问题之前，它不会写任何 PRD。

十、最后

这个 skill 本质上，是把一件很反直觉的事做成了默认行为：

在需求分析里，「慢」不是拖延，「快」才是风险。

业务方等不起、老板催得急，这些压力最后都会变成"先出一版草稿吧"。而这一版草稿的代价，不是多花半小时改，是猜错的部分会以「已确认需求」的形态混进文档，然后被下游的功能需求、验收标准、测试用例整条继承——一处猜，全链错。

所以我给它加了一道硬闸门。闸门会在你觉得「差不多了」的时候拦住你，问你一句：

你确定吗？还是你只是累了？

这句话在需求分析里，可能比任何模板都值钱。

仓库：https://github.com/yangdavip/effective-requirements-analysis-skill

MIT 许可，欢迎拿去改、拿去用、拿去指出哪里做错了。

如果你的团队也在做 B 端系统，欢迎来提 issue——尤其是那些「这个闸门太严了」或者「这个闸门漏了」的具体场景，我想看看能怎么改。

本文提到的所有脚本输出均为实跑结果。仓库已同时提交至 Anthropic 官方 skills 仓库、ComposioHQ 的 awesome-claude-skills、以及中文社区 claude-code-skills-zh 的 PR 列表。