多Agent需求规范生成与自动审查流

场景演示

产品经理最头疼的循环：写了 PRD → 没人认真看 → 开发按自己理解做 → 上线发现需求对不上 → 返工。

根本原因不是大家不配合，而是：

• PRD 版本混乱，不知道哪个是最新
• 评审靠线下，口径传着传着就失真
• 缺少自动追踪，开发节奏对产品黑盒
• 验收无依据，产品觉得做了但研发说没做

多Agent需求规范生成与自动审查流把这个问题彻底自动化：

需求录入 → Agent自动生成结构化PRD → 评审协同 → 版本锁定 → 开发任务分解 → 进度追踪 → 验收确认
     ↑                                                                                  ↓
     ←←←←←←←←←←←←←← 验收异议自动回流 → 产品确认 ←←←←←←←←←←←←←←←←

一个真实场景：

产品经理在飞书发了一条需求："用户反馈登录太慢，要优化。"

小虫立即自动生成：《登录性能优化 PRD v1.0》，包含：背景、目标、用户故事、验收标准、技术约束、优先级、预计工时。

同时通知相关研发负责人，5分钟内各方在线确认，直接进入开发任务拆分阶段。

Step by Step

Step 0：初始化飞书多维表格（只需一次）

在飞书知识库创建一个多维表格，命名为「需求规范中枢」，包含以下视图：

字段设计：

• 需求标题（文本）
• 原始需求（长文本）
• PRD版本（文本，自动更新）
• 评审状态（单选：待评审/通过/需修改）
• 优先级（单选：P0/P1/P2/P3）
• 研发负责人（用户）
• 产品负责人（用户）
• 预计工时（数字）
• 截止日期（日期）
• 验收意见（长文本）

Step 1：录入需求（触发）

产品经理在飞书文档写一条需求描述，格式随意，例如：

登录页面加载超过3秒，用户流失严重，希望优化到1.5秒以内。

然后在多维表格新建一行，填入「需求标题」和「原始需求」。

Step 2：Agent自动生成结构化PRD

当多维表格有新行时，触发小虫执行以下工作：

1. 需求理解 Agent：读取原始需求，提取核心问题、用户故事、验收标准
2. PRD生成 Agent：将理解结果转换为标准 PRD 格式
3. 合规审查 Agent：检查 PRD 是否完整、是否存在模糊条款、是否符合团队规范
4. 版本写入 Agent：将 PRD 内容写入飞书文档，生成规范链接

生成后的 PRD 结构：

# 【PRD】登录性能优化

## 1. 背景与问题
- 问题描述：当前登录页面加载时间 >3s，用户反馈体验差
- 数据支撑：[埋点数据截图]
- 影响范围：登录转化率下降约12%

## 2. 目标
- 短期：首屏加载时间从3s降至1.5s
- 长期：建立性能基准，后续功能不得劣化

## 3. 用户故事
| 作为... | 我希望... | 以便... | 优先级 |
|---------|----------|--------|--------|
| 登录用户 | 3秒内完成登录 | 减少等待焦虑 | P0 |
| 产品经理 | 有量化指标 | 验收有据可依 | P1 |

## 4. 验收标准（可测试）
- [ ] Lighthouse 性能分数 ≥ 90
- [ ] 登录成功率达 99.9%
- [ ] TTI（交互时间）≤ 1.5s
- [ ] 回归测试：无现有功能退化

## 5. 技术约束
- 不得引入新的第三方追踪脚本
- 必须在 Safari 15+ 下通过
- 预算：0（纯优化，无新增采购）

## 6. 预计工时与排期
- 研发：4h（图片懒加载 + CDN优化）
- 测试：2h（性能回归）
- 上线窗口：本周五

## 7. 评审记录
- 产品负责人：✅ 张三（2026-05-19）
- 研发负责人：⏳ 待确认
- 测试负责人：⏳ 待确认

Step 3：评审协同与版本锁定

PRD 生成后，系统自动：

