Codex * Excel神组合:把每月重复的判断做成Skill,月结不用一张张对

现实里处理 Excel 表格，最花时间的往往不是复制粘贴，而是前面的判断。

因为每个人交过来的表都可能长得不一样。

文件格式不一样，工作表名称不一样，栏位名称和排列顺序也不一样。

你得先判断哪些栏位说的是同一件事，哪些数字能不能直接加。

最后还要回头检查有没有漏行，金额能不能对上。

所以很多人到了月底，真正重复做的其实就是这一整套的判断。

下面这个是我把五张格式不同的分店业绩表全部拖进 Codex，调用我自己搭建的月结 Skill，然后只跟它说了三个字：

跑月结

最后它交给我的不只是把五张表拼在一起。

25 行资料全部保留，5 家店分别有小计，整张表有总计，每一行还能追溯到来源的文件。

旁边也保留了处理的记录、规则和检查结果。

只有函数和金额全部对得上，最后才会显示 pass。

以前碰到这种工作，我得一张张打开查看每张表哪里不一样，再手动调整。

现在我把这套每个月都会重复的判断，直接做成了一个可以反复使用的 Skill。

所以这期我要帮你解决的一件事就是：让月底合表这件事，从两个小时变成一句话。

具体我们会做四件事。

第一，先把这五张表到底哪里对不上看清楚。

第二，我直接把表丢给 AI 试一次，看看一句话能做到什么，距离真正可以交付还差在哪里。

第三，我们一起写一个 Skill，把公司内部的规矩装进去。

第四，换一批全新的表，重新打开一个对话，只说一句「跑月结」，看它还能不能按照同一套标准完成。

上一期 Codex 七个打工人的零基础用法得到了很多朋友的喜欢，非常感谢。

这一期我们还是用最简单的话继续带你深入使用 Codex，全程新手友好。

我打开 Codex，把这五张表全部拖进去，然后说一句：

帮我把这5张表合成一张

它确实是合出来了，速度也很快。

但是我们打开来看一下，这一次真实跑出来的结果，其实比我原来预想的好很多。

25 行资料全部保留了。

民国 115 年被正确地转换成了 2026 年。

台北、台北店、TPE 也都正确合并成了台北店。

来源文件和原始的店名都留了下来，数量乘以单价也没有算错。

所以这一次不能为了证明 Skill 有用，硬说它第一次就做错了。

至少在合并明细这件事上，它第一遍已经完成得很好。

但这份表还没有达到我这次演示设定的最终交付标准。

它把含税来源的金额和未税来源的金额分别统计了出来，却没有按照 5% 的税率统一换算。

也没有套用公司固定的 12 栏模板。

没有分店的小计、总计和异常的处理。

那这个也不能怪它。

因为我刚才只说了把五张表合成一张，并没有告诉它含税和未税应该怎么统一、最后要套什么模板、遇到对不上的资料应该怎么办。

它完成了我交代的事情，没有完成我没有交代的标准。

碰到这样的情况，我们通常的做法还是继续在这个聊天窗口当中一次次地优化迭代。

告诉它税率怎么算、模板怎么套、异常怎么处理，直到结果符合要求。

但真正的问题是：这一次它推断对了，不代表以后每个月换一批新表、换一个新的对话，我们都应该继续依赖它临场来推断。

含税的口径、固定的模板、不准拆的边界，还是需要变成一套可以重复执行的标准。

所以平常我们讲「教 AI」，其实是个错觉。

你在一个对话里跟它讲的所有规矩，只在这个对话里有效。

你把它关掉，那些东西就跟着没了。

下次你开一张新的，它面对的依旧是一张白纸。

所以你以为你在教它，实际上你每一次都是在重新描述一遍你的需求。

你重复的不是那个活，你重复的是「交代」这个动作。

他们的做法都很朴素：既然单次对话会结束，就把长期的规则写进项目文件。

在 Codex 里，长期项目规则主要写在 AGENTS.md。

在 Claude Code 里，主要写在 CLAUDE.md。

两边都支持 Skill，但 Skill 更像是可复用的能力包或标准操作流程，而不只是一个存放项目规矩的文件。

你可以把它想象成一个餐厅。

每次在对话里告诉 AI「代码要写得简洁」「不要随便改目录的结构」，就像老板每次临时口头嘱咐厨师。

换一个人，或者过一段时间，这些话就可能没有人会记得。

而 AGENTS.md 和 CLAUDE.md，就像是贴在后厨墙上的员工守则，不管今天谁来上班，都要先按照这些长期的规则来做事。

