变通方案不等于故障点
入档：2026-07-22 来源：《实战6-自动化口播剪辑》并入公司钉钉知识库的交付链路（母档 钉钉知识库交付_格式白名单与终版回填闭环_v1） 验证状态：⚠️ 首次；一次错误归因让交付方式多绕了两版
一句话律
别从对方的变通方案反推故障点。 变通方案只证明”他当时撞到了什么”，不证明”障碍在哪一步”；要定位故障点，直接问”是哪一步失败的”。
来源实例
接手钉钉交付时，我看到仓库里同日提交了 4 个格式变体（附件版 / 公网图链版 / 纯文字版 / 占位标注版），据此反推出结论：“钉钉粘贴带不了图片，所以要准备多种兜底”，并把这条写进了交付 skill 的硬规则，后续两版交付都按”图片一律用 🔴 文字占位、导入后手动补 14 张图”来做。
作者一句话澄清后才发现症结完全不在那里：导入钉钉这一步本身没问题，图片能带进去；出问题的是「从钉钉文档复制到另一个钉钉文档」这一步会丢图。 4 个变体是在为”中转复制”这个动作找活路，不是在为”导入”找活路。
代价：交付方式绕了两版（占位标注 → 公网直链），skill 里写下并传播了一条错误硬规则。改对之后，14 张图随导入自动带入，零手工补图。
为什么会错
变通方案是故障的下游产物，中间隔着当事人的猜测、习惯和临时妥协：
- 他可能也没定位准，只是广撒网试了四种；
- 他可能为了别的约束（比如领导要纯文本）顺手做的；
- 同一个变通方案可以对应好几种故障点，反推是一对多，必然失真。
而”哪一步失败了”是一句话就能问清的事实。用一小时的推理替代一句话的提问，是典型的成本倒置。
操作规则
- 接手别人做了一半的工作流，先问三句：哪一步是通的？哪一步失败了？失败时看到什么现象？
- 把从产物反推出来的结论标注为假设，不要直接写进规范或 skill；真正入库的规则必须有当事人确认或自己实测过。
- 已经写进规范的推断，一旦被澄清，同时改三处：规范 / skill、复盘档的事实记录、以及按旧规则做出来的交付物。
- 反过来自查：当自己做了一堆兜底变体时，在提交信息或文档里写清”这是在绕开哪一步的什么问题”，别让下一个人也去反推。
边界
当事人不可达（离职、跨时区、异步等待成本高）时，反推是合理的临时手段——但要按规则 2 标成假设，并在第一次能验证时立刻证伪或坐实，别让它沉淀成硬规则。
关联文档
- 钉钉知识库交付_格式白名单与终版回填闭环_v1 —— 本律的来源实例；其”导入 vs 复制粘贴”事实已按澄清更正
- ⭐ 交付前实测证伪律_v1 —— 同族纪律的另一半：本律管”别把推断当事实”，那条管”别把没测过的方案当能行”
- 沟通成本的第二来源_范围与高度错位 —— 同根问题：继承他人结构化产物时，缺失的边界信息要主动问出来，不能从产物形态猜
- 复盘事实先行原则 —— 事后同理：先冻结事实，再做归因
- 有意改动不是故障_v1 —— 姊妹律：那条管”别从产物形态反推故障位置”，这条管”别把文件变化默认成故障去还原”，都是接手他人产物时的错误归因
- 04_方法论与洞察索引