产品与需求工程师

开篇速查：推荐模型与工具

推荐模型：复杂规划用 GPT-5.6 Sol；跨大量会议、图像和长资料用 Kimi K3；低成本批量摘录用 DeepSeek V4 Flash。决策冲突须回到原文证据。
推荐产品：Kimi、ChatGPT、Claude（会议、长资料和需求讨论）；需要直接读取仓库、改文档或联动 Issue 时再用 Codex / Claude Code。 常用工具：Granola/会议转写、Notion/文档库、Linear/Jira、原文检索与表格工具。 核对日期：2026-08-04；上线前再查厂商官方模型列表并用内部评测集验证。

历史依据：从 8,276 条用户消息中命中 181 条，精确去重后 70 条。以下工作方式优先针对这些历史任务和返工问题。

1. 历史记录暴露的问题

• 明确验收标准：11/70（16%）。
• 明确要求验证：37/70（53%）。
• 提供失败/复现证据：18/70（26%）。
• 出现“功能不可用/报错”类返工：11 条。
• 出现“再检查/再测试”类返工：3 条。
• 出现“继续/不要停”但退出条件不清：7 条。

因此本岗位的模板会把验证、证据和退出条件写进首轮提示，而不是等失败后补充。

2. 什么时候使用

• 把一句想法整理为可开发需求
• 从会议、Word、聊天记录中提取需求
• 划分 MVP、P1、P2
• 为开发和测试建立同一套验收口径

3. 责任边界

• 负责用户、场景、流程、规则、范围和验收
• 区分事实、假设、建议和待确认项
• 不擅自决定具体框架、表结构和部署架构
• 不把会议中的讨论性设想全部当成立即需求

4. 开始前必须提供

• 原始需求、会议记录或业务资料
• 用户角色和实际工作流程
• 当前产品/系统能力
• 时间、预算、平台和合规约束
• 业务指标及数据口径

缺少信息时，先从仓库、配置、运行状态和现有资料中查证。只有会改变业务方向、造成生产影响或无法安全推断的内容才询问。

5. 完整可复制提示词

你是产品经理与需求工程师。本轮只整理需求和验收，不写实现代码。

原始资料：【粘贴聊天、会议、文档或现有功能】
目标用户：【角色】
业务目标：【结果与指标】
当前系统：【已经存在什么】
约束：【时间、预算、平台、合规】

请按以下顺序工作：
1. 建立“原文事实—你的解释—是否需要确认”表，不把推断当事实。
2. 提取用户角色、触发场景、目标、前置条件和完成结果。
3. 画出主流程，并补充失败、取消、重复、超时、权限和人工介入分支。
4. 建立业务规则、状态机、数据口径和关键不变量。
5. 划分 MVP/P1/P2；列出本版明确不做项。
6. 为每条 MVP 用户故事写 Given/When/Then 验收。
7. 给出架构、前端、后端、数据库、测试各自所需输入。

只询问会改变业务方向且无法从资料确认的问题。最后输出《需求基线》和《待确认项》，不要直接进入开发。

6. 推荐执行流程

1. 先逐条提取原始材料，不急着总结
2. 合并同义需求并保留来源
3. 标记冲突、缺失和无法验证的数字
4. 按用户价值和依赖划分版本
5. 把每条功能转成可观察验收
6. 请业务方只确认会改变方向的问题
7. 冻结本版范围并生成变更记录

每一步都要留下可复核产物：文件、命令、截图、请求、任务ID、数据库记录、指标或决策记录。

7. 标准交付物

• 需求事实表与冲突清单
• 角色—场景—任务地图
• 主流程、异常流程、权限流程
• 业务规则与状态机
• MVP/P1/P2及不做项
• Given/When/Then验收条件
• 交给架构、设计、开发、QA的输入包

8. 历史中常见失败写法

• 需求写成几十条功能清单，但没有用户路径
• 把愿景、讨论和确定需求混在一起
• 使用‘智能、完整、高级、好用’等不可测词
• 只有正常流程，没有退款、失败、权限和撤销
• 后续不断追加‘这个也要’，导致范围漂移

修正提示词

当前结果未满足验收。不要整体重做，先按证据定位差距。

原目标：【目标】
原验收：【可观察标准】
实际结果：【截图/日志/请求/任务ID/数据库记录】
差距：【逐条列出】
必须保持：【已正确部分和接口不变量】

请先复现并说明根因，再实施最小修正。修正后重复原验证，并给出修改前后证据。未通过的项继续保留为失败，不要用“基本完成”代替。

9. 完成检查清单

• 目标、范围和不做项没有漂移。
• 关键假设已用代码、运行或数据验证。
• 成功、失败、空、重复、超时和权限路径已处理。
• 交付物可由另一人独立打开或运行。
• 验收命令/路径已实际执行并保留证据。
• 未完成项、风险和数据限制被明确列出。
• 下游岗位得到接口、不变量、文件和验证入口。

10. 交接模板

岗位：产品与需求工程师
已完成：【内容】
证据：【文件、命令、截图、日志、任务ID、数据库记录或指标】
接口与不变量：【下游必须遵守】
配置/迁移影响：【内容】
未完成与风险：【内容、严重度、负责人】
下一岗位：【岗位】
下一步输入：【精确文件、环境、账号或任务】
禁止假设：【仍未知内容】

11. 实用组合技巧

• 会议直接变需求：让资料提取 Agent 把会议录音、Word 和聊天记录合并成“事实—决策—待确认—需求—验收”表，再交给业务方只确认冲突项。
• 自动生成版本计划：把全部需求交给优先级 Agent，按用户价值、依赖、风险和开发成本自动划分 MVP、P1、P2，并强制生成不做项。
• 需求自动变测试：每条用户故事生成 Given/When/Then 后，直接交给 QA Agent 转成测试矩阵，避免产品与测试使用不同口径。
• 用反馈反推需求缺口：将历史返工消息按“遗漏、理解偏差、不可用、视觉不符”分类，自动补充下一版需求模板。
• 原型先验证高风险流程：对于权限、支付、任务状态和异常恢复，先让原型 Agent 生成可点击流程，不急着做完整视觉。