产品 · 岗位场景库

岗位依据

岗位依据与数据 · WorkBuddy · 产品岗位场景库

5 个子角色为什么这样切，依据在哪

公开的产品经理晋升体系写的是「产品助理→产品经理→高级→总监」，按产品/策略/数据/平台四个方向横切。但中小企业真实招聘 JD 里写的是另一回事：「负责产品规划、原型设计、UI 输出、需求文档、项目跟进、客户培训」一人全包——20 人公司连 UI 美工都算进 JD。SaaS 产品经理的自述更直接：60% 以上时间在跟客户沟通，画原型写文档只是「附带工作」。连用 Jira 的团队里，产品经理也私下维护着一张影子 Excel —— 不是落后，是对重流程工具的理性反抗。

所以这套场景库按「五张面具各自背的锅」切分，而不是按大厂职能表：需求进不来、查不到的锅（需求归集）、文档被喷、评审被锤的锅（文档评审）、变更失控、指令失真的锅（变更与指令）、上线事故的锅（验收与发布）、客户扯皮、定制拖垮的锅（客户之声）—— 五类锅在中小企业里是同一个人背的，区别只在锅什么时候炸、炸的时候谁在场。

需求归集

Requirement Intake

让散在微信截图、客服工单、邮件和老板语音里的需求第一次被完整看见 —— 归集有结构、重复有合并建议、每条能回溯到「谁提的、当时原话」

3 个场景

这个子角色为什么真实存在：销售带回的需求有结构性失真：客户随口一提、销售为签单先答应 —— 「研发一做就翻车」的链路从入口就歪了需求池的欠账是普遍事实：「进来了没人清、历史需求没人敢删」；连用 Jira 的团队也私下维护影子 Excel —— 17 个必填字段的表单没人自愿填老板突袭式提问（「那个导出功能后来怎么了」）是产品经理的高频噩梦 —— 没有回溯档案，每次提问都是一次翻聊天记录的考古产品经理 60% 以上时间在跟客户沟通、画原型写文档只是附带工作 —— 需求归集的体力活（转写、查重、补字段）从来没有整块时间做

公开来源：销售带回的需求为什么研发一做就翻车：客户传递给销售的需求不一定表达到位，销售收集的不一定全面——「销售的第一目标是签单，而不是做深度的需求调研」，客户随口一提、销售为拿下订单先一口答应需求池的普遍欠账：「需求进来了没人清、历史需求没人敢删」—— 被拒需求因新商机复活是 B 端常态，但删一条历史需求有商业与政治双重风险需求来源回溯的价值判例：蓝点案例的核心即「任何需求可回查谁提的、什么场景、当时原话」—— 老板突袭式提问（「王工那个导出功能后来怎么了」）是产品经理的真实高频场景SaaS 产品经理日记自述：一天开 3 个客户会、回复 4-5 个人追问、给研发补规则 —— 「跟客户沟通需求和解决方案是主要工作（60% 以上时间），画原型、写文档是附带工作（30%）」

它实际在用的数据：销售/客户微信截图（原图扔进来，不要求先转文字）客服工单导出（Excel 原样）客户与实施顾问的邮件往来需求池现状导出（Excel/飞书表格/禅道均可）

关键字段与口径：归集结果：结构化需求条目（背景/来源/场景/频次）+ 重复簇合并建议 —— 人确认后人池清淤体

检：归档建议 + 复活建议 + 重复簇 —— 不自动删、人拍板

本组场景：

• RQ-01 多渠道需求归集结构化 · 优先级 8.3
• RQ-02 需求池清淤体检 · 优先级 8.0

升为客户真实案例还缺什么：需要客户提供：微信聊天记录、工单导出、需求池现状 —— 全是现成文件。不要求换工具、不要求先填表单。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

文档与评审

Docs & Review

让评审会不再是产品经理的单方面汇报 —— 找茬预演在会前抓漏洞、一致性终审在提交前抓矛盾、评审材料提前凑齐，研发的每个质疑都有出处可答

3 个场景

