PRD驱动开发：我如何使用30多个PRD与AI代理协同交付

SaasMaker的RalphBlaster工作流能在45分钟内根据一行工单生成完整的拉取请求，开发者在实现过程中无需编写任何代码。¹

我尝试过这种模式。它确实有效。但它也会以演示视频未展示的方式失败。

TL;DR

在过去六个月中，我为AI代理任务编写了30多个PRD。这种模式在需求明确、验收标准清晰的任务中表现良好：CRUD端点、测试补充、遵循既定模式的UI组件。但在需求模糊、涉及新架构决策以及需要迭代式人工判断的场景中，它会失败。我的PRD模板从简单的用户故事格式演变为包含文件位置、测试预期、约束条件和明确的”禁止修改”列表的结构化文档。这一演变的原因是代理对模糊PRD的解读出乎意料。

我实际使用的工作流

第1步：创建工单

我用自然语言定义需要完成的事项。具体程度比我最初意识到的更为重要：

模糊（产生不可预测的结果）：

Add user preference saving to the settings page.

具体（产生可预测的结果）：

Add dark mode toggle to /settings. Persist to user_preferences
table (column: dark_mode, type: boolean, default: false).
Use existing SettingsForm component. Add toggle below the
notification section. No new dependencies.

第二个版本对代理施加了足够的约束，使输出符合预期。第一个版本则给我生成了一个带有新React组件、三个新npm包的设置页面，并使用了localStorage实现而非我所需的数据库持久化。

第2步：生成或编写PRD

我的/prd技能会将工单转换为包含用户故事、验收标准、文件位置和测试预期的结构化PRD。²一个典型的PRD如下所示：

## Story: Add dark mode toggle
**As a** user
**I want to** toggle dark mode from settings
**So that** I can read comfortably in low light

### Acceptance Criteria
- [ ] Toggle appears in SettingsForm below notifications
- [ ] Persists to user_preferences.dark_mode (boolean)
- [ ] Default: false (light mode)
- [ ] Toggle state reflects current DB value on page load

### Files to Modify
- app/routes/settings.py (add dark_mode to form handler)
- app/templates/settings.html (add toggle component)
- app/models/user.py (add dark_mode column if missing)

### Files NOT to Modify
- app/static/css/styles.css (dark mode CSS already exists)
- app/templates/base.html (already reads dark_mode class)

### Test Expectations
- Test toggle persists to database
- Test default value on new user
- Test toggle reflects current state on reload

“Files NOT to Modify”部分是模板演变中最重要的改进。没有这一部分，代理会热心地”改进”相关文件，引入我未请求也不需要的更改。

第3步：代理实现

代理在隔离的git worktree中工作，防止干扰我当前的分支：³

# Create isolated worktree for agent task
git worktree add ../worktrees/dark-mode -b feature/dark-mode

# Agent works in ../worktrees/dark-mode/
# I continue working in main workspace

# Review and cleanup after merge
git worktree remove ../worktrees/dark-mode

我的递归守卫会监控代理的派生行为。我的git安全守护程序会阻止代理强制推送或提交凭证。这些钩子自动运行，我在实现过程中无需监督代理。

第4步：审查

代理完成后会收到通知。我根据PRD验收标准审查差异。如果所有标准都通过，我就合并。否则，我会手动修复或使用更新的上下文重新启动代理。⁴

PRD驱动开发有效的场景

具有明确数据模型的CRUD端点。 PRD指定了模型、路由和响应格式。代理生成的样板代码与现有模式一致。

为现有代码添加测试。 “为app/content.py编写测试，覆盖load_post_by_slug的有效slug、无效slug和文件缺失场景”会产生有用的测试，因为函数已经存在且验收标准是客观的。

遵循既定模式的UI组件。 “使用与指南页面相同的标签模式，为博客列表页面添加分类筛选器”之所以有效，是因为代理可以参考现有模式。

具有明确schema的数据库迁移。 PRD指定了列名、类型、默认值和约束条件。代理生成迁移脚本并更新模型。

PRD驱动开发失败的场景

需求模糊。 “让博客更好”不是PRD。代理会做出更改，但不会符合您的意图，因为您的意图未被明确表达。

新架构决策。 当我需要设计协商系统的共识模型时，没有任何PRD能够捕捉这个决策。我需要探索选项、评估权衡并迭代设计。这需要我的协商技能，而非PRD。

性能优化。 “让页面加载更快”需要分析、测量和迭代调查。代理无法通过PRD来分析您的生产流量模式。