1. 在飞书创建评审群，把相关研发/测试/产品负责人拉进来
2. 发送 PRD 链接 + 评审要点摘要
3. 每方确认后，多维表格「评审状态」更新

评审状态流转：

待评审 →（所有人确认）→ 通过
待评审 →（任意一方提出异议）→ 需修改 → 重新生成 → 待评审

版本锁定规则：

• 只有「评审状态 = 通过」时，PRD 文档才标记为「正式版」
• 后续任何修改自动产生新版本（如 v1.1），并记录修改说明
• 历史版本全部保留，可追溯

Step 4：开发任务自动分解与追踪

PRD 确认后，系统自动：

1. 读取「预计工时」和「截止日期」
2. 在多维表格创建对应的开发任务子行（子表）
3. 每条任务关联负责人，发送飞书提醒
4. 每天定时巡检：在开发中的任务若超过截止日期前一天仍未更新 → 自动提醒

Step 5：验收确认与闭环

研发完成，在任务行备注「开发完成」：

1. 测试 Agent 自动验证：对照 PRD 的验收标准逐条核验
2. 验收通过 → 多维表格状态流转至「已上线」，PRD 标记闭环
3. 验收异议 → 自动通知产品经理，产品可在 PRD 评论区提出异议，研发收到后处理

可复制提示词

触发PRD生成的提示词

请将以下原始需求转换为结构化PRD，输出标准格式文档：

需求内容：
{粘贴需求文本}

要求：
1. 包含：背景、用户故事、验收标准、技术约束、工时估计、评审记录
2. 验收标准必须可量化、可测试
3. 用户故事用「作为/我希望/以便」格式
4. 评审记录留空，待相关方填写
5. 输出为飞书可识别的格式（Markdown）

触发验收核验的提示词

请对照以下PRD验收标准，对开发完成情况进行核验：

PRD文档：{链接}
验收标准：
{逐条列出}

请逐条判断：
- [ ] 标准1：是否达成？说明核验方法和结果
- [ ] 标准2：是否达成？说明核验方法和结果

如有问题，列出具体缺陷和建议修复方案。

触发需求评审通知的提示词

请在飞书创建评审群并发送以下内容：

标题：PRD评审邀请 - {需求标题}

内容：
产品经理已提交《{需求标题}》PRD，请各方确认。

📋 PRD文档：{链接}

评审要点：
1. {验收标准1} - 请确认技术可行性
2. {验收标准2} - 请确认测试覆盖方案

⏰ 请在{日期}前在PRD评论区回复「✅确认」或提出异议。

相关方：@{研发负责人} @{测试负责人} @{产品负责人}

使用的Skills

价值与注意事项

核心价值

1. 消灭「写了没人看」：PRD 由 Agent 自动生成结构化版本，阅读体验好，各方5分钟内能 get 到重点
2. 评审有记录：所有评审意见在文档内可见，不靠线下口头确认，事后可追溯
3. 开发节奏透明：多维表格实时展示状态，产品不再追着研发问「做到哪了」
4. 验收有据可依：PRD 中的验收标准就是验收依据，不再扯皮「做了还是没做」
5. 知识自动沉淀：每个需求的处理过程形成完整档案，下次遇到类似需求可快速复用

注意事项

1. 需求不能太模糊：Agent 生成质量依赖输入质量，如果原始需求只有「登录慢，优化一下」而无数据支撑，生成的验收标准会缺乏量化依据。建议配合「5W1H」格式引导产品补充背景数据。
2. 评审不能流于形式：如果评审方习惯不读文档直接点通过，这个流程就失效。建议设立规则：评审意见必须包含至少一条有效反馈或明确「确认无异议」。
3. 技术约束要现实：PRD 中的「技术约束」需要研发真实参与填写，避免费了半天劲做的方案最后发现违反技术红线。
4. 不要追求完美再上线：PRD 是协作工具，不是论文。先跑通流程，再逐步完善模板。
5. 维护多维表格需要权限：确保 Agent 有足够的飞书多维表格读写权限，否则状态流转无法自动执行。

本文隶属于「OpenClaw 有价值应用」专栏，记录真实工作流实践。