这个子角色为什么真实存在：评审会形式化是结构病：单方面汇报、其他角色事后才提异议、开发阶段频繁返工 ——PRD 缺验收标准时研发估算偏差超 50%AI 写 PRD 的翻车不在质量在「虚假精确」：把没推敲的假设填成详细规则，返工两周、延期三个月的判例在案 —— AI 该做的是找茬与一致性检查，不是生成评审会的高压时刻：「研发问这个需求哪个客户要的，PM 翻半天聊天记录」—— 材料凑齐的活恰是取数型 Agent 的独占区

公开来源：需求评审的真实痛点：评审会变成产品经理单方面汇报、其他角色沉默或事后才提异议，导致开发阶段频繁返工；许多 PRD 缺少验收标准与非功能性要求，致使研发估算偏差超 50%AI 写 PRD 的翻车判例：审批提醒 PRD 因AI 把没被推敲的假设填成详细规则（「每小时触发提醒」），研发照做，返工两周、项目延期一个月；另有「编造细节」致延期三个月与 SQL 注入漏洞返工找茬预演的实测口径：让 AI 扮演挑剔工程师提前找茬（「模拟杠精」），PRD评审通过率从 60% 左右提升到 90%；全程单对话窗口防前后矛盾，能省一半返工

它实际在用的数据：PRD 草稿（任何格式：飞书文档/Word/Markdown）该需求的相关聊天记录与工单（评审材料的原料）历史评审纪要（上次被喷的点）技术方案或接口文档（研发侧，如有）

关键字段与口径：找茬报告：逻辑漏洞/边界遗漏/埋点缺失逐条定位 + 修改建议一致性报告：前后矛盾/「本期不做」与正文冲突/验收标准与用户故事脱节

本组场景：

• DC-01 PRD 评审前找茬预演 · 优先级 8.0
• DC-02 PRD 一致性终审 · 优先级 7.5
• DC-03 评审材料自动凑齐 · 优先级 6.7

升为客户真实案例还缺什么：需要客户提供：PRD 草稿 + 该需求的相关记录 —— 找茬预演实测口径能把评审通过率从六成抬到九成。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

变更与指令

Changes & Directives

把「口头需求禁止生效」从一句制度变成事实 —— 每次变更留档（内容/影响/决策人）、每场评审的决议变成待办、老板的语音微信翻译成带澄清问题的结构化需求

3 个场景

这个子角色为什么真实存在：项目后期的普遍事故根源：「搞不清哪些需求满足了、哪次变更谁批的」—— 靠人执行的「口头需求禁止生效」制度从未成功过中小企业的需求主产地就是会议和老板微信：纪要无人记是常态；「老板半夜发微信加功能」的吐槽密集出现Agent 项目 90% 以上试点失败的第一死因是责任归属 —— 所以每个场景都设计人拍板点：AI 留档、翻译、追问，生效与否人签字

公开来源：发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out of Scope）是对外交付的护身符Agent 项目的行业失败率：麦肯锡统计超 90% 企业 Agent 试点即失败，

「Demo 惊艳、两周被叫停」的复盘直指责任归属无人敢碰 —— 每个场景必须有人拍板点「越快越慢」的机制：AI 把没想清楚的部分填成看似完整的八千字，看似提速、实则把推敲成本后置给研发；15 页 AI PRD 没人读、研发喂给自己的 AI 做总结 ——「AI 消化 AI，链条里没人用大脑」

它实际在用的数据：会议录音/速记（评审会、客户会）老板的语音与微信指示（原样扔进来）变更通知（研发群/客户邮件）本迭代的需求清单（变更挂接的对象）

关键字段与口径：变更台账：变更内容/提出人/决策人/影响范围/生效版本 —— 每行可回溯到原始记录结构化需求卡：老板指令的原文 + 翻译 + 澄清问题清单 —— 反问恰好对冲「AI 不主动澄清」的最大抱怨

本组场景：

• CH-01 需求变更留档登记 · 优先级 10.0
• CH-02 评审决议与待办登记 · 优先级 8.0

升为客户真实案例还缺什么：需要客户提供：录音或速记、聊天记录 —— 变更发生的当下扔进来，台账当场生成。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