Skill 更像是一本完整的招牌菜菜谱。

它不只是规定少放盐、注意卫生，而是把准备的食材、制作步骤、使用的工具和检查标准，都整理成一套可以反复执行的流程。

简单来说：对话是临时交代，AGENTS.md 和 CLAUDE.md 是长期的守则，Skill 是一套可以直接照着执行的标准作业流程。

存下来之后，它每次开工会先去读一遍，你不用再讲，它自己就知道。

我觉得这个设计最聪明的地方是，它没打算让模型记住你，它是让你把规矩变成一个文件。

文件你可以改、可以复制，也可以直接丢给同事。

记忆做不到这些。

接下来我们不手动创建这个文件，也不要求你先记住什么路径、文件名和格式。

因为这样讲对刚开始接触 Codex 的人并不友好。

我们直接用 Codex 自带的 Skill Creator。

你只需要把自己的业务规矩，用平时说话的方式告诉它。

它会帮你把这些内容整理成一个可以重复使用的 Skill，并且把需要的文件创建出来。

这里有一个细节要注意，它的名字叫 Skill Creator。

你可以把它理解成一个专门帮你制作 Skill 的 Skill。

我先打开 Codex，进入准备用来处理报表的项目，然后直接对它说：

请使用 Skill Creator，帮我创建一个用于整理分店月度业绩表的 Skill。

这个 Skill 每个月都会收到 4 到 6 张格式不统一的 Excel 业绩表，需要清理、日期统一、栏名换算、税额与店名归一，并按照固定的模板输出。

在遇到无法判断的数据时，不允许自行猜测，必须标记出来让我确认。

你看，我没有写程式，也没有自己创建文件夹。

我只是在对话框里把我要它做的事讲清楚。

Codex 接下来会根据这些要求，帮我们生成 Skill 的基本结构。

它的核心文件叫做 SKILL.md，里面写的并不是什么复杂的程式，主要是我们能够看得懂的大白话。

生成以后我们不要急着接受最终版本，还要继续把真正的业务规则补进去。

我这里一共准备了七条规则。

不过在一条条输入之前，我想把我为什么要这么写的背后逻辑讲清楚。

理解了逻辑，你也可以根据自己的实际情况进行调整。

因为它们并不是想到什么就补什么，也不是七个零散的技巧。

它们其实是在完成一条从原始表格到最终交付的完整流程。

第一条，是先让 AI 认清自己到底收到了什么。

第二、第三和第五条，是把不同的写法背后的真实意思统一起来。

日期到底是哪一天，栏位到底代表什么，几个不同的店名到底是不是同一家店。

这些意思确认以后，第四条才开始处理含税、未税和税额的这些计算口径。

第六条在规定最后必须交付成什么样子。

第七条比较特别。

前六条是在告诉 AI 确定的事情应该怎么做，第七条是在告诉它碰到不确定的事情，什么时候必须停下来问人，不能自己猜。

所以你以后在搭建其他 Skill 的时候，也可以先问自己这五件事。

它会收到什么资料，分别代表什么业务，应该怎么算，最后要交付成什么样子，还有遇到不知道的情况什么时候必须停。

这五件事情想清楚了，Skill 的骨架基本上也就出来了。

第一条，先讲清楚它会收到什么。

这一条是在规定输入范围。

因为文件都是表格，不代表表里面的结构就一样。

如果不先逐张识别，AI 很可能拿第一张表的格式硬套后面的文件。

结果资料放错栏、漏读的工作表，甚至丢了几行都不一定会报错。

我还特意加上「只处理这次明确提供的文件，不要扫描其他目录，也不要覆盖来源的文件」。

这句话是在限制它的工作范围，避免它为了找资料跑去读取不相关的文件，或者直接改动我们的原始表。

第二条，统一日期。

这里做的统一，不是日期看起来长什么样，而是它真正代表哪一天。

如果我只说「统一日期格式」，AI 可能只是把外观整理整齐，但实际年份仍然可能判断错。

所以这一条同时写了识别的条件、换算的方式、最后的输出格式，还有什么时候不能继续拆。

第三条，统一栏位的名称。

这一条是在给 AI 一份公司内部的词典。

AI 能看出两个词很相近，但是它不知道在我们的公司报表里，这两个词是不是真的代表同一个指标。

所以已知的叫法直接写进对照表，没登记过的叫法就保留下来问我，不能偷偷按相似的意思做归类。

第四条，处理含税和未税。

