PS-01 · 需求澄清纪要

① 场景引入

一、这件事现在是什么样

售前与方案 · 真实业务触发

林嘉怡陪梁总去精工拜访回来，录音两小时、微信里聊了一晚上。何志远（技术经理兼售前）收到的需求是：「精工要上装配自动线，预算 200 左右，下周出方案」。何志远的方案返工记录：过去一年 7 个方案里 5 个返工，返工理由Top1是「客户说这不是他们要的」。

二、痛点 · 每条都有来源

1. 「做个方案，明天就要」是售前的日常：销售晚上与客户聊嗨了听到一个需求，一个电话让售前忙活一两周，材料交上去石沉大海 —— 方案返工的根因不是售前不行，是需求在传递中只剩一句话
   依据：「做个方案，明天就要」是售前的日常：销售晚上与客户聊嗨了听到一个需求，一个电话让售前忙活一两周，材料交上去石沉大海 —— 方案返工的根因不是售前不行，是需求在传递中只剩一句话
2. 售前被三个方向挤压：销售嫌「只会拽专业术语」、售后吐槽「过度承诺」、客户认定「只是销售的小跟班」，没中标时被一句「方案不行」轰成渣 —— 需求没澄清清楚，锅最后都是方案的
   依据：售前被三个方向挤压：销售嫌「只会拽专业术语」、售后吐槽「过度承诺」、客户认定「只是销售的小跟班」，没中标时被一句「方案不行」轰成渣；凌晨一点被销售总监电话叫起来改配置清单也是常态
3. 规范做法是需求澄清文档 + 客户逐条签字确认形成《需求确认清单》，避免后期需求变更争议 —— 模板极其成熟，但中小企业没人在拜访后花两小时整理录音
   依据：规范做法是需求澄清文档 + 客户开需求评审会逐条签字确认形成《需求确认清单》，避免后期需求变更争议 —— 模板极其成熟，但中小企业没人在拜访后花两小时整理录音

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 「做个方案，明天就要」是售前的日常：销售晚上与客户聊嗨了听到一个需求，一个电话让售前忙活一两周，材料交上去石沉大海 —— 方案返工的根因不是售前不行，是需求在传递中只剩一句话
• 售前被三个方向挤压：销售嫌「只会拽专业术语」、售后吐槽「过度承诺」、客户认定「只是销售的小跟班」，没中标时被一句「方案不行」轰成渣 —— 需求没澄清清楚，锅最后都是方案的
• 规范做法是需求澄清文档 + 客户逐条签字确认形成《需求确认清单》，避免后期需求变更争议 —— 模板极其成熟，但中小企业没人在拜访后花两小时整理录音

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 原话还原 · 逐条带时间戳客户说的每条需求保留原话 —— 「节拍要快一点」和「12 秒以内」是两种完全不同的需求等级
2. 结构化拆解 · 显性需求/隐性需求/约束条件业务需求、功能需求、非功能需求（精度/节拍/占地）+ 约束（预算/工期/技术栈）分列 —— 隐性需求标注推断依据
3. 矛盾检测 · 自相矛盾的需求点「要上三班连续运转」vs「设备部说周末不生产」、「预算 200」vs「提到的配置清单市价 260+」—— 矛盾不裁决，列出来给客户确认第4 步决策链还原 · 谁把关谁拍板谁用采购部长（把关）、设备部长（使用者）、生产副总（拍板）、技术科（评

估）、财务（付款）—— 每人立场与关注点标注，拜访策略由此定第 5 步确认清单 · 要客户签字的那份23 条需求逐条「确认/修正/删除」栏 + 未决问题 4 条 —— 销售下次拜访带着它逐条过，客户签完字，方案的靶子就钉死了

要准备什么：拜访录音（手机录音文件，两小时以内）最原始也最真实的需求现场与客户的微信聊天记录（导出或截图）口头没聊透的，微信里往往补了刀销售的口述补充（想到哪说到哪即可）录音之外的判断与背景 —— 标注为「销售判断」与客户原话分开历史需求文档（如有）同客户上次提过的需求 —— 对比变化

为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 4 ÷ 落地难度 2 = 10.0

