CH-01 · 需求变更留档登记

① 场景引入

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

一、这件事现在是什么样

变更与指令 · 真实业务触发

v3.4 开发第二周，郑海洋在客户群里答应华正：「导出格式加个 Excel 模板选择」。研发群里谭锐看到后问江晓：「这是新增需求还是改动？谁批的？」江晓翻聊天记录 —— 昨天沈知行在电梯里口头说过「可以加」，但没有任何书面记录。这类变更这个迭代已经发生四次：两次来自客户群、一次来自研发自优化、一次就是电梯里那句。每一次都改了代码，没有一次进过台账。

二、痛点 · 每条都有来源

1. 项目后期的普遍事故根源：「搞不清哪些需求满足了、哪次变更谁批的」—— 口头变更不留档，验收与追责两头都是糊涂账
   依据：发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out of Scope）是对外交付的护身符
2. Agent 项目 90% 以上试点失败的第一死因是责任归属 —— 变更是责任最密集的场景：谁提的、谁批的、影响什么，每一环都要有人签字
   依据：Agent 项目的行业失败率：麦肯锡统计超 90%企业 Agent 试点即失败，「Demo 惊艳、两周被叫停」的复盘直指责任归属无人敢碰 —— 每个场景必须有人拍板点
3. 「AI 消化 AI、链条里没人用大脑」的教训反过来用：变更的每一次发生都把原始记录（聊天/语音/群消息）留档 ——留痕本身就是交付证据
   依据：「越快越慢」的机制：AI 把没想清楚的部分填成看似完整的八千字，看似提速、实则把推敲成本后置给研发；15 页 AI PRD 没人读、研发喂给自己的 AI 做总结 ——「AI 消化 AI，链条里没人用大脑」

三、换个做法之后

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

✕ 现在的做法

• 项目后期的普遍事故根源：「搞不清哪些需求满足了、哪次变更谁批的」—— 口头变更不留档，验收与追责两头都是糊涂账
• Agent 项目 90% 以上试点失败的第一死因是责任归属 —— 变更是责任最密集的场景：谁提的、谁批的、影响什么，每一环都要有人签字「AI 消化 AI、链条里没人用大脑」的教训反过来用：变更的每一次发生都把原始记录（聊天/语音/群消息）留档 —— 留痕本身就是交付证据

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 变更识别 · 哪些算变更新增/修改/删除/口径调整四类 —— 客户群的一句「加个模板选择」识别为「新增功能点」
2. 台账登记 · 每行可回溯变更内容/提出人/决策人/时间/影响版本 —— 每个字段带原始记录引用
3. 影响范围分析 · 顺藤摸瓜受影响模块/接口/在途测试用例/排期顺延 —— 从需求清单与模块表反查
4. 决策留痕 ·谁批的写清楚电梯里的口头批准也登记（标注「口头·未书面确认」）—— 事后补书面确认的流程挂上
5. 迭代账本 · 本期变更总览四次变更/新增 2/修改 1/自优化 1 —— 评审延期与工时顺延的账一起算

要准备什么：变更的原始记录客户群消息、研发群讨论、老板语音 —— 发生什么样就扔什么样本迭代需求清单变更挂接的对象 —— 影响范围判断的基线研发的模块与排期表影响哪些模块、顺延多少 —— 影响范围的原料历史变更记录（如有）本迭代已发生的变更 —— 台账是累计的

为什么这个场景值得做

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

最大差异点：不要求任何人先填变更单。变更发生的当下把原始记录（群消息截图/语音/邮件）扔进来 —— 台账当场生成，事后补录同样有效。

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

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

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

五、会产出什么

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

• 正式件本体：需求变更台账.xlsx 逐次登记 + 原话引用 + 状态
• 可派发清单：影响范围分析表.xlsx 每次变更的受影响模块/用例/排期顺延
• 可派发清单：口头待确认清单.xlsx 口头批准的变更 · 补书面确认的流程与模板

这套东西不承诺什么：不做「自动批准或拒绝变更」—— 生效与否是人的签字权。也不做「变更影响自动修改代码」—— 影响范围是提示，改不改研发定。

② Live Demo（演示逐步）

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

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

案例设定：驭数科技（虚构）v3.4 开发第二周：郑海洋在客户群里答应华正「导出格式加个 Excel 模板选择」。研发群里谭锐问江晓：「这是新增需求还是改动？谁批的？」江晓翻聊天记录 —— 昨天沈知行在电梯里口头说过「可以

