PRD
中级通用
PRD（产品需求文档）是一份把产品目标、目标用户、功能范围和验收条件讲清楚的文档。它解决的是团队或 AI Agent 各凭猜测做功能的问题，例如先写明预约功能的规则，再让 Agent 开发。
你可能会说：「我想让 AI 帮我做个预约功能，怎么把用户要做什么、功能边界和完成标准一次说清楚？」
要点一份 PRD 要讲清哪些事？
- 1
先说明用户遇到什么问题
比如你要给诊所网站加预约功能，先说清谁在预约、他们现在卡在哪里，以及这次希望改善什么。因为开发只看到“做个预约页面”，很难判断哪些操作才是重点。
- 2
把本次范围和规则说具体
我们可以写清用户能选哪些时段、已满的时段如何显示、取消预约是否在本次范围内。这样 AI Agent 才不会自行补出一套你没决定过的规则，也方便团队识别后来新增的需求。
- 3
用可检查的结果收尾
与其写“预约体验顺畅”，不如写“提交成功后显示预约时间；时段已满时不能提交”。因为这些结果能实际验证，我们才知道功能是做完了，还是只做出了看起来像的页面。
容易混淆的地方
PRD 讲的是某项产品需求为什么做、这次做什么、怎样算完成。产品路线图关注多个方向和阶段的安排，不替单个功能说明细节；产品待办列表记录待处理事项和优先级，也不一定解释完整的用户流程与规则。你可以从 PRD 拆出待办事项，但两者不是同一份东西。
什么时候用
适合用
- 你要让 AI Agent 开发网站预约功能，涉及可选时段、提交结果和异常情况，需要先对齐实现范围。
- 设计师、前后端要一起做 App 的会员开通流程，彼此需要用同一套规则判断方案是否完整。
- 一个后台导出功能会影响不同角色，你想在动工前说清谁能导出、导出什么以及怎样验收。
不适合用
- 你还不知道用户是否需要预约功能，先做用户访谈或产品发现，比先写一份看似完整的 PRD 更合适。
- 你只是把页面上一处错别字改正，直接写清修改位置和目标文案即可，没必要为此写 PRD。
- 线上接口突然报错，你需要先排查日志并记录修复任务；此时 PRD 不能代替故障定位。
练一练选一个答案，看看解释
你要让 AI Agent 给网站增加预约功能。团队只确定了用户要选时段，还没讨论满额时怎么处理。动工前哪种做法最能发挥 PRD 的作用？
让 AI 帮你做复制给 AI Agent 直接用
请先和我一起整理一份预约功能的 PRD，不要直接写代码。根据我提供的信息，列出目标用户、要解决的问题、本次范围、关键流程和验收条件；遇到未确定的业务规则，请列为待确认问题，不要自行假设。