验收与发布

Acceptance & Release

让「没有专职测试、产品即测试」的公司也有一道像样的闸门 —— 验收用例从 PRD 长出来、发布检查清单逐项留痕、事故复盘的初稿当场出

3 个场景

这个子角色为什么真实存在：上线事故的形状：「连锁反应式灾难」—— 一行代码的变更踩了别人的线、影响范围图没拉、回滚预案没有；产品经理是「上线后 24 小时手机不能静音」的第一责任人中小企业没有专职测试是常态：产品经理兼测试 —— 从 PRD 生成验收用例恰是「扩张型」活（AI 出清单、人跑测试）复盘的通病是「只停留在口头，下次还会重演」：同类事故二次发生的根因不是没复盘、是改进项没有跟踪

公开来源：连锁反应式灾难上线判例：跨域限制只在生产环境生效导致数据服务失效 —— 需求评审时没拉出影响范围图，一行代码的变更踩了别人的线；「上线后 24 小时手机不要静音，你是第一责任人」是产品经理的自保实录发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out of

Scope）是对外交付的护身符Agent 项目的行业失败率：麦肯锡统计超 90% 企业 Agent 试点即失败，「Demo 惊艳、两周被叫停」的复盘直指责任归属无人敢碰 —— 每个场景必须有人拍板点

它实际在用的数据：PRD 与需求清单（用例的原料）发布计划与涉及模块清单事故的时间线素材（告警记录/群消息/工单）上一次复盘的改进项清单（如有）

关键字段与口径：验收用例清单：按需求逐条展开的用例 + 预期结果 —— PM 跑测的脚本发布检查报告：五维度逐项核验 + 缺项拦截 —— 留痕本身就是交付证据

本组场景：

• VA-01 验收测试用例生成 · 优先级 8.0
• VA-02 发布检查清单执行留痕 · 优先级 8.0
• VA-03 事故复盘初稿 · 优先级 8.0

升为客户真实案例还缺什么：需要客户提供：PRD、发布计划、事故素材 —— 发布前一天跑检查，事故当天出复盘初稿。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

客户之声

Customer Voice

让客户的声音第一次被全量听见、让承诺第一次被集中看见、让定制的账第一次被算清 —— 工单聚类替代 1%-2% 抽检、承诺台账对冲续约纠纷、定制毛利给老板一张钱表

3 个场景

这个子角色为什么真实存在：客服数据是金矿但从未开采：人工抽检只能覆盖 1%-2% 的会话，全量聚类从未做到 —— 大模型聚类发现人工盲区、满意度提升 23% 有正面判例承诺散落销售微信是续约纠纷之源：售前答应的功能与时间线，产品侧从没集中看见过定制侵蚀有投资人标准：大客户毛利率不足 65% 即定制过重 —— 而绝大多数中小 SaaS 从没算过自己的定制占比

公开来源：客服数据的金矿从未被开采：传统客服质检只能覆盖 1%-2% 的会话量，全量聚类在人手上从未做到 —— 这是「AI 干了人一直没干成的事」的最硬证据聚类发现人工盲区的正面判例：用大模型对客服工单做全量聚类，发现人工抽检长期漏掉的主题、满意度提升 23% —— 聚类的价值不是统计是发现定制侵蚀的收入结构判例：国内 SaaS 毛利率普遍不足 60%（国际代表公司超 70%）；投资人判断标准 ——「纯 SaaS 企业大客户毛利率在 70%-75%，不足 65% 则说明定制化程度过重」

它实际在用的数据：客服工单/会话导出（近 30-90 天全量）销售与客户的聊天记录（承诺的原料）研发工时记录（定制打标的原料）客户与版本对照表（私有化分支现状）

关键字段与口径：VoC 聚类报告：主题/频次/情感/金句引用 —— 替代抽检的全量视图定制毛利月报：定制占比/侵蚀趋势/客户维度 —— 给老板的钱表

本组场景：

• CX-01 客服工单全量聚类 · 优先级 8.3
• CX-02 客户承诺台账 · 优先级 8.0

