软件SaaS · 行业场景库

岗位依据

岗位依据与数据 · WorkBuddy · 软件与SaaS场景库

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

公开的组织架构图上，软件公司写的是「售前部 → 产品部 → 研发部 → 交付部」四级流水线，各管一段、责任分明。但真实 JD 与从业者自述里写的是另一回事：售前工程师「上午写技术建议书、远程 Demo，下午陪销售拜访客户谈安全合规、搭 PoC 环境，晚上把客户吐槽反馈给产品经理」一岗横跨售前、产品与交付三段；需求入口「客户反馈、销售建议、客服工单、老板临时想法、运营诉求、实施现场问题」六个渠道人人能提、没人知道该提到哪里；而研发侧的真实写照是「文档更新在 PR 合并那一刻变成 backlog 的一项任务，而 backlog 是良好愿望安享晚年的地方」。部门墙是画在纸上的，口径不一致的坑是踩在每一份标书、每一次验收里的。

所以这套场景库按一份合同的责任交接点切分，而不是按大企业的职能表：把承诺递出去的（售前应答）、把承诺兑现掉的（交付验收）、把散落声音归口的（需求收口）、把事实写准的（研发文档）——这四类活在中小软件公司里往往分别由同一拨人兼着干，区别只在承诺什么时候到期、错了谁来举证、产出物被谁消费。

售前解决方案

Pre-sales Solution

把销售许出去的每句话变成敢写进合同的技术口径——RFP 答过的不重写，没答过的不瞎编

2 个场景

这个子角色为什么真实存在：依据一：单份 RFP 平均 32 小时、7 人参与、年均 266 份——而其中八成问题是上一份标书里答过的，重复劳动是结构性浪费依据二：售前的正式交付物是 Word 方案书（进招投标审计材料）+ PPT 宣讲稿双格式，讲标答辩还要求对竞品口径随问随答依据三：「销售为拿单乱承诺、售前去圆谎」是行业最典型的跨部门矛盾；最高法判例已把「功能点清单」钉死为验收与违约认定锚点依据四：约 15% 的投标因漏掉必备要求被废标——必答项漏项是比答错更廉价的失败方式

公开来源：Loopio/HubSpot 基准（聚合于 openasset 统计页）：单份 RFP 平均投入 32 小时（约每题 25 分钟），企业级团队 27-38 小时，企业年均响应 266 份9 年从业经验的 IT 售前博客：售前核心交付物是 Word 版方案书（招投标审计材料）+ PPT 版宣讲材料（由 Word 精简提炼）；售前的一天=写建议书/画架构图/远程 Demo/陪访谈合规/搭 PoC/晚上反馈吐槽给产品(2020) 最高法知民终 1545 号（武汉中新蓝案）：定制开发合同约定 4 端 26 模块 72 个功能点，验收标准明确为「需求书功能点是否实现」；交付 UI 图被发现是其他项目改名，演示时功能不能实现，被认定未实质开发构成根本违约，返还已收 11 万元首期款投标统计：约 15% 的投标因漏掉必备要求而被废标，历史数据（2014）曾高达30% 源于缺文件少表格

它实际在用的数据：RFP 问卷原件（Excel/Word，客户方格式，含必答项与评分标准）历史标书与应答库（Word/PPT 多版本，散在售前个人电脑与网盘）产品功能清单与 roadmap 对照表（产品部维护，更新滞后是常态）售前与销售的项目沟通记录（微信/邮件导出，口头承诺的第一现场）

关键字段与口径：应答库栏位：问题 / 标准应答 / 依据（出自哪份文档哪个版本）/ 最后核验日期偏离表栏位：招标要求 / 产品现状（已支持-部分支持-不支持）/ 偏离说明 / 责任人签字竞品对比栏位：能力项 / 本方现状 / 竞品现状 / 证据链接 / 口径等级（可承诺-仅展示-不提及）

本组场景：

• PS-01 RFP 应答初稿与错承诺拦截 —— 八成题答过，要命的是没答过还敢承诺 · 优先级 10.0
• PS-02 竞品对比矩阵与讲标弹药 —— 客户拿着竞品报价单逐条对问的那一刻 · 优先级 8.8