到这一条才真正开始算钱。

因为一串数字本身不会告诉你它含不含税。

哪些店含税、税率是多少、除不尽的时候怎么取整，这些都是公司自己的业务规则。

只说一句「帮我处理税额」远远不够。

公式必须写到别人能够重新核对。

否则每一行数字都可能是真的，但把含税和未税金额直接加在一起，最后的总数还是错的。

第五条，统一店名。

这一条的目的是在统一「这是谁」。

同一家店可能有简称、正式名称和英文缩写，只要它们经过公司确认，就放进店名对照表。

没有登记过的名字，哪怕看起来再像，也不能自行归类。

不然明细一行都没少，同一家店却被拆成了好几家店，后面的门店小计和排名也会跟着拆散。

第六条，规定最终的输出格式。

发送这一条之前，我先把公司标准的输出模板拖进当前的对话。

这一条的目的是在规定「什么才叫真正的交付」。

AI 生成了一个 Excel，不代表这项工作已经完成。

栏位的顺序、工作表的名称、小计位置和数字的格式，都是后面的人能不能直接使用这份报表的一部分。

所以能给模板，就不要让 AI 猜格式。

否则它每个月虽然都能生成一个结果，但你还是得手动排栏、补小计、调格式。

自动化只完成了一半。

第七条，对不上的时候不准猜。

这是我认为最重要的一条。

这一条的目的是在给自动化画停止线。

前六条是在告诉 AI 确定的事情应该怎么做，而第七条是在告诉它，遇到规则之外的情况什么时候必须停。

而且光写一句「不准猜」还不够。

还要告诉它保留哪些证据、把问题放在哪里、确认以前能不能进入总计，以及确认以后要怎么重新处理。

真实业务里，一个被明确标出来的异常，通常比一个完整但没有依据的数据更安全。

我把这一条在文件里写死成这样：

任何一行如果对不上，不准自己判断。
把那几行单独列出来问我，保留原始值与来源文件，先不进入总计。
我确认之后，记录这次人工决定，再回到原始文件重新处理。

我把这一条单独强调一下。

AI 有个毛病，它非常不愿意跟你说「我不知道」。

你给它一行对不上的数据，它多半会自己挑一个看起来最合理的填进去，而且填完不会告诉你。

那张表交出去的时候看起来完全正常，但你根本就发现不了。

七条规则整理完之后，Codex 会把散落在对话里的规则整理成一套正式的工作流程。

核心的 SKILL.md 大致是这个样子，你可以直接照着改成自己的：

# 月结合表骨架

先阅读「需要填写的业务规则」。只处理用户在本次对话中明确提供的文件，
不扫描其他目录，不覆盖来源文件。

## 使用前门禁
1. 检查业务规则里是否仍有【待填写】。
2. 如果有任何待填写项，停止正式处理，逐项向用户询问。
3. 将用户确认的规则写回参考文件。
4. 把用户正在使用的标准模板替换进来。
5. 用第一批真实样本测试，再换新对话和新样本复测。

## 固定执行顺序
1. 列出用户明确提供的来源文件。
2. 逐份识别文件格式、工作表名称、栏位名称、排列顺序和金额口径。
3. 按用户填写的日期规则统一日期。
4. 按用户填写的栏名对照统一字段。
5. 按用户填写的店名对照统一名称。
6. 按用户填写的税率与含未税规则计算金额。
7. 复制公司标准模板并另存输出。
8. 对无法判断的数据保留原值、标记异常并询问用户。
9. 得到明确回答后再补入正式结果。
10. 核对来源数、明细数、小计、总计和金额勾稽。

## 绝对边界
- 不根据地名、缩写、上下文或"看起来合理"自行归类。
- 不把未知记录静默放入最相似的分类。
- 不覆盖来源表和标准模板。
- 不删除用户未要求删除的栏位或记录。
- 不把未执行、未验证或未发生的动作写成成功。

配套的「需要填写的业务规则」就是一张待填的清单，把方括号换成你公司的真实规则就行：

## 输入
- 每次来源文件数量：【待填写，例如 4 到 6 张】
- 允许的文件格式：【待填写，例如 xlsx、csv】
- 哪些文件不属于输入：【待填写，例如模板、标准答案】

## 日期
- 本地年份或特殊日期识别规则：【待填写】
- 年份换算公式：【待填写】
- 最终日期格式：【待填写，例如 yyyy-mm-dd】

## 栏名对照 / 名称对照
- 原始栏名 → 统一栏名：【待填写】
- 原始店名 → 统一店名：【待填写】

## 税额与金额
- 税率：【待填写】
- 哪些来源是含税 / 未税：【待填写】
- 统一输出口径与舍入规则：【待填写】

## 输出模板
- 正式栏位顺序、分组排序、小计位置、总计位置、输出文件名：【待填写】

## 无法判断时
- 必须保留哪些原始字段、异常写到哪里、需要向用户询问什么：【待填写】

## 验收
- 输入行数检查、金额勾稽检查、公式错误检查、人工抽查规则：【待填写】

所以创建 Skill 并不是在写程式。

更准确地说，它是在带一个新员工。

你先把工作交代清楚，让他整理成操作手册，再拿真实任务检查这本手册到底能不能用。

现在我们来验收。

我把刚才那个对话整个关掉，重新打开一个全新的对话，再把五张新的表丢进去，只说三个字：跑月结。

它自己找到了我们刚才创建的 Skill，然后按照里面的规则开始处理。

但是第一次运行，它发现了一些无法确定的资料。

它没有继续往下拆，而是把相关数据全部保留下来，单独列进「待人工确认」，然后停下来问我。

这种情况在真实的 Excel 合并里很常见。

因为人工填写的表格除了格式和栏位顺序不一样，还经常会出现新的栏位、新的名称，或者一些没有提前登记过的内容。

AI 看起来也许能够猜个大概的意思，但「看起来合理」和「公司已经确认」不是一回事。

所以我把这些问题确认完以后，它会记录这次人工决定，再回到五份原始文件重新处理。

第二次运行：25 行资料全部进入正式的明细，待确认变成 0 行。

5 家店分别有小计，整张表有总计，金额和函数全部对上，最后的检查状态显示 pass。

这一段我最想让你看到的，其实不是它把表格做完了。

而是它遇到不确定资料的时候，真的停下来问我。

好的自动化不只是知道应该怎么做，还要知道什么时候不能继续做。

而且这次实测也说明，Skill 不是写完一次就永远不会出问题。

真正的做法是：先把规则写进去，再换一批新的资料去测试。

它在哪里会停住，我们就会知道规则还缺在哪里。

其实不是。

我自己做了一段时间以后发现，一件工作值不值得做成 Skill，主要看四个条件。

第一，这件事会不会重复发生。

不一定非得每周一次。像月底核表就是每个月一次，但每次都要重复做一套判断，这种工作就值得考虑。

第二，最后的交付标准是不是相对固定。

输出的格式越稳定越适合固化。如果每次的任务和结果都完全不同，就很难整理成同一套流程。

第三，这里面有没有一套只有你或者公司内部才知道的规矩。

如果一句话就能让 AI 稳定做对，那你不一定需要 Skill。

真正值得写进去的，是那些 AI 不可能凭空知道、但你每次都要重复交代的业务判断。

第四，这个结果能不能被清楚地验收。

你要知道什么叫完成，什么叫没有完成。如果最后连你自己都无法判断结果对不对，那这个 Skill 做完以后你也不敢真的使用。

这四个条件基本满足，才值得花时间搭建。

第一，先找出这项工作里反复出现的判断，不要一开始就急着自动化。

第二，把 AI 不可能知道的业务规则写清楚，包括资料代表什么、业务怎么算、最后要交付成什么样子。

第三，规则不要只写一个大概的方向，要写清判断条件、处理方式和验收标准。

第四，一定要规定遇到不确定资料时怎么办：不能自己猜，要保留原始证据，停下来问人。

第五，Skill 写完以后一定要更换新资料、开新对话再跑一次。

结构验证通过不代表真实业务已经通过。

只有经过新资料的测试，函数、金额、异常和最终结果都能对上，这个 Skill 才算真正可以重复使用。

其实这一期我更想表达的一个想法是：我们只是借 Excel 整理表格这个案例，来从头跑一遍 Skill 的搭建流程。

换到其他的场景当中，Skill 搭建的底层方法逻辑都是相通的。

包括如何搭建专属自己的 PPT 制作 Skill，还有日常生活当中所有能够 SOP 的一套流程，都可以用这样的方式完成搭建。

这个我觉得才是最重要的，是搭建 Skill 的一种元认知。

这里是 Fanko AI 范式。我会继续把自己亲手跑过的 AI 方法写成能独立读完的文章，需要动手的时候，再把提示词、Skill 和工作流留给你。

以上，既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们下次再见。

>/ 作者：fanko

>/ 每期都是自己亲手跑过一遍才写