实战四：Claude 写一份完整 PRD（含提示词模板）
⚙️
AI 很擅长生成结构完整的文档，但如果你没有提前拆清思考步骤，最后得到的往往是一份“像 PRD 的文字”，而不是一份“可推进需求的文档”。
这种 PRD，最大的问题不是“写得不好”，而是它只是生成了一份文档，不是帮你完成了一次产品思考。
所以我现在用 Claude 写 PRD，已经不再是“一次性让它生成全文”。
我会把整个过程拆成 4 步：
先跑用户故事
再推功能设计
再补边界条件
最后压验收标准
AI 最适合帮产品经理写 PRD 的地方，不是替你一键生成全文，而是帮你把“想不清”的地方一层层想清楚。
第一步：先不要写功能，先让 Claude 帮你把用户故事写清楚
真正好的 PRD，第一步不是写页面。而是先写清楚：
•
谁在用？
•
在什么场景下用？
•
为什么现在需要它？
•
如果没有这个功能，问题卡在哪里？
所以我第一步会先把非常原始的需求背景丢给 Claude。让它帮我整理成用户故事。
📢
很多 PRD 一开始就写偏，不是因为功能不会设计，而是因为用户问题和使用场景没有先说清楚。用户故事跑不顺，后面的方案通常都会飘。
提示词模板
代码块
Markdown
我们在做一个知识型内容 App，里面有大量长文章、问答和研究报告。
用户在浏览内容时，经常因为内容太长、信息密度太高而放弃阅读。
现在希望增加一个“AI 摘要卡片”能力，让用户在进入正文后，先快速获得内容重点，再决定是否继续读全文。
请你先不要写 PRD。
先站在产品经理视角，帮我完成下面 4 件事：
1. 提炼这个需求背后的核心用户问题
2. 写出 3-5 条典型用户故事
3. 识别这个需求最可能服务的用户类型
4. 用一句话总结这个功能的产品价值
要求：
- 不要空话
- 尽量贴近真实用户行为
- 每条用户故事都按“作为一个...我希望...以便于...”格式输出
第二步：基于用户故事，让 Claude 推功能设计，不要直接让它“自由发挥”
👾
功能设计最怕的不是想不到，而是想太多。真正有效的提示词，不是让 Claude 多写，而是帮你守住目标、范围和阶段边界。
用户故事清楚以后，第二步才进入功能设计。但这里有个很大的坑。
很多人会直接问：
“请根据上面内容帮我写功能方案。”
这句话太宽了。一宽，AI 就容易开始“自我发挥”。
最后给你一套看起来很完整、但其实不一定贴着业务目标走的方案。
所以我现在的做法是：不给它自由生成权限。
而是给它明确设计任务。
提示词模板
代码块
Markdown
⚠️
PRD 写作里，真正高级的能力不是“想出更多功能”，而是“知道这期先不做什么”。
第三步：让 Claude 专门补边界条件，这是很多 PRD 最容易偷懒的地方
✍️
主流程谁都会写，边界条件才是最容易被忽略、却最影响评审和上线质量的部分。AI 在这里的价值非常高，因为它特别适合做结构化枚举。
坦诚说，大多数产品经理写 PRD，最容易糊弄过去的就是边界条件。真正能不能落地、会不会被研发追着问、上线后会不会出事故，很多时候就看边界写得够不够细。
提示词模板
代码块
Plain Text
第四步：最后再让 Claude 帮你压验收标准，不然 PRD 很容易停在“感觉写完了”
很多 PRD 最大的问题是：写完了，但无法验。
研发、测试、设计、产品自己都很难判断：到底做到什么程度，才算交付完成。
所以最后一步，我一定会单独让 Claude 帮我输出验收标准。
提示词模板
代码块
Plain Text
基于前面的功能方案和边界条件，
请帮我输出“AI 摘要卡片”功能的验收标准。
Claude 的价值已经不只是帮你写文档。它是在帮你做一种产品语言的翻译：把“产品脑子里的设想”，翻译成“团队可以共同执行的标准”。
一篇完整 PRD，不该是一段提示词生成的，而应该是这样拼出来的
到这里，其实你已经能发现一个很重要的区别了。
很多人用 Claude 写 PRD，思路是：
“我给你一个需求，你帮我生成一份完整 PRD。”
我现在更认可的思路是：
“我把 PRD 拆成几个关键思考环节，让 Claude 在每一环帮我补足。”
这两个思路差别非常大。
前者生成的是文本。
后者生成的是过程。
而真正有复用价值的，永远是后者。
✍️
AI 不是替你把 PRD 一次写完。AI 更像是在陪你，把 PRD 一层一层推出来。
你可以直接拿去用的 PRD 提示词模板
下面我把整套模板给你，尽量做成能直接复制的版本。
模板 1：需求澄清与用户故事
代码块
Markdown
我正在写一个产品需求文档，请你先不要直接写 PRD。
下面是原始需求背景：
【在这里贴需求背景】
请你先帮我完成下面 4 件事：
1. 提炼这个需求背后的核心用户问题
2. 写出 3-5 条典型用户故事
3. 识别目标用户类型
4. 用一句话总结这个功能的产品价值
要求：
- 不要说空话
- 尽量贴近真实用户行为
- 用户故事按“作为一个...我希望...以便于...”格式输出
模板 2：功能方案设计
代码块
Markdown
基于刚才整理出的用户问题和用户故事，
请继续输出功能方案。
请按以下结构输出：
1. 功能目标
2. 核心功能说明
3. 用户主流程
4. 页面展示建议
5. 用户可操作动作
6. 非目标范围（这期不做什么）
要求：
- 所有设计都围绕核心目标展开
- 明确区分“必须有”和“后续再做”
- 避免过度设计
模板 3：边界条件补全
代码块
Plain Text
现在请不要重复前面的内容，
只帮我补充边界条件。
请按下面维度输出：
1. 内容侧边界
2. 用户侧边界
3. 状态侧边界
4. 异常侧边界
5. 权限/风控侧边界
每个维度请列出：
- 可能出现的边界场景
- 建议处理方式
- 是否需要在 PRD 中明确写出
要求：
模板 4：验收标准输出
代码块
Markdown
基于前面的功能方案和边界条件，
请帮我输出验收标准。
请按以下结构输出：
1. 功能验收
2. 展示验收
3. 交互验收
4. 异常验收
5. 数据埋点验收
要求：
- 每一条都写成可判断、可验证的句子
Claude 能帮你写 PRD，但它替代不了你的产品判断
🔧
AI 最适合补的是结构、枚举和表达。真正决定 PRD 质量上限的，仍然是产品经理自己对需求价值、范围边界和优先级的判断。
我很认同 AI 能大幅提升产品经理的写作效率。
但我也越来越确定一件事：
AI 最适合帮你补的是结构、枚举、表达。它最替代不了的，还是判断。
比如：
•
这个需求值不值得做
•
这期范围该不该收
•
哪个场景是主场景
•
哪些边界必须优先写
•
哪种验收标准对业务最关键
这些事，最终还是产品经理来定。所以别把 Claude 当成“自动 PRD 机器”。
更好的用法是把它当成：
•
一个帮你澄清需求的产品助理
•
一个帮你补边界的评审搭子
•
一个帮你压语言精度的文档编辑器
这样你会发现，AI 真正带来的不是“替你把 PRD 写完”。
而是让你把 PRD 写得更快、更全，也更像一份能真正拿去评审的文档。
💪
用 AI 写 PRD，最重要的不是“让它帮我写”，而是“让它帮我把想不清的地方逼清楚”。
最后
如果你现在也在用 Claude 写 PRD，不妨回头看一下你过去生成的那些文档。
你可以问自己一个问题：它们是真的帮你推进了需求，还是只是帮你生成了一份看起来很完整的文字？
这两者差别非常大。