信息论

这篇文章记录了一次完整的工程资料审计与重建过程。不只是"我们修了哪些bug"的工作日志，更是对工程资料领域几个底层问题的追问：合同数据和设计数据谁说了算？为什么隐藏行是最危险的陷阱？为什么生成器模式比手动改文档靠谱一千倍？——希望能帮到所有和工程资料打交道的人。 一、故事开始于一次"再看一眼" 甲方要交一份施工组织设计。项目是云南临沧一个低效林改造工程——5750亩林地，四个乡镇，312万的合同。我们之前做过一版，交了。 然后说"再审计一下"。 这一审，审出问题了。 不是小问题。是整个文档的根基有问题。 二、合同10000亩，设计5750亩——数据的双重人格 这是整个项目最大的底层矛盾。 合同签的是10000亩。中标的投标文件写的也是10000亩。按合同，四个乡镇的面积是：爱华镇5570亩、幸福镇3730亩、晓街乡600亩、忙怀乡100亩。 但当我们用 formatting_info=True 打开XLS设计附表，逐行检查隐藏行之后，真相浮出来了： 设计批准的改造面积只有5750亩。 四个乡镇的实际数据是：爱华镇2303亩、幸福镇2802亩、晓街乡603亩、忙怀乡42亩。差距4250亩。 差的这4250亩去哪了？在Excel的隐藏行里。爱华镇有69行隐藏数据（涉及忙回村、新寨村、田心村等6个行政村），合计4250亩——这部分被调出了六标段范围，归了其他标段。 但合同没改。 合同上写的还是当初投标时的估算面积。 这就是工程资料领域最经典也最危险的场景：商业文件和技术文件说的不是同一件事。 合同是商务承诺，作业设计是工程真理。两者不一致时听谁的？合同里其实写了答案——“具体以甲方经批准的作业设计为准”。这句话，就是整个数据选择逻辑的法理依据。 底层原则1：工程资料的权威来源是经批准的作业设计，不是商业合同。合同的数字只有在和设计一致时才能用。 三、隐藏行——Excel里最危险的幽灵 上面这个错误不是偶然的。我们来推演一下它是怎么发生的： 有人打开XLS设计表，筛选出"云县"的行，用SUM求和。Excel的SUM函数不区分可见行和隐藏行——它全加了。于是他得到了一个接近10000的数字，觉得和合同对得上，就用了。 但实际上这里面混入了大量不属于六标段的数据。 隐藏行不是"不重要的行"。它们是"不应该在这里的行"。 但Excel不会告诉你这个。你看到的是一张表，你求和的是所有数据，你以为你做对了——直到有人用 xlrd 的 formatting_info=True + rowinfo_map[rid].hidden 把每一行拆开来看。 这个教训远远超出了XLS文件格式的范畴： 底层原则2：任何聚合数据都要追问"你的分母是什么"。求和之前先问：哪些行应该参与计算？哪些行不应该？如果数据源本身有隐藏/过滤/排除逻辑，你的工具必须能感知到它。 从信息论的角度看，隐藏行本质上是一种带外信息（out-of-band information）——数据的含义不仅取决于单元格的值，还取决于你看不到的格式属性。忽略带外信息，就是在用一个不完整的信号做决策。 四、生成器模式——数据与呈现的解耦 上一版施工组织设计还有一个更隐蔽的问题：面积数据分散在多个docx文件里，有些是手动填的，有些是从不同来源抄的。当发现面积数据需要修正时，要一个一个文件打开改。 这次我们建了一个 common_data.py——项目所有关键数据（面积、预算、工期、公司信息、各乡镇明细）的唯一真相源（Single Source of Truth）。然后写了8个生成脚本（gen_*.py），每个脚本只做一件事：从 common_data 读数据，填充到文档模板里，输出 docx。 修复的效果立竿见影：改 common_data.py 一行 → 重新运行所有 gen 脚本 → 所有产出文件自动更新。不需要手动打开任何一个 docx。 这不是什么新技术。程序员管它叫 DRY（Don’t Repeat Yourself），数据库管它叫规范化（Normalization），工程管理管它叫"统一数据源"。名字不重要，重要的是： 底层原则3：如果一个数据出现在两个以上的地方，它就不应该以手动方式维护。建立唯一真相源，让所有产出文件从它派生。这不是偷懒，是防错。 手动复制粘贴是工程资料质量的第一杀手。不是因为人不行，是因为人脑不适合做"在多处保持同一数据完全一致"这种事。这种事应该交给代码。 五、审计四件套——为什么要用四种不同的视角看同一件事 这次审计我们动用了四个工具，按固定顺序跑： 顺序 工具 擅长 盲区 ① 规则脚本 数量/格式一致性（快，秒级） 看不懂上下文 ② LangGraph 多步骤交叉验证（灵活） 需要写好prompt ③ 代码审查 代码级逻辑bug 不看数据文件 ④ CrewAI 业务逻辑/语义合理性 慢，依赖LLM质量 四个工具各自发现了不同的问题： ...