14 页校验全部 status: ready，pptx 文件也安安静静躺在目录里。我差点就直接发给老板了。幸亏多嘴问了一句”里面到底有几张幻灯片”，一查，零张。文件在，内容是空的。

先把今天的坑记下来，免得你重蹈。

坑一：一个字母的手滑

封面页我本该写换行标签 <br />，手一抖写成了 <bt />。一个字母之差，肉眼扫十遍都发现不了，因为整页代码看过去”长得都像标签”。它是靠校验报错加渲染异常才暴露的——页面该换行的地方没换，排版全挤在一起。这种错不致命，但很阴，专挑你赶时间的时候出现。

坑二：校验全绿，产物是空的

这才是今天的主角。

当时 14 个页面文件逐个跑 slidep-validate，回报全是 status: ready，pptx 也确实生成了。一切绿灯，按理说可以交付。我偏要验一下产物本身，命令是：

unzip -l 签字盖章数字分身方案.pptx | grep -cE "ppt/slides/slide[0-9]+\.xml"

数出来，0。零张幻灯片。一个 84 KB 的壳子，里面空空如也。

原因搞清楚了：实时编译服务在我把 14 页写进项目之前就启动了，它打包的时候页面还没进来，中途也没把新页面重新写进包。也就是说，校验跑的是源文件，不是最终产物。源文件个个 ready，产物却是个空包。绿灯亮在过程中，没亮在结果上。

解法不复杂，但得知道往哪下手：先 slidep-stop 把服务停掉，再重新 slidep-start 强制重建一次，让编译服务在页面齐全之后才打包。复跑那条解压命令，这回数出 14 张，文件 84 KB，对上了。

方法论：过程通过不等于产物正确

我把这件事提炼成一句话，写进了复盘文档：过程校验通过，不等于产物正确。

任何自动化流水线都一样。你让系统每天跑批、跑测试、跑构建，中间的绿灯只能证明”每一步看起来没问题”，证明不了”最后那包东西能用”。最后一步必须验产物本身——这里是解压数幻灯片数量，换到别的场景，可能是真机点开看一眼、是接口实际调一次、是报表真的导出来。

生活里我打个比方：验收装修，不能只看施工队每天的日报都写”正常”，你得自己进屋敲敲墙，看空鼓不空鼓。日报是过程，墙是产物，两码事。

你明天就能用的三件事

第一，任何自动生成的文件，交付前加一句”数一数产物”。PPT 数幻灯片，报表数对少行，压缩包数文件数，成本几乎为零。

第二，编译服务这类东西，确认源文件齐了再启动，或者启动后强制重建一次，别信”中途会自动同步”。

第三，把”校验源”和”校验产物”当成两件事写进你的交付清单，绿灯只信后者。

今天这 84 KB 的教训不贵，但值得记一辈子：别被绿灯骗了，进屋敲敲墙。