装好 15 个 Skills，就等于有了一个可靠的 Data Agent 吗？
还差最关键的一步：把“会做什么”变成“怎样证明已经做好”。
这一篇不是新的官方 Skill，而是基于前 9 期原文整理的产品化方法。文中提到的任务协议、验收链和陷阱清单都是编辑整理的框架，不是原文定义的统一规范。
别把 Skill 数量当成系统成熟度
工作流需要按任务选择：补背景、定指标、诊断变化、检查质量、组织计算、表达或发布。
不是每次都串行跑一遍，也不是 15 个文档就代表 15 个独立 Agent。原文的口径一直很明确：主 Skill 只有一个，支持 Skill 按需加入，由主 Skill 决定什么算完成。
真正重要的是交接：前一步交给后一步什么证据？来源缺失时停在哪里？完成条件由谁核验？
这三个问题，正好对应下文的协议、工作链和验收链。
给每个任务写一份小协议
建议至少写清六项：
| 要素 | 要回答的问题 |
|---|---|
| 输入 | 这个问题需要哪些必要信息才算清楚 |
| 必需来源 | 哪个系统或文档控制这个答案 |
| 允许的方法 | 可以做什么、不可以做什么 |
| 交付产物 | 输出是什么形态、给谁看 |
| 验收条件 | 什么证据能证明任务完成 |
| 失败分支 | 来源缺失、口径冲突、证据不足时怎么办 |
以“解释留存变化”为例：
- 输入需要窗口、人群和产品范围；缺任何一个都应该先问。
- 必需来源不可用时暂停，而不是拿相邻口径代替。
- 输出不能只有“下降了 3%”，还要有定义、证据、备选解释和限制。
- 验收要求关键数字可复算，且比较基线明确。
六项写全之后，一个任务的“完成”就不再依赖模型的自我判断。
同时设计工作链和验收链
分析负责形成判断，验证负责检查判断有没有超出证据。
两条链并行推进，而不是串联：在工作链里，Metric Diagnostics 形成解释；在验收链里，Validate Data 检查这个解释的方法、数字和措辞。
高风险结论应当复算数字、核对口径、检查比较基线与表达边界，而不是让模型再润色一遍。润色只会让措辞更自信，不会让证据更充分。
可复用的语义层值得保存，但当前分析的临时背景不必全部写入。维护动作和任务分析要保持边界，否则语义层会被一次性上下文污染，反而降低可靠性。
用六类陷阱检验真实表现
这是最实用的一部分：与其问 Agent “你会不会”，不如设计具体的失败场景。
| 陷阱 | 测试设计 | 期望行为 |
|---|---|---|
| 缺权威来源 | 只提供弱替代数据 | 停止并说明需要什么来源 |
| Join 膨胀 | 多对多关联后直接汇总 | 发现重复计数并修正粒度 |
| 比例汇总 | 直接平均各分组转化率 | 用分子分母重算整体 |
| 比较期不完整 | 当期少一天或缺一个渠道 | 降低结论强度或先补齐 |
| 只有相关性 | 时间吻合的业务事件 | 不写成因果，标注为假设 |
| 已发布的快照 | 页面可访问但数据过期 | 说明是快照及截止时间 |
每个测试都要有预期行为和可检查的产物。不能只凭回答“听起来很专业”打分——专业感恰恰是模型最擅长伪造的东西。
从一个任务开始落地
原文的建议在工程上同样成立：先选一个高频、边界清楚的场景，记录成功、带限制交付和阻塞的样本。
三类样本都要留：
- 成功：证据完整、结论可复算。
- 带限制交付：结论成立但边界明确，接收者知道能用在哪。
- 阻塞：正确拒绝执行，并说明缺什么。
第三类最容易被忽略，却最能反映系统成熟度。一个从不阻塞的 Agent，通常意味着它从不检查。
逐渐沉淀口径、工具与验收，再扩大覆盖。语义层和验收用例是复利资产：每解决一个失败场景，下一批任务就少一类错误。
一个判断成熟度的简单问题
如果只能问一个问题来判断这套系统是否可靠，可以问：
当证据不足时，它会不会停下来？
会停下来的系统，需要先定义“什么是足够的证据”，这就倒逼出协议、工作链和验收链。不会停下来的系统，即使演示再流畅，也只是把不确定性转移给了读者。
系列回顾
前 9 期分别拆解了路由、上下文、指标、诊断、市场估算、质量与验证、计算与表达、看板与报告、发布。它们各自解决一个局部问题，这一期把它们收成一条可验收的链。
可靠的 Data Agent，不是永远给答案，而是知道什么时候证据够用、什么时候需要补证据，以及怎样把这件事交代清楚。