这是示例案例，用来演示结构和写法。正式使用时请换成你自己的项目。 文中的数字都是编的，只示意要写到什么颗粒度。
背景
运营同学每天早上要做一份经营日报：从三个系统分别导订单、库存、退款数据，在表格里拼起来，核对口径，画两张图，发到群里。做完大概要两个小时。
这件事持续了八个月。中间提过两次「能不能自动化」，都被排到了很后面，因为看起来不是核心业务。
我为什么决定接这个需求
不是因为它「能省时间」。两小时听上去很多，但对一个团队来说，单独做个工具，收益并不明显。
让我改变判断的是另一件事：这份日报每天都会被不同的人引用，而每个人的口径都不一样。有人按支付时间算，有人按下单时间算；有人算退款，有人不算。所以开会时经常出现「一个数字两个结论」。
也就是说，真正的问题不是慢，是大家信的数是不同的数。
一个反直觉的判断
如果一开始就去自动化，最好的结果也就是「更快地生成一份没人完全信任的表」。所以我先把顺序倒过来：
- 先定义指标（每个指标一个明确口径，写进字典）
- 再用字典去替换现有的手工流程
- 最后才做一键生成
前两步没有写一行代码，只是把一个 Excel 里的口径说明整理成了 23 条定义，逐条跟业务方确认。
方案
- 指标字典：23 个核心指标，每个写清楚定义、计算公式、取数口径、责任人
- 一键生成：后台一个按钮，跑完直接出图并推送到群
- 异常提示：某天数据波动超过阈值时，在日报顶部标注，避免有人用错数据
第三点是运营自己提的。他们的原话是「有时候数据看着不对，但我们不敢不发，也不知道该怎么查」。所以加了一行提示，把不确定说出来。
结果
- 日报制作时间：2 小时 → 15 分钟
- 会议里因为口径不一致产生的争论，从每周 3~4 次降到基本没有
- 指标字典后来被另外两个团队拿去复用
复盘
做对的地方：没有直接答应「做个自动化工具」。如果按最初的诉求做，很可能做出一个快但不可信的东西。
判断失误的地方：我一开始低估了「推动别人认可口径」的难度。23 条定义改了四轮，前后花了一个多月，比写工具的时间长得多。这个时间在立项时没有算进去，导致后面的排期很被动。
一条经验：内部工具项目里，真正的交付物往往不是那个工具，而是让大家对「同一个词指的是不是同一件事」达成一致。工具只是把这个共识固化下来。