履约周报里出现了一个红色数字。运营主管想知道为什么变差，但在解释业务之前，还有一个更基础的问题：这周和上周，算的是同一批对象、同一个口径，而且数据都到齐了吗？
Agent 可以整理检查记录、定位受影响行、准备异常清单。指标怎么算、多少算异常、谁来调查，仍由团队决定。流畅的分析不能替代这些输入。
先固定一张指标定义卡
假设一个虚构履约团队提供两份获准使用的 CSV：订单表、发货事件表。这是方法示例，不是真实客户案例或已执行实验。团队把“超期订单”定义为：承诺发货期限已过，截至周报截止时仍无发货事件的订单。分母是承诺期限落在本周窗口内的全部订单，包含尚未发货的订单；取消订单是否剔除，按团队书面规则处理。
比较相邻两个完整七天：周一零点到下周一零点，结束时点不包含在内，统一时区。定义卡记录截止时间、导出时间、来源覆盖区间、订单 ID、承诺期限、实际发货时间。下载日期不是业务日期；如果发货表没采全，“没有发货记录”也不能直接等同于超期。
三种异常，进入三个分支
| 虚构输入 | 已知证据 | 应如何处理 |
|---|---|---|
| A：来源晚到 | 发货事件只到周日，报表截止到周一 | 标记数据缺口，不发布全周超期率 |
| B：口径变了 | 退款从归属下单周，改成归属退款发生周 | 标记不可比，统一口径重算或展示可比切片 |
| C：业务偏差 | 两窗来源齐全，定义一致 | 先算真实变化，再对照团队阈值 |
A 的输出首先是缺失区间和受影响订单 ID。缺失值保留 null，不填成 0。上一份完整报告可以保留，但必须带原日期，不能冒充本周结果。局部统计若有用，应明确覆盖区间和分母，不与完整周直接比较。
B 中，退款事件可能完全真实，错误发生在比较方式。它与超期订单指标分开处理。让指标负责人确认归属规则，记录版本后重算两窗。Agent 不能为了让图表顺眼，悄悄选一套更方便的定义。
C 的虚构源表显示：本周 200 单中 20 单超期，上周 200 单中 8 单超期。超期率从 4% 升至 10%，增加 6 个百分点，绝对增加 12 单。假设团队事先设定的调查条件是“至少上升 5 个百分点，且至少多 10 单”，本例同时通过两条条件。这是示例团队规则，不是行业标准，也不是让模型自己猜的默认值。
异常清单要能交接，不要提前写因果
每行保留：异常编号、类型、受影响指标、来源文件与行 ID、定义版本、本期值、前窗值、阈值、待确认问题、实际提供的负责角色、下次核查条件和状态。没有指定负责人，就写“待分派”，不要虚构姓名。
“多了 12 单超期”是观察；“承运商故障导致增加”是待验证假设。地区汇总和设备汇总也不能拼成某地区某设备导致异常的确定结论。可以提出要查的交叉切片，但不能把调查建议写成原因。
摘要首层直接展示：已确认偏差、来源缺口、需要谁决定什么。原始行与计算过程保持可查。安静的一周可以没有已证业务异常，同时仍有未补齐的数据缺口。
先把检查方法留下，再考虑排期
在 Buda 运营场景里，可以把指标卡、获准输入副本、带日期的报告和异常表放在 Drive。Drive 与记忆保留的是文件；执行时仍需明确读取哪个版本，文件夹名称本身不是权限策略。
先拿一份脱敏历史周报手动试跑。要求 Agent 输出三类判定、计算和未决清单，不发告警、不改正式记录。人工确认后，再把方法沉淀为 Skill；可在 Buda AI 的 Marketplace 搜索并安装合适的 Skill，安装前先阅读说明。Skill 与自动化能让方法复用或按计划运行，但不代表所有来源接口、审批流程都已配置。
这与把并行 Agent 产物整合成一份交付不同：这里检查的是每一期比较是否成立，而不是怎样合并多份结果。晚到数据补齐后保留 v1，新出 v2，明确哪项输入变了、哪些异常被重核。
常见问题
阈值由谁定？
由负责业务结果的人决定。事先记录业务理由、百分点条件与最小绝对量。没有规则时，先展示观察并请求确认，不把模型建议写成已批准标准。
晚到数据回来，旧报告怎么办？
保留旧版和原始输入；新导出另存版本，重跑受影响指标及完整度检查。缺口关闭后可能出现新的业务异常，两件事分别记录。
订单很少，百分比很夸张怎么办？
同时展示分子分母。5 单里 1 单是 20%，但首先是 1 单。使用团队确认的最小数量条件，先看具体订单，不只按百分比升级。
可以用三个故意破坏的历史副本试验：缺一段来源、改一个定义、加入越过阈值的样本。这是建议测试，并非已完成效果。确认三个分支都走对，再决定是否排期。