先交代背景我谈不上懂技术代码水平停留在大学时代用过几天 C 语言的阶段。日常工作里我和 Excel 打交道的时间比和同事打交道的时间还长。真正让我动起“让 AI 替我干活”念头的是有一次月末对账——45 个门店发来销售表表头写法有七种版本产品名有的写简称、有的带空格金额有的带两位小数、有的直接存成了文本。那个周五下午我从两点整理到六点半搞完只觉得眼睛发酸脑子里只有一个想法这种事情如果再发生一次我一定要找办法甩出去。后来我做到了。我把这套“脏活”的完整处理思路整理成了 AI 的 Skill再遇到同类表格丢给 AI十分钟内拿到干净结果。这篇文章不是教人写代码的教程我也不打算讲什么高深的技术框架。它更像是我的制作手记一个没有编程基础的普通人怎么理解 Skill 是个什么东西怎么把自己的 Excel 处理经验“翻译”给 AI又在哪里踩了坑、填了坑。如果你也天天被 Excel 的重复劳动折磨这篇文章应该能给你一条能直接落地的路径。1. Excel 脏活到底脏在哪我盘点了自己的重复劳动清单先说说我口中的“脏活”具体指什么。不是复杂的数据分析更不是深度的财务建模而是那些看起来不费脑子、做起来却极其耗时的机械操作。我给自己做了个分类大致能分成五类。第一类是表格清洗。去重复行、去掉首尾空格、修正错别字、统一日期格式、处理空值。听起来简单但真实表格永远有意外。有些客户在“备注”里写“无”有些写“-”有些干脆留空日期格式有的是 2024/1/5有的是 20240105有的是“2024年1月5日”。每一列都要单独检查稍不留神就漏掉一行。第二类是结构转换。宽表转长表、分列、合并单元格、把一列拆成多列或者反过来把多列拼成一列。这些操作我每次都靠搜索引擎现学现用学会了这周用下周又忘等于从头再来。第三类是跨表汇总。这是最让我头疼的一类。各个分公司发来的报表同样代表“月份”这一列有的叫“期间”有的叫“统计月”有的直接不写列名靠位置对应。收入这列有的叫“销售额”有的叫“营收”有的叫“业绩”。把这些表合并到一起如果只是简单地堆行数字全对不上。第四类是核对差异。两列数据对比找不同两个 sheet 之间找缺失上个月的余额和这个月的期初数对平。这个工作最怕的是“好像对上了又好像哪里没对上”的模糊状态面对几千行数据时眼睛根本不够用。第五类是常规公式和菜单技巧的反复使用。比如 VLOOKUP 嵌套、二级联动菜单制作、把 IP 地址按网段排序这类偏门需求。网上教程一大堆但每一次都是“会了又忘、忘了又查、查了还会踩坑”效率极低。如果把这些动作加总我估算自己平均每周至少要花六到八个小时在这类事情上。如果遇到月底、季度末这个数字会翻倍。问题在于这种工作不上秤称不出重量但它实实在在地把白天的时间切成碎片让人没法安心做真正想做的业务分析。在决定用 AI 之前我也想过其他方案。比如学 VBA 写宏或者用 PHP 写个批量处理脚本甚至尝试过把表格导入数据库再写 SQL 处理。这些方案对我这种人来说都有同一个问题学习成本太高而且思路是“把整个流程用代码固化下来”一旦表格结构变了一点代码就要跟着改。真正让我留出心思的反而是当时新流行起来的 Skill 概念——它不需要我写完整程序只需要我把“我是怎么做的”讲清楚这我有把握。2. 非技术人理解 Skill 的正确姿势先忘掉“编程”两个字我最初看到“Skill”这个词脑子里默认它是某种插件后来发现这个理解不太准确。最贴近的说法是Skill 是交给 AI 的一份“工作说明书”或者说给 AI 员工的“操作手册”。它本身不是程序也不是一个能独立运行的 App而是让 AI 在面对某一类任务时能按一套预设的步骤、规则、示例去干活的东西。这里需要稍微解释一下背后的原理不然很容易误解。AI 助手在没有 Skill 的时候就像一个能力很强但没有经验的实习生。你让它“处理一下这张表”它知道可以调用表格读写工具但没有既定步骤走一步算一步很容易发挥不稳定这次记得去空值下次就忘了这次把“缺考”记成 0 分下次可能把 0 分当成“缺考”。Skill 干的活就是把“老员工心里那套没写下来的流程”固化成显性文字让每次执行都尽量稳定。实际的运转逻辑大概是这样的我向 AI 助手发送一个请求AI 会先读一下我提供的 Skill 描述判断当前这个问题适不适合调用这个 Skill。如果适合它会加载 Skill 里的详细说明按里面写的步骤、约束、示例来处理。所以一个 Skill 文档通常包含三样核心内容什么时候用、一步一步怎么做、做完怎么检查。这刚好是不需要写代码就能完成的。这里我还想专门澄清一个常见误区。很多人和我一样以为制作 Skill 需要懂 API、会写 Python实际不是。做 Skill 最核心的能力是“把业务专家脑子里的经验翻译成能复现的操作步骤”。就像给新员工写培训手册你不必会搭建培训系统但你必须把你每天怎么做事的细节一个字一个字写清楚。Excel 处理这件事最大的门槛恰恰不是技术而是很多人根本没留意过自己的操作步骤是什么。我第一次尝试写的时候拿起笔想写清楚“我怎么删除重复值”才发现自己的动作全是碎片化的先筛一遍看有没有重复再删删完还要数一下数量对不对看有没有误删……这些细节不落到文字上AI 再强也猜不出来。对非技术人来说掌握这个心智模型就够了把 AI 当成一个“能读文件的实习生”把 Skill 当成交给它的实习手册把示例当成带它做一遍的示范课。由这个逻辑出发反而能避开我一开始踩的坑——很多人上来想做“全能 Excel Skill”把一个文档写得什么都想管结果 AI 在执行时根本不知道该按哪个分支走。正确的做法是先做窄再慢慢加这我后面会详细说。3. 我的第一个 Excel Skill 制作全流程从“自己手动做一遍”开始我做的第一个 Skill 不是最复杂的跨表汇总而是“合并各区域门店周报”。选它有两个原因第一它每周都要做频率足够高回报最直接第二它规则相对明显适合作为第一次练习。我不会在这里贴完整的成果文件但会把制作思路和骨架完整展开你可以顺着这个逻辑做自己的第一个 Skill。3.1 第一步选择单点任务然后亲手做一遍很多人一开始就想做一个能处理所有表格问题的万能 Skill我劝你不要这么干。第一次做一定要选一个“你每周都会重复且规则明确”的任务。我当时选的是把各门店发来的周报合并成一张总表。选定任务后我的做法是打开一个真实的历史文件自己手动完整处理一遍同时用文字把自己每一步的动作记录下来。这一步非常关键。你会惊奇地发现自己平时处理表格的时候很多判断是在脑子里瞬时完成的根本没有形成文字。比如我看到日期列时会下意识判断“这个格式能不能排序”看到金额列时会先想“汇总时要不要保留两位小数”这些瞬间判断都必须被捕捉下来才能写进 Skill。我记录下来的几个按钮动作看起来相当简单确认表头、规范列名、删掉完全重复的行、检查是否存在合并单元格、统一日期格式、把文本型金额转成数字、最后汇总求和。但真正有价值的是那些“如果情况出现就这么处理”的判断规则如果表头叫“门店”或“店名”或“分店”统一改成“门店”如果金额是空值不做任何推断保留为空白而不是填 0。3.2 第二步写 SKILL.md 的基础框架在 AI 生态里Skill 通常是以一个 Markdown 文件为核心来组织的不少平台约定这个文件叫 SKILL.md。文件里最前面的部分是描述信息也就是给 AI 判断“什么时候调用本技能”用的。这部分不能写得模棱两可要明确触发场景。我当时的写法大概是下面这样的结构你可以对照参考--- name: weekly_sales_consolidator description: 合并各门店周报。适用于多张结构相似但不完全一致的 Excel 表 需要统一表头、清洗异常值并生成汇总 sheet 的场景。 --- # 门店周报合并处理流程 ## 目标 把多张门店周报合并为一张总表并输出汇总数据。 ## 输入要求 - 接受多份 .xlsx 文件每个文件代表一个门店。 - 每个文件中含有“销售明细” sheet。 ## 处理步骤 1. 读取所有文件列出每个文件的所有列名。 2. 将列名按映射表统一为门店、日期、渠道、销售额。 3. 删除所有列完全相同的重复行。 4. 将日期统一为 YYYY-MM-DD 格式。 5. 检查是否存在合并单元格若存在则取消合并并填充。 6. 将“销售额”列转换为数字类型空值保留空白。 7. 生成一张“汇总”sheet包含每家门店的周销售额合计。 ## 禁止事项 - 不得把空值填充为 0。 - 不得修改原始文件只允许生成新文件。这个框架看起来并不复杂但它是整份 Skill 的骨架。关键不是 Markdown 语法写得多漂亮而是每个步骤都要表述到“让一个没做过这活的实习生也能照着执行”的程度。你如果打开我早期的版本会发现很多描述都太模糊比如“调整格式”这种词AI 根本不知道要怎么调。3.3 第三步给 AI 提供“看一眼就能对齐”的列名映射表跨表汇总最大的拦路虎是列名不统一。同一个意思这个门店叫“店名”那个门店叫“门店名称”还有的干脆写成“Name”。我第一次做的时候没有写映射表结果 AI 合并后的表里“门店”这一列有几种不同的叫法等于没合并。修复方式是在 Skill 里增加一个同义词映射表。把我在实际文件中见过的所有列名都列进去并指定一个标准列名。比如标准列名可能的原始列名门店店名、门店名称、分店、店铺、Name日期销售日期、交易日期、时间、Date销售额收入、营收、业绩、金额、GMV这个表看起来不起眼但它是整个 Skill 最值钱的部分。因为它来源于我一年的实战积累不是随便能写出来的。写完之后我再跑一遍AI 的合并效果直接从“勉强能用”变成“基本不出错”。我在后来做其他 Skill 的时候也把这项习惯保留了下来每个 Skill 里都维护一份“术语映射表”它是业务经验最直接的载体。3.4 第四步加一个示例模拟“带教”过程光有规则还不够AI 在执行时偶尔会陷入“卡在抽象规则里”的状态。我后来意识到在 Skill 里加入最小示例非常管用给一张只有两行数据的简化输入表以及对应处理完的输出表相当于带 AI 走了一遍正确路径。这个示例不用复杂甚至可以说越简单越好只要能让 AI 明白“我要求的最终效果长什么样”。我的示例大概是这样的输入是一个只有三列的迷你表格列名写的是“分店名”“日期”“收入”其中“收入”列有文字型数字和空值输出展示的是一张列名已经标准化、日期已统一、空值保留空白的新表。这短短两行数据比写两百字规则更能让 AI 抓住重点。后来我测试时发现凡是加上示例的 Skill执行准确率明显高于只有描述的 Skill。4. 真实数据把 Skill 打回原形三次迭代修复记录Skill 第一次写完的时候我感觉自己相当机智。一运行就出结果看起来也有模有样。但把它丢到真实数据里我的心态就崩了。真实数据和我在文档里描述的场景差距非常大这一节我把我走访过的坑完整记录一遍不是单纯列问题而是尽量还原我是怎么一步步排查的。4.1 第一次失败列名映射表没有覆盖“新变体”问题现象是这样的我把 89 个文件全丢给 AI 合并它在汇总说明里写“处理完成”但我抽查了几行发现“门店”列里有大量空白。我第一反应是怀疑读取文件出了问题于是打开一个原始文件对照发现那批文件根本没有“门店”列而是把门店信息写在了工作表名称上——文件名是“上海店”里面只有“日期”和“收入”两列。排查之后我明白了AI 按照映射表找不到“门店”列但它没有报错而是默默地把这一列留空了。这是一个特别容易埋雷的点AI 在任务无法完全满足时有时会选择“尽力而为”而不是“停下来问”最后结果里就会出现隐性错误。我的修复方法是在映射表里加了一条新规则如果门店信息存在于文件名或工作表名中则从文件名提取并填充到“门店”列。同时我还加了一条强制要求处理完成后必须检查“门店”列是否存在空白如果存在就中止并报告问题而不是继续输出。这次修复让我学到一个重要经验Skill 不仅要告诉 AI“怎么做”还要告诉 AI“做不出来的时候怎么处理”。后来我把“异常处理策略”单独作为一个小章节写进了每个 Skill包括遇到缺失列怎么处理、遇到编码乱码怎么处理、遇到文件打不开怎么处理。把异常情况提前写进去比运行到一半时靠 AI 临时发挥要稳妥得多。4.2 第二次失败空值语义被粗暴统一了第二次翻车现场更隐蔽。当时我处理的表格是各门店上报的培训记录里面有“业绩完成率”一列有些门店没开展培训填的是“无”有些填了空有些写的是“-”。我此前在 Skill 规则里写了“空值保留空白”结果 AI 把所有“无”“-”“空”全部转成了空白单元格。从形式上看挺干净但业务语义全变了——“没开展培训”和“数据缺失”是两回事一个是真实的 0 状态一个是不明状态。排查过程是这样的我先看到汇总统计里“完成率”一列计数少了十几行然后就拿原始数据一个单元格一个单元格对照才发现这批特殊文本被清零了。修复方案是建立一个“缺失值语义地图”规定“无”“-”“/”“null”统一转为“未开展”真正的空单元格保留为空并新增一列叫“备注说明”把原因写进去。这个问题的本质是业务数据里同一个空值背后可以有好几种含义AI 不知道这些含义我必须定义清楚。4.3 第三次失败合并单元格让数据整行错位还有一次失败不是 AI 的锅是 Excel 文件本身暗藏陷阱。我处理一张供应商报表时AI 合并完的数据看起来完全正常但一排序就乱套。我慢慢排查最终定位到原始文件“品类”列里有大量合并单元格合并后只有第一行有值下面各行是隐藏的。AI 在读取时通常只把这一个值读出来导致下方多行数据都缺失了品类信息后续一旦排序行与行之间的关联就全部错位。修复策略分两步。第一步在 Skill 的处理步骤里加上“检查并取消所有合并单元格内容填充到下方单元格”的固定动作第二步在检查清单里追加一项“合并后必须校验品类列有没有空值”。这个坑让我注意到Excel 里“看起来正常”和“数据真的正常”是两回事后续我在做任何 Skill 时都会要求 AI 在输出前做一次“行数一致性校验”原始文件总行数是否等于清洗后总行数加删除的重复行数如果对不上说明有数据被吞掉了。除了这三次大的迭代中间我还修了一堆小 bugCSV 文件打开乱码需要在读取时指定编码格式有些表格里带着公式结果缓存AI 读到的和 Excel 重新计算后的结果不一致所以我在收集文件时尽量让大家用“粘贴数值”后的版本还有一次系统弹出了“这个操作只对当前安装的产品有效”的报错这是在本地 Excel 环境里处理数据时遇到的加载项兼容性问题后来发现跟表格本身没关系是机器上的 Excel 加载项环境需要修复和 AI 无关但当时也把我绕进去大半天。几次折腾下来我的感受是做 Skill 的过程根本不是在写文档而是在给我的 Excel 处理经验做一次次压力测试。每一个真实数据文件都会带来一种新意外而每次意外都会让我对“这个任务到底是怎么做出来的”理解得更深入一层。5. 把 Skill 嵌入日常办公流触发、验证与协作边界Skill 能跑通只是第一步。我真正觉得“这事成了”的标志是它被稳定嵌入到我的日常流程里到了时间点它会自动被调用我不需要每次重新描述需求。这里有几个实用经验和代码无关但对非技术人来说非常重要。5.1 利用“文件命名 触发描述”来控制 AI 何时出手Skill 的触发机制通常分两种一种是 AI 根据用户描述自动判断是否匹配另一种是通过显式关键词或者指令来触发。我的做法是两者结合。在文件层面我会约定一个以“处理_”开头的仓库文件夹把每周要处理的报表丢进去在和 AI 对话时我会直接说“用每周门店周报合并流程处理这个文件夹”。这样做的好处是AI 不需要猜我到底想不想用这个 Skill我也不用担心它误触发。后来我还发现给 Skill 起名不要太文艺描述里也不要堆形容词。直接写清楚“合并”“门店周报”“周报汇总”这类关键词触发准确率会提高很多。如果你以后要做多组 Skill这套命名和触发习惯能帮你减少大量“牛头不对马嘴”的调用。5.2 每次跑完必须留一个“人工复核窗口”我见过有些朋友用完 AI 处理 Excel 就把结果直接发出去这是我最想提醒大家别犯的错。AI 处理数据的速度再快它也不是在“理解”你的业务而是根据你的书面规则在做模式匹配。哪怕是经过三轮迭代的 Skill也有可能遇到全新的列名变体或者全新的空值语义所以“输出检查”绝对不能省。我的办法是在 Skill 的最终步骤里固定生成一份“处理报告”里面包含输入了几份文件、输出总行数、删除了多少重复行、哪些列存在无法识别的表头、哪个门店的数据缺失全部列出来。我只需要花两三分钟扫一眼这份报告就能判断这次处理可不可信。这比在几万行数据里自己重新核对一遍高效太多了。我甚至会把“生成处理报告”设成 Skill 的硬性要求如果 AI 没有给出报告就算处理失败。5.3 多人协作和数据库入库学会保留操作边界我踩过的一个大坑是AI 直接去修改共享工作簿。当时我想着让 AI 把数据写好以后自动回填到在线协作表格里结果它一写整个表格的联动公式全部乱了还牵连了别的同事的数据。后来我在本地方案里反复测试发现“直接修改在线共享文档”这件事对 AI 来说风险太高它没法判断当前有哪些人在编辑、哪些单元格被保护、哪些 sheet 被锁定了。我的经验是所有 AI 处理都在本地副本上完成处理结束后把结果文件单独另存给同事绝不直接动在线表格的原始区域。至于“多人编辑怎么互不可见”这类协同问题我现在的答案非常朴素先把 AI 当成数据处理环节不把它当成协同编辑工具。数据清理、结构转换、批量合并这种活儿交给它真正需要人参与的内容再回到表格里填写。同样道理如果需要把表格导入数据库我会让 AI 生成规范化的 CSV 文件再由懂数据库的同事或专用工具去做导入不让 AI 跨过边界直接操作数据库。这不是不相信 AI而是把每一步的责任边界划清楚出了问题也好定位。5.4 和宏、加载项、脚本工具怎么相处做这套 Skill 的过程中我也查过“Excel VBA”“加载项”“批量处理”这些方案。老实说在 AI Skill 之外它们仍然是有效的工具但我的选择逻辑变了凡是“交互性强、需要我自己打开 Excel 看效果的操作”比如做一个日期控件、做一个二级联动下拉菜单用 VBA 或加载项反而更顺手凡是“数据量中等、规则重复、主要是清洗和合并”的工作我会毫不犹豫交给 AI Skill。原因很简单今天的 AI Agent 优势在于它能理解“有歧义的自然语言”比如“把销售额列里面那种带 约 字的数字处理一下”这种指令用 VBA 写判断条件会绕很多圈但对 AI 就是一句话的事。如果你目前也在用 VBA 或加载项我不建议立刻放弃它们。更好的思路是让两者互补Skill 负责“读表、清洗、合并、输出新文件”VBA 或加载项负责“在 Excel 界面里做交互和展示”。尤其在处理“Excel 双击出现加载项报错”这类环境问题时我更倾向于先把 Excel 环境修稳定再谈自动化不然 Skill 读到的数据本身可能就是错的。工具不是越高级越好是越合适越好。6. 做了一堆 Skill 之后我对“AI 替人干活”的重新理解如果你问我现在还有没有必要学 VBA、学 Python我的真实感受是如果你想用 AI 帮你干活第一优先级不是学编程而是学会“拆解自己的经验”并把它写清楚。这段时间做 Skill 最大的收获不是我会了什么新技术而是我突然发现自己原来对 Excel 的很多操作是“知其然不知其所以然”的。逼自己把流程写下来的过程其实是在逼自己补上“所以然”那一课。我先后给财务、人事、运营三个团队做了几个小 Skill有的用来做工资表字段核对有的用来整理培训报名信息有的用来合并项目周报。做多了以后我反而开始劝自己克制不是所有任务都值得做成 Skill。判断标准很简单如果这个任务一年只出现一次或者每次输入格式都完全不同更快的方案是临时让 AI 处理一次写成 Skill 反而会增加维护成本。真正值得做的是那些高频、规则相对稳定、错误成本可接受的任务。我大概算过一个每周节省两小时的 Skill花上四五个小时去制作和迭代是完全值得的投产比很高。在这个过程里我还意识到了“数据安全”和“验证意识”这两个非技术词汇的重要性。涉及客户隐私、员工薪酬、未公开财报的数据我坚决不传到外部平台即便用内部部署的方式跑我也会先在样例数据上验证好了再放真实数据进去。每次执行完我还会保留 AI 的处理报告和中间过程方便回溯。这些习惯听起来不酷但在真实工作里比任何炫技都管用——毕竟数据出了问题最后担责的还是你自己。整体做下来我的体会是AI 并没有把我变成程序员它只是让我这个普通业务工作者拥有了一种“把自己的经验复制很多份”的能力。以前我一个人会做某张表现在只要我把流程写清楚AI 就是一个随时能帮我干活的影子分身。写一份好的 Skill本质上不是技术工作而是管理思路的梳理你要能说清楚目标是什么、边界在哪里、异常怎么处理。这跟带一个新人几乎一模一样。最后再分享一个我自己觉得特别实用的小技巧做第一个 Skill 时不要从“我要做一个完美的技能”出发而要从“我上周哪项表格操作重复了两遍以上”出发。把那项操作完整复述出来写成一个只有五个步骤的小文档加一个十行以内的示例立刻去跑一次真实文件。你会发现让它跑通一次带来的正反馈比看十篇教程都有用。踩坑记录多了再慢慢增加异常处理规则这个 Skill 就会长成你离不开的助手。