升为客户真实案例还缺什么：现场要向客户要三样东西：上一份答过的完整 RFP 及其中标后的合同功能点清单、产品功能清单当前版、销售与客户的近三期沟通记录导出——应答库的真实度完全取决于这三样。

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

交付实施

Delivery & Implementation

让每一步实施都留下能拿上仲裁庭的证据——验收按功能点逐项对，延期按责任逐天归因

2 个场景

这个子角色为什么真实存在：依据一：仅 29% 软件项目完全成功；失败根因里技术问题垫底（17%），需求不清晰

（39%）与范围蔓延（33%）才是前两名——延期归因本身就是专业能力依据二：司法实践以「需求书功能点逐项是否实现」为验收判定框架；实施日志、测试报告、沟通记录被法律界明示为仲裁的关键证据链依据三：SaaS 实施塌方的常见前兆是 SOW 模糊、买方义务无人承担、需求变更不走书面确认——每个前兆都对应一类可留痕的动作依据四：延期罚金惯例每周 0.5%-1%、上限合同额 10%——延期天数每归因错一天，都是真金白银

公开来源：Standish Group CHAOS Report 2024（5 万+ 项目）：仅 29% 软件项目完全成功，52% 受挑战，19% 取消；千万美元级大型项目成功率仅 6%；失败根因排序：需求不清晰 39%、范围蔓延 33%、计划不足 29%、沟通中断 25%、技术问题仅 17%（垫底）云软件实施纠纷的六大高频争点：实施延期（触发违约金）、功能不达标、培训支持不足、数据迁移出错、SLA 违约、提前终止与退款；法律界明确提示「日志、测试报告、沟通记录是仲裁的关键证据链」SOW清单实践：很多项目延期始于「买方义务没人配备」（数据、测试、安全审批、干系人出席），SOW 必须按责任表（厂商/客户/第三方）指定每项唯一责任人SaaS 实施 SOW 标准结构：4-6 个里程碑（kickoff→设计评审→测试环境→验收签字→生产上线→hypercare）；典型付款 30%（签约）/30%（验收）/40%（上线）；延期罚金惯例每周

0.5%-1%、上限合同额 10%

它实际在用的数据：合同/SOW 与需求确认书（含功能点清单与里程碑付款节点）实施日志与周报（散在项目经理个人笔记与群消息里，从未系统归档）双方往来函件（催款函/暂停开发告知函/变更确认邮件）测试记录与演示勘验记录（验收争议时的第一证据）

关键字段与口径：验收核对表栏位：功能点编号 / 需求书原文 / 实现状态（通过-部分-未达）/ 证据（测试记录或演示日期）/ 双方签字实施日志栏位：日期 / 事项 / 责任方（厂商-客户-第三方）/ 证据附件 / 影响天数延期归因栏位：延期原因 / 责任归属 / 起止日期 / 天数 / 合同依据 / 处置建议

本组场景：

• DL-01 验收报告初稿与功能点核对 —— 72 个功能点逐项对，5 项不达标各有各的处置 · 优先级 7.5
• DL-02 实施日志归档与延期归因 —— 37 天延期，21 天是客户的、11 天是变更的、5 天认回来 · 优先级 11.0

升为客户真实案例还缺什么：现场要向客户要三样东西：任意一个在途项目的 SOW 与需求确认书、项目经理的最近四周周报原始版、一份双方有争议的验收或变更记录——证据链的完整性检验必须拿真实项目来跑。

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

产品管理

Product Management

把六个渠道涌进来的声音收成一条证据链——谁提的、几家客户、值多少 ARR，而不是谁声音大做谁

2 个场景