升为客户真实案例还缺什么：需要客户提供：工单导出、销售聊天记录、工时记录 —— 双周一次聚类，月度一次算账。这里列的是这个岗位真实会用到的数据类型，

不做什么

明确不做的伪需求 · WorkBuddy · 产品岗位场景库

12 个伪需求以及为什么不做

客户看到「四十个场景」的第一反应不是「好全」，而是挑最不靠谱那个来问。

一个伪需求会削弱旁边所有真场景的说服力 —— 所以这一页存在的意义，是让 15 个真场景更可信。

产品岗是伪需求重灾区，因为「AI 替你写 PRD」的故事最好讲、翻车的判例也最全。判断只需要三句话：这个判断你敢让 AI 替你拍吗？这份文档里的每句话都有依据吗？这个表现在有人维护吗？第三句答不上来，就不要做。

2

法则一 · 一段脚本更快更准更便宜

5

法则二 · 需物理感知或对外担责

5

法则三 · 真实瓶颈不在这一步

!

最典型的一条：办公用品领用登记电子化

它看起来完全合理：纸质登记乱、统计麻烦、月底要追问还剩多少。

但制度里写着「月度汇总提交采购与财务作成本核算依据」——

现实中签完字这件事就结束了，汇总表没有人看。

把一张没人看的表加速录进系统，等于加速垃圾数据入库。

真正有价值的是另一个问题：为什么某个部门的耗材是别人的三倍。

清单逐条说明

最后一列是客户主动提出时的回应口径 —— 不是拒绝，是把他引到真场景上

伪需求命中法则

更优解 / 真实瓶颈在哪客户提出时怎么回应

AI 一键生成完整可开发 PRD法则三 · 瓶颈在需求理解与拍板，虚假精确害人PRD 找茬预演（DC-01）+ 一致性终审（DC-02）—— AI 做检查，写作与拍板留给人老板，AI 写 PRD 出过这样的事：把没想清楚的假设填成「每小时触发提醒」这种详细规则，研发照做，返工两周、项目延期一个月。AI 越快、推敲的成本越往后压。咱们换个打法：您的人写 PRD，AI 扮演最挑剔的工程师提前找茬 —— 实测能把评审通过率从六成抬到九成，这才是省返工。AI 竞品分析一键出报告法则三 · 瓶颈在分类框架与差异化判断（市场侧竞品情报已由市场库覆盖）工单聚类（CX-01）里的「竞品提及」主题 —— 竞品情报从客户原声里长出来五十页的竞品分析我们见过太多 —— 开三周会定不了「对标是

谁」。真有用的竞品情报在客户的抱怨里：工单聚类会把「客户提到别家」的原话聚成一簇，那才是对手真正打中的点。AI 直接定需求优先级 / 自动排期法则二 · 排序即取舍即担责需求归集（RQ-01）带证据包（提及频次/客户价

值）—— 预打分人排序排优先级这事儿，AI 给的每一分都会被老板一句「和本季度核心指标关联度在哪」问死。AI 能做的是把每个需求的证据摆齐：几个客户提的、什么级别、提了几次 —— 排序那一下，还得您来。AI 对客户承诺上线时间 / 交付范围法则二 · 对外承诺担责客户承诺台账（CX-02）只登记已发生的承诺 —— 生效与变更人拍板有家公司让 AI 托管智能客服，三天出 PRD、一周 demo、两周全量上线，结果字段对不上、引用旧条款，客户投诉直接炸了。对客户说「Q3 一定上」这种话，必须是人的承诺。AI 做的是把已经许出去的承诺集中登记 —— 至少您知道销售替您答应了什么。AI 自动扩写需求 / 生成功能点充需求池法则三 · 制造虚假繁荣，清洗成本转嫁研发需求归集（RQ-01）只收真实来源 —— 一条需求必须有出处（人/渠道/时间）V2EX 上有个真实帖子：PM 用 AI 两周生成一千多个功能点，前端被迫加班「糊弄」演示逻辑。需求池的价值在真不在多 —— 我们的归集只收有出处的：谁提的、哪个渠道、什么时候，一条都编不了。需求状态自动流转 / 到期提醒机器人法则一 · 确定性规则任务，脚本更快更准需求池清淤（RQ-02）管的是「该不该留」这个理解题 —— 流转交给工具自带 Automation状态提醒这种活，飞书项目、

