每到周五下午，很多中小企业都会上演同一幕：运营催门店交数据，财务核对销售和回款，仓库补库存表，负责人再把几份 Excel 拼成一份周报。
月末更忙。数字刚合上，老板追问一句：“销售额为什么少了？库存为什么又高了？”做报表的人只能重新翻表、问人、找原因。
真正消耗时间的，通常不是写那几段总结，而是前面的四件事：找数据、统一口径、检查异常、追问原因。
Codex 适合解决的，正是这些重复而又有规则的工作。它可以帮助企业编写数据整理脚本、生成图表、建立预算与实际对比、形成初版问题清单，并把整套流程做成下一周还能重复运行的工具。OpenAI 的官方用例也覆盖合并表格、预算与实际差异、定期经营复盘等场景。
Codex 可以自动做计算和准备材料，最终的经营判断仍然应该由管理者负责。
一、先别急着“让 AI 写周报”
很多人第一次尝试时，会把几张表扔给 AI，然后输入一句：“帮我写一份经营周报。”
这样往往能得到一篇语言通顺的文字，却很难得到一份可以拿去开会的报告。AI 不知道退款算在哪一天，不知道库存金额用含税价还是成本价，也不知道“老客户”在公司内部究竟如何定义。
所以，自动报表的第一步不是写提示词，而是先建立一份小型的“报表合同”：
- 报告覆盖什么时间；
- 每个指标来自哪份数据；
- 指标采用什么计算口径；
- 哪些变化达到阈值后必须提示；
- 哪位负责人需要解释异常；
- 谁负责审核和发布最终版本。
一句话概括：先固定口径，再自动生成。
二、Codex 在整条流程里做什么
一套实用的自动报表流程，可以拆成四层。
1. 数据层：把散落的数据收进来
数据可能来自 ERP 导出、财务软件、POS、电商后台、CRM、考勤系统，也可能只是各部门提交的 Excel 和 CSV。
刚开始不必追求系统全部打通。最稳妥的做法，是先规定每周把导出文件放进同一个文件夹，并统一文件名。等流程稳定后，再考虑调用 API 或数据库自动取数。
关键原则是：原始数据只读，不在源文件上直接修改。 每次运行都保留一份带日期的快照，出了问题才能追溯。
2. 规则层：清洗、校验和计算
Codex 可以根据企业规则编写脚本，处理日期格式、客户名称、产品编码、空值、重复订单和跨表匹配，然后计算销售额、毛利率、库存周转、回款率等指标。
这里最重要的不是“算得快”，而是加入校验：
- 销售明细合计能否与财务收入对上；
- 本周数据是否完整覆盖 7 天；
- 是否出现重复订单号；
- 环比变化是否超过预设阈值；
- 某个部门是否还没提交数据。
如果校验不通过，流程应该停止并给出错误清单，而不是继续生成一份看似完整的报告。
3. 报告层：图表、差异和初步解释
脚本完成计算后，可以自动生成三类内容：
- KPI 总览：销售、毛利、费用、库存、回款、交付等；
- 差异分析：实际与预算、上周、上月、去年同期的比较；
- 管理摘要：哪些指标变差、影响多大、需要谁补充原因。
“原因”要区分为两类：数据能够直接证明的原因，以及需要业务负责人确认的推测。报告中最好明确写成“已验证”和“待确认”，不要混在一起。
4. 管理层：确认原因并形成行动
真正有价值的周报，不是图表多，而是能推动下一步行动。最终版本至少要回答四个问题：
- 本期发生了什么；
- 为什么发生；
- 对目标有什么影响；
- 谁在什么时间前采取什么行动。
Codex 可以生成待办事项初稿，但负责人、截止日期和优先级应由管理者确认。
三、实战：用六步搭出第一版自动周报
第一步：只选一份高频报表
不要一开始就做“全公司经营驾驶舱”。先选一份每周固定制作、至少需要两小时、数据来源相对稳定的报表，例如销售周报、门店经营周报或库存周报。
第二步：建立指标字典
把指标名称、公式、来源、更新频率和负责人写清楚。
| 指标 | 计算口径 | 数据来源 | 异常阈值 | 负责人 |
|---|---|---|---|---|
| 销售收入 | 已确认发货且扣除退款 | 订单明细 | 低于预算 5% | 销售负责人 |
| 毛利率 | 毛利 ÷ 销售收入 | 订单与成本表 | 环比下降 2 个百分点 | 财务负责人 |
| 库存金额 | 期末数量 × 移动平均成本 | 库存表 | 高于预算 10% | 仓库负责人 |
| 逾期应收 | 超过合同账期的未收金额 | 应收账龄表 | 任意新增大额逾期 | 财务负责人 |
第三步：设计输入目录
可以先采用最简单的文件夹结构：
reporting/
├─ input/2026-08-14/
│ ├─ sales.xlsx
│ ├─ inventory.xlsx
│ ├─ receivables.xlsx
│ └─ budget.xlsx
├─ rules/
│ └─ metric_dictionary.xlsx
├─ output/
└─ logs/
日期文件夹用来保存每次输入快照，rules 保存指标口径，output 保存报表，logs 记录运行结果和异常。
第四步：让 Codex 先写方案，再写脚本
不要只说“帮我做报表”。可以给 Codex 一段更像任务书的提示：
请先检查 reporting/input 下的文件结构，不要修改任何原始文件。
根据 rules/metric_dictionary.xlsx 中的口径，设计一套周报生成流程。
要求：
1. 先输出字段映射、计算规则和风险点，等我确认后再编写脚本；
2. 检查缺失字段、重复订单、日期范围和跨表合计；
3. 生成 KPI 汇总、预算与实际差异、异常清单和待办事项草稿；
4. 所有结果写入新的 output/日期目录，并保留运行日志；
5. 对不能从数据中确认的原因标注“待业务确认”，不要自行下结论；
6. 为核心计算编写测试，并用上月数据进行回测。
这种写法的关键，是把权限、输入、输出、校验和停止条件一次说清楚。
第五步：拿历史报表做回测
选择已经人工确认过的 2 至 3 个历史周期，让新流程重新计算。逐项比较销售额、毛利、库存和应收等关键指标。
如果结果不同，不要急着改成“和旧表一样”。先判断是新脚本有问题，还是旧表长期存在手工错误。把差异原因记录下来，最终沉淀为明确规则和测试用例。
第六步：固定审核与发布
第一阶段建议采用“人工点击运行 + 人工审核发布”，不要直接全自动群发。
稳定运行数周后，再逐步加入定时取数、自动生成草稿和消息提醒。即使到了自动化阶段，报告也应显示数据时间、来源文件、校验结果和审核人。
四、案例解析：一家 45 人工贸企业如何改造月报
这家模拟企业同时做线下经销和电商零售。每周数据来自订单明细、仓库库存、应收账龄和费用预算四份表。过去，运营专员每周需要约 5.5 小时汇总，财务再花约 1.5 小时复核；月报通常要占用两个人大半天。
第一版自动化没有接 ERP 接口，只统一了四份导出表的格式，然后让 Codex 协助完成数据处理脚本、图表模板和校验规则。
模拟数据里，收入只比预算低 3.3%，表面看问题不大；但毛利率下降了 2.4 个百分点，同时库存比预算高 19.3%，逾期应收天数也增加了 9 天。
如果只看销售额，老板可能会认为“这个月基本正常”。把指标放在一起后，经营问题就变得清晰：收入差距有限，但资金占用和盈利质量正在变差。
自动生成的摘要草稿可以这样写：
本月销售收入完成预算的 96.7%，差额主要集中在经销渠道。毛利率较预算低 2.4 个百分点，初步可由低毛利产品占比提升解释，但促销折扣和采购成本影响仍需销售、采购共同确认。期末库存高于预算 19.3%，其中两个 SKU 连续四周周转放缓。建议本周暂停补货并制定清理方案。逾期应收账期增加 9 天，需要财务确认前三大逾期客户的回款计划。
这段文字不是替管理者下结论，而是把会议需要讨论的问题提前摆到桌面上。报表最终转成三项行动：
- 销售负责人在周三前解释经销渠道缺口，并更新本月预测；
- 仓库与采购暂停两个慢周转 SKU 的补货，周五提交去库存方案；
- 财务逐一确认前三大逾期客户的回款时间，并标记高风险账户。
经过三个周期回测后，这家模拟企业将周报准备时间从约 7 小时缩短到约 1 小时，节省的主要是复制、匹配、检查和制图时间。管理者仍然需要确认原因、选择行动并审核发布。
五、周报和月报不能用同一套写法
| 维度 | 周报 | 月报 |
|---|---|---|
| 主要目的 | 发现偏差并迅速纠偏 | 评价经营结果并调整计划 |
| 重点指标 | 订单、交付、回款、库存异常 | 收入、毛利、费用、现金流、预算完成 |
| 对比方式 | 上周、近四周、周目标 | 预算、上月、同期、年度累计 |
| 分析深度 | 快速定位异常 | 解释结构变化和主要驱动因素 |
| 输出动作 | 本周负责人和截止时间 | 下月目标、资源调整和预测更新 |
周报应该短、快、能追责；月报需要讲清楚趋势、结构和原因。企业可以复用同一套数据底座，但报告模板和会议问题应分别设计。
六、五个容易踩坑的地方
1. 先自动化错误口径
如果部门之间连“销售额”都没有统一定义，自动化只会更快地产生争议。指标字典必须先得到财务和业务共同确认。
2. 把解释写得过于肯定
数据能证明销量下降，却不一定能证明是竞争对手降价造成的。报告应区分事实、推断和待确认信息。
3. 没有保留原始数据和日志
没有输入快照，就无法解释某次报告为什么变化。每次运行至少保留输入文件清单、文件校验值、运行时间、规则版本和错误记录。
4. 一上来连接所有系统
接口开发、权限申请和历史数据清洗会迅速放大项目范围。先用稳定的导出文件跑通闭环，往往更适合中小企业。
5. 生成后直接群发
经营报表涉及财务、客户和员工信息。访问权限、脱敏规则、审核人和发布范围必须提前确定。自动生成不等于自动决策，更不等于可以跳过审批。
七、一个 7 天可执行的试点计划
- 第 1 天： 选择一份高频报表，记录当前耗时和错误；
- 第 2 天： 收集最近三期输入文件和人工确认的结果；
- 第 3 天： 建立指标字典，确认口径、阈值和负责人；
- 第 4 天： 让 Codex 输出处理方案并完成第一版脚本；
- 第 5 天： 用历史数据回测，逐项解释差异；
- 第 6 天： 调整图表、摘要模板和待办事项格式；
- 第 7 天： 由原报表负责人试跑，记录节省时间和遗留问题。
试点的验收标准不应是“报告看起来很漂亮”，而应该是：关键指标计算正确、异常能够被发现、来源可以追溯、准备时间明显下降，而且负责人愿意继续使用。
今天可以试
- 挑一份每周都在重复制作的 Excel 报表，记录它的数据来源、耗时和最常出错的步骤。
- 用“指标、口径、来源、阈值、负责人”五列建立第一版指标字典。
- 把最近三期已审核报表作为回测基准，再让 Codex 开始写处理脚本。
- 把“校验失败就停止、不确定原因标记待确认、发布前必须审核”写进任务书。
结语
中小企业做自动报表，不需要先买一套庞大的商业智能系统。最现实的起点，是挑一份每周都在重复制作的 Excel 报表，把数据来源、指标口径、检查规则和输出模板梳理清楚，再让 Codex 把它做成可重复运行的流程。
一份好报表的价值，不在于自动写出多少文字，而在于让管理层更早看见问题、更快找到负责人，并在下一次会议前推动事情发生。
Codex 负责把数据变成可审核的材料，管理者负责把材料变成经营决策。