01｜先说结果

很多业务部门其实都有这种工具：一个 Excel 文件，里面十几个 Sheet、大量公式、几个宏按钮，再加一套 VBA。它能跑，也确实解决了很多实际问题。

问题通常不是“不能用”，而是随着时间越来越久，越来越难接手、越来越难维护，也越来越难正式交付。

所以这次我试的不是“让 AI 再帮我改几个公式”，而是让 Codex 先把旧工具看懂，然后问它一个更大的问题：

如果把这套已经验证过的业务逻辑保留下来，能不能不再只交付一个 Excel，而是做成一个更清晰的小应用？

示意图｜旧工具最大的问题往往不在计算，而在长期维护和交付

02｜第一步不是重写

先让 Codex 把旧 Excel 里的“业务逻辑”拆出来

一个用了很多年的 Excel 小工具，本质上并不只是一张表。它通常同时承担了数据存储、业务计算、界面交互和成果输出几件事。

真正重构之前，最重要的是先把这些东西分开。

示意图｜先识别输入、计算、界面、输出和人工判断，再决定哪些部分适合迁移

这里最关键的不是代码，而是先把“哪些是规则、哪些只是表现形式”分清楚。

例如，一个公式可能只是计算实现；一个 VBA 宏可能同时包含业务判断；某个 Sheet 的人工勾选可能其实代表一条不能自动替代的专业规则。AI 如果没把这些关系搞清楚，就不应该直接重写。

03｜拆开以后，交互方式也可以一起变

以前是“找 Sheet、改参数、点宏”，现在可以直接变成一个工作流程

Excel/VBA 小工具最常见的使用方式，是让使用者去适应文件结构：打开哪个 Sheet、在哪里改参数、哪个按钮不能点错、结果又在哪一页。

但如果业务逻辑已经被拆出来，界面就可以重新设计。

示意图｜原来的“操作 Excel”，可以变成更明确的“上传—检查—计算—查看—导出”

这时候 Excel 仍然可以存在——它可以继续作为数据导入模板，也可以作为结果导出格式。但它不再承担整个系统。

更清楚的拆分方式：
数据层：Excel / CSV / SQLite
计算层：Python / JavaScript 等业务规则
界面层：网页或轻量桌面应用
输出层：Excel / 图表 / PDF / HTML

04｜真正改变的，是交付方式

以前交付的是“一个文件”，以后更像是在交付“一套业务能力”

这可能才是这次实验最值得讨论的地方。

过去一个小型业务工具交付时，常常就是一个 .xlsm 文件，再附一份操作说明。只要 Office 版本、宏权限、文件路径或者数据模板发生变化，就可能出现运维问题。

示意图｜从“交付文件”走向“交付应用 + 规则 + 数据结构 + 日志”

重构以后，真正稳定的东西——计算逻辑、参数、数据结构、输出规则——可以单独维护。界面坏了，可以换界面；数据源变了，可以改接口；计算规则调整，也不必先到十几个 Sheet 里找公式。

05｜AI 在这里真正改变了什么

不是“AI 会写一个网页”，而是旧工具第一次有机会被低成本重新拆解

把 Excel/VBA 工具改成应用，这件事以前当然也能做。真正困难的是：需要有人先花很多时间理解旧逻辑，再把需求重新说给开发人员，最后重新实现和验证。

Agent 带来的变化是，这个过程里大量原本很费时间的“阅读旧文件、梳理依赖、解释代码、搭建原型、反复修改”，开始可以由 AI 参与完成。

于是对很多规模不大、但又确实有业务价值的小工具来说，“值不值得重新开发”这道门槛开始降低。

AI 不只是帮我们维护旧工具，它正在改变“小型业务工具”的交付方式。

06｜但有一个边界不能省

看懂旧逻辑 ≠ 自动证明旧逻辑是对的

这里也必须保留一个限制：Codex 可以帮助识别公式、VBA、依赖关系并完成迁移，但这并不意味着旧工具里的每一条业务规则都应该原样继承。

真正重构时，至少要把三类东西区分开：

① 可以确定的计算逻辑：自动迁移并测试；
② 可能是历史遗留的规则：单独列出，人工确认；
③ 涉及专业判断的环节：明确保留人工确认，不让 AI 擅自替代。

所以这不是“把 Excel 一键变网页”，而更像一次有记录、有边界的旧工具重构。

一个普通人学 AI · 11

以前一个业务小工具，可能最终交付的是一个 Excel。
现在，我们可以开始重新想一件事：
真正应该交付的，到底是文件，还是一套可维护的业务能力？