Teambition 自带的自动化就能干，九块九的插件都有 —— 犯不着用 AI。AI 真正的题是「这 96 条半年没动的需求哪些该归档」—— 这要读懂内容，脚本干不了。强制全字段需求提交表单（+AI 字段校验）法则三 · 表单本身填了归档没人看，瓶颈在治理不在填写多渠道归集（RQ-01）反向解决 —— 从聊天记录自动抽取字段，人只做确认Jira 十七个必填字段的下场是六个月后团队滑回 Excel —— 填表的成本全压在干活的人身上。我们不要求任何人改习惯：销售照样发微信截图，AI 从截图里把字段抽出来 —— 表单不空转，字段全自动。全自动无人工干预的需求处理 Agent（端到端）法则二 · 责任归属无人敢碰 + 90% 试点失败率全库 15 个场景每个都有人拍板点 —— 归集确认、清淤拍板、变更签字麦肯锡的数字：超九成企业的 Agent 试点失败，第一死因就是「出了事算谁的」没人敢碰。所以这套东西的每个环节都留着拍板点：AI 归集、人确认入池；AI 建议归档、人拍板删除 —— 掌控权在您的团队手里。AI 自动删除 / 归档需求池条目法则二 · 删除有商业与政治风险清淤体检（RQ-02）只出建议清单 —— 删除逐条人拍板「历史需求没人敢删」不是胆小 —— 被拒的需求因为新商机复活是 B 端常态，删错一条的代价远大于留着。AI 把该归档的挑出来、理由列清楚，删不删您看，黑锅我们不替您背也不让您背。AI 周报 / 汇报 PPT 自动生成（作为主场景）法则一 · 模板脚本可做 + 法则三 · 瓶颈在需求池本身失真工单聚类（CX-01）与定制毛利（CX-03）—— 汇报的原料先真实周报写得再快，需求池本身是失真的，周报就是失真的汇总。先把需求池、工单、定制三本账记真了，周报那点活顺手就有—— 主次别搞反。AI 画原型 / 自动生成交互稿法则三 · 瓶颈在交互判断与业务适配验收用例（VA-01）管的是「做出来的对不对」—— 原型是设计师的活原型的好坏在交互判断和业务理解，AI 生成的原型研发一眼就看出「没走过脑子」。AI 能管的是另一头：功能做出来了，用例从 PRD 长出来、逐条验 —— 那才是缺人手的环节。AI 自动回复研发关于 PRD 的提问法则二 · 文档即承诺，答错算产品的一致性终审（DC-02）保证文档本身可靠 —— 研发的问题人来答PRD 里的每句话都是要开发照做的承诺，AI 答研发的提问、答错了返工算谁的？先把文档的一致性把住，研发的提问自然会少 —— 少掉的那些，值得人亲自答。

声明这套东西不承诺什么

主动讲限制比被问出来强得多

这是演示与验证资产，不是已接入生产系统的软件所有 Live Demo 页面展示的是「应该怎么跑、每一步看什么、交付什么」，使用的是真实业务格式的脱敏构造数据，不冒充任何公司的真实经营数据。不承诺效率提升百分比本场景库不出现任何「几天压到几分钟」「节省百分之九十」这类数字 —— 没有用客户自己的数据实测过，这种数字说出来就是砸口碑。我们讲的是可核实的条数与金额：归集了多少条来源、聚出多少主题、拦下几个发布缺项、算出多少定制占比。判例与数据一律注明「个案口径」报告引用的返工判例（返工两周/延期三个月）、聚类效果（满意度