这个子角色为什么真实存在：依据一：需求天然来自六类来源（客户反馈/销售建议/客服工单/老板想法/运营诉求/实施现场），「大家都能提需求，但没人知道该提到哪里」——重复录入与优先级失序是结构病依据二：PM 每周 12+ 小时用于收集管理反馈，只有 1/10 的团队能全渠道捕获客户反馈；74% 的 PM 把高质量反馈列为最大挑战依据三：同一个需求换个说法就是三条记录（「夜间太刺眼」「增加深色主题」「重点客户问过 Dark Mode」）——关键词去重解决不了语义重复，还会误合并依据四：反馈闭环差的公司最多浪费 35% 开发资源造没人要的功能；需求池治理共识是「先堵新增（入口收口）→ 再梳分类 → 最后归档存量」依据五：只有 1/10 的团队能全渠道捕获客户反馈、74% 的 PM把高质量反馈列为最大挑战；72% 的高绩效销售组织与产品有正式反馈闭环、绩效差的只有 28%——收口这件事的差距直接写进业绩

公开来源：国内产品管理实践：需求来源天然包括客户反馈、销售建议、客服工单、老板临时想法、运营诉求、实施现场问题；入口一多就出现「大家都能提需求，但没人知道该提到哪里」——重复需求变多、优先级变乱，产品经理被「谁声音大就先做谁」牵着走UserVoice 调研（200 名产品从业者）：收集和管理反馈可占产品经理每天 25% 以上、每周 12+ 小时需求重复录入的典型形态：客户访谈说「夜间看起来太刺眼」、客服工单写「希望增加深色主题」、销售反馈「几个重点客户都问过 Dark Mode」——逐条录入就是三条记录；按关键词机械去重又会把场景不同的相似诉求错误合并需求池治理共识：需求池越堆越满的根因不是需求多，而是入口未治理——只进不出、缺乏准入判断、没有分层处理；治理次序是「先堵新增（入口收口）→ 再梳分类 → 最后归档存量」Productboard 引用调研：只有 1/10 的团队能从所有可用来源捕获客户反馈，1/3 的团队没有任何反馈收集流程ProductPlan 2024 State of Product

Management：74% 的产品经理把「获得高质量客户反馈」列为最大挑战Salesforce State of Sales：72% 的高绩效销售组织与产品团队有正式反馈闭环，绩效差的组织只有 28%

它实际在用的数据：客服工单导出（含口语化问题描述，需求密度最高的矿脉）销售/售前的客户反馈（微信记录与拜访纪要，ARR 证据在销售手里）客户访谈纪要与录音转写（含未过滤的原始抱怨）现有需求池导出（Excel/看板，只进不出是常态）

关键字段与口径：需求条目栏位：原始表述 / 归一需求 / 来源渠道 / 提出客户 / 关联 ARR / 语义重复组 / 首次出现日期评审材料栏位：需求摘要 / 客户证据链（几条来自几个渠道）/ 竞品现状 / 建议优先级（留空，评审定）

本组场景：

• PM-01 需求池多源收口与语义去重 —— 「深色主题」从三个渠道进来就是三条记录 · 优先级 11.0
• PM-02 基于自有需求库的 PRD 初稿 —— 评审会 3 小时，八成时间耗在信息对齐 · 优先级 8.0

升为客户真实案例还缺什么：现场要向客户要三样东西：最近一个月的客服工单原始导出、销售拜访纪要样本十条、现有需求池全量导出——三个源对不上号的地方，就是这个场景的价值所在。

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

研发与开发者文档

Engineering & DevDocs

让文档跟上代码——客户集成联调卡住的那一刻，过时文档的利息就到期了

2 个场景

这个子角色为什么真实存在：依据一：47% 的组织承认 API 文档与实现不同步、只有 5% 认为文档非常好；Postman

2024：39% 把文档不一致列为最大协作障碍、44% 只能直接翻源码依据二：75% 的生产 API 与其 OpenAPI 规范存在实测偏差；71% 的开发者曾因更好的文档而弃用一个 API——文档就是产品的销售页依据三：技术写手与开发者的真实配比从 1:12 到 1:200——靠人力追代码变更速度在数学上就不成立依据四：「发布 changelog 条目和更新参考文档是两件不同的事，团队普遍做了第一件就当完成了」——发布说明的欠账就是这样积出来的

公开来源：SmartBear 2020 State of API（1,500+ 开发者）：47% 的组织承认 API 文档与实际实现不同步，只有 5% 认为自己的文档「非常好」；64% 表示「没时间」是文档质量最大障碍；70% 的开发者把代码示例列为文档最重要组成部分Nordic APIs / APIContext 实测研究：75% 的生产 API 与其 OpenAPI 规范存在偏差；71% 的开发者曾因更好的文档而选择 A API 弃用 B API技术写作配比综述：常被引用的目标是 1:7 至 1:10，但真实世界的比例从 1:12 到 1:200 不等——写手配比根本追不上代码变更速度Changelog 最佳实践：「发布 changelog 条目和更新参考文档是两件不同的事——团队普遍做了第一件就当完成了」

它实际在用的数据：OpenAPI/Swagger 规范文件（理想态，多数团队只有注释）代码仓库的接口注释与近期合并记录（文档漂移的对照基准）现有 API 文档站（静态页面，更新频率远低于发版频率）客户集成联调工单（文档过时的直接受害者名单）

关键字段与口径：同步巡检表栏位：端点 / 文档版本 / 代码实际版本 / 漂移类型（参数-返回-示例-状态码）/ 影响面 / 修复建议发布说明栏位：变更类型（Added/Changed/Deprecated/Fixed/Security）/ 影响端点 / 是否 Breaking / 迁移动作本组场景DV-01 API 文档与代码同步巡检 —— 75% 的生产 API 和它们的规范对不上 · 优先级 8.8DV-02 发布说明与迁移指南起草 —— 发了 changelog 不等于更新了文档，这是两件事 · 优先级 7.5

升为客户真实案例还缺什么：现场要向客户要三样东西：OpenAPI 规范文件（有就要）、任意 5 个核心端点的当前文档页截图、最近一次发版的 commit 记录与 changelog——三样一对，漂移立即现形。

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

不做什么

明确不做的伪需求 · WorkBuddy · 软件与SaaS场景库

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

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

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

软件行业是「用 AI 提效」喊得最响的领域，也是伪需求密度最高的领域——因为它的每个环节都能生成点什么，但生成出来有没有人接着用，是另一回事。判断只需要三句话：这份文档现在有人看吗？这个数据现在有人维护吗？如果Agent 明天就把这件事做完了，下游的人会不会因此改变行为？第三句答不上来，就不要做。

7

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

6

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

9

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

!

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

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

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

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

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

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

清单逐条说明

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

伪需求命中法则

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

