DL-01 · 验收报告初稿与功能点核对

① 场景引入

一、这件事现在是什么样

交付实施 · 真实业务触发

优选百货项目到验收节点：合同需求确认书列了 72 个功能点，UAT 演示当天 5 项不达标——其中 1 项（供应商对账单导出格式）是当初销售口头承诺、合同里没有写的；客户方验收委员会要求三日内提交逐项核对报告，付款节点（合同额 30%）卡在验收签字上。

二、痛点 · 每条都有来源

1司法实践以「需求书功能点逐项是否实现」为验收判定框架，演示时功能不能实现即可能构成根本违约、返还首期款依据 · (2020) 最高法知民终 1545 号（武汉中新蓝案）：定制开发合同约定 4 端 26 模块 72 个功能点，验收标准明确为「需求书功能点是否实现」；交付 UI 图被发现是其他项目改名，演示时功能不能实现，被认定未实质开发构成根本违约，返还已收 11 万元首期款2验收条款是争议高发地：缺乏双方认可的缺陷优先级定义，会导致「验收不完整、带病上线」——客户应有自建测试用例权依据 · 验收条款争议分析：SOW 若强制用厂商测试计划、缺乏双方认可的缺陷优先级定义，会导致「验收不完整、带病上线」——客户应有自建测试用例权和缺陷升级通道3《验收补充说明（承诺函）》和系统故障赔付记录在司法案例中成为关键证据——验收阶段的每一个字都有证据属性依据 · 承德中院 2026 年度典型案例：乙方出具的《验收补充说明（承诺函）》和系统故障赔付记录成为「未达到合同约定的连续稳定运行六个月付款条件」的关键证据，合同解除、反诉全部被驳回4合同额 30% 的付款节点通常卡在验收签字上——核对表拖一天，回款就晚一天依据 · SaaS 实施 SOW 标准结构：4-6 个里程碑（kickoff→设计评审→测试环境→验收签字→生产上线→hypercare）；典型付款 30%（签约）/30%（验收）/40%（上线）；延期罚金惯例每周 0.5%-1%、上限合同额 10%5云软件实施纠纷六大高频争点里「功能不达标」排第二，日志与测试记录是仲裁的关键证据链依据 · 云软件实施纠纷的六大高频争点：实施延期（触发违约金）、功能不达标、培训支持不足、数据迁移出错、SLA 违约、提前终止与退款；法律界明确提示「日志、测试报告、沟通记录是仲裁的关键证据链」

三、换个做法之后

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

✕ 现在的做法

• 司法实践以「需求书功能点逐项是否实现」为验收判定框架，演示时功能不能实现即可能构成根本违约、返还首期款验收条款是争议高发地：缺乏双方认可的缺陷优先级定义，会导致「验收不完整、带病上线」——客户应有自建测试用例权《验收补充说明（承诺函）》和系统故障赔付记录在司法案例中成为关键证据——验收阶段的每一个字都有证据属性合同额 30% 的付款节点通常卡在验收签字上——核对表拖一天，回款就晚一天

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 功能点清单结构化72 项逐条编号对齐需求书原文，验收标准逐项落地
2. 证据链逐项挂接每个功能点挂测试记录/演示日期/函件编号——没证据的实现状态标「待补证」
3. 不达标项分类5 项逐项定性：可实现缺陷 / 需求理解偏差 / 合同外事项（口头承诺）
4. 处置建议起草返修期限 / 降级上线条件 / 合同外协商口径——每条给依据，决策留给人
5. 核对报告成稿与签批流转双方验收委员会逐项签字栏留空，附证据附件索引

要准备什么：合同/SOW 与需求确认书72 个功能点的编号、原文与验收标准——核对表的唯一合法基准UAT 测试记录与演示勘验记录5 项不达标的第一现场证据，含日期与在场人双方往来函件（变更确认/暂停通知/催办）口头承诺有没有被书面追认，全看这里缺陷清单（当前未关闭项）带优先级与责任人——处置建议的事实基础

为什么这个场景值得做

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

最大差异点：核对表不是验收前夜赶出来的表格，而是从实施第一周就开始滚动的证据链：每个功能点的实现状态对应「哪次测试记录/哪天演示/哪份往来函件」——72 个功能点逐项有证据，5 项不达标各有处置路径（返修/降级上线/合同外协商），而不是笼统一句「基本完成，建议通过」。

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

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

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

