用 Claude 写 PRD 和技术方案：先让它采访你，再分章节成稿，用标签喂材料并核对验收标准

本文根据 Claude 官方提示词指南、Claude Code 官方文档《Best practices》和帮助中心《How can I create and manage projects?》《Create and edit files with Claude》整理，资料核对于 2026-11-05。配图为本站整理的示意图，不是界面截图。本站（bigolab.com）不是 Anthropic 官方网站。

适用于谁

• 需要写 PRD、需求说明、技术方案的产品经理、开发者和创业者；
• 脑子里只有想法，不知道文档该怎么搭的人；
• 想把 PRD 交给开发或交给 AI 编程工具去实现的人。

结论先说

1. 想法不清楚时，先让 Claude 采访你。官方在 Claude Code 最佳实践里给了这个做法：描述你想做的事，让它不停提问，直到能写出规格为止，再把规格写进文件。这个思路放到聊天里同样好用。
2. 按章节写，不要一次要全文：每章确认后再往下，前面的结论成为后面的输入。
3. 材料用标签分开：官方说 XML 标签可以让 Claude 清楚区分指令、背景、范例和输入，减少误解。
4. 验收标准必须能被检验：官方在 Claude Code 里反复强调给 Claude「能判断对错的检查」，PRD 里对应的是可验证的验收标准。
5. 数字、竞品信息、政策依据由你核对，让 Claude 缺信息时留空并标注。

图：本站根据 Claude 官方提示词指南 整理的示意图

一、先采访，再成文

官方的原话思路是：你还没想清楚时，不要硬着头皮先写，让 Claude 提问，它会用选择题问你没有定下来的部分，直到答案足以写出一份规格。

提示词 1：需求采访

text
我想做一个【产品 / 功能的一句话描述】，但还没有想清楚。
请采访我，直到你能写出一份可以交给开发的 PRD。
规则：每次最多问 3 个问题，尽量用选择题；优先问最影响方案的事：目标用户是谁、要解决什么问题、怎样算成功（指标）、有哪些限制（时间、预算、技术、合规）、明确不做什么。
当你认为信息足够时，告诉我，并列出你做出的假设让我确认。

二、按章节写 PRD

一份常见的 PRD 包含：背景与目标、用户与场景、需求清单、功能细节、验收标准、非功能要求、范围之外、风险与待定事项。你的团队有固定模板就用团队的。

提示词 2：把采访结果整理成 PRD 提纲

text
基于我们刚才的对话，整理 PRD 提纲，每章写出一句话的内容说明和你准备写的要点。暂时不要写正文。
章节：背景与目标、用户与场景、需求清单（按优先级 P0/P1/P2）、功能细节、验收标准、非功能要求、范围之外、风险与待定事项。
对于对话里没有明确说明、你是自己假设的内容，标上【假设】。

提纲确认后逐章展开：

提示词 3：展开某一章，写可验收的需求

text
请展开 PRD 的「需求清单」和「验收标准」两章。
<context>
【粘贴已确认的提纲、关键背景和约束】
</context>
要求：1）每条需求写成「作为【用户】，我希望【做什么】，以便【得到什么好处】」；2）每条需求至少配 2 条验收标准，写成「给定……当……则……」的形式，必须是别人看了能判断通过与否的；3）凡是需要数字（时长、数量、比例）的地方，如果我没提供就写【待补：xxx】，不要自己定。

三、写技术方案

技术方案的关键是「有选择、有取舍」，而不是只写你一开始想到的方案。

提示词 4：方案对比与评审

text
下面是需求和技术约束：
<requirements>
【粘贴 PRD 的核心需求】
</requirements>
<constraints>
【团队技术栈、人力、时间、已有系统】
</constraints>
请给出 2 到 3 个可行的技术方案，用表格对比：实现思路、优点、缺点与风险、开发工作量（相对大小即可）、对现有系统的影响。
然后推荐一个，说明理由和适用前提；再列出 5 个需要在评审会上和团队确认的问题。
不要编造我没有提到的技术细节，不确定就写出来问我。

采访、对比这类需要多步推理的任务，可以考虑选择能力更强的模型或开启思考功能，模型的区别见 /guides/claude-models-compare。

四、让 Claude 当挑剔的评审者

写完以后，让它从另一个角度检查。注意官方的提醒：被要求挑毛病的审查者总会找到点什么，所以要限定范围，说明只报告影响正确性或交付的问题。

提示词 5：评审 PRD

text
请以开发负责人的身份评审下面的 PRD：
<prd>
【粘贴 PRD】
</prd>
只报告以下几类问题：1）需求之间互相矛盾；2）验收标准无法判断通过与否；3）开发时一定会问、但文档里没有回答的问题；4）明显遗漏的异常情况。
每个问题注明所在章节，没有问题的类别写「未发现」。不要提文风和排版方面的意见。

五、用项目管理长期文档

PRD 往往要多次迭代。官方说明项目（Projects）有知识库，你可以上传文档、文本文件，项目内所有对话都能使用；还有项目指令，对项目里每个对话生效；每个文件最大 30MB。把产品背景、术语表、已定稿的 PRD 放进知识库，新的功能需求就可以在同一个项目里讨论，不必每次重新交代。注意官方说项目里不同对话之间的上下文不共享，新结论要自己补进知识库。项目用法见 /guides/claude-projects-guide。

要得到 Word 文件，需要开启 Settings > Capabilities 里的 Code execution and file creation（新版界面叫 Create and edit files），然后让 Claude「把这份 PRD 生成 Word 文件」。官方说明它能创建 Word、Excel、PowerPoint 和 PDF，每个文件最大 30MB，你需要检查并调整输出。

如果这份 PRD 是要交给 AI 编程工具去实现的，可以把验收标准整理成清单，放进项目的 CLAUDE.md 或规格文件，思路见 /guides/claude-code-best-practices。

图：本站根据官方提示词指南整理的示意图

写 PRD 的几个容易忽略的地方

• 先写「不做什么」：范围之外一章经常被省略，却能挡掉后期大部分扯皮。让 Claude 帮你列出「看起来相关、但这一期不做」的功能，再由你删减。
• 把成功指标写成数字：比如「注册转化率提升多少」，这类数字只有你的业务知道，Claude 不应该替你编。在提示词里写明「没有数据就留空」。
• 异常和边界：网络断开、权限不足、数据为空、重复提交，这些情况往往是开发返工的来源，可以单独让 Claude 按功能逐个检查一遍。
• 术语统一：同一个概念全文只用一个名字。把术语表放进项目知识库，让它写作时遵守。

常见问题

Q：Claude 写出来的需求很空泛怎么办？

通常是因为输入太少。回到采访环节，补充用户场景、现有流程和具体数字，再让它改写。

Q：能直接写出可以开发的详细方案吗？

可以得到底稿。涉及你们系统的真实情况，例如数据库结构、接口约定，要把相关材料给它，否则它只能给出通用方案。

Q：额度消耗大吗？

长文档加多轮修改消耗较快，规则见 /guides/claude-usage-limits。经常写文档可以了解 /chongzhi/claude-pro，价格和额度以官方页面当前显示为准。

相关教程

• /guides/claude-projects-guide：项目怎么用
• /guides/claude-write-official-document-report-summary：写公文和报告
• /guides/claude-code-best-practices：Claude Code 官方最佳实践

参考资料

• Claude 开发者文档：Prompting best practices — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Claude Code 文档：Best practices for Claude Code — https://code.claude.com/docs/en/best-practices
• Claude 帮助中心：How can I create and manage projects? — https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects
• Claude 帮助中心：Create and edit files with Claude — https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude