前言

一个人做产品，最容易卡住的常常不是写代码，而是还没想清楚第一版到底要做什么。

脑子里有个念头：做一个小工具、一个记账本。真准备动手时，问题就来了：给谁用？第一版做哪些功能？哪些先不做？做到什么程度才算完成？如果这些问题没有答案，代码写得越快，返工可能越多。

PRD（Product Requirements Document，产品需求文档）可以把这些判断整理下来。现在也可以让 AI 先帮忙起草，再由你补充背景、收窄范围、检查内容。

这篇用一个财务记账产品做例子，看看从一句需求开始，如何让 AI 先提问、生成一份 PRD，再对其中一部分进行修改。重点不是让 AI 一次写完所有答案，而是把模糊想法变成可以检查、可以讨论的初稿。

一、PRD 要回答哪些问题？

一份 PRD 至少要帮你理清三件事：

把这些写清楚，能帮助你梳理想法、控制第一版范围，也让后续开发有据可查。一个人做产品也需要这份记录：隔几天再回来时，当初为什么这样取舍，不一定还记得。

没有范围和验收标准时，常见情况是功能越加越多、做到一半才发现方向不对，或者交付时说不清“完成”是什么意思。PRD 不能消除这些风险，但可以把它们提前摆到桌面上。

写之前，先确认问题真的存在

“我想做一个记账工具”是产品想法，还需要找到具体的使用理由。可以先问目标用户：最近一次想记录消费是什么时候？现在用什么方法？在哪一步放弃过？相比微信账单、表格或现有记账软件，为什么愿意换一种方式？

如果暂时只有自己使用，就记录几天真实的消费和记账过程；如果准备给别人用，可以先找几位目标用户访谈或试用一个简单原型。这些反馈能帮助发现问题，但少量访谈还不足以证明市场需求。

比如，“希望手机上几步完成记录，月底看清主要支出”可以作为待验证的问题假设。AI 可以帮忙整理访谈、列出假设，但不能替你编造用户反馈。 PRD 中最好注明哪些内容来自真实观察，哪些还需要验证。

二、先准备一个干净的工作目录

示例先建了一个项目目录，把 PRD 放进单独的阶段文件夹：

my-product/
└── 001.产品PRD/

目录怎么命名并没有固定答案。重点是让 AI 知道当前项目在哪里，以及产物应该保存到哪里；重要文件写入前，也要确认路径和文件名正确。

三、第一句话要给哪些信息？

示例中的起始提示词很短：

我想做一个财务记账小产品，用户可以记录每天的收入和支出。
请先了解我的需求，再帮我整理一份 PRD，保存到 001.产品PRD 文件夹。

这句话交代了三件事：产品方向、希望 AI 先澄清需求，以及交付物和保存位置。它没有提供目标用户、平台和第一版范围，所以 AI 还需要继续提问。

“你是一个非常厉害的产品经理”这类角色提示可以作为语气或视角的补充，但不会自动补齐业务事实。目标用户、产品边界、交付格式和验收要求，说得越清楚，初稿越容易贴近实际。

四、让 AI 先问，再开始写

在这个例子里，Claude Code 先确认了工作目录，然后针对产品形态和目标用户提出选择题。选择题降低了回答门槛，也帮助发现提示词里还没有说明的地方。

例如，产品形态可以是手机 App、Web 网页、小程序或多端；目标用户则可能是个人、家庭、情侣或小微企业。用户进一步补充：第一版先做 Web，手机浏览器可用；主要面向个人，同时也考虑家庭或经营场景。

这里有个需要继续确认的地方：个人、家庭和小微企业的需求差别不小。如果都作为第一版的核心用户，功能范围很容易膨胀。更稳妥的做法是选定一个主要用户，把其他人群暂时列为后续方向，或明确他们是否属于本次范围。

因此，AI 提问的价值不只是“帮你补资料”，还在于让你看到需求里的模糊和冲突。回答完问题后，先让它复述理解；如果复述偏了，先纠正，再让它写文档。

把第一版收敛成一句可以执行的话

沿着这个例子继续，可以提出一份供确认的首版范围：