报价 BOM 金额汇总与税率折扣计算法则一 · 确定性规则任务加总、税率、阶梯折扣是确定性算术，Excel/规则引擎即可，硬用 AI 反而引入算错风险；AI 的机会在行项清单的语义整理（PS-01 的应答范围）现场话术：算钱这件事您的Excel 比任何模型都可靠；我们整理清单，数字您自己算。回归测试执行调度与用例选择法则一 · 确定性规则任务测试选择与调度是约束优化问题，CI 规则可解；AI 适配的部分是「从需求生成用例」，那属于测试工具链的领地现场话术：调度交给您的 CI；用例生成这块建议先看测试平台的能力。甘特图排期求解与资源排布法则一 · 确定性规则任务排期求解是运筹问题；任务拆解（WBS）的初稿可以用 AI 出，但求解器算得更优现场话术：拆活可以帮您拆，排期这种最优解问题，求解器比大模型靠谱。规则明确的工单自动路由法则一 · 确定性规则任务「产品线=路由目标」这类映射用配置表即可；只有语义歧义大的工单分类才需要理解能力——那是 PM-01 收口的上游现场话术：路由规则明确就用配置表；真正需要理解的是工单里那些说不清的需求——那些我们收进需求池（PM-01）。license 与席位到期自动提醒法则一 · 确定性规则任务计费系统的标配功能，加个定时任务就能做；AI 的机会在续约风险的多信号判断——但那需要先过数据门槛（见下）现场话术：到期提醒您的计费系统自己就能发；续约该担心谁，是另一个问题。CI 构建失败自动重试编排法则一 · 确定性规则任务工具链自身能力（重试策略/熔断规则），与语义理解无关现场话术：这块在您的 DevOps 工具里，不需要我们。代码格式化与规范静态检查法则一 · 确定性规则任务linter/formatter 秒级确定性执行，AI 插进来只有副作用现场话术：格式问题交给 linter，一毫秒都不用模型算。投标技术偏离表终稿定稿法则二 · 对外担责投标承诺具法律效力，误写「满足」而实际偏离可致废标/违约；PS-01 只出初表与风险标注，逐条人工核实签字写死在流程里现场话术：偏离表的初表我们出得又快又稳，但每一行的「满足」两个字，必须您的负责人亲眼核过、亲笔签字。验收报告结论与签字法则二 · 对外担责验收签字是合同交付里程碑，虚构测试结果属重大风险；DL-01 汇总证据出核对初稿，结论与签字栏留空给双方验收委员会现场话术：核对表、证据链我们做到位；「通过」两个字和签字栏，永远留给人。安全问卷/合规尽调的最终应答提交法则二 · 对外担责合规承诺对外提交后即成为客户追责依据，答错属合规风险；可以套用 PS-01 的应答库模式做「预填+逐题人审」，但「不适用」这类判断必须人做现场话术：安全问卷可以复用历史应答库预填——但每一题提交前都要人过目，尤其「不适用」三个字，说错就是合规事故。合同/SLA 条款定稿法则二 · 对外担责条款风险识别 AI 可做（定位到人审），但修改决策与定稿必须法务/负责人确认；AI 定位是「风险提示器」而非「条款决策者」现场话术：帮您把风险条款标出来可以；改不改、怎么改，您的法务说了算。对外报价终审法则二 · 对外担责报价数字错误直接造成利润损失；AI 出行项与工作量清单，价格数字人核现场话术：清单我们列，价格您核——这行字值多少钱只有您知道。生产环境变更的执行与发布法则二 · 对外担责变更可以出评估单与影响分析（谁受影响、怎么回滚），执行审批与发布动作必须人按变更管理流程走现场话术：变更影响分析可以交给工具；点「发布」按钮的必须是人，且是能担责的人。代码生成与调试（个人 IDE 场景）法则三 · 真实瓶颈不在这一步85% 开发者已在用 Copilot 类工具写代码调 Bug，个人 IDE 场景已被占满——正面竞争无胜算；WorkBuddy 的空档在「团队级、跨岗位、流程性」的场景：RFP 应答、需求收口、文档同步、验收归档——这些正是单个开发者工具永远不管的空隙现场话术：写代码这件事您的团队已经在用很顺手的工具了；我们管的是代码之外那 70%——从答标书到验收到文档，那些没人管、但决定回款和续约的部分。通用 PRD 一键生成（不吃自有数据的版本）法则三 · 真实瓶颈不在这一步PRD 模板网上泛滥，凭空生成的背景段全是漂亮空话——评审会照旧吵 3 小时；价值在基于自有需求库证据链的版本（PM-02：背景句句带出处、功能点三态拆解），排除的只是不吃数据的那条路线现场话术：PRD 我们做，而且做得深——但原料必须是您自己的需求池和工单（先跑 PM-01 沉淀，再上

PM-02）；模板生成那条路，等于把评审会的时间黑洞原样保留。通用竞品分析报告生成法则三 · 真实瓶颈不在这一步网上竞品分析一搜一堆，谁都能写；价值在结合本方打单记录与口径分级（PS-02）——「上次这家客户问过这题」比十页公开对比值钱现场话术：公开信息大家都有；您家丢单的原因分析，才是矩阵里最值钱的一列。PPT 美化与排版法则三 · 真实瓶颈不在这一步排版工具链早已成熟；方案宣讲输赢在口径与弹药（PS-02），不在像素现场话术：PPT 好看救不了一句不敢承诺的功能；弹药卡才是讲标现场的真武器。会议纪要自动生成（通用版）法则三 · 真实瓶颈不在这一步钉钉/飞书/Teams 已内置；价值在纪要之后的结构化流转——需求条目进池（PM-01）、变更确认留痕（DL-02），那是「纪要之后」的事现场话术：纪要您的会议工具自己就会记；纪要里那句「客户说要改」变成池子里带证据链的需求，才是我们干的事。NPS/满意度开放题聚类分析法则三 · 真实瓶颈不在这一步观察池场景：价值真实但频率低（季度/半年一次），且与 PM-01 的多源收口共用同一套语义归一能力——先跑高频的工单与销售反馈现场话术：这个能力 PM-01 里就有，工单和拜访纪要每周都在跑；NPS 半年一次的题，顺手就归了，不值得单独立项。客户Success Story 采写法则三 · 真实瓶颈不在这一步采写瓶颈在客户授权与真实访谈，不在文字生成；没有授权编号的案例不能发现场话术：稿子好写，授权难拿——先解决授权流程，再谈成稿。需求自动排优先级（AI 直接定序）法则三· 真实瓶颈不在这一步优先级是资源分配决策，决策权在评审会；AI 给的应该是证据链与打分依据（PM-01 的产

