AI Dev Tasks 实战：用 create-prd.md 引导 AI 生成高质量 PRD（产品需求文档）-平芜编程栈

提示工程
开发工具

【免费下载链接】ai-dev-tasks

A simple task management system for managing AI dev agents

项目地址：https://gitcode.com/GitHub_Trending/ai/ai-dev-tasks

本文基于开源仓库 AI Dev Tasks 中的 create-prd.md 编写，系统讲解如何利用该规则文件，让 AI 从一句话需求出发，通过"澄清问题 → 生成 PRD → 保存到 /tasks"的标准化流程产出可落地、面向初级开发者、结构完整的产品需求文档（PRD）。读完本文，你将掌握 create-prd.md 的完整调用方式、九章节 PRD 骨架、澄清问题的提问技巧与格式规范，并能与仓库中的 generate-tasks.md 衔接，把 PRD 进一步拆解为逐步实施的任务清单。

为什么需要一份 PRD？——AI 辅助开发的结构化起点

在 AI 编程助手（如 Amp、Claude Code、Windsurf 等）日益普及的今天，直接向 AI 抛出一大段"帮我做个功能"的请求，往往得到的是不可控、难调试、甚至过度复杂的代码。AI Dev Tasks 仓库的核心理念，就是通过结构化工作流解决这一问题，其完整闭环为三步（见 README.md）：

定义范围（Defining Scope）：用产品需求文档（PRD）明确"要构建什么"；
详细规划（Detailed Planning）：把 PRD 拆解为细粒度的可执行任务清单；
迭代实施（Iterative Implementation）：引导 AI 一次只处理一个任务，逐个审查与批准变更。

create-prd.md正是这个工作流的第一块基石——它本身不是 PRD 模板的静态文档，而是一份给 AI 的规则提示词（Rule Prompt）。你把这份文件"喂"给 AI 后，AI 会严格按照其中定义的流程、结构与输出规范来为你撰写 PRD，而不是自由发挥。

create-prd.md 的定位与设计目标

从文档标题# Rule: Generating a Product Requirements Document (PRD)可以看出，这是一份"规则文件"。它的目标（Goal）是：

引导 AI 助手基于用户的初始提示（initial user prompt），创建一份 Markdown 格式、清晰、可执行（clear, actionable）的 PRD，且该 PRD 应适合初级开发者理解并据此实现功能。

关键词有三个：清晰（clear）、可执行（actionable）、适合初级开发者（suitable for a junior developer）。这决定了 create-prd.md 生成的 PRD 不会是一份含糊的产品愿景陈述，而是一份可以直接进入开发环节的工程蓝图。它聚焦回答"做什么（what）"与"为什么做（why）"，而把"怎么做（how）"留给开发者去实现。

四步工作流：从一句话需求到完整 PRD

create-prd.md 定义的核心流程（Process）包含四个步骤：

第一步：接收初始提示（Receive Initial Prompt）

用户向 AI 提供对新功能或新需求的简要描述。这一步通常结合 README 中建议的调用方式完成：在你的 AI 工具中引用create-prd.md文件并描述功能，例如：

Use @create-prd.md Here's the feature I want to build: [Describe your feature in detail] Reference these files to help you: [Optional: @file1.py @file2.ts]

需要注意的是，这里描述得越具体，后续澄清成本就越低；README 的"Tips for Success"也特别强调：Be Specific（越具体的初始描述与说明，AI 的输出质量越高）。

第二步：提出澄清问题（Ask Clarifying Questions）

在动笔写 PRD 之前，AI必须先就理解上的关键缺口提问。规则对提问数量有硬性约束：只问 3～5 个最关键的澄清问题，且要以"字母/数字列表"形式给出选项，方便用户直接用类似1A, 2C, 3B的答案快速回复。这一步的目标是搞清楚功能的"What"和"Why"，而不是"How"（后者由开发者解决）。

第三步：生成 PRD（Generate PRD）

基于初始提示 + 用户对澄清问题的答复，AI 按照下文所述的九章节结构生成 PRD。

第四步：保存 PRD（Save PRD）

将生成文档保存为prd-[feature-name].md，存放于/tasks目录下。例如，若功能涉及用户资料编辑，则输出文件名为prd-user-profile-editing.md。注意：这里的/tasks是使用流程中的运行时目录（由使用者自行创建/指定），并非本仓库内自带的目录。

