近日，软件开发团队面临着一个常见的问题，即需求文档写作耗时且开发人员仍然不清楚需求内容。为了解决这个问题，提出了一种创新的方法，即使用三段提示词来将一句想法变成可接手的产品需求文档草稿。这种方法先让人工智慧工具帮助用户澄清需求，然后根据问答内容生成文档草稿，最后模拟开发和测试人员的角色对文档进行反馈和修正。这种方法不仅可以节省时间还可以提高需求文档的质量和可行性，软件开发团队可以使用这种方法来提高工作效率和质量。
菜鸟之友系列：《AI 工具实操与提示词》・模板篇作者：业州愚公
带过专案的人都遇过这种场景：老板一句话「我们也做个签到功能吧」，你埋头写了三天文档，格式漂亮、配图齐全，结果开发看完第一句话是「这个签到，一天一次还是随时都能签？」，第二句是「漏签了怎么办？」——三天的心血，卡在这两个你从没想过的问题上。
PRD（产品需求文档）难写，不是因为文笔，而是因为它逼你把脑子里那团模糊的「想做个什么」拆成一条条可执行、可验收的条目。而大多数人卡住的方式是一样的：对着空白文档从「背景」开始写，写到「功能需求」就开始自由发挥，漏掉的地方用「等等」「相关细节后续补充」糊弄过去——这些糊弄的地方，恰恰就是开发提问、返工、扯皮的来源。
换个角度看，PRD 的本质不是文档，是决策记录：哪里有空白，哪里就还没做决定；没做的决定不会消失，只会变成开发阶段的提问、测试阶段的扯皮、上线之后的返工。所以写草稿的正确目标不是「写得快」，是「把空白暴露出来」——先暴露给你自己。
用 AI 写 PRD，最忌讳的用法是直接说「帮我写一份签到功能的 PRD」。它会立刻给你一份格式完美、内容全是编的文档：流程是它猜的、数字是它编的、边界是它脑补的。你拿到的不是需求文档，是一份看起来很专业的小说。更麻烦的是，假完整的文档会让你产生「已经想清楚了」的错觉——空白被它的猜测填满了，你连哪里没想过都看不出来。
正确的顺序是反过来的：先让 AI 逼你把需求想清楚，再让它照着你的回答成稿，最后让它扮演最挑剔的开发来挑错。下面三段模板就是这三步，任何能对话的模型都能跑，不依赖任何特定工具的专属功能。
适用场景：需求还是一句话，甚至只是个念头。这一步的产出不是文档，是一份「你被问倒的清单」。
```
你是一名资深产品经理。我想做一个功能：【一句话描述你的想法，例如：让门店员工每天打卡签到】。
先不要写任何文档，也不要给方案。你的任务是通过提问帮我把需求想清楚：
1. 每轮最多问 3 个问题，等我回答后再问下一批，问完为止；
2. 问题必须覆盖：目标用户是谁、要解决什么具体问题、成功的标准怎么衡量；
3. 对我回答里含糊的词（如「方便」「好用」「优化体验」），要追问到可验证的描述为止；
4. 全部问完后，输出一节「你还没想清楚的三件事」，只列影响最大的三个，各附一句为什么关键。
禁止：替我补充我没说过的需求；禁止提前给任何功能设计。
```
要替换的变数：只有一个——【一句话描述你的想法】。写得越口语越好，就照你跟老板复述的原话写，别润色。
为什么这样写：这段模板最关键的是第一行「先不要写任何文档」。不写这句，模型会急着表现，问两个问题就开始输出方案。「每轮最多 3 个问题」是防止它一口气列二十条把你淹死；「追问到可验证为止」是专门对付你自己脑子里的含糊地带——你说「要方便」，它会问「方便是指几秒内完成，还是少点几步？」，这一问你就知道该定什么指标了。
回答的质量决定这一步的价值。举个对照：问「目标用户是谁」，答「门店员工」，这个答案没有信息量；答「门店店员，早上开店和晚上关店各打一次卡，用的是店里那台共用平板」，这就是能写进文档的答案。你每多给一个具体细节，模型后面替你编造的空间就少一分。整个过程大约三到五轮对话，花不了十五分钟，但能把「漏签了怎么办」这类要命的问题提前拦在文档之外。
适用场景：模板一的问答做完之后。这一步的产出才是 PRD 草稿，而它质量的上限，就是你上一轮问答的质量。
```
根据下面两份材料，写一份 PRD 草稿。
【我的想法】：……
【问答记录】：……
要求：
1. 按固定结构输出：背景与目标／目标用户与使用场景／功能需求（从 PF-01 开始编号）／不做的事／验收标准；
2. 每条功能需求必须包含：触发条件、正常流程、至少 1 个异常情况的处理；
3. 「不做的事」一节至少列 3 条，每条附一句不做的原因；
4. 验收标准禁止使用「良好」「快速」「易用」等不可测的词，必须写成「在 X 条件下、Y 时间内完成 Z」的句式；
5. 信息不足的地方，插入标记【待补：缺什么】并停笔，严禁自己编造数字、流程或规则补上；
6. 全文用陈述句，禁用「大概」「可能」「等等」「后续补充」。
```
要替换的变数：【我的想法】和【问答记录】。问答记录直接把上一轮的对话原样贴进来，包括你答得含糊的部分——含糊处模型会标【待补】，正好提醒你去找答案。
为什么这样写：「不做的事」是整份文档里最能省钱的一节。开发扯皮的一半来源，是他以为要做、你以为不用做的部分；白纸黑字列三条「不做」，比十条「要做」都管用。第 4 条句式限制是逼着验收标准可测试：「载入要快」改成「在 4G 网络下，首屏 2 秒内完成载入」，测试才知道怎么判合格。第 5 条的【待补】标记是防幻觉的核心——没有它，模型会用最合理的猜测填满所有空白，而猜错的部分，代价是返工。
拿到草稿后别急着发，先做一件事：把所有【待补】标记集中起来逐条处理。每一条只有三种下场——找到答案填进去、明确写成「本版不做」、或者带着这个问题去问能拍板的人。三种都比留着空白强，更都比让模型猜一个强。另外提醒一句：模板里的固定结构（背景、用户、功能、不做的事、验收标准）是最小可用集，团队有自己的模板就让 AI 照你们的结构改，把要求第 1 条的结构名单换掉即可，其他条目照用。
适用场景：草稿完成之后、发给开发之前。这一步模拟的是「文档评审会」，把开发的追问提前到你自己这里消化掉。
```
下面是一份 PRD 草稿。你同时扮演两个角色来审查它：
角色 A：要接手开发的工程师。只挑「会导致你没法动工、或做完大概率要返工」的问题。每条指出在第几节，说明你看到这句话时想到的两种可能理解分别是什么。
角色 B：负责验收的测试。只挑「没办法客观判断合格与否」的条目，并把每一条改写成可测试的版本。
最后输出一张汇总表，栏位为：位置｜问题｜两种可能理解（或不可测的原因）｜建议改法。
禁止任何夸奖和客套；禁止修改你认为没问题的部分。
【PRD 草稿】：……
```
要替换的变数：只有【PRD 草稿】。把模板二的输出整份贴进来即可；如果文档很长，可以分节审，但每次都要把「背景与目标」一起带上，否则评审会脱离上下文。
为什么这样写：「两种可能理解」是这段模板的杀手锏。开发提问的本质就是「这句话有两种读法，我做哪个」——让 AI 把两种读法都摆出来，你只需要选一个或补充条件，比等开发在会上问快得多。禁止夸奖这条不能省：不写，模型会用三分之一的篇幅夸你文档结构清晰，然后只挑两条不痛不痒的。
评审结果拿到手，逐条消化时记得分成三类处理：改几个字就能消除歧义的，直接改；需要补条件、补数字的，回到模板一那套追问，自己定或者找人拍板；还有一小部分会让你发现「这条需求本身就不该存在」——这是评审最有价值的产出，砍掉它，比改十遍措辞都划算。跑完这一轮再发出去的文档，开发的追问会少一大半，因为最容易被问倒的地方，已经被你自己的「假开发」问过一遍了。
| 你的处境 | 先用哪段 | 核心动作 | 产出物 |
|---|---|---|---|
| 只有一句话的想法 | 模板一 | 让 AI 追问，你回答 | 需求盲点清单 |
| 问答做完，要出初稿 | 模板二 | 按固定结构成稿，缺处标【待补】 | PRD 草稿 |
| 草稿完成，发出前 | 模板三 | 双角色评审，逼出歧义 | 修改清单＋改后终稿 |
三段可以一次跑完，也可以拆开用。时间紧的时候，最省的组合是「模板一＋模板三」：先问清楚，自己动手写个一页粗稿，再让它打回一次——比直接生成一份假完整的长文档靠谱。
另外两个常见的坑提前说。一是别在模板二里贴竞品数据让它「参考着写」——模型的习性是照抄，你贴了 A 产品的截图，它就会把 A 的流程原样搬进你的 PRD，连你自己没打算做的功能都一并搬进来；竞品信息应该出现在「不做的事」的决策过程里，而不是需求正文里。二是需求变更后别只改正文那一处，把模板三重跑一遍——改动往往会让别的条目产生新的歧义，人眼检查不出来，双角色评审查得出来。
最后一个提醒：AI 产出的 PRD 草稿里，所有标了【待补】的地方都是它提醒你「这里只有你知道答案」。把这些空补完再发出去，开发的第一句话就不会再是「这里到底要做什么」了。
工具推荐随身机器人（新用户免费试用 7 天）
文中三段模板可长期保存、反覆替换变数使用。如果你想要一个随手就能呼叫、无需折腾配置的对话入口，试试随身机器人：新用户免费试用 7 天，把手头的需求直接丢进去跑一遍模板一，你就知道差在哪了。
下一篇预告：书读完一个月，只言片语都记不起来？下篇我们用三段提示词，把一本书拆成能长期复用的「知识卡片」——读书笔记与知识卡片，敬请期待。
业州愚公 ｜ SY 视野（sylogs.com）原创内容，转载请注明出处。