看板全绿、定时成功、零告警——
而这条 AI 流水线实际发出 0 封邮件
这是我自己业务上的真实起点，也是我做 FDE 之前踩过的坑。这一页是交付实记录：怎么发现「执行成功」不等于「业务发生了」，怎么在三处看板看不见的地方止血，以及这套判断方法怎么迁移到你厂里的任何一条 AI 流程。
先把边界说清楚：哪些能讲，哪些不能
三档分开写。混在一起讲故事就是超售——而超售过一次，你就再也拿不到「这个人说话算数」这个印象了。
可讲 · 已附收据
- 重复扣费与无门禁查证已消除：一次完整执行，计费余额 22 → 22，零消耗
- 多线索入库修复：重放 2 条线索，两条各自独立处理——一条新建、一条不被重复创建
- 已付费线索回收率 1/2 → 2/2
- 生产运行全链实测：140 秒、实耗 5 次计费、4 条滞留记录全部回收、4 条线索各得自分 55 / 45 / 45 / 72
还没做 · 不能讲
- 下游三件套（冷邮件生成 / 回复判定 / 退订处理）未激活
- 真实邮件未发出——累计 0 封
- 成交转化未发生：这个试点至今没有产生过一个真实客户
口径未定 · 不能讲
- 评分阈值 80 与实际得分口径不一致（最强线索 72 分），正向分支至今没有执行收据
起点：看板全绿，业务零产出
上线三天后，我按节点逐级对数——不是看执行状态，是看每个环节的条数。数字对不上的时候，绿灯是没有意义的。
3 天累计 15 条候选 → 内部资格审核拒绝 13 条 → 只有 2 条通过
进了 CRM 的真人线索只有 1 条（两条有邮箱的线索只入库了一条）
下游培育系统 0 线索、0 发信；整条链路实际发出 0 封邮件
按次计费的余额：上线 3 天烧掉一半，而账单不会告诉你烧在哪
成功的执行 + 真实的账单 + 空的下游，三者同时成立。
这就是 AI 流水线最难发现的一类故障：它不报错，它只是从不把事情做完。日志写着 success，看板一片绿，但没有任何一封信发出去，没有任何一条线索进了你的系统。
三条「显而易见的原因」，全部被证据推翻
这是整份记录里最值钱的一节。立项时听到的每一条解释都不成立——而这恰恰是最省时间的做法。
- 证伪 1
「阈值太严，把线索全滤掉了」
推翻。内部门禁拒绝的 13 条每条都带理由文本；外部评分给唯一那条线索 55 分并附理由——两道门禁都在正常工作。
- 证伪 2
「执行 success 说明链路是健康的」
推翻。2 条已付费线索只进了 CRM 1 条；每次「成功」执行都伴随一次计费查证调用。
- 证伪 3
「部署的就是仓库里那份文件」
推翻。三处缺陷全部源于「以为部署的是适配版」——仓库里的配置根本不是线上跑的那份。
下游空 ≠ 上游全拦。
结果异常时，先证明每一条「显而易见」的原因是错的对的，再去猜新的。这一步把排查范围从「调参」收窄到了「架构」——否则你会在阈值、提示词、模型参数里耗掉一整周。
三处缺陷，全部藏在看板看不见的地方
它们不在代码仓库里，不在架构图里，不在任何一个监控面板上。它们只在部署态里。
无门禁的付费调用
- 位置
- 编排层里另有一套邮箱查证节点，位置在入库与评分之前
- 后果
- 已经查过邮箱的线索被二次查证、二次计费
- 为什么没被发现
- 执行画面一切正常，月底看账单才发现
发现请求缺了「只取新线索」参数
- 位置
- 发现节点的请求体（部署时被改，仓库里那份是对的）
- 后果
- 每次调度都返回同一批线索，重复扣费
- 为什么没被发现
- 每次都有结果，看不出是在重复
单条目取值
- 位置
- 建联系人节点只取了第一条
- 后果
- 一次运行多条线索，只有第一条入库
- 为什么没被发现
- 执行 success，第二条无声消失
验证：claimed ≠ accepted
止血之后系统进入了「安全空转」——上游修好了，下游永远走不到，所有绿灯都失去了意义。解法不是等，是制造样本。
- 不再重复扣费一次完整执行 2 分 35 秒，状态成功，计费余额 22 → 22，零消耗；全程无查证调用记录
- 两条线索各自处理一条新建（邮箱、职位、时间戳完整），另一条未被重复创建，原时间戳未变
- 生产运行真跑140 秒、实耗 5 次计费、4 条滞留记录全部回收（入库数 8 → 12）
- 评分可复核4 条线索各得自分 55 / 45 / 45 / 72，无一条越过阈值 80
- 夹具已清理用于重放的固定数据已复位，工作流仍在运行状态
- 改动方式通过编排层原生接口 19 次原子操作完成，任一失败全部回滚；旧链路保留并标注为审计痕迹
缺收据的成果，不许进「已交付」。
本次修复先按「声称」记账，直到重放拿到收据才升格为「已验收」。收据不是形式主义——它是「你凭什么说修好了」的唯一答案，也是你和你老板之间唯一不用吵架的凭据。
重放还顺带暴露了两个被空转掩盖的真实缺陷（取值写错了包装层、跨节点引用被随手降级），一并修掉了——这正是「空跑是缺陷的隐身衣」这句话的代价：你不让它跑一次，它就一直藏着。
这套方法怎么迁移到你厂里
它不依赖我用的技术栈。任何一条 AI 流程——从询盘分类到老师傅经验沉淀——都能用同一套检查表。
- 01
成功 ≠ 完成
「执行成功」是最容易骗人的信号。要验的是条目守恒——每一环节的输入和输出对不对得上，而不是灯是不是绿的。
- 02
先证伪显而易见的原因
三条常识解释全部被推翻，才收敛到真正的架构缺陷。这一步省下的时间，远超花掉的时间。
- 03
部署态才是真相
仓库里的配置、文档里的架构图都不是。本次三处缺陷全部来自「以为部署的是适配版」。
- 04
计费调用必须有门禁，而且门禁要看部署图
一道设计良好的内部门禁旁边，完全可能并行着一道没设防的野路子。
- 05
修完要留下可追溯的对比痕迹
旧链路不删除，断开并标注——它既是审计痕迹，也是「修复前 / 修复后」的对照物证。
- 06
空跑是缺陷的隐身衣
上游修好之后，系统可能因为「没有数据」而永远走不到下游，此时所有绿灯都失去意义。改了数据路径，就必须用夹具强制覆盖那条路径，否则验收就是走过场。
交付的终点不是跑通的系统
是下次能更快跑通的系统
可复用的知识不会自己流动——散在对话和临时脚本里的经验，换个会话就丢了。这次把验证过的方法文件化成可复用资产（打法手册、评估标准、可执行技能），并建立了「流程态 + 知识态」双轨记忆：方法沉淀在系统里，而不是留在某个人脑子里。
关于这份记录的常见疑问
这是客户案例吗？
不是。这是自营试点的交付实记录——用我自己的业务当第一个客户，验收人与执行人是同一个人，不是客户签收。它能证明的是方法与判断力，不能证明业务结果。
你们能保证我的项目不出现这类问题吗？
不能保证它不出现，但能保证用同一套方法去找它：逐环节对数、验条目守恒、留执行收据。这里展示的每一条都带收据，没有收据的成果不进「已交付」。
这个流程花了多久？
交付第一天没有写一行新代码——先把三处缺陷找出来并止血，让「执行成功」重新等于「业务发生了」。后面才是验证、复验和资产化。
我怎么判断自己的 AI 项目是不是也在静默空转？
数三个东西：每个环节的输入/输出条数、计费消耗与实际产出、最终下游到底有没有真的发生（发出了什么、进了谁的库）。这三组数对不上，就是在空转。
这套方法对我有什么用？
它不依赖我用的技术栈。发现→验真→去重→打分→入库→培育，任何一条 AI 流程都能用同一套检查表：每一环的条数守恒、每一笔计费都有门禁、每一句「修好了」都有收据。