DL-02 · 实施日志归档与延期归因

① 场景引入

一、这件事现在是什么样

交付实施 · 真实业务触发

优选百货项目累计延期 37 天，合同里的违约金条款（每周 0.5%）第一次真实地摆在桌上；客户方项目例会上直接发问：「这 37 天怎么算？」——项目经理手里只有散在群消息和个人笔记里的碎片记录，要在下次例会前给出一份经得起双方逐天对质的归因报告。

二、痛点 · 每条都有来源

1. 延期罚金惯例每周 0.5%-1%、上限合同额 10%——延期天数每归因错一天都是真金白银，而多数项目经理的记录散在群消息和个人笔记里
   依据：SaaS 实施 SOW 标准结构：4-6 个里程碑（kickoff→设计评审→测试环境→验收签字→生产上线→hypercare）；典型付款 30%（签约）/30%（验收）/40%（上线）；延期罚金惯例每周 0.5%-1%、上限合同额10%
2. 法律界明确提示：日志、测试报告、沟通记录是仲裁的关键证据链——实施周报必须会前一天发出、纪要书面化并传阅
   依据：云软件实施纠纷的六大高频争点：实施延期（触发违约金）、功能不达标、培训支持不足、数据迁移出错、SLA 违约、提前终止与退款；法律界明确提示「日志、测试报告、沟通记录是仲裁的关键证据链」
3. SaaS 实施塌方前兆之一是「SOW 模糊、买方义务无人承担」：客户主数据延迟、干系人不出席这类客户侧原因，不留痕就永远算在厂商头上
   依据：SOW 清单实践：很多项目延期始于「买方义务没人配备」（数据、测试、安全审批、干系人出席），SOW 必须按责任表（厂商/客户/第三方）指定每项唯一责任人
4. 仅 29% 软件项目完全成功，需求不清晰（39%）与范围蔓延（33%）是失败前两大根因——延期归因本身就该是实施的专业能力，而不是事后辩护
   依据：Standish Group

CHAOS Report 2024（5 万+ 项目）：仅 29% 软件项目完全成功，52% 受挑战，19% 取消；千万美元级大型项目成功率仅 6%；失败根因排序：需求不清晰 39%、范围蔓延 33%、计划不足 29%、沟通中断 25%、技术问题仅 17%（垫底）5「永不结束型」实施项目 85% 源于糟糕的客户数据——客户侧义务的延迟不逐日留痕，延期就全部变成厂商的依据 ·SaaS 实施侧一线经验：超过 85% 的「永不结束型」实施项目问题源于糟糕的客户数据；其余主因是「roadmap 依赖」——销售承诺了 roadmap 上未经产品确认的功能；塌方前兆：售后团队没参与 scoping、SOW 模糊、实施免费赠送、无联合成功计划；最佳实践：每周状态报告必须会前一天发出、会议纪要书面化并传阅6最高法判例：合同约定「变更须书面确认」，乙方主张口头新增的功能开发（合同额 2.5 倍以上）两审均败诉——变更不走书面确认，丢的不止延期天数，还有整块工作量依据 · (2022) 最高法知民终 56 号（广州电软案）：乙方主张合同外口头新增 63.42 万元功能开发（原合同额 24 万元的 2.5 倍以上），因合同约定「变更须书面确认」且无书面证据，两审均败诉

三、换个做法之后

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

✕ 现在的做法

• 延期罚金惯例每周 0.5%-1%、上限合同额 10%——延期天数每归因错一天都是真金白银，而多数项目经理的记录散在群消息和个人笔记里
• 法律界明确提示：日志、测试报告、沟通记录是仲裁的关键证据链——实施周报必须会前一天发出、纪要书面化并传阅
• SaaS 实施塌方前兆之一是「SOW 模糊、买方义务无人承担」：客户主数据延迟、干系人不出席这类客户侧原因，不留痕就永远算在厂商头上
• 仅 29% 软件项目完全成功，需求不清晰（39%）与范围蔓延（33%）是失败前两大根因——延期归因本身就该是实施的专业能力，而不是事后辩护

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 散装记录结构化归档群消息/笔记/邮件按日期线合并成实施日志，每条标责任方与证据
2. 里程碑对照与偏离计算计划基线 × 实际完成——37 天延期分段定位
3. 逐日归因初表21（客户主数据延迟）/ 11（需求变更）/ 5（厂商缺陷）——每段挂证据附件
4. 联动核对变更类天数对 PM-01 变更记录、缺陷类天数对 DL-01 缺陷清单——数字咬合才算闭合
5. 归因报告成稿逐日台账 + 三类责任汇总 + 处置建议，双方项目委员会确认栏留空