出），不是答案现场话术：哪条需求先做，这个决定我们永远不替您做——我们保证的是您做决定时，每条需求背后站着可指认的客户。帮助中心多语言全自动翻译发布法则三 · 真实瓶颈不在这一步翻译质量不是瓶颈，术语一致性与发布审核才是；全自动发布等于把未验证的示例直接推给客户（金融接口的示例错一行就是事故，见 DV-02 验证规则）现场话术：翻译能做，发布必须人审——跟迁移示例同一个道理，验证关卡不能拆。SaaS 客户健康分与流失预警（全信号版）数据门槛 · 多源打通需要同时打通产品埋点、CRM、工单三源数据，中小公司数据基础参差（B 组调研对中小客户已按此调高落地难度）；降级切口是 PM-01 的工单语义聚类——先把工单这座现成的矿挖起来，健康分所需的工单信号同步就在攒现场话术：全信号健康分需要三套数据打通，您的埋点和 CRM 现在能对上吗？对不上就先从工单开始（PM-01）——它本来就是健康分最重的信号源之一。数据库 Schema 变更全链影响分析数据门槛 · 多源打通需代码库与数据字典双向打通，且依赖元数据质量；对多数客户，「Schema 变更前评估」退化为 DBA 人工排查现场话术：这个的前提是您的数据字典还活着；多数团队的字典比文档死得更早。项目范围蔓延实时检测（SOW 持续比对）数据门槛 · 结构化前提需要 SOW 结构化 + 工时台账实时归档两个前提；在 DL-02 的日志归档跑起来之前，实时比对无从谈起——先攒台账，后有检测现场话术：范围蔓延的检测要拿台账实时对——您的实施日志现在还在群消息里，先把 DL-02 跑三个月。竞品情报全自动监控（无人工归集）数据门槛 · 信源质量全自动抓取的信源质量不可控（Beta 功能当正式功能、拆分报价当一口价——PS-02 里两个真实坑）；公开资料的归集要保留人工核对关卡，否则矩阵的口径分级失真现场话术：竞品官网会骗人——Beta 写成正式上线那种；全自动监控省的人工会加倍还在口径纠错上。

声明这套东西不承诺什么

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

这是演示与验证资产，不是已接入生产系统的软件所有 Live Demo 页面展示的是「应该怎么跑、每一步看什么、交付什么」，使用的是真实业务格式的脱敏构造数据（虚构公司明衡软件及其客户），不冒充任何真实厂商的生产数据。不承诺效率提升百分比本场景库不出现任何「32 小时压到 3 小时」「提效 90%」这类数字——没有用客户自己的单据实测过，这种数字说出来就是砸口碑。我们讲的是可核实的能力差异：命中了多少题、拦了几处错承诺、归因拆成了几类。拿不到的数据会明确说拿不到历史标书已随离职售前带走、实施记录只存在于群消息、API 规范文件从未建过——这些情况会在交付物里写清「本项无法核实，建议补录」，而不是估一个数填上去。高风险动作只建议不执行偏离表终稿、验收结论与签字、合规应答提交、对外报价、生产变更发布、客户通知发送——这六类动作本场景库全部只出草稿、清单和依据，不代替人做决定，也不自动执行。产出是初稿与清单，最终签字权在人所有正式交付物都留有编制/审核/会签/批准签批栏，偏离判定、验收结论、责任认定、弃用承诺这几栏一律留空——自己给自己打分的报告，没人会信。

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

回到场景总览 →

来源说明

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

场景审核

场景审核 · WorkBuddy · 软件与SaaS场景库