加」，但没有任何书面记录。这类变更本迭代已经发生四次，每一次都改了代码，没有一次进过台账。

本迭代变更4 次 · 零留档累计影响排期顺延 3 人日口头未确认1 次 · 电梯批准结论台账立起来 · 1 条待补书面确认

输入产品手上能拿到的东西

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

• 01_客户群聊天记录（华正）.txt 变更的第一现场 —— 销售答应客户的原始记录微信客户群 · 2026-08-18
• 02_研发群讨论（变更质疑）.txt 谭锐那句「谁批的」的上下文 —— 变更落地的必经之路微信研发群 · 2026-08-19
• 03_本迭代需求清单与排期.xlsx 变更挂接的基线 —— 影响范围的判断依据禅道导出 · v3.4 迭代 · 2026-08-08
• 04_本迭代已发生变更记录（补录）.txt 前三次变更的原始记录 —— 从聊天记录里考古出来的聊天记录考古 · 2026-08-20 整理
• 05_上迭代验收争议记录.txt 「搞不清哪些满足了」的旧伤 —— 台账缺失的实际代价v3.3 验收沟通记录 · 2026-07

注意标橙色那一份 ——02_研发群讨论（变更质疑）.txt。它微信研发群 · 2026-08-19，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

这周又冒出来四次变更：客户群里郑总答应的、研发自优化没打招呼的、还有昨天电梯里沈总口头说的那次，原始聊天记录都在这，本迭代的需求清单和排期表也附上。 每次变更都帮我登进台账：内容、谁提的、谁批的、什么时候 —— 原话引用都带上； 每个变更影响哪些模块、排期顺延多少，帮我摸一下； 电梯口头那次标出来 —— 口头的可以登记，但生效前要书面确认，流程给我一个； 研发那次自优化，到底是越权还是没等到回复，帮我从群记录里判断清楚； 最后给我本迭代的变更总账：四次的类型、代价、还有哪些没闭环。

短是因为「变更识别规则、影响范围反查、口头/书面分级、台账结构」都在能力包里。产品经理只要把原始记录扔进来。

触发第四次「半路加进来」vs 谭锐要的书面口径

口头变更不留档，验收与追责两头都是糊涂账

江晓把客户群记录、研发群讨论、迭代清单、四次变更的考古记录、上迭代的验收争议全部扔进来 —— 台账的骨架，一半靠记录、一半靠教训。

第 1 步 · 变更识别 · 四次各归各类

新增/修改/口径调整/环境适配 —— 类型不同，登记的要素不同

第 2 步 · 影响范围分析 · 顺藤摸瓜

每次变更动的是哪个模块、顺延多少 —— 从迭代清单反查

第 3 步 · 决策留痕 · 口头的怎么处理

意向可登记、生效须签字 —— 电梯批准的处理规则

第 4 步 · 旧账审计 · 台账缺失的代价

上迭代的验收争议 —— 这本台账要防的那类事故

第 5 步 · 迭代变更总账 · 给沈知行的版本

四次的类型、代价、闭环状态 —— 一页讲完

项数据说明本迭代变更次数4 次客户引发 3 / 内部 1排期顺延1 人日已发生 + 1.5 人日待确认缓冲剩 6 人日 → 剩 3.5 人日PRD 同步缺口1 处（缓存策略）已列入补档清单待书面确认1 条（模板选择）今天发沈知行微信确认这页总账的用途：周五的迭代例会上，变更不再是「怎么又加需求」的情绪议题，而是「缓冲还剩 3.5 人日、第 5 次变更要不要接」的数字议题 —— 台账把变更管理从道德问题变成容量问题。

台账还不能交付 —— 模板选择的书面确认没闭环，台账就有空行四次变更里，「Excel 模板选择」仍处于「口头批准·未书面确认」状态 —— 台账若带着这个空行交付，等于把「电梯批准」合法化了：下次的口头变更会指着这一行说「上次也没确认就登记了」。台账的信用建立在「每一行都有闭环」上，一个空行毁一整本。给出的不是干等：方案A（今天闭环·推荐）：江晓现在就把变更单发给沈知行微信（内容/影响/顺延 1.5 人日三行），他回「同意」截图—— 台账补上闭环证据，下午交付。成本：一次微信往返；方案 B（带条件交付）：台账先交付，该行标红「待确认· 24 小时未闭环自动升级至迭代例会」—— 交付不等人，但红字挂着，谁都看见。若沈知行明确不批，该变更从台账转入「拒绝」状态，排期顺延的 1.5 人日即刻回收，华正侧的沟通走 CX-02 承诺台账的校准流程。两案差的是「今天闭环」还是「红字挂 24 小时」—— 但都好过上迭代那种「查两天聊天记录、三方记忆三个版本」的考古现场。

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

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

