公式在某一个人的电脑里
日报的口径通常沉淀在一份用了很久的 Excel 里，只有做它的人知道哪一列为什么这么算。这个人休假，这条线就断，或者接手的人算出另一个数。
公司日报：从各部门源表穿透到成表，上班前发到群里
日报真正的风险不是「没人做」，是**做出来是错的而没人发现**。源表的表头会被人改、列会被加、日期会往前放几天，一张全是 0 的日报和一张正确的日报看上去一样整齐。
01
接手之前，卡在哪
源表会变，而错误是静默的
部门源表不是给机器用的：有人加一列、改个列名、把日期往前排几天都很常见。按位置取数的脚本这时候不会报错，它会安静地算出一张错表。
每天早上的固定消耗
取数、对齐、套公式、贴进模板、发群——流程不难，但它每天都要发生一次，而且必须赶在上班之前。
02
接手之后，怎么跑
隔夜把各部门源表取下来
定时任务在夜里跑，不占用白天的人和带宽。取不到就报警，而不是拿昨天的数接着算。
按你们自己的公式算，公式存在云端
口径从云端按组织下发，不是藏在某个人的工作簿里。改一次，所有人下一次跑都按新的算。
认表头，不认列的位置
列按名字匹配并容忍空格和细微改名；对不上的时候**停下来问**，而不是算出一张零表。日期错位这类问题会被当成异常报出来。
上班前发到群里
成表连同当期的异常一起发，异常在前——先看哪里不对，再看数。
03
哪里必须停下来等人
- 只读源表、只写日报的副本，**任何情况下不回写源表**
- 列匹配不上、数据缺口超过阈值时停下来问人，不猜
- 发群之前可以设成先给你过一遍，确认了再发
怎么验收
- 和人工做的那一版逐格对一遍
- 换一个历史月份重算，结果应当稳定复现
- 故意改一个源表的列名，它应该报异常而不是算出零
04
口径从哪来
06
常见问题
源表格式经常变，能扛住吗？
列按名字匹配并容忍空格与细微改名。真的对不上时它会停下来问，这是设计——静默降级算出一张错表，比不出表危险得多。
会不会把我们的源表写坏？
不会。源表只读，写只写日报的副本。这条是硬约束，不是配置项。
公式复杂，能支持到什么程度？
多表关联、跨表查找、按维度分摊这类都在能力范围内。交付时会把你们现有那张表的口径逐项标定，验收标准就是和它对得上。