先过场景不急着做素材

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

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

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

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

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

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

清空选择

返回总览

售前

售前解决方案

把销售许出去的每句话变成敢写进合同的技术口径——RFP 答过的不重写，没答过的不瞎编

2 个

PS-01

10.0

RFP 应答初稿与错承诺拦截 —— 八成题答过，要命的是没答过还敢承诺单份 RFP 平均 32 小时、7 人参与 · 其中八成问题是上一份标书里答过的

保留

待讨论

后置

PS-02

8.8

竞品对比矩阵与讲标弹药 —— 客户拿着竞品报价单逐条对问的那一刻加急竞品专项 3-5 人 × 3 天 ≈ 1.4 万元 · 而讲标答辩只给你 30 秒反应时间

保留

待讨论

后置

交付

交付实施

让每一步实施都留下能拿上仲裁庭的证据——验收按功能点逐项对，延期按责任逐天归因

2 个

DL-01

7.5

验收报告初稿与功能点核对 —— 72 个功能点逐项对，5 项不达标各有各的处置法院的验收判定框架就一句话：需求书功能点逐项是否实现 · 而多数团队的核对表在验收前夜才拼出来

保留

待讨论

后置

DL-02

11.0

实施日志归档与延期归因 —— 37 天延期，21 天是客户的、11 天是变更的、5 天认回来延期罚金每周 0.5%-1%、上限合同额 10% · 归因错一天，都是真金白银

保留

待讨论

后置

产品

产品管理

把六个渠道涌进来的声音收成一条证据链——谁提的、几家客户、值多少 ARR，而不是谁声音大做谁

2 个

PM-01

11.0

需求池多源收口与语义去重 —— 「深色主题」从三个渠道进来就是三条记录PM 每周 12+ 小时收集管理反馈 · 同一个需求换个说法就是三条记录

保留

待讨论

后置

PM-02

8.0

基于自有需求库的 PRD 初稿 —— 评审会 3 小时，八成时间耗在信息对齐每场需求评审会 3 小时以上，其中八成时间在补背景、对数据、讲竞品 · 决策反而没时间

保留

待讨论

后置

研发

研发与开发者文档

让文档跟上代码——客户集成联调卡住的那一刻，过时文档的利息就到期了

2 个

DV-01

8.8

API 文档与代码同步巡检 —— 75% 的生产 API 和它们的规范对不上44% 的开发者只能直接翻源码理解 API 行为 · 过时文档的利息，在客户联调卡住那一刻到期

保留

待讨论

后置

DV-02

7.5

发布说明与迁移指南起草 —— 发了 changelog 不等于更新了文档，这是两件事Stripe 给 12 个月迁移期 · 而「发了条changelog 就当文档更新完了」是全行业的默认操作

保留

待讨论

后置

审核进度未选择 8

交付说明

交付说明 · WorkBuddy · 软件与SaaS场景库

软件与SaaS场景库怎么用这套东西

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

包含 4 个子角色、8 个场景、24 个内容页、

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

8完整场景

24三件套页面

26明确不做的伪需求

53可核验来源

路径三种人怎么看

客户初次看

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

打开场景总览

现场演示

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

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

看一个完整 Demo

内部选型

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

打开场景审核

话术现场必备的三句话

开场 · 先说 AI 做不到什么

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

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

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

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

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

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

收尾 · 三个问题要金额

「你们上一次 RFP 应答里写「支持」而实际要等下个版本的功能，客户发现后花了多少代价收场？80% 在不同标书里重复出现的问题，第二遍是从历史库调的，还是从零重写的？延期违约金谈判桌上，实施日志翻得出按天划分的责任记录吗？」

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

状态已完成与未冒充完成

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

明确未冒充完成尚未接入任何客户的生产系统素材是真实业务格式的脱敏构造数据，不是客户生产数据场景尚未用客户自己的原始文件实跑过（这是下一步）有来源支撑不等于完成客户一手验证没有实测前不出现任何效率提升百分比投标应答终稿提交、验收结论签署、对外承诺功能与工期、报价终审、生产环境变更、安全问卷提交一律人工

下一步怎么往前推

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

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

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

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

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