要准备什么：实施过程记录（群消息/个人笔记/邮件，散装）从 kickoff 到现在的原始碎片——归档的原料SOW 与里程碑计划计划基线——偏离了几天、偏在哪一段，全靠它对照双方往来函件与会议纪要客户侧延迟的第一证据（催办记录、数据交付延迟通知）需求变更记录（联动 PM-01）11 天变更类延期逐条对应：走了书面确认的、没走的，分开标为什么这个场景值得做

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

最大差异点：归因报告不是出事后的回忆录：实施日志从项目第一周就按「日期/事项/责任方/证据/影响天数」滚动归档，37 天延期拆成「21 客户主数据延迟 + 11 需求变更未走书面确认 + 5 厂商缺陷修复」——每一类天数挂着证据附件，和 PM-01 的需求池变更记录、DL-01 的缺陷清单互相咬合。例会上逐天对质时，拿出来的不是观点，是台账。评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

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

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

五、会产出什么

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

• 正式件本体：延期归因报告初稿.docx 正式件 · 逐日台账 + 21/11/5 三类归因 + 证据附件索引 · 双方确认栏留空
• 可派发清单：实施日志归档表.xlsx kickoff 起全量 · 日期/事项/责任方/证据/影响天数 · 可持续滚动
• 可派发清单：待补证与待确认事项.xlsx 未走书面确认的变更 / 待补证据日 · 补办期限跟踪

这套东西不承诺什么：归因结论与责任认定必须由双方项目委员会确认，本场景只出逐日事实与归因初表；客户侧延迟如实记录，不夹带情绪化表述——对质时情绪是减分项；与 PM-01 的需求变更记录联动：变更类天数必须能对应到书面确认或未确认的标记。

② Live Demo（演示逐步）

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

案例设定：明衡软件交付部。优选百货项目延期 37 天（3 月 9 日 kickoff、原计划 5 月 25 日、实际 7 月 1 日），客户按合同主张 37 天全额违约金 2.22 万——实施日志散在群消息和个人笔记里，今天归档归因、逐日对质。

输入文件4 份延期37 天 · 21/11/5违约金口径0.05%/天 · 2.22 万归因完成度37/37 天 · 逐日闭合

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

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

• 01_项目日志原始记录_优选百货.txt 项目群消息与实施笔记节选——散装的原始记录，归档的原料项目群与个人笔记 ·3 月起累积
• 02_变更登记台账_优选百货.xlsx 变更事项登记——书面与口头分列，影响天数逐项记录交付部登记 · 项目期累积
• 03_缺陷与修复工单_优选百货.xlsx 缺陷单与修复记录——厂商侧 5 天的逐日对应（与 DL-01 素材同源）研发部缺陷系统导出
• 04_合同工期与函件_优选百货.txt 合同工期条款与客户违约金主张函——归因报告的对立面口径商务归档 ·8 月底收到客户函件

注意标橙色那一份 —— 01_项目日志原始记录_优选百货.txt。它项目群与个人笔记 · 3 月起累积，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

优选百货项目延期 37 天，客户在例会上直接问怎么算。我手上的记录很散：群消息、我的个人笔记、往来邮件都有，这是 SOW 和里程碑计划，这是需求变更记录和缺陷清单。 帮我做三件事：

1. 把散装记录按日期线归档成实施日志，每条标责任方（我们/客户/第三方）和证据。
2. 37 天延期逐日归因——客户主数据延迟、需求变更、我们自己的缺陷，各占多少天，每一段要能挂上证据。
3. 客户原因的表述要克制，写事实别写情绪；变更类的天数要能对上有没有书面确认。 归因报告按双方确认的格式出，结论栏留空我们自己填。

日志归档结构、归因三分类口径、证据附件格式在能力包里；现场只需把散装记录丢进来——「从脏输入开始」是这个场景的默认前提。

触发客户主张 37 天全额违约金 · 日志散在群消息和个人笔记里

