用户研究
优先试点这一场景的目标是把访谈、问卷、反馈和行为数据整理成用户画像、任务、痛点和证据。
- 输入
- 访谈、问卷、反馈和行为数据
- 输出
- 用户画像、任务、痛点和证据
- 验收
- 检查需求整理时间、缺项率、版本同步及时率
- 边界
- 样本不代表全部用户,个人信息需保护

产品经理可以把AI智能体放进调研、需求、文档和复盘链路,重点提升信息完整性。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 用户研究 | 访谈、问卷、反馈和行为数据 | 用户画像、任务、痛点和证据 | 样本不代表全部用户,个人信息需保护 |
| 需求澄清 | 一句话想法、业务目标、约束 | 问题树、假设、待确认项和验收条件 | AI不能替干系人确认真实需求 |
| PRD初稿 | 已确认需求、流程、规则、指标 | PRD结构、用户故事和异常流程 | 范围、优先级和承诺由产品负责人确定 |
| 原型与页面说明 | 用户流程、组件、品牌规范 | 低保真原型、页面说明和交互清单 | 可用性需真实用户测试 |
| 需求优先级 | 价值、成本、风险、依赖和数据 | 评分矩阵和不同假设结果 | 模型不能替代资源与战略取舍 |
| 反馈归类 | 工单、评论、访谈和标签 | 主题、频次、严重度和原文证据 | 频次不等于价值,保留原始语境 |
| 竞品分析 | 产品、功能、价格、公开资料 | 功能矩阵、流程差异和验证清单 | 公开资料可能过期,关键能力需实测 |
| 产品数据复盘 | 使用、转化、留存和实验数据 | 漏斗、分群、异常和下一步实验 | 统计显著性和埋点质量需核验 |
| 产品文档同步 | 会议变更、PRD、版本记录 | 更新建议、差异和影响范围 | 正式版本和发布说明由负责人确认 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把访谈、问卷、反馈和行为数据整理成用户画像、任务、痛点和证据。

这一场景的目标是把一句话想法、业务目标、约束整理成问题树、假设、待确认项和验收条件。

这一场景的目标是把已确认需求、流程、规则、指标整理成PRD结构、用户故事和异常流程。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“需求澄清”。它所需输入是一句话想法、业务目标、约束,目标交付是问题树、假设、待确认项和验收条件。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:需求整理时间、缺项率、版本同步及时率。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。