五、会产出什么

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

• 正式件本体：验收核对报告初稿.docx 正式件 · 72 项逐项核对 + 证据索引 + 处置建议 · 双方签批栏留空
• 可派发清单：不达标项处置跟踪表.xlsx 5 项 · 定性/处置路径/期限/责任人 · 每天可跟
• 可派发清单：合同外事项与待补证清单.xlsx 口头承诺事项 / 待补证据项 · 供双方协商与补证

这套东西不承诺什么：验收结论与签字栏必须由双方验收委员会填写，本场景只出核对初稿与证据汇编；口头承诺未进合同的功能点如实标注「合同外事项」，不美化、不隐匿；缺陷优先级按双方 SOW 约定分级，没有约定的按行业惯例分级并标注「待双方确认」。

② Live Demo（演示逐步）

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

案例设定：明衡软件交付部。优选百货 SCM 一期（合同额 120 万）到验收节点：72 个功能点演示后 5 项不达标，客户验收委员会要求三日内提交逐项核对报告——验收款（合同额 30%，36 万）卡在验收签字上。

输入文件4 份功能点72 项 · 不达标 5验收款合同额 30% · 36 万客户期限三日内提交核对报告

输入软件公司手上能拿到的东西

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

• 01_合同需求确认书_优选百货.xlsx 合同附件需求确认书的功能点清单——验收判定的唯一基准双方签署 · 2026-03 冻结版
• 02_UAT与勘验记录_优选百货.xlsx 验收演示与 UAT 的双方在场记录——每个功能点通过状态的证据源交付部记录 ·验收周当场形成
• 03_缺陷清单与修复记录_优选百货.xlsx 验收周缺陷单与修复记录——厂商侧 5 天的逐日对应研发部缺陷系统导出 · 验收周
• 04_往来函件与会议纪要_优选百货验收.txt 验收阶段往来函件与纪要节选——合同外事项与付款节点的书面依据交付部归档 · 验收周

注意标橙色那一份 —— 02_UAT与勘验记录_优选百货.xlsx。它交付部记录 · 验收周当场形成，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

优选百货到验收了。这是合同和需求确认书，72 个功能点；这是 UAT 测试记录和演示当天的勘验记录，5 项不达标；这是双方往来的函件和变更确认，还有当前的缺陷清单。 帮我做逐项核对：每个功能点对上「测试记录/演示日期/函件编号」这类证据，没证据的标出来。5 个不达标项逐项定性——是缺陷、是理解偏差、还是合同外的事，定性要给依据，处置建议给路径但别替我们做决定。 销售当初口头答应过「对账单导出格式定制」但合同里没有——这项怎么处理，给我选项别替我定。核对报告按双方签批的格式出。

功能点核对表结构、缺陷优先级分级、证据链格式全部在能力包里；现场只需给四样：需求确认书、测试与勘验记录、往来函件、缺陷清单。

触发72 项功能点演示完 · 5 项不达标，付款节点卡在验收签字上

三日内交逐项核对报告——过去这种报告在验收前夜才拼凑出来

验收周（8 月 25-27 日）演示与 UAT 走完，8 月 28 日客户函件到了。核对报告过去的状态是：通过项「基本完成」四个字、不达标项含糊带过——这一次逐项对、逐项给证据、逐项给处置路径。

第 1 步 · 模块盘点 · 67 通过 + 5 不达标 = 72，一顶帽子都扣不下来

逐模块对功能点清单——每个数字都能回溯到勘验记录

第 2 步 · 证据链分组 · 43 项勘验 + 24 项 UAT + 5 项不达标，各有各的效力

司法口径下「双方在场」的记录效力最高——证据类型分了组

35 项不达标逐项定性 · 缺陷、偏差、合同外，各有各的处置路径

笼统的「基本完成」拆成可执行的处置——每项有期限有责任人