面向用手机浏览器记账的个人用户，先支持记录、查看、修改和删除自己的收支，并查看当月汇总。暂不包含家庭共享、企业报销、银行自动同步和多币种换算。

这是用于演示的范围建议，需要由产品负责人确认。它也带出一个重要决定：数据保存在当前浏览器，还是通过账号保存在云端？ 前者需要说明清理浏览器数据或更换设备后的影响；后者涉及登录、同步和用户数据隔离，工作量会明显增加。这类选择会影响整个方案，适合在写详细流程前确认。

五、看懂生成的 PRD：有结构不等于已可开发

确认需求后，Claude Code 生成了一份约 316 行的《财务管家 PRD》。初稿包含产品概述、用户与场景、功能清单、功能流程、界面建议、版本规划、风险和成功指标等内容。

下面继续沿着记账案例补充评审建议；这些内容是为了演示怎样完善需求，不代表初稿已经包含或确认了所有规则。

例如，功能清单按优先级整理：

优先级还要说明判断依据：在这个例子里，可以约定 P0 是缺少后主流程无法完成或数据不可靠的能力，P1 是改善效率的能力，P2 是后续扩展。不同团队的定义可能不同，不能只贴一个标签就算排过优先级。

按这个标准，原清单还漏了记录列表、修改和删除记录。用户记错金额却无法修正，统计也会跟着失真。这几项应纳入首版评估，和“记录 → 查看 → 纠错 → 汇总”组成完整流程。还要结合可投入的时间判断首版能否完成；超出预算时，优先减少扩展能力。

单个功能也可以继续写到流程级。比如“快速记账”不只是一句“支持记账”，还要说明入口、输入内容、保存动作和完成后的反馈：

入口：首页的“记一笔”按钮
流程：选择收入或支出 → 选择分类 → 输入金额 → 可选填备注和日期 → 保存
反馈：保存成功后返回首页，并更新当月收支数据

这类细节能减少开发时的猜测，但仍然需要结合真实产品决定。例如是否需要账户选择、离线记录、数据同步或多人共享，都不能只因为 AI 写进 PRD 就当作已经确认。

把业务规则和异常情况写出来

对记账工具来说，金额、时间和保存结果会直接影响用户是否信任产品。下面是一组供确认的示例规则：

只写正常流程很容易得到一个能演示的页面。把空列表、金额不合法、保存失败、重复点击和记录被删除后的状态补齐，才更方便开发和验收。

记账数据也有隐私要求。如果采用账号和云端存储，需要明确每个用户只能访问自己的记录，以及数据导出、删除的范围。采集行为数据时，避免把金额、备注等明细直接放进分析事件。若采用本地存储，则要向用户说明丢失风险，并评估备份或导出是否应提前进入首版。

用具体场景写验收标准

“记账功能正常”很难作为交付依据。可以把规则改写成可复现的检查场景：

这些是核心示例，不能代替完整的验收清单。如果选择云端账号方案，还应补上账号隔离、登录失效和网络异常等场景。

指标和数值要特别核实

初稿还可能列出 DAU、记账成功率、留存率和满意度等指标。指标名称可以作为讨论起点，但 AI 给出的数字（例如“DAU 500+”或“次日留存 40%”）不一定有依据。

没有用户研究或业务目标支撑时，不要把这些数值直接当成承诺。可以先写清楚要观察什么、如何采集、之后根据什么数据设目标；有基线后再确定合理区间。

首轮试用可以先关注更贴近产品价值的信号：

“首次记账完成情况”看用户能否走通流程，“保存成功率”看系统是否可靠，两者要分开分析。每项还要写明统计周期、采集方式和负责人；在完成一轮试用后，再结合基线设定目标。

同样，PRD 里的日期、用户画像、竞品结论、技术假设和法规要求都应逐项核对。文档很长、表格很齐，并不等于内容真实或可落地。

六、局部修改：一次只调整一个明确问题

初稿完成后，用户希望视觉更粉嫩、可爱一些。与其让 AI 重写整份 PRD，不如明确要求只改配色章节，并保留其他已经确认的内容：

请只调整 PRD 中的配色方案，让视觉更粉嫩、亲和。
保留其他章节和功能范围不变；完成后列出修改的章节，并检查新配色是否与收入、支出状态的可读性冲突。