从脏输入开始是这个场景的默认前提——能归档多少算多少，缺的明说缺

违约金函件把一件事摆上了台面：延期责任怎么拆。「记录不全的时段」如实标注，比事后补写可信——归因报告的底气来自逐日在案的记录，不来自形容词。

第 1 步 · 逐日台账归档 · 21 + 11 + 5 = 37，一天不悬空

群消息、笔记、缺陷单、邮件回填成同一种格式的台账

第 2 步 · 变更 11 天拆开 · 书面 4 天有邮件，口头 7 天只有时间戳

缺书面依据的变更单独成清单——补办期限逐条跟踪

第 3 步 · 厂商 5 天认回来 · 缺陷单与修复记录逐日在案

自己该认的天数一分不少——这是台账公信力的本钱

第 4 步 · 违约金口径 · 37 天 2.22 万，还是 5 天 0.30 万

归因差额就是违约金差额——数字摆在谈判桌中央

IO成稿 · 归因报告初稿 + 归档表 + 待补证清单

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

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

1. Skill 能力包

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

实施日志归档与延期归因 —— 37 天延期，21 天是客户的、11 天是变更的、5 天认回来 · Skill

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

版本 v1.0

implementation-log-and-delay-attribution.zip

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

包内结构

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

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

2. 原始素材

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

📁DL-02 · 演示素材

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

共 4 份

• 01_项目日志原始记录_优选百货.txt 项目群消息与实施笔记节选——散装的原始记录，归档的原料
• 02_变更登记台账_优选百货.xlsx 变更事项登记——书面与口头分列，影响天数逐项记录
• 03_缺陷与修复工单_优选百货.xlsx 缺陷单与修复记录——厂商侧 5 天的逐日对应（与 DL-01 素材同源）
• 04_合同工期与函件_优选百货.txt 合同工期条款与客户违约金主张函——归因报告的对立面口径

怎么用

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

3. 提示词卡片

优选百货项目延期 37 天，客户在例会上直接问怎么算。我手上的记录很散：群消息、我的个人笔记、往来邮件都有，这是 SOW 和里程碑计划，这是需求变更记录和缺陷清单。 帮我做三件事：

1. 把散装记录按日期线归档成实施日志，每条标责任方（我们/客户/第三方）和证据。
2. 37 天延期逐日归因——客户主数据延迟、需求变更、我们自己的缺陷，各占多少天，每一段要能挂上证据。
3. 客户原因的表述要克制，写事实别写情绪；变更类的天数要能对上有没有书面确认。 归因报告按双方确认的格式出，结论栏留空我们自己填。

为什么这么短就够了：日志归档结构、归因三分类口径、证据附件格式在能力包里；现场只需把散装记录丢进来——「从脏输入开始」是这个场景的默认前提。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

XLSDL-02_延期归因报告初稿.docx正式件 · 逐日台账 + 21/11/5 三类归因 + 证据附件索引 · 双方确认栏留空下载

↓XLSDL-02_实施日志归档表.xlsx kickoff 起全量 · 日期/事项/责任方/证据/影响天数 · 可持续滚动下载

• ↓XLSDL-02_待补证与待确认事项.xlsx 未走书面确认的变更 / 待补证据日 · 补办期限跟踪

Skill 里固化了什么：37 天拆开了：21 + 11 + 5「客户原因」这四个字怎么写才不带火药味排除性结论把技术动作翻译成钱

输入清单：实施过程记录（群消息/个人笔记/邮件，散装）从 kickoff 到现在的原始碎片——归档的原料SOW 与里程碑计划计划基线——偏离了几天、偏在哪一段，全靠它对照双方往来函件与会议纪要客户侧延迟的第一证据（催办记录、数据交付延迟通知）需求变更记录（联动 PM-01）11 天变更类延期逐条对应：走了书面确认的、没走的，分开标

人工边界：归因结论与责任认定必须由双方项目委员会确认，本场景只出逐日事实与归因初表；客户侧延迟如实记录，不夹带情绪化表述——对质时情绪是减分项；与 PM-01 的需求变更记录联动：变更类天数必须能对应到书面确认或未确认的标记。

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

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

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

• DL-01 · 验收报告初稿与功能点核对：72 个功能点逐项对，5 项不达标各有各的处置

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

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