编号模块问题定性处置路径U-01报表中心定制报表模板渲染错位缺陷已修复 · 附 D-2401 复测记录U-02报表中心报表导出字段缺失缺陷已修复 · 附 D-2402 复测记录U-03结算对账对账单币种口径与需求书不一致偏差出具偏差说明 · 客户确认后签字U-04结算对账汇率折算精度两位 vs 需求书四位偏差调整精度或修订需求书 · 二选一U-05单据导出供应商对账单导出格式合同外转商务协商 · 不入验收范围定性依据司法判例口径：缺陷=应实现而未正确实现；偏差=实现了但口径不一致；合同外=需求确认书未列、无验收义务。从历史里想起的偏差根子U-03 币种口径偏差的根子在 3 月的需求冻结阶段——当时没人问「多币种按什么口径算」。而这条链的上游是销售在售前阶段的口径松动（见 PS-01 第 26 题拦截记录），下游会流进 PM-01 的需求池。偏差不是实施做错了什么，是口径从来没对齐过——这份核对报告把证据留下来了，下一次需求冻结时有人会翻到。

第 4 步 · 回款与风险的账 · 36 万验收款与顶格 6 万违约金

核对报告每拖一天，回款晚一天——数字摆在明处

IO成稿 · 核对报告初稿 + 处置跟踪 + 合同外清单

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

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

1. Skill 能力包

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

验收报告初稿与功能点核对 —— 72 个功能点逐项对，5 项不达标各有各的处置 · Skill

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

版本 v1.0

acceptance-report-and-feature-check.zip

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

包内结构

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

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

2. 原始素材

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

📁DL-01 · 演示素材

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

共 4 份

• 01_合同需求确认书_优选百货.xlsx 合同附件需求确认书的功能点清单——验收判定的唯一基准
• 02_UAT与勘验记录_优选百货.xlsx 验收演示与 UAT 的双方在场记录——每个功能点通过状态的证据源
• 03_缺陷清单与修复记录_优选百货.xlsx 验收周缺陷单与修复记录——厂商侧 5 天的逐日对应
• 04_往来函件与会议纪要_优选百货验收.txt 验收阶段往来函件与纪要节选——合同外事项与付款节点的书面依据

怎么用

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

3. 提示词卡片

优选百货到验收了。这是合同和需求确认书，72 个功能点；这是 UAT 测试记录和演示当天的勘验记录，5 项不达标；这是双方往来的函件和变更确认，还有当前的缺陷清单。 帮我做逐项核对：每个功能点对上「测试记录/演示日期/函件编号」这类证据，没证据的标出来。5 个不达标项逐项定性——是缺陷、是理解偏差、还是合同外的事，定性要给依据，处置建议给路径但别替我们做决定。 销售当初口头答应过「对账单导出格式定制」但合同里没有——这项怎么处理，给我选项别替我定。核对报告按双方签批的格式出。

为什么这么短就够了：功能点核对表结构、缺陷优先级分级、证据链格式全部在能力包里；现场只需给四样：需求确认书、测试与勘验记录、往来函件、缺陷清单。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

XLSDL-01_验收核对报告初稿.docx正式件 · 72 项逐项核对 + 证据索引 + 处置建议 · 双方签批栏留空下载

• ↓XLSDL-01_不达标项处置跟踪表.xlsx 5 项 · 定性/处置路径/期限/责任人 · 每天可跟
• DL-01_合同外事项与待补证清单.xlsx 口头承诺事项 / 待补证据项 · 供双方协商与补证

Skill 里固化了什么：「供应商对账单导出」被标成了合同外事项72 项里 67 项证据链完整排除性结论把技术动作翻译成钱

输入清单：合同/SOW 与需求确认书72 个功能点的编号、原文与验收标准——核对表的唯一合法基准UAT 测试记录与演示勘验记录5 项不达标的第一现场证据，含日期与在场人双方往来函件（变更确认/暂停通知/催办）口头承诺有没有被书面追认，全看这里缺陷清单（当前未关闭项）带优先级与责任人——处置建议的事实基础

人工边界：验收结论与签字栏必须由双方验收委员会填写，本场景只出核对初稿与证据汇编；口头承诺未进合同的功能点如实标注「合同外事项」，不美化、不隐匿；缺陷优先级按双方 SOW 约定分级，没有约定的按行业惯例分级并标注「待双方确认」。

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

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

交付实施 · 产出即下一步输入

DL-02 · 实施日志归档与延期归因 —— 37 天延期，21 天是客户的、11 天是变更的、5 天认回来 — 延期罚金每周

0.5%-1%、上限合同额 10% · 归因错一天，都是真金白银 查看 →

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

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