定时报表的假成功：从退出码走到正文验收

一个完成状态，可能没有完成交付

在定时报表的历史排障记录中，出现过一种容易漏掉的故障：调度器显示 completed，模型请求也返回了响应，但最终报告只有标题占位符。对进程而言，命令已经结束；对读者而言，日报并没有交付。这让我重新审视自动化的验收边界。

任务采用直接输出模式，脚本的标准输出就是消息正文，中间没有另一个模型负责补写。这个结构减少了额外推理，也使生成器必须对自己的产物负责。只检查退出码为零、输出不为空，挡不住只有一个井号的“报告”。

把正文、推理和诊断分开

核对现有生成器可以看到，响应解析会区分正文与 reasoning_content，并记录结束原因。推理内容再长，也不能替代交给读者的正文。finish_reason 为 length 时，生成器会识别截断，避免把格式未完成的响应当成正常结果。

正文校验进一步检查篇幅与必要章节。现有实现设置了至少八百字符的门槛，但长度只是最低条件；报告还需要符合约定结构。包装脚本在输出前再次调用同一校验函数，校验无法加载时也按失败处理。这样，生成器的遗漏不会直接穿过交付边界。

标准输出与标准错误也有明确分工：前者承载报告，后者承载运行诊断。把两者混在一起，会让读者收到日志，也会让下游程序难以判断哪一段才是正文。

成功应当由可用产物证明

这次经验并不意味着增加一个字符数判断就能保证分析正确。格式完整、事实可靠、消息送达，是不同层次的验收。结构校验可以拦住空壳，却不能证明模型推断成立；脚本返回成功，也不能证明目标会话已经收到消息。

因此，排障时应沿着生成、包装、调度、交付逐层观察，各层只证明自己看见的事实。失败说明需要清楚，重试也必须有边界，不能用不断重跑掩盖配额或输出预算的问题。

本文根据历史排障记录及整理时的脚本实现撰写，未重新运行定时报表，也不代表此刻消息通道的可用性。留下这篇复盘，是为了让下一次自动化验收先检查读者真正得到什么。