澄清问题的艺术：只问最关键的问题

澄清问题是 create-prd.md 中最具实战价值的设计之一，它把"AI 与人对齐需求"这一环节制度化。规则给出三条明确准则：

什么时候才需要提问

重要提示：只有当答案无法从初始提示中合理推断出来时，才需要提问。优先提出会显著影响 PRD 清晰度的问题。

也就是说，AI 不应机械地每次都问满 3～5 个问题；如果初始描述已经足够明确，应当直接进入生成环节，避免浪费用户时间。

四大高频澄清领域

当初始提示存在歧义或缺失关键上下文时，可以围绕以下常见领域提问：

领域	触发条件	示例问题
Problem/Goal（问题/目标）	需求不明确时	"这个功能为用户解决了什么问题？"
Core Functionality（核心功能）	功能描述含糊时	"用户应该能执行哪些关键操作？"
Scope/Boundaries（范围/边界）	需求过于宽泛时	"有哪些事情是这个功能不应该做的？"
Success Criteria（成功标准）	未说明时	"我们如何判断这个功能成功实现？"

提问的格式化要求

所有问题必须编号（1、2、3……）；
每个问题的选项用 A、B、C、D 等字母列出，便于用户引用；
让用户可以用1A, 2C, 3B这样的组合简单作答。

完整的提问示例（文档原样）

create-prd.md 给出了一个可直接套用的格式范例：

1. What is the primary goal of this feature? A. Improve user onboarding experience B. Increase user retention C. Reduce support burden D. Generate additional revenue 2. Who is the target user for this feature? A. New users only B. Existing users only C. All users D. Admin users only 3. What is the expected timeline for this feature? A. Urgent (1-2 weeks) B. High priority (3-4 weeks) C. Standard (1-2 months) D. Future consideration (3+ months)

这套格式的价值在于：用户无需打字描述，只需回复"1A、2C、3B"即可完成澄清，大幅降低交互成本——这正是面向 AI 工作流的提问设计要点。

PRD 标准结构：九个章节详解

create-prd.md 规定，生成的 PRD 必须包含以下九个章节。这是整份文档的核心骨架，下面逐一展开说明并补充撰写要点：

1. Introduction / Overview（引言与概述）

简要描述该功能及其解决的问题，并陈述目标。这是 PRD 的"电梯演讲"，让任何读者（包括初级开发者）在 30 秒内理解"我们为什么做这个东西"。

2. Goals（目标）

列出本功能具体、可衡量的目标（specific, measurable objectives）。目标应可量化、可验证，避免空泛表述。

3. User Stories（用户故事）

以用户视角描述功能的用法与收益，即"谁在什么场景下，想要什么结果"。用户故事让需求从功能清单变成有温度的使用叙事，帮助开发者理解功能背后的用户动机。

4. Functional Requirements（功能需求）

列出功能必须具备的具体功能点。规则强调两点：使用清晰、简洁的语言（例如 "The system must allow users to upload a profile picture."），并且对这些需求进行编号。编号后的需求（如 FR-1、FR-2……）可以在后续任务拆解时被精确引用。

5. Non-Goals (Out of Scope)（非目标 / 范围外）

明确说明这个功能不会包含什么，以管理范围。这是最容易被省略却最重要的章节——它划定了边界，防止实现过程中范围蔓延（scope creep）。

6. Design Considerations（设计考量，可选）

如果适用，可链接到原型图（mockups）、描述 UI/UX 要求，或提及相关的组件/样式。非必需章节，但涉及界面类功能时建议补充。

7. Technical Considerations（技术考量，可选）

提及已知的技术约束、依赖或建议，例如 "Should integrate with the existing Auth module"（应集成现有认证模块）。这为开发者提供了实现层面的初步方向。

8. Success Metrics（成功指标）

定义如何衡量该功能的成功，例如 "Increase user engagement by 10%"（用户参与度提升 10%）、"Reduce support tickets related to X"（减少与 X 相关的支持工单）。成功指标把 Goals 落到实处，是验收的重要依据。

9. Open Questions（待解决问题）

列出剩余的问题或需要进一步澄清的领域。PRD 不必假装一切都已确定——把开放问题显式记录下来，反而为后续迭代留出明确入口。

面向初级开发者的写作准则

create-prd.md 明确假设 PRD 的主要读者是初级开发者（junior developer），因此写作时要求：

