PRD 是产品需求文档，用来说明为什么做一项需求、做哪些功能，以及开发、设计和测试如何判断结果符合要求。写 PRD 时，可以先搭好“背景与目标—用户流程—功能说明—页面状态—数据与边界规则”的结构，再把每项功能写成可执行的条目。最容易漏掉的通常是规则冲突、失败后的恢复方式和验收条件，这些内容比继续扩写项目背景更值得补齐。
如果需求还比较零散，可以用墨刀AI生成产品PRD文档整理初稿。输入时给出用户、场景、范围和已确认规则；生成后重点核对业务判断、异常分支和验收标准。AI 适合帮你组织材料，优惠能否叠加、谁有权操作、数据如何保存等决定，仍要由项目相关负责人确认。
PRD文档写给谁看，要回答哪些问题
开发需要明确处理逻辑、数据来源和边界；设计需要明确页面组织、操作反馈与各种状态；测试需要可复现的条件和可判断的结果。同一份文档可以服务这三类读者，但不必把接口实现、视觉细节和测试用例全部塞进正文。明确关联材料的位置，并让相同业务规则只有一个维护入口。
例如，“提交订单按钮点击后进入支付页”只描述了一个界面动作。开发还需要知道库存何时校验，设计需要知道提交过程中按钮如何反馈，测试需要知道重复点击或请求超时后应出现什么结果。把这些信息放在同一功能条目里，读者才能按条件还原完整过程。
先搭五部分结构，再填写具体需求
1. 项目背景与目标
写清用户遇到的具体困难、问题依据和本期要改变的结果。例如“用户无法确认购物车优惠是否已使用”，比“优化购物体验”更容易转成需求。已有数据可以注明统计口径；暂时没有数据，就记录来自访谈或反馈的问题，不补一个看似精确的提升比例。
2. 用户场景与流程
说明谁在什么条件下从哪里进入，经过哪些操作，在哪里结束。电商下单可以拆为“购物车选择商品 → 确认地址与配送 → 核对优惠和金额 → 提交订单 → 查询支付结果”。同时标出登录过期、地址不可配送、商品不可售等分支；不要把所有异常都归为“提示错误”。
3. 功能说明
按可以单独讨论的功能模块分组，如地址选择、优惠计算、订单提交。每个条目给出编号、触发条件、输入、处理规则和输出，再关联原型页面。一个规则被多个页面使用时，写在公共规则区，页面条目引用它，避免改价逻辑在购物车、确认页和订单页出现三个版本。
4. 交互与页面说明
注明默认、加载、空数据、成功和失败时显示什么，哪些操作可用。重点描述变化和行为，而不是逐个复述静态元素。例如提交中是否禁用按钮、地址切换后是否重新计算运费、返回上一步是否保留输入，都应该能在文档和原型中找到一致答案。
5. 数据与边界规则
列出关键字段的来源、类型、必填条件、范围和校验时机。金额需要明确币种、精度和舍入规则；权限需要明确适用角色及数据范围；库存、价格等可能变化的数据，需要说明提交时是否重新校验。尚未确认的规则列入待决项，标注负责人和影响范围。
一个功能条目怎么写：以提交订单为例
下面是一组写法示例，具体库存、优惠与支付规则需按项目确定。它可以作为 PRD 中的一个功能小节，而不是整份文档。
| 条目字段 | 填写示例 |
|---|---|
| 功能编号与范围 | ORD-01 提交订单；包含确认页提交与结果反馈，不包含退款和售后。 |
| 用户与前置条件 | 用户已登录，已选择商品、有效地址和配送方式；存在待确认信息时不能直接提交。 |
| 触发与输入 | 用户点击“提交订单”；提交所选商品、数量、地址、配送和优惠选择。 |
| 处理规则 | 提交时校验商品可售状态、库存和适用优惠；价格变化先展示差异，由用户重新确认。 |
| 成功结果 | 显示订单号、应付金额和待支付状态；用户可在订单列表找到这笔订单。 |
| 异常与恢复 | 商品不可售时返回可修改的确认页；提交超时先查询提交结果，不能把未知结果直接当作创建失败。 |
| 依赖与待决项 | 价格来源由业务与研发确认；优惠叠加规则由运营确认，未确认前不能作为已定规则进入评审结论。 |
字段规则应继续落到具体值与约束。例如收货地址不能只写“必填”，还要说明从地址簿选择还是允许新增、变更后如何校验配送范围；购买数量不能只写“数字”，还要说明允许范围以及库存变动后如何提示。敏感信息的展示与保存要求也应单独确认，不交给工具自行补全。
对于重复提交，PRD 可以明确用户可观察的结果：“连续点击不产生多笔同一提交订单；恢复网络后能查到原订单”。实现如何去重由研发方案说明，产品文档不要把一个未经确认的技术做法当成既定接口设计。
把“功能完成”写成能验收的结果
验收条件要能判断通过或不通过。使用“在什么条件下，执行什么操作，应出现什么结果”的写法，比“体验流畅、逻辑完整”更有用。正常路径和关键异常路径分别写。
| 场景与前置条件 | 操作 | 可观察的预期结果 |
|---|---|---|
| 商品可售，地址有效，金额已确认 | 提交订单 | 出现订单号与待支付状态，订单列表可查询到相同金额和商品。 |
| 确认页停留期间商品变为不可售 | 再次提交 | 明确指出受影响商品，保留其他输入，允许移除商品或返回购物车。 |
| 提交请求发出后网络超时 | 重试或返回订单列表 | 可以查询原提交结果；确认已创建后进入原订单，不重复创建。 |
| 支付未返回明确成功或失败 | 查看支付结果 | 展示查询中的状态和查询入口；查明后更新订单，不提前显示“支付失败”。 |
| 地址变更导致优惠或配送条件不适用 | 选择新地址 | 指出失效项目并更新金额，用户确认新金额后再继续提交。 |
若团队要验收加载时间、并发量或可用性，需要另列测试环境、测量方式和阈值，并与研发确认。不要只在 PRD 里写“高性能”或直接复制一个没有测量条件的数字。
用墨刀AI起草，再补齐项目已经确定的规则
先整理现有访谈、业务规则和范围，再交给 AI 组织初稿。需要比较不同起草工具时，可以查看PRD生成工具的适用场景与限制；如果还没有明确要解决的问题，应先进行需求分析，不急着生成完整文档。
第一步：选择需求文档入口
在墨刀AI中选择 PRD 文档相关入口。下图对应“产品规划”下的“需求文档PRD”，进入后填写需求。使用时以界面显示的入口名称为准。
第二步：输入范围和规则，回应补充问题
不要只输入“帮我写一份电商 PRD”。说明目标用户、本期范围、已确认规则和仍未确定的事项，才能减少初稿中的猜测。下面这段可作为输入的起点：
为电商 APP 的订单确认与提交功能起草 PRD。用户是已登录消费者，本期包含地址选择、配送方式、优惠核对、订单提交和结果查询，不含售后。请按功能编号整理前置条件、输入、规则、正常结果、异常恢复及验收条件。已确认：价格变化后需用户重新确认；提交结果未知时先查询，不直接重复下单。优惠叠加、库存锁定时机尚未确认，请列为待决项并提出需要确认的问题，不自行补成事实。
如果生成流程提出补充问题，按已有资料回答；暂时没有结论就保留待确认状态。尤其要检查角色、业务流程和边界条件，避免为了尽快得到文档而接受不适用的默认方案。
第三步：按条目校对初稿，并形成评审版本
先确认功能范围没有扩大，再逐条核对业务规则、异常状态和验收条件。把“支持优惠券”补成适用条件与失效处理，把“支付失败后重试”拆成明确失败和结果未知两种情况。每处修改应能说明对应哪个用户任务或已确认规则。
评审前保留文档版本、修改日期、负责人和变更摘要。存在待决项时写明影响哪些条目；评审后将已确认结论更新到原条目，避免结论只停留在会议记录里。后续新增需求也沿用相同的功能编号与规则引用，读者才能看出本次具体改了什么。
交付前，沿着一条真实流程通读
从入口开始，按文档完成一次正常流程，再检查缺少数据、无权限、请求失败和返回修改的情况。只要出现“这里应该怎么办”的空白，就回到对应功能条目补规则或标注待决项。最后由开发、设计和测试各确认自己需要的信息与关联材料是否齐全，再将这一版作为后续实施和变更的基准。
