企业官网建设流程全解析

先交代背景：我谈不上懂技术，代码水平停留在大学时代用过几天 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 里增加一个同义词映射表。把我在实际文件中见过的所有列名都列进去，并指定一个标准列名。比如：

这个表看起来不起眼，但它是整个 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 在输出前做一次“行数一致性校验”：原始文件总行数是否等于清洗后总行数加删除的重复行数，如果对不上，说明有数据被吞掉了。

除了这三次大的迭代，中间我还修了一堆小 bug：CSV 文件打开乱码需要在读取时指定编码格式；有些表格里带着公式结果缓存，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 就会长成你离不开的助手。