• ✓ 「哪次变更谁批的」从糊涂账变成每行可回溯的台账 —— 验收与追责两头都有据
• ✓ 电梯口头批准有了处理规则 ——意向可登记、生效须签字，保护所有人
• ✓ 「研发自作主张」被群记录排除 —— 追责清楚，下次变更不再藏得更深
• ✓ 「就加一点点」的真实价格第一次被记录 —— 销售答应前的谈判有了数字依据

追问现场可能被问到的

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

• 补录的变更算数吗？ 算 —— 台账记录的是事实，什么时候补录不影响真实性。但补录间隔越久、原始记录越难找，趁热登记是纪律。
• 沈总嫌签字麻烦怎么办？ 书面确认不等于开会 —— 变更单发他微信，回个「同意」截图就算书面。门槛低到只剩责任。
• 变更台账跟需求池什么关系？ 需求池记「要不要做」，变更台账记「做的过程改了什么」—— 一条需求从入池到上线，两本账合起来才是完整档案。

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

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

1. Skill 能力包

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

需求变更留档登记 · Skill

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

版本 v1.0

change-ledger.zip

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

包内结构

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

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

2. 原始素材

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

📁CH-01 · 演示素材

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

共 5 份

• 01_客户群聊天记录（华正）.txt 变更的第一现场 —— 销售答应客户的原始记录

• 02_研发群讨论（变更质疑）.txt 谭锐那句「谁批的」的上下文 —— 变更落地的必经之路

• 03_本迭代需求清单与排期.xlsx 变更挂接的基线 —— 影响范围的判断依据

• 04_本迭代已发生变更记录（补录）.txt 前三次变更的原始记录 —— 从聊天记录里考古出来的

• 05_上迭代验收争议记录.txt 「搞不清哪些满足了」的旧伤 —— 台账缺失的实际代价 #### 怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）

• 粘贴下方提示词发送

• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这周又冒出来四次变更：客户群里郑总答应的、研发自优化没打招呼的、还有昨天电梯里沈总口头说的那次，原始聊天记录都在这，本迭代的需求清单和排期表也附上。 每次变更都帮我登进台账：内容、谁提的、谁批的、什么时候 —— 原话引用都带上； 每个变更影响哪些模块、排期顺延多少，帮我摸一下； 电梯口头那次标出来 —— 口头的可以登记，但生效前要书面确认，流程给我一个； 研发那次自优化，到底是越权还是没等到回复，帮我从群记录里判断清楚； 最后给我本迭代的变更总账：四次的类型、代价、还有哪些没闭环。

为什么这么短就够了：短是因为「变更识别规则、影响范围反查、口头/书面分级、台账结构」都在能力包里。产品经理只要把原始记录扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

• CH-01_需求变更台账.xlsx 正式件本体 · 逐次登记 + 原话引用 + 状态
• CH-01_影响范围分析表.xlsx 每次变更的受影响模块/用例/排期顺延
• CH-01_口头待确认清单.xlsx 口头批准的变更 · 补书面确认的流程与模板

Skill 里固化了什么：从历史变更里「想起」了上次的糊涂账该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：变更的原始记录客户群消息、研发群讨论、老板语音 —— 发生什么样就扔什么样本迭代需求清单变更挂接的对象 —— 影响范围判断的基线研发的模块与排期表影响哪些模块、顺延多少 —— 影响范围的原料历史变更记录（如有）本迭代已发生的变更 —— 台账是累计的

人工边界：不做「自动批准或拒绝变更」—— 生效与否是人的签字权。也不做「变更影响自动修改代码」—— 影响范围是提示，改不改研发定。

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

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

变更与指令 · 产出即下一步输入

CH-02 · 评审决议与待办登记 — 评审会开完，决议散在三个人各自的记忆里 · 一个月后「当时不是说好挂起吗」—— 没有纪要的会议等于没开 查看 →CH-03 · 老板口头指示翻译 — 老板周日晚上 60 秒语音：「巡检报告加个导出，最好下周就能用」· 翻译成需求卡需要三件事：原话、结构化、澄清问题 查看 →

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

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