产品经理
真实工作流
产品经理场景不是“AI 替你决定产品方向”，而是把零散需求、进度和风险整理成团队能评审和执行的材料。
| 维度 | 真实情况 |
|---|---|
| 触发点 | PRD 评审、Sprint 计划会、站会前进度汇总、上线协调 |
| 现有材料 | 需求背景、用户反馈、PRD 模板、任务列表、研发进度和阻塞项 |
| 卡点 | 用户故事不清，验收标准模糊，多个项目争资源，风险发现太晚 |
| DesireCore 介入 | 产品经理智能体生成 PRD 初稿、拆验收标准、汇总进度、标出资源冲突 |
| 验收结果 | PM 拿到可进入评审的文档和风险清单，再确认优先级、排期和取舍 |
推荐智能体
产品经理 -- 适合需求文档、迭代计划、进度摘要、资源冲突分析和风险清单整理。
前期教学：让智能体掌握你的产品流程
每个团队的迭代流程和文档规范都不同。先教清楚模板、优先级定义和验收标准，后续输出会更容易进入评审。
教规则
你: 教你我们团队做产品的几个规范：
[上传 PRD模板_v3.docx]
1. 用户故事格式："作为[角色]，我希望[功能]，以便[价值]"（强制）
2. 优先级定义：P0 = 本迭代必须完成，P1 = 尽量完成，P2 = 下迭代（强制）
3. 迭代节奏：双周迭代，周一计划会、周五回顾会（偏好）
4. 验收标准：每个需求必须有可测试的验收条件，不能写"优化体验"这种模糊描述（强制）
产品经理: 📝 学到了新内容
来源：PRD模板_v3.docx + 本次说明
类型：规则（产品流程规范）
层级：强制 × 3 项，偏好 × 1 项
我的理解：
写 PRD 时用上传的模板格式。用户故事必须按"作为...我希望
...以便..."句式。优先级分 P0/P1/P2 三级。每个需求必须
附可测试的验收标准。迭代按双周节奏排期。
[✓ 正确] [✎ 修改] [✗ 撤销]
你: [✓ 正确]
教学完成后，产品经理智能体已掌握你的 PRD 规范和迭代流程。之后提供需求时，它会按模板生成 PRD 初稿。
完整对话示例
你: Sprint-7 进度怎么样了？
产品经理: Sprint-7 进度报告
周期：6月3日 至 6月14日（第 6 个工作日）
总体进度：85%（时间进度 60%，进度超前）
任务完成情况
- 已完成：18/24 个（75%）
- 进行中：4 个
- 待开始：2 个
各成员进度
张三（前端）：已全部完成 6/6
李四（后端）：进行中 4/5，剩余"认证接口优化"
王五（后端）：进行中 3/5，"订单模块重构"预计 2 天
赵六（测试）：完成 4/6，集成测试等待开发完成
风险预警
- 订单模块重构进度略慢，建议张三协助王五
- 集成测试依赖后端任务，需优先保障
预计完成率：95%
建议：将 1 个低优先级任务移至下个 Sprint
你: 帮我写一份"用户标签系统"的需求文档。
产品经理: 用户标签系统 -- 需求文档
一、需求背景
运营团队需要对用户进行精细化分群，目前只能通过
手动筛选，效率低且无法实时更新...
二、核心功能
1. 标签创建与管理
2. 自动标签规则引擎
3. 用户分群查询
4. 标签数据看板
三、用户故事
作为运营人员，我希望能够创建自定义标签并设定
自动打标规则，以便自动化用户分群...
四、验收标准
...
📋 回执摘要
引用的规则：用户故事格式 · P0/P1/P2 优先级 · 验收标准要求
引用的模板：PRD模板_v3
均来自你的教学（上周）✓
关键步骤
- 界定问题和目标 -- 写清用户问题、业务目标、成功指标和非目标范围
- 拆用户故事 -- 按角色、行为和价值拆成可开发的用户故事，而不是堆功能点
- 定义验收标准 -- 每个需求都要有可测试条件、边界情况和埋点/数据要求
- 同步研发约束 -- 把依赖系统、资源冲突、技术风险和上线窗口写进计划
- 跟踪迭代风险 -- 每日看完成项、阻塞项、范围变更和延期风险
最终成果
进度报告、PRD 初稿、用户故事、验收标准、资源分配建议和风险清单。正式排期前，需要结合团队实际产能和业务优先级再确认。
最佳实践
- 每日站会前让智能体生成进度摘要，先看清完成项、阻塞项和待决策项
- 写需求文档时先描述业务场景和用户痛点，智能体会自动拆解为用户故事和验收标准
- 多项目并行时，让智能体分析资源冲突并给出可选分配方案
- 季度规划有多个功能需求时，可以让产品经理智能体分别生成 PRD 初稿，再统一做优先级评审
- PRD 不是越长越好，关键是让研发、测试、设计和业务对“完成标准”有同一理解