用Claude Code写PRD，我总结了这几条有用的经验！

最近我连PRD都不想自己动手写了，我觉得产品经理的核心价值，应该需求评估、逻辑思考和产品决策，至于具体的PRD怎么写，只要前面的问题想清楚，写文档就是个体力活，所以我开始尝试用和Claude code对话的方式开始写PRD，效果出奇的好，而且效率非常高。

一、PM写PRD的痛

1.1 思路和文档之间有条沟

脑子里已经有80%的想法了，但一坐下来开始打字，整理思路会占用自己很多的时间。另外写PRD的过程极度需要专注力，如果一会想到功能A，一会补充背景B，效率会比较低，另外最本质的效率问题还是：人手敲键盘的速度还是比大脑的思路慢、比说话速度慢，大脑输出的速度，比模型对话输出的方式慢。

1.2 格式焦虑比内容焦虑更消耗精力

「这个需求背景应该放几个字」「用例图是不是必须要画」「验收标准要列多细」——这些元问题每次都要重新想一遍，纯粹是认知负担，和需求本身毫无关系。

1.3 单人写作缺乏「对话感」

一个好的PRD，本质上是PM和团队提前把对话打完了。但当你自己一个人憋着写，很容易站在自己视角反复确认，忽略了开发会问什么、测试会漏什么、老板会质疑什么。

当我开始用Claude Code写PRD，上面三个问题全部消失了——它是那个「对话方」，帮我把思路对话成文档。

二、Claude Code写PRD的核心逻辑

很多人第一次用AI写PRD，方式是这样的：「帮我写一个XX功能的PRD」。

然后AI给了你一份通用模板填充版，看起来有模有样，但里面全是假设，没有你真实的业务背景，没有你真正关心的核心逻辑，开发拿到直接问「这个边界怎么理解」「这个异常怎么处理」。

正确的方式是：把Claude Code当成一个资深老PM，你来接受他的结构化追问，他来帮你把想法转化成文档。

核心思路分三步：

• Step 1：喂背景 — 告诉AI你的产品形态、用户群体、这个需求的来源

• Step 2：被追问 — 让AI用PM视角追问你，把你没想清楚的地方逼出来

• Step 3：出结构 — 带着已经想清楚的答案，让AI按你们公司的PRD框架输出

三、完整工作流实操（含真实提示词）

3.1 第一轮：喂背景 + 触发追问

我通常这样开头：

「我是一个SaaS产品的PM，我们的产品是面向中小企业的CRM工具，当前MAU约8000。现在我要写一个『批量导入联系人』功能的PRD。先不要写文档，用资深PM的视角问我10个你最想知道的问题，帮我把这个需求想清楚。」

这一步有几个关键设计：

• 明确产品背景，避免AI瞎猜场景

• 「先不要写文档」这句话非常重要，防止AI冲动出稿

• 「10个问题」是个锚定数字，让AI追问足够深但不会无限发散

3.2 第二轮：回答追问 + 补充核心判断

AI问出来的问题，通常覆盖这几个维度：

你不用一次回答完整，可以逐个回答，Claude会记住你说过的每一条。

3.3 第三轮：生成结构化PRD

当追问差不多了，我会说：

「好，基于你对我的所有追问和我的回答，现在帮我输出一份完整PRD。结构包括：需求背景、目标用户、功能描述（含主流程+异常流程）、数据字段说明、验收标准、不在范围内的事项（out of scope）。用markdown格式输出。」

这时候出来的PRD，不是模板填充，是真正基于你业务的内容。我实测下来，90%的内容可以直接用，剩下10%是需要你补图或者补交互细节的地方。

四、让PRD更专业的几个进阶技巧

4.1 让Claude扮演挑剔的开发

PRD初稿出来后，我会追加一条：

「现在你扮演一个非常挑剔的后端工程师，阅读上面的PRD，给我列出5个你认为描述不清楚或者可能引发歧义的地方，并说明原因。」

这个操作堪称防御性写作神器。很多开发评审会上的「这里没说清楚」，提前在这一步就消灭了。

4.2 自动生成验收标准

验收标准是大部分PM最懒得写的部分，AI最擅长。让它从功能描述反推：

「根据上面的功能点，帮我逐条生成对应的验收标准，格式为：Given-When-Then。」

4.3 一键切换文档语气

不同公司PRD风格差异很大。有的公司喜欢简洁bullet风格，有的要求叙述型。直接告诉Claude：

「把上面的PRD改成更精简的风格，每个功能点不超过3行描述，删掉所有重复表述。」

五、真实对比：用Claude前后各花了多少时间

六、几个容易踩的坑

6.1 背景喂得太少

如果你只说「帮我写个XX功能的PRD」，AI会用最通用的假设来填充，结果文档看起来人模人样，实际上全是废话。背景越详细，输出质量越高。

6.2 一次让AI改太多

「帮我把整个PRD重新整理一遍」这种指令成功率很低。改到一半AI会开始幻觉，把你没说改的地方也改掉。要改就指定具体段落或者具体问题点。

6.3 忽略「out of scope」

我见过很多PRD没有这个章节。但在Claude辅助下，这一节非常容易生成——它会根据你们讨论的边界自动总结哪些事不做。这节内容在评审会上能省掉很多「这个你们考虑了吗」的问题。

6.4 把AI当主角，把自己变成旁观者

AI是工具，最终文档里的判断是你的。业务逻辑上的核心决策——比如「这个去重到底用邮箱还是手机号作为唯一键」——必须是你想清楚了告诉AI，不能指望AI帮你做产品决策。

七、适合用这套工作流的PRD类型

结尾：CC写PRD不是「偷懒」，是把精力放对地方

有人会说，用AI写PRD算什么PM能力？

我的观点是：一个好PM的核心竞争力从来不是写一个漂亮的PRD，而是想清楚产品逻辑、做对关键判断、让团队理解需求。

如果我每次写PRD能少花两个小时在格式和措辞上，那多出来的两个小时我可以多做一次用户访谈，多复盘一次上线数据，多想一想下个季度的产品方向。