需求表述明确、无歧义（explicit, unambiguous）；
尽量避免专业行话（avoid jargon where possible）；
提供足够的细节，使其能理解功能的目的与核心逻辑。

这意味着撰写 PRD 时应多用直白的"系统必须允许用户……"式陈述，而不是抽象的产品语言。这份"读者画像"也提醒使用者：当你的 PRD 连初级开发者都能无障碍读懂时，它同样能被 AI 顺畅地翻译为代码任务。

输出规范：格式、命名与存放位置

create-prd.md 的输出章节（Output）规定了三要素：

要素	规定
格式（Format）	Markdown（`.md`）
位置（Location）	`/tasks/`目录
文件名（Filename）	`prd-[feature-name].md`

统一的命名与存放约定让整个工作流可预期：后续生成任务清单时，使用者可以直接在提示中引用这个 PRD 文件（如@prd-user-profile-editing.md），AI 即可准确读取需求。

三条最终指令：PRD 生成后的行动边界

create-prd.md 在结尾给出三条"最终指令"（Final instructions），约束 AI 在生成 PRD 后的行为：

不要开始实现 PRD（Do NOT start implementing the PRD）——PRD 只是蓝图，实现属于后续任务拆解与迭代实施阶段；
务必向用户提出澄清问题（Make sure to ask the user clarifying questions）；
结合用户的澄清答复完善 PRD（Take the user's answers to the clarifying questions and improve the PRD）。

这三条指令体现了整个工作流的边界意识：AI 的角色是"需求分析师 + 文档撰写者"，而不是越权实现者；同时澄清与迭代贯穿始终，PRD 是可修改的活文档。

与 generate-tasks.md 的衔接：PRD 如何驱动后续任务拆解

PRD 的终点是任务拆解的起点。仓库中的 generate-tasks.md 正是为衔接而设计：它以 PRD（或用户需求/既有文档）为输入，生成带层级结构的任务清单（如0.0 Create feature branch、1.x父任务、1.x.y子任务），输出为/tasks/tasks-[feature-name].md。

README 给出的标准衔接方式是：

Now take @MyFeature-PRD.md and create tasks using @generate-tasks.md

其中@MyFeature-PRD.md替换为第一步生成的 PRD 实际文件名。这意味着，create-prd.md 生成的九章节 PRD（尤其是编号后的功能需求）会直接影响任务拆解的质量——功能需求写得越清晰、越可执行，generate-tasks.md 越容易产出精确、可逐一勾选（- [ ]→- [x]）的细粒度任务。可以说，PRD 的质量决定了整个 AI 实施流水线的上限。

在 AI 工具中的实际调用方式与注意事项

综合 README 的完整工作流与 create-prd.md 的内容，推荐的实际用法如下：

准备文件：将本仓库的create-prd.md放到你的项目中（或 AI 工具可访问的位置）；
发起 PRD 创建：在 AI 工具中执行Use @create-prd.md并附上功能描述，可选择性引用相关源码文件辅助理解；
回答澄清问题：AI 会给出 3～5 个编号 + 字母选项的问题，用1A, 2C, 3B式回答即可；
获取并检查 PRD：AI 按九章节结构生成prd-[feature-name].md，存放于/tasks/；
进入下一阶段：用generate-tasks.md将 PRD 拆解为任务清单，逐步实施并勾选完成。

使用注意事项：

描述要具体：初始功能描述越详细，澄清成本越低、PRD 质量越高；
文件名要准确标注：在后续任务生成时，务必正确引用 PRD 文件名（如@prd-user-profile-editing.md），避免 AI 引用错误文档；
可自由适配：README 说明使用者可以按需修改.md内的提示词，以适应自身编码风格与团队规范；若 AI 在某次任务上表现不佳，可尝试改写初始描述或进一步细化需求；
PRD 是过程文档：最终指令明确禁止 AI 在 PRD 阶段直接动手实现，使用者应遵循"PRD → 任务清单 → 逐个实施"的顺序，在每个小步骤上审查 AI 产出，以保证质量与可控性。

从"一句话需求"到"九章节 PRD"，再到"可勾选的任务清单"，create-prd.md 用一份规则文件把 AI 辅助开发中最容易失控的"需求定义"环节变得清晰、可重复、可验证——这正是结构化 AI 开发工作流的价值所在。