最大差异点：不要求销售会写纪要。两小时录音（手机录音文件直接扔）+ 微信聊天记录 + 销售的口述补充 —— 需求清单、决策链、矛盾点自动还原，销售只要带着清单去跟客户确认。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：需求澄清纪要与确认清单.xlsx 23 条需求逐条 + 确认栏 + 未决问题 · 客户签字版
• 可派发清单：需求矛盾与缺口清单.xlsx 3 条矛盾 + 4 条缺失 · 逐条给确认话术
• 可派发清单：决策链图谱.xlsx 五人角色 × 立场关注点 ·拜访与方案策略

这套东西不承诺什么：不做「需求该不该接」的判断 —— 那是梁总的生意决策。本场景做的是还原：客户说了什么、哪些自相矛盾、决策链是谁、什么没说清 —— 整理成可签字的确认清单，澄清由销售与客户当面做。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：沃德智能装备（虚构）方案开工前：林嘉怡与梁总昨天拜访精工汽车零部件，录音 2 小时 06 分、微信当晚又聊了一阵。售前何志远等着开工 —— 他收到的需求是一句「精工要上装配自动线，预算 200 左右，下周出方案」。录音时长2h06m还原需求23 条矛盾+缺失3 + 4 条结论暂缓开工 · 7 问确认后动工

输入销售手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_拜访录音转写（节选）.txt 两小时录音的机器转写 —— 需求的第一现场林嘉怡手机录音 · 2026-08-19 14:00-16:06
• 02_微信沟通记录（当晚）.txt 拜访当晚的微信补充 —— 口头没聊透的，微信里补了刀林嘉怡与精工采购部长 · 2026-08-19晚
• 03_销售口述背景.txt 林嘉怡的口述补充 —— 判断与背景（与客户原话分列的软信息）林嘉怡口述 · 2026-08-20
• 04_上次小方案返工复盘.txt 2024 年上料机构改造项目的返工记录 —— 同款坑的档案项目复盘邮件存档 · 2024-11

注意标橙色那一份 —— 03_销售口述背景.txt。它林嘉怡口述 · 2026-08-20，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

昨天去精工聊了两个多小时，录音和微信记录都发你了，我再口述几句背景你记一下。 帮我把客户的需求一条条理出来，原话尽量保留，别给我加工成漂亮话。 哪几条是自相矛盾的、哪些关键信息他们没说清楚的，单独列出来，我明天打电话确认。 决策链也帮我理一下，谁拍板谁使用。 最后给我一份能让我客户逐条签字确认的清单，方案那边等这份东西定了再动手。

短是因为「需求三分类、矛盾检测口径、决策链模板、确认清单结构」都在能力包里。销售只要把录音和聊天记录扔进来。

触发一句「预算 200 左右」要变成下周的方案

过去一年 7 个方案 5 个返工 —— 返工 Top1 理由「客户说这不是他们要的」

第 1 步 · 原话还原 · 23 条需求逐条带时间戳

「节拍要快一点」和「12 秒以内」是两种需求等级 —— 原话是唯一可靠的分界

第 2 步 · 矛盾检测 · 三处自相矛盾

矛盾不裁决 —— 列出来给客户确认

第 3 步 · 关键信息缺口 · 四个没说清的

缺的恰恰是上次返工的那一类 —— 具体编号与尺寸

第 4 步 · 决策链还原 · 五个人五个关注点

谁把关、谁拍板、谁使用 —— 拜访与方案策略的地基

第 5 步 · 确认清单 · 半页纸，客户签个字

23 条需求逐条「确认/修正/删除」+ 7 个未决问题 —— 方案的靶子钉死

确认清单按「销售明天一个 15 分钟电话能问完」的密度组织 —— 不做成给客户的问卷（没人填），而是销售拿着清单逐条口头确认、微信留痕。客户签字最好，留痕是底线。

这份需求还不能交给售前开工 —— 7 个问题确认前，返工概率 5/723 条需求里 3 条自相矛盾、4 条关键信息缺失（含上次返工同款的产线编号）—— 照现状开工，按过去一年的返工记录（7 个方案 5 个返工），这个方案大概率重蹈覆

