运营周报自动化生成的第一步不是选工具，是先砍掉一半指标。我见过格子最多的周报有六十多个，一周填一次，真正有人看的只有四个。剩下那五十几个，既没人核对也没人追问，纯粹在消耗填表人的耐心。工具换了一茬又一茬，周报还是没人看，问题从来不在工具上。
需求背景：我要解决的到底是哪一段
先把周报拆成三段，你会发现需要自动化的只有前两段：
- 取数：从各个后台把上周的数拉出来。重复、机械、最容易出错。
- 整理：算环比、挑异常、排成表。规则明确，最该被自动化。
- 判断：这个异常说明什么，下周要做什么。这段别自动化，它是周报唯一值钱的部分。
行业里比较通行的写法是「关键指标 + 趋势分析 + 行动项」三段式，我认同这个结构，因为它天然把「判断」留给了人。反面教材也很常见：通篇只有数字、没有一句结论，周报就成了流水账，发出去等于没发。
还有一个更隐蔽的问题：口径不统一。同一个词在不同后台的定义往往不一样，比如「订单数」在 A 平台按下单时间算、在 B 平台按支付成功算，两边一凑，环比就变成了自己吓自己。所以自动化的前置条件其实是先把口径写死，写在一张表里，谁接手都照这个来。这件事不做，换成什么工具都白搭。
我们自己在内容流程上验证过这套思路：把取数和整理固定成四步走，第一步让运营填「参数卡」，剩下的交给流程跑，判断部分仍然人来拍（这个改法在用 GEO 重构内容那次复盘里写过）。下面三种方案，本质上都是在解决前两段，区别在代价。
方案 A：定时脚本 + 文件/邮件，最笨也最可控
做法很直白：脚本定时跑查询，结果落 CSV 或 Excel，再定时发邮件或丢到共享盘。它没什么神秘的，胜在每一环你都能看见。
代价在维护。重试、告警、失败留证全得自己写，源接口一改字段就断，而且断的时候往往是静默的——邮件照样发，只是里面是上周的数。我们做 FFmpeg 直播流录制自动化时踩过同样的坑，最后真正花时间的不是录制本身，是把容错和留证补齐。
这里有个能省一半工作量的设计：周报不需要日粒度。我们在指数数据上做过降采样——查询时按「周 + 省份」用 avg 聚合，前端真要日粒度，API 也只返回最近 30 天的日数据，更早的自动降为周（百度指数批量采集到 ECharts 全流程里是这么干的）。周报照抄这个思路，查询压力和文件体积一起降下来。
真要落地，我建议把「留证」做成默认动作，而不是出错后再补：每次跑完把查询时间、源接口、返回行数、失败明细一起写进日志，跟着周报一起归档。这一步加不了几行代码，但能让半年后的口径争议当场结束。我们在发票识别自动化里也是同样的结论——部署成服务之后，容错比准确率更重要。
适合：数据源不超过两个、格式常年不变、团队里有能写脚本也能改脚本的人。
方案 B：BI 定时推送，把「送」这件事外包出去
报表做好之后，投递可以不用自己写。Google Looker Studio 官方就支持安排自动报告递送：邮件里带 PDF 附件、首页预览图，以及一个回看完整报告的链接；频率可以设置成每周二和周四、或每两周的周五这种自定义节奏。
三个官方文档里写了、但很多人不知道的细节：
- 送出去的是 PDF，收件人只能看不能改，想让他改就得回来看板。
- 筛选值要单独设。官方原话是：PDF 默认用报表的默认筛选值；在报表上改筛选默认值，不会影响到已经建好的投递计划。
- 敏感数据用「仅发链接」。Looker 的邮件数据策略有三档——仅发链接 / 仅发数据 / 链接和数据都发，官方明确推荐敏感数据选「仅发链接」，收件人必须登录才能看。
还有个硬约束：邮件正文形式不超过 20 MB、附件形式不超过 15 MB（官方原文）。周报附件塞太多明细表，很容易撞上这个上限。
适合：指标已经稳定、读者只需要看不需要改、不想养脚本的团队。
方案 C：AI 生成 + 人工确认，只补最后一段
这个方案不是让 AI 写整份周报，而是让它把「整理」阶段产出的数字，转成一段人能读的结论草稿，人再改。我们实测的收益是实打实的：内容流程自动化之后，单篇生产时间从 4 小时压到 1.8 小时（用 AI 做竞品内容拆解那次的数字）。
代价是它会编。所以我给自己定了两条：一是必须有人工确认这一环，草稿就是草稿，不能直接发；二是每个结论都要能点回原始数字，不能只给一句「环比上升明显」。标题和首段这类需要抓注意力的部分，也让模型先给三版、人来选，比让它一次定稿靠谱得多（这个做法跟流量断崖后重构关键词时改标题的逻辑是一样的）。
上线前还有一步别省：先空跑两周。就像文件批量重命名工具会建议你第一次用复制模式跑一遍、确认规则符合预期再就地改名（AI 出图批量重命名整理里的建议），AI 生成周报也应该先并行跑一段，人工比对没问题再放开。
横向对比表
| 维度 | A 定时脚本 | B BI 定时推送 | C AI 生成 + 人工确认 |
|---|---|---|---|
| 上手成本 | 高，要写代码 | 低，界面点几下 | 中，要先有稳定的数据源 |
| 维护成本 | 高，接口一改就断 | 低，平台兜着 | 中，提示词和口径要跟着调 |
| 灵活性 | 最高，想怎么算都行 | 低，受看板能力限制 | 高，但输出不稳定 |
| 出错表现 | 静默失败，最难发现 | 平台会提示，可控 | 会编，且看起来很合理 |
| 适合谁 | 有工程能力的小团队 | 指标稳定、读者多 | 每周必须输出结论 |
这张表只在我们自己的场景里成立。数据源一多、口径一变，A 的维护成本会陡增，B 反而更稳。
怎么选：一条明确不建议的路
我的建议是先 B 后 C，A 只在特殊情况下用。
不建议的路是：数据还没跑稳就直接上 C。取数和整理都没自动化干净，就让模型去写结论，等于把原本只是「数字错了」的风险，放大成一份看起来很专业、但结论全错的正式文档。真要上 C，先确认前两段已经连续跑顺了四周以上。
比较稳的组合是 B 打底、C 补结论：图表和明细由 BI 定时送出去，结论部分人工拿 AI 草稿改完再追加。这样即使模型这周抽风，周报的下限仍然是一份数据正确的图表。
取数这一段如果卡在「平台后台导不出来」，可以看看现成的批量采集与导出工具，比如抖音指数批量查询工具、微信指数查询工具，或者做竞品排名追踪的公开榜单排名追踪，把「从后台一点点点出来」这段先自动化掉，再谈报表。采集时请遵守目标平台的规则与相关法律法规。
常见问题
Q：周报里到底该留几个指标？
A：我的经验是控制在 5 到 8 个，且必须有一半是能触发动作的。看一眼不产生任何动作的指标，从周报里挪到看板里，需要时再看。
Q：AI 生成的结论不敢直接用怎么办？
A：那就先别直接用。让它只做「把数字翻译成句子」这一步，判断和行动项还是人写；每个结论旁边附上原始数值，方便一眼核对。
Q：BI 定时推送能不能替代周报？
A：只能替代「送数据」这一段。它送的是 PDF，没有结论、没有下周计划，读者看完还是不知道该干什么。
Q：数据源换了，之前的历史周报还能对得上吗？
A：大概率对不上，所以每次换源要在周报里留一行说明。我们做采集时会强制留采集时间戳，就是为了半年后还能解释这批数的口径。