+23%）、投资人毛利标准（65% 警戒线）等均为公开报道的个案或行业统计口径，用于说明风险量级与路径存在，不构成对贵司任何结果的承诺。判断与拍板不碰，证据层全包AI 定优先级（取舍担责）、对客户承诺（对外担责）、自动删除需求（政治风险）、端到端全自动（责任悬空）—— 全部不做。归集、查重、回溯、找茬、留痕、算账 —— 证据层的粗活全包。把这条边界讲明白，是给客户的第一个信任动作。不要求换工具、不要求先填表单所有场景的输入都是现成文件：微信截图、工单导出、会议速记、PRD 草稿 —— 连用 Jira 的团队也私下维护影子 Excel 的现实说明：要求改变工作流的方案，六个月后都会滑回原点。产出是 Excel、文档草稿与台账，不是新系统所有交付物保持 Excel/文档/一页纸形态、微信可直接转发 —— 「大家都在填、没人受益」的项目管理工具已经够多了，我们不生产第十八个必填字段。

那哪些是真场景？15 个逐条打过分的场景，全部保留了评分口径可核

回到场景总览 →

来源说明

本场景库的痛点均有公开来源可查。网页版已对来源中的具体机构做了脱敏处理，不再逐条列出。

场景审核

场景审核 · WorkBuddy · 产品岗位场景库

先过场景不急着做素材

共 15 个场景。逐个点「保留 / 待讨论 / 后置」，

结果只保存在本机浏览器，可以复制出来。

建议的判断顺序：先问这件事没做好谁会生气（痛感）→

再问错了能不能当场看出来并改（能不能交给 Agent）→

最后问客户手上现有的文件够不够跑（落地难度）。

需要客户先做数据治理的场景，不要放在第一批。

清空选择

返回总览

归集

需求归集

让散在微信截图、客服工单、邮件和老板语音里的需求第一次被完整看见 —— 归集有结构、重复有合并建议、每条能回溯到「谁提的、当时原话」

3 个

RQ-01

8.3

多渠道需求归集结构化同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段 —— 六次转世，需求池里还是没有它

保留

待讨论

后置

RQ-02

8.0

需求池清淤体检需求池 427 条，最近半年动过的不到三分之一 · 「进来了没人清、历史需求没人敢删」—— 每一条都是不敢碰的存量

保留

待讨论

后置

RQ-03

8.0

需求来源回溯档案老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古

保留

待讨论

后置

评审

文档与评审

让评审会不再是产品经理的单方面汇报 —— 找茬预演在会前抓漏洞、一致性终审在提交前抓矛盾、评审材料提前凑齐，研发的每个质疑都有出处可答

3 个

DC-01

8.0

PRD 评审前找茬预演评审会上研发问「两个状态同时触发怎么办」· 这种问题最好的出现时机是评审前一天，不是评审会上

保留

待讨论

后置

DC-02

7.5

PRD 一致性终审「本期不做」写在范围声明里，正文却详细描述了它的交互 · 研发按正文实现，范围争议回到产品头上

保留

待讨论

后置

DC-03

6.7

评审材料自动凑齐评审会前一小时还在找「这个需求哪个客户提的」· 证据没带齐的评审，每个问题都是一次减分保留

待讨论

后置

变更

变更与指令

把「口头需求禁止生效」从一句制度变成事实 —— 每次变更留档（内容/影响/决策人）、每场评审的决议变成待办、老板的语音微信翻译成带澄清问题的结构化需求

3 个

CH-01

10.0

需求变更留档登记项目后期「搞不清哪些需求满足了、哪次变更谁批的」—— 靠人执行的「口头需求禁止生效」制度，从来没有成功过

保留

待讨论

后置

CH-02

8.0

评审决议与待办登记评审会开完，决议散在三个人各自的记忆里 · 一个月后「当时不是说好挂起吗」—— 没有纪要的会议等于没开

保留

待讨论

后置

CH-03

8.0

老板口头指示翻译老板周日晚上 60 秒语音：「巡检报告加个导出，最好下周就能用」· 翻译成需求卡需要三件事：原话、结构化、澄清问题

保留

待讨论

后置

验收

验收与发布

让「没有专职测试、产品即测试」的公司也有一道像样的闸门 —— 验收用例从 PRD 长出来、发布检查清单逐项留痕、事故复盘的初稿当场出

3 个

VA-01

8.0

验收测试用例生成没有专职测试的公司，验收就是产品经理拿自己的手机点一遍 · 「感觉没问题」是唯一的测试报告保留