安全关键代码。 针对认证系统的PRD生成的代码只处理了正常路径。认证中的边缘情况（时序攻击、会话固定、非标准流程中的CSRF）需要PRD无法编码的人类专业知识。

我的PRD模板演变历程

版本1（第1个月）：简单用户故事

As a user, I want to save preferences so I can customize my experience.

问题： 太模糊。代理对存储机制、UI位置和范围做出了合理但错误的假设。

版本2（第2个月）：添加文件位置

## Story: Save preferences
### Files to Modify
- app/routes/settings.py
- app/templates/settings.html

问题： 有所改善，但代理仍会在未经许可的情况下”改进”相邻文件。

版本3（第4个月）：添加约束条件

## Story: Save preferences
### Files to Modify (only these)
- app/routes/settings.py
- app/templates/settings.html
### Constraints
- No new dependencies
- Use existing database models
- Do not modify CSS

问题： 当约束条件与训练数据中的”最佳实践”冲突时，代理有时会忽略约束。

版本4（当前版本）：明确排除项 + 测试预期

当前模板增加了”Files NOT to Modify”、明确的测试预期和验收标准复选框。此版本大约85%的情况下能产生可预测的结果。剩余15%需要使用澄清后的指令进行第二轮处理。⁵

30个PRD的模式库

在编写30多个PRD后，模式浮现：

创新型功能的成功率（50%）解释了为什么PRD驱动开发是我工作流的补充而非替代。一半的创新型工作需要PRD无法预先捕捉的迭代过程。

关键要点

面向独立开发者： - 从一种定义明确的PRD类型（CRUD、测试）开始，验证工作流后再扩展到复杂任务 - 在每个PRD中添加”Files NOT to Modify”；代理会热心地”改进”您未要求修改的代码 - 使用git worktree隔离代理工作；失败的代理运行的清理成本应该只需一个命令，而非一场git考古

面向工程管理者： - PRD质量决定代理输出质量；在扩大自主代理使用规模之前，先投资于PRD模板和审查流程 - 跟踪无需修改直接合并的比率来衡量工作流成熟度；随着PRD模板的演变，该比率应有所提升 - 新架构工作和安全关键代码不应通过PRD委派；将代理委派保留给定义明确、可重复的任务

常见问题

什么是PRD驱动开发？

PRD驱动开发是一种工作流：用产品需求文档（PRD）把任务定义得足够具体，让AI代理能够自主完成实现。PRD包含用户故事、验收标准、文件位置、约束条件和测试预期。代理在隔离的git worktree中工作，您可以同时推进其他事情。这种模式最适合定义明确、可重复的任务，例如CRUD端点、测试补充，以及遵循既定模式的UI组件。

在信任这套工作流之前，我该写多少个PRD？

先从一个您对预期产出把握较大的类别入手，写3到5个PRD，比如测试补充或数据库迁移。按我的经验，这些类别的成功率约为90%。确认模板能稳定产出可预测的结果后，再扩展到UI组件（成功率约85%）和缺陷修复（约80%）。新功能的成功率只有约50%，不应作为您进入PRD驱动开发的起点。

与Claude Code配合使用的PRD，采用什么格式最有效？

最有效的PRD格式包含五个部分：带验收标准复选框的用户故事、列出具体路径的”Files to Modify”清单、作为排除项的”Files NOT to Modify”清单、写明具体场景的测试预期，以及约束条件（不引入新依赖、沿用既有模式）。其中排除清单是我的模板中收益最大的一项改进，它能阻止代理”热心地”修改任务范围之外的代码。

PRD驱动开发能取代人工代码审查吗？

不能。PRD驱动开发取代的是实现环节，而非审查环节。每个完成的PRD在合并前仍需由人根据验收标准进行审查。在我的工作流中，代理完成后会收到通知，我会逐条标准审查差异。质量循环和独立的测试验证只是补充手段，无法取代人在架构契合度与正确性上的判断。

AI代理为什么有时会忽略PRD中的约束？

当约束与训练数据中的模式相冲突时，代理就会忽略它。即便PRD写明”不引入新依赖”，只要模型的训练数据把该任务与某个特定库关联在一起，模型仍可能装上那个库。解决办法是明确的排除项：”Files NOT to Modify”和”禁止安装”这类清单比正面表述的约束更有效，因为它们给了代理一条具体的边界，而不是一条笼统的准则。

参考文献