什么是Prd
Prd 是一个围绕产品需求文档编排的工具，重点不是写一份笼统的说明，而是把单个功能拆成可执行、可验证、可追踪的 PRD。它面向功能规划阶段使用，要求把需求整理成一组结构化用户故事，每条故事都带有明确描述、验收标准、优先级和完成状态。对于既要和开发协作、又希望让 AI 智能体参与实现规划的团队来说，这种写法比传统长篇需求文档更直接：读者一眼就能看出要做什么、先做什么，以及怎样算完成。
从证据包给出的定义看，Prd 强调三件事。第一，功能要被拆成小而独立的用户故事，而不是用一句“做完整个模块”概括。第二，每条故事都必须有可验证的验收标准，避免“工作正常”“体验更好”这类难以判断的表述。第三，任务顺序要遵守依赖关系，通常从数据结构或数据库变更开始，再到后端逻辑，最后才是界面层与汇总视图。这样整理出来的 PRD，本质上已经接近一份可执行计划，而不只是产品和研发之间的沟通材料。
Prd 的信息载体是项目中的 prd.json 文件。这个文件会记录项目名、功能对应分支、功能简介，以及一组 userStories。每条故事包含唯一编号、标题、采用“作为某类用户，我想要……”模式的描述、验收标准、执行顺序、完成状态和补充备注。工具还鼓励在执行过程中把 passes 从 false 更新为 true，并在 notes 中写入运行时观察，例如迁移时采用了什么处理方式。这使 PRD 不只是需求输入，也承担了部分执行跟踪的职责，适合在功能从规划进入落地的过程中持续维护。
核心功能特点
- 把功能拆成小而独立的用户故事，避免需求粒度过大难以执行
- 为每条故事定义可验证的验收标准，并明确要求用结果可检查的表述
- 按依赖关系安排任务顺序，通常遵循 schema→backend→UI 的实施链路
- 通过 prd.json 统一记录项目、分支、故事优先级、完成状态与运行备注
- 支持将 passes 状态持续更新，用同一份文档追踪未完成与已完成事项
适用场景
如果团队正在规划一个新功能，但又不希望需求文档停留在概念层，Prd 比较适合用在这个阶段。比如要给现有产品增加任务优先级、筛选器或新的服务端动作，团队可以先把改动拆成若干条用户故事：先改数据库字段和迁移，再补后端逻辑，最后接上界面组件。这样做的价值在于，需求讨论结束后，研发拿到的已经不是一段抽象描述，而是一组带顺序和验收条件的实施单元，产品、工程和测试对“完成”的理解也更容易对齐。
它也适合需要把工作分配给 AI 智能体或人类开发者的场景。证据包明确提到，Prd 可用于为 AI 智能体或人工开发者规划功能实现，而其中“每条故事应能在一个上下文窗口内完成”的原则，正是面向这类执行方式设计的。对于 AI 来说，过大的任务会让上下文失控；对于人类开发者来说，过大的需求同样会模糊边界、拉长反馈周期。将工作切成大小合适的故事后，不论交给谁执行，拆解、验证和回报都会更顺畅。
在持续跟进进度时，Prd 也有比较实际的用处。很多团队的需求文档在评审后就被搁置，真正的状态散落在代码提交、聊天记录和看板里。Prd 的做法是直接在同一份文件里维护 passes 状态，并允许添加 notes 记录执行中的观察。这种方式尤其适合功能开发周期不长、但需要频繁确认“哪些故事已完成、哪些还卡住”的项目。它并不是全面项目管理系统，却很适合承担轻量级、结构化的功能规划与进度同步角色。
另外，当团队希望提高验收讨论的清晰度时，这类工具也很有价值。Prd 反复强调验收标准必须可验证，例如字段默认值、下拉选项内容、类型检查通过等，而不是写成主观判断。对产品经理、测试和开发来说，这意味着需求条目从一开始就带有交付边界，后续不必不断解释“到底算不算完成”。因此，它更适合那些希望把功能需求写得更像执行说明书，而不是写成长篇背景材料的团队与项目。