这样可以把变化限制在一个范围。原文示例中的粉色、薄荷绿和奶油白色板，可以作为讨论稿，但仍要检查文字与背景的对比度、状态颜色的辨识度，以及色彩在实际页面上的效果。

PRD 是可以逐节讨论的工作文档。功能、用户范围和指标确认后，改视觉时就不必连带推翻它们；如果修改影响了其他章节，再明确要求同步更新相关内容。

例如，把本地保存改成云端同步，就不能只改一句描述。登录、网络异常、数据隔离、统计采集和验收范围都可能受影响。可以让 AI 先列出影响项，再由你决定是否进入当前版本，并在文档里简要记录版本、变更原因和待确认事项。

七、一份 PRD 的自检清单

文档写完后，可以按下面的问题逐项检查：

特别留意不做什么和哪些结论还只是猜测。前者能帮你控制范围，后者能避免把 AI 补出来的细节误认为已经做过调研。

进入开发前，至少要确认：首版目标与范围已定，核心规则和验收可执行，影响方案的未决事项有人负责处理。尚未解决的问题可以保留在文档中，但像“本地还是云端保存”这样会改变整体方案的问题，需要先作出决定。开发完成后，再对照验收场景和首轮试用反馈决定下一步。

八、可复用的提示词

换成其他产品时，可以把下面的内容补全后再交给 AI：

我想做一个产品，请先阅读我提供的背景，再通过问题补齐关键需求。
在我确认你的理解之前，先不要生成完整 PRD。

【产品想法】
（一句话说明产品解决什么问题）

【目标用户】
（谁会使用，最主要的使用场景是什么）

【需求依据】
（目前的替代方式、真实反馈或观察；没有证据的内容请注明是假设）

【第一版范围】
（先做哪些平台和核心功能；明确暂时不做什么）

【资源与关键约束】
（可投入时间、预算、现有系统，以及已确认的数据保存方式等约束）

【交付要求】
先复述你的理解，列出需要我决策的问题，并优先追问影响首版范围和方案的问题。
需求确认后，生成一份 PRD，包含产品定位、用户场景、首版做与不做的范围、
功能优先级及依据、核心流程与异常状态、业务规则、数据保存与访问边界、
页面结构、可复现的验收场景、指标口径，以及风险与待确认假设。
对待确认事项注明影响、负责人和确认时机；生成后再检查跨章节是否矛盾。
将文件保存到 001.产品PRD 文件夹。对缺少依据的指标或结论，请标记为待确认，
不要自行编造为已验证事实。

如果自己已经清楚第一版边界，就直接写明，减少来回追问；如果还不确定，可以让 AI 一次提出几个关键问题，并在回答后先复述理解。把问题交给 AI 帮忙拆解，不代表把最终取舍也交给它。

九、常见的坑

1. 一上来就要“完整版”：多端、多人协作和数据同步一起塞进第一版，容易让范围失控。先明确一个核心用户和主流程。
2. 功能没有优先级：每项都标成“必须”，优先级就失去了作用。先找出最小但完整的核心流程。
3. 只写功能，不写流程：“支持分类统计”还不够，要说明统计维度、展示方式和交互结果。
4. 没有写清不做什么：把本次不包含的内容列出来，减少开发中不断扩大的需求。
5. 直接照单全收 AI 的指标和结论：来源不明的数字、用户画像和竞品判断都应标注并验证。
6. 文档写完就不再看：开发中发现假设不成立时，更新对应章节和验收标准，让 PRD 与实际决策一致。

十、总结

这次值得借鉴的不是“AI 一句话写出 316 行文档”，而是把需求整理分成几个可检查的步骤：

• 先补背景：通过提问找出平台、用户和范围上的空白；
• 再写初稿：把定位、功能、流程和验收整理成文档；
• 逐项核对：区分已确认事实、待验证假设和 AI 建议；
• 小步修改：一次改一个明确章节，并检查相关内容是否受影响。

一句话：PRD 不是让 AI 替你做决定，而是帮你把决定摆出来、写清楚，再由你确认。 先把第一版的用户和边界定下来，再开始写代码，往往比追求一份看起来完整的文档更有用。