辙。给出的不是干等：方案 A（今天确认）：林嘉怡下午一个电话逐条确认 7 问（15 分钟）+ 约周五现场勘测（半天，产线编号与工位尺寸一测即定）—— 何志远下周一开工，比「先做着回头改」省的返工约 15 人日（上次返工的实测成本）。方案 B（客户时间约不上时）：方案按双轨写 —— 矛盾点各出一个版本（两班型含税 177 档 / 三班型 200档），缺口项全部标注「假设条件」—— 多花约 3 人日，但客户确认前的每次沟通都有方案可谈，不空转。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 需求从「一句话微信」变成 23 条带原话的结构化清单 —— 方案的靶子第一次钉死
• ✓ 「客户签字确认」成为方案开工的前置条件 —— 需求变更争议有了依据
• ✓ 矛盾需求在方案开工前暴露 —— 5/7 的返工率从源头断流
• ✓ 决策链图谱指导拜访策略 —— 拍板人的关注点与使用者的话术分开准备

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 客户不肯签字确认怎么办？ 把清单做成会议纪要形态发工作群留痕 —— 客户不签，但「已发已读」的记录也是争议时的依据。签字最好，留痕是底线。
• 销售口述的判断和客户原话混在一起怎么办？ 纪要里两类信息分列标注 —— 客户原话带时间戳、销售判断标「推断」。给售前的是两种可信度不同的输入，不能混。
• 每个项目都要做这么细吗？ 大单（百万级或方案复杂）必做；小单做轻量版（只做矛盾检测和决策链）—— 能力包里有分档口径。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

需求澄清纪要 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

requirement-clarify.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是销售手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁PS-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_拜访录音转写（节选）.txt 两小时录音的机器转写 —— 需求的第一现场
• 02_微信沟通记录（当
• 晚）.txt 拜访当晚的微信补充 —— 口头没聊透的，微信里补了刀
• 03_销售口述背景.txt 林嘉怡的口述补充
• —— 判断与背景（与客户原话分列的软信息）
• 04_上次小方案返工复盘.txt 2024 年上料机构改造项目的返工记录 —— 同款坑的档案

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

昨天去精工聊了两个多小时，录音和微信记录都发你了，我再口述几句背景你记一下。 帮我把客户的需求一条条理出来，原话尽量保留，别给我加工成漂亮话。 哪几条是自相矛盾的、哪些关键信息他们没说清楚的，单独列出来，我明天打电话确认。 决策链也帮我理一下，谁拍板谁使用。 最后给我一份能让我客户逐条签字确认的清单，方案那边等这份东西定了再动手。

为什么这么短就够了：短是因为「需求三分类、矛盾检测口径、决策链模板、确认清单结构」都在能力包里。销售只要把录音和聊天记录扔进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

XLSPS-01_需求澄清纪要与确认清单.xlsx正式件本体 · 23 条需求逐条 + 确认栏 + 未决问题 · 客户签字版下载

• ↓XLSPS-01_需求矛盾与缺口清单.xlsx 3 条矛盾 + 4 条缺失 · 逐条给确认话术
• PS-01_决策链图谱.xlsx 五人角色 × 立场关注点 · 拜访与方案策略

Skill 里固化了什么：从上次方案里翻出了同款返工该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：拜访录音（手机录音文件，两小时以内）最原始也最真实的需求现场与客户的微信聊天记录（导出或截图）口头没聊透的，微信里往往补了刀销售的口述补充（想到哪说到哪即可）录音之外的判断与背景 —— 标注为「销售判断」与客户原话分开历史需求文档（如有）同客户上次提过的需求 —— 对比变化

人工边界：不做「需求该不该接」的判断 —— 那是梁总的生意决策。本场景做的是还原：客户说了什么、哪些自相矛盾、决策链是谁、什么没说清 —— 整理成可签字的确认清单，澄清由销售与客户当面做。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

售前与方案 · 产出即下一步输入

PS-02 · 拜访前作战简报 — 最尴尬的瞬间：人站在客户公司门口，才开始手忙脚乱翻找上次的沟通记录 查看 →PS-03· 报价测算表生成 — 报价单发出去就石沉大海 · 因为客户财务那边一眼看出合价没对上，而没人回头检查 查看

→PS-04 · 方案初稿组装（带出处） — AI 写的方案漂亮极了 · 直到客户技术总监问「这个参数哪来的」，全场安静查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。