待讨论

后置

VA-02

8.0

发布检查清单执行留痕「连锁反应式灾难」的复盘第一条：回滚预案没有 · 检查清单的价值不在列出来，在逐项核过并留下痕迹

保留

待讨论

后置

VA-03

8.0

事故复盘初稿事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点

保留

待讨论

后置

客户

客户之声

让客户的声音第一次被全量听见、让承诺第一次被集中看见、让定制的账第一次被算清 —— 工单聚类替代 1%-2% 抽检、承诺台账对冲续约纠纷、定制毛利给老板一张钱表

3 个

CX-01

8.3

客服工单全量聚类人工质检只能抽检 1%-2% 的会话 · 「报表与导出」168 条工单聚成一个主题 —— 而需求池里这条需求去年被拒了

保留

待讨论

后置

CX-02

8.0

客户承诺台账销售答应客户的「Q3 一定上」，产品侧从没看见过 · 承诺散落销售微信是续约纠纷之源

保留

待讨论

后置

CX-03

5.3

定制工时与毛利台账定制工时占研发 39%、毛利掉到 58% —— 投资人的警戒线是 65% · 这笔账绝大多数中小 SaaS 从来没算过

保留

待讨论

后置

审核进度未选择 15

交付说明

交付说明 · WorkBuddy · 产品岗位场景库

产品岗位场景库怎么用这套东西

这是一套售前演示与客户验证资产，不是已经接入客户生产系统的软件。

包含 5 个子角色、15 个场景、45 个内容页、

15 个 Skill 包与配套素材和预期输出。

15完整场景

45三件套页面

12明确不做的伪需求

20可核验来源

路径三种人怎么看

客户初次看

从总览按子角色选场，先看「场景引入」。三分钟看清这件事现在什么样、痛点依据在哪、产出是什么。

打开场景总览

现场演示

打开「Live Demo」逐步讲。重点讲 Agent 在哪一步拦住了 ——

一、个会在该停的地方停下来的助手，比一个永远给得出答案的助手可信得多。

看一个完整 Demo

内部选型

在「场景审核」页逐场标保留 / 待讨论 / 后置，复制结果后再决定哪些进入真实素材制作。

打开场景审核

话术现场必备的三句话

开场 · 先说 AI 做不到什么

把限制先摆出来：不承诺效率百分比、拿不到的数据会说拿不到、高风险动作只建议不执行。

主动说限制比被问出来强得多 —— 而且这一句会把后面所有内容的可信度垫起来。

中场 · 用一句话帮客户剔掉伪需求

客户提到某个表单类需求时，问一句：「这张表现在有人看吗？看完做了什么决定？」

答不上来就当场建议先不做。这一下建立的是顾问式信任 ——

客户会开始相信你不是来卖东西的。

收尾 · 三个问题要金额

「你们上一次续租谈判省了多少？三家报价逐项比过吗？知道水电为什么涨吗？」

三、问都答不上来，场景就成立了。

状态已完成与未冒充完成

已经完成5 子角色 × 15 场景完整内容每场景：场景引入 / Live Demo / 能力沉淀 三页每场景：Skill 包（含输出骨架与渲染脚本）、素材、预期输出痛点逐条挂来源，可点开核对12 个伪需求逐条说明命中哪条排除法则岗位依据页说明子角色为什么这样切

明确未冒充完成尚未接入任何客户的生产系统素材是真实业务格式的脱敏构造数据，不是客户生产数据场景尚未用客户自己的原始文件实跑过（这是下一步）有来源支撑不等于完成客户一手验证没有实测前不出现任何效率提升百分比证照申报、账号停用、资产核销、对外发文、用印、签署一律人工

下一步怎么往前推

第 1 步过场景15 个逐场标保留 / 待讨论 / 后置

第 2 步选 3 到 5 个按客户类型组合，优先零集成的

第 3 步要一手材料真实文件、审批链、一次出过问题的案例

第 4 步用客户文件实跑记录结果、返工点、真实耗时

第 5 步再谈系统对接此时才评估 API、权限与回写