产品工作

用 AI 写 PRD

用 AI 写 PRD 教程说明如何从问题证据、目标、范围、用户流程到验收标准形成可评审需求文档，并用假设示例和复核表避免 AI 补写事实。

预计阅读: 3 分钟
首次发布: 2026/07/10
最近更新: 2026/07/10

用 AI 写 PRD 的稳妥方式，是先提供真实背景与证据，再让 AI 补结构、找冲突、提出追问和生成验收草案。AI 不知道团队的真实优先级、技术约束和用户承诺，因此不能靠一句“帮我写完整 PRD”得到可直接立项的结论。

页面摘要

项目	说明
阅读时间	约 8 分钟
适合人群	产品经理、创业者、业务负责人、项目经理和需要写需求的运营人员
核心产出	问题定义、目标与非目标、范围、流程、规则、异常状态、验收标准和未决项
使用前提	至少有需求来源、目标读者、当前流程和关键限制
不适合	让 AI 决定商业优先级、虚构用户证据，或替研发承诺实现时间

适用边界

AI 擅长把零散会议记录、工单摘录、现有规则和草图整理成一致结构，也能检查术语、遗漏状态和前后矛盾。它不能确认样本是否代表用户、数据口径是否准确、方案是否可实现，以及某项需求是否已经获得审批。

可交给 AI	必须人工确认
整理背景、统一术语、生成章节提纲	问题是否真实、目标是否值得投入
把流程改写成步骤和状态表	权限、合规、成本和技术边界
依据明确规则生成验收草案	验收是否覆盖真实业务与上线条件
标出冲突、模糊词和缺失信息	决策、排期、责任人和对外承诺

六步写成可评审 PRD

写决策说明：说明谁会用这份 PRD 做什么决定，例如确认范围、估算方案或准备测试。
建立证据包：列出来源编号、日期、原文摘录和限制；无来源的内容标记为“待验证假设”。
定义问题与目标：描述用户在什么情境下遇到什么阻碍，以及本期希望改变的可观察行为；另列非目标。
拆流程与规则：用主路径、异常路径、权限、数据字段和边界条件说明方案，不把界面稿当作全部需求。
生成验收草案：按“给定—当—那么”或检查表写可测试标准，并覆盖空状态、错误状态和恢复方式。
组织评审与留痕：记录已确认、需修改、待研究和不在本期四类结果，保留决策人和依据。

可复制输入框架

任务：根据材料生成 PRD 初稿，不补写不存在的用户、数据、日期或承诺。
决策用途：[范围评审 / 技术估算 / 设计启动 / 测试准备]
需求来源：[带编号的工单、访谈、数据、会议记录]
当前流程：[用户现在怎样完成任务]
目标与非目标：[本期想改变什么；明确不解决什么]
业务规则：[权限、状态、字段、审批、通知]
限制：[合规、技术、时间、依赖]
输出：摘要、问题、证据、目标、范围、用户流程、规则、异常状态、验收、未决项。
所有推断标记“假设”，缺失信息写“未提供”。

假设示例：导出任务增加状态提示

以下内容仅用于演示结构，不代表真实产品、用户研究或上线结果。

示例输入

S1 工单摘录：用户点击导出后不知道是否仍在处理。
S2 现有规则：文件生成完成后才会出现下载入口。
S3 技术说明：任务存在排队、处理、成功、失败四种状态。
范围：只改善状态可见性，不改导出格式，不承诺完成时间。

示例输出

PRD 字段	草案
问题	导出请求提交后，界面没有持续说明任务状态；证据来自 S1，影响范围未知
目标	用户能看到当前状态，并在失败时知道如何重试或求助
非目标	不调整格式、性能与任务优先级；不显示未经确认的完成时间
主路径	提交后显示“排队中”或“处理中”；成功后出现下载入口
异常路径	失败时显示原因类别、重试动作和帮助入口，不暴露内部错误详情
待确认	状态刷新机制、任务保留时间、权限变化后的处理方式

验收草案

给定用户有导出权限，当请求成功进入队列时，那么页面显示任务状态且不会重复提交。
给定任务处理失败，当页面获得失败状态时，那么用户能看到可执行的恢复动作。
给定用户权限在处理期间发生变化，当文件完成时，那么下载入口按最新权限规则处理。

这些验收项仍需研发、设计和测试确认。示例没有推断队列时长，也没有声称新提示会改善任何比例。

决策与复核表

检查项	合格表现	退回修改
问题	描述场景、阻碍和证据来源	把“新增一个按钮”写成问题
目标	可观察，并与非目标成对出现	使用“全面提升体验”等模糊词
范围	包含、不包含、后续候选明确	依赖只藏在正文角落
规则	权限、状态、字段和异常可追踪	只有理想主流程
验收	可测试，写明前提、动作和结果	用“正常”“友好”“智能”作标准
未决项	有负责人和确认时点	AI 自行选择答案填入正文

常见错误

用方案名称当作标题，却没有说明用户问题。
把一条反馈扩写成“用户普遍需要”，没有样本边界。
让 AI 自动补齐市场数据、埋点结果或竞品能力。
验收只覆盖成功路径，遗漏权限、空数据、超时和撤销。
评审意见直接覆盖原文，没有留下变更理由与决策记录。

常见问题

AI 写的 PRD 可以直接发给研发吗？

不建议。至少要确认需求来源、范围、业务规则、异常路径、验收和未决项，并让相关责任人完成评审。

没有用户研究材料怎么办？

把文档定位为“问题假设与验证计划”，不要伪装成正式 PRD。列出需要补的工单、访谈、数据或现场观察。

PRD 应该写多长？

长度取决于决策复杂度。简单改动可以使用一页式说明；状态多、权限复杂或跨系统的需求需要更完整的规则与验收表。

如何让 AI 少编内容？

提供带编号来源，要求缺失值写“未提供”，所有推断标记为假设，并逐项核对输出是否能回到输入。

带走什么

一份可评审 PRD 不靠文字完整感，而靠证据、范围、规则和验收彼此对齐。让 AI 负责整理与追问，让团队负责事实、取舍和承诺。