Codex+Excel:先改表,不改系统

很多企业一说数字化，就想到上系统、换 ERP、做大屏。但订单、回款、库存、报价、渠道、项目进度，最后往往仍要落在一张张 Excel 里。真正卡住团队的，不是没有系统，而是每天都在导出、复制、核对、汇总，却没人把这条流程做清楚。

Microsoft Graph 的 Excel 能力说明，业务云盘中的工作簿、表格、区域和图表可以被程序读取和修改。这不是要求每家企业立刻接 API；它至少说明了一件事：Excel 不是临时工具，它本来就是可以被管理、被校验、被连接的业务数据表面。

— 信息图：表格里的重复劳动

— 信息图：表格改造的第一价值

优先挑三个条件同时满足的表：每周至少整理一次；字段和计算规则相对清楚；最后能由业务负责人核对。例如销售周报、回款明细、库存预警、项目进度表。不要从最复杂、最敏感、最容易造成外部影响的表开始。

选定以后，先记录基线：原来谁做、要多久、最常见错误是什么、要等谁确认、返工几次。没有这些数据，后面就只能说“感觉快了一点”。老板要的不是漂亮演示，而是能比较的前后差异。

— 信息图：选表三条件

— 信息图：基线怎么记

让 Codex 直接覆写生产表，是最差的起步方式。第一步只允许它做四件事：读表结构、检查缺失或异常、按既定口径汇总、生成一个结果草稿。它可以提出问题和标出异常，但不能替负责人确认业务事实。

对于存在云端协作的表，Microsoft Graph 也区分保存与不保存的会话。对普通团队来说，翻译成一句话就是：原始表永远不动；任何 AI 处理结果都在副本或新工作表里呈现；确认后再由人写回。

— 信息图：只读分析的边界

— 信息图：写回前对账

一份 AI 整理出的周报，至少要能回答：这个数字来自哪几行、按什么口径计算、和上周相比为什么变化、谁确认过。若回答不了，数据再漂亮也不能用于经营决策。AI 擅长整理和发现模式，业务负责人负责判断数字是否真实。

把“来源行、计算口径、异常说明、确认人”固定成每次输出的四列。这样即便换了人、换了模型、换了文件，团队仍能快速找到问题在哪里。表格改造的重点不是做出炫酷仪表盘，而是降低每次核对的沟通成本。

— 信息图：原表与工作副本

— 信息图：周报校验循环

第一周，选表、记录基线、跑两次只读分析；第二周，把异常和结果草稿交给原负责人核对。两周后只看四个数：整理周期有没有缩短、错误有没有减少、返工有没有变少、它有没有影响现金、交付或风险。

如果四项里只有“做得更快”，却没有减少错误和返工，就先优化规则；如果结果稳定、口径清楚、负责人愿意复用，再推广到第二张表。系统建设当然重要，但老板最先该改造的，往往就是每天已经在流转的那张表。

— 信息图：老板的四项评分

— 信息图：两周启动计划

先让一张表少出错、少返工、能解释，再谈更大的数字化项目。

选一张每周都要人工整理的业务表，先做“只读分析＋人工确认写回”的两周试点。

来源区

Microsoft Learn：Working with Excel in Microsoft Graph

Microsoft Learn：Excel workbooks and charts API overview

OpenAI Developers：Codex use cases

我是 AI洞察，热衷于分享 AI 观察与干货。