2-6 · Excel 与表格处理提效
在掌握手工处理逻辑后，再进入简单自动化。理解 AI 可以帮忙写“小自动化”。
先把《Excel 自动化需求描述模板》搭出第一版，不要只停留在看懂。
建议按“自动化最该解决的是重复动作 不是炫技 -> Power Query 和 VBA 的边界 先分清再选工具 -> 自动化需求要写成动作清单 不是写成一句愿望”的顺序往下看，先抓方法，再做练习和模板。
在掌握手工处理逻辑后，再进入简单自动化。理解 AI 可以帮忙写“小自动化”。
第 1 节 · 导入
先知道什么任务值得自动化 什么任务不值得。
很多人第一次接触 Power Query 或 VBA 容易陷入一个误区 觉得只要能自动化就应该自动化。
其实财务里真正值得自动化的 往往是 三个特征同时满足 的任务 重复频率高 步骤稳定 手工出错率高。
比如 每月合并 15 家门店销售表 每周整理银行流水格式 每天把报销明细按规则拆列。
这些动作重复又机械 最适合交给脚本。
反过来 如果任务规则经常变 需要大量主观判断 或每次量都不大 自动化反而可能不划算。
自动化不是为了看起来高级 而是为了把人从重复劳动里释放出来。
案例一：每月固定合并门店销售表 非常适合 Power Query。
容易出错的地方通常出在先知道什么任务值得自动化 什么任务不值得。
先把你每月重复做 3 次以上 且步骤几乎一样 的动作列出来 这些才是自动化候选项。
案例二：老板临时问一份一次性的专项分析 规则还没定 清楚前就不适合急着写 VBA。
第 2 节 · 概念
别再用错工具 导致脚本越做越重。
Power Query 更适合做 数据读取 清洗 合并 转换 这类表格流程。
它的优势是可视化 可追踪 对批量文件和结构化清洗很友好。
VBA 更适合做 界面交互 批量操作 工作簿控制和一些复杂自动动作。
它更灵活 但维护成本更高。
财务里很多任务其实 Power Query 就够了 比如 合并多个工作表 保留来源字段 统一列名 过滤空行。
只有当你需要按钮触发 自动生成多份文件 批量发邮件 或复杂格式操作时 才更可能考虑 VBA。
先选对工具 后面描述需求才不会跑偏。
案例一：每月合并门店明细并保留门店名 直接用 Power Query 很合适。
容易出错的地方通常出在别再用错工具 导致脚本越做越重。
描述需求前先写一句 这是数据转换任务 还是操作控制任务。
案例二：点击按钮后自动按部门拆分报表并另存 这种更接近 VBA 场景。
第 3 节 · 概念
学会把业务需求翻译成脚本能执行的步骤。
很多自动化需求失败 就败在描述方式太像许愿。
比如 帮我自动整理这些表 这句话对脚本没有意义。
更有效的写法是 读取某个文件夹下所有 Excel 文件 取每个文件第一个工作表 保留来源文件名 统一列名为 日期 门店 销售额 成本 过滤空行 合并后新增 毛利列 最终输出到汇总表。
脚本只认动作和条件 不认你心里的默认想法。
你把动作写得越具体 AI 越有机会给出可执行的 Power Query 步骤或 VBA 框架。
案例一：只说 自动合并门店表 AI 只能给泛泛建议。
容易出错的地方通常出在学会把业务需求翻译成脚本能执行的步骤。
以后写自动化需求 至少写出 输入源 处理动作 输出结果 三部分。
案例二：把 文件来源 工作表位置 列名 过滤条件 输出位置 写清后 它就能生成接近可用的步骤。
第 4 节 · 操作
用一个完整场景看懂需求拆解方式。
假设你每月要合并 15 家门店的销售表。
先把需求拆成七个动作。
第一 读取指定文件夹。
第二 只抓取扩展名为 xlsx 的文件。
第三 进入每个文件的 销售明细 工作表。
第四 统一列名和数据类型。
第五 增加 来源门店 字段 可从文件名提取。
第六 过滤空行和合计行。
第七 输出到汇总表 并保留刷新能力。
你把这七步写给 AI 它才能判断更适合给你 Power Query 步骤 还是 VBA 脚本框架。
这里最关键的不是代码 而是你先把动作拆清。
案例一：如果不说明要保留来源门店字段 合并后就失去门店维度。
容易出错的地方通常出在用一个完整场景看懂需求拆解方式。
拿你自己一个重复性任务 按 读取 过滤 转换 新增 输出 这类动词先拆成步骤。
案例二：如果不提前说明要过滤合计行 后面汇总金额会重复累计。
第 5 节 · 操作
知道为什么自动化越能跑 越要先守住安全边界。
第一类风险是 覆盖原文件。
任何会回写原始数据的脚本 都必须先备份 或改成输出到新文件。
第二类风险是 结构变化。
比如门店突然多出一列 或工作表名称改了 如果脚本没考虑 它可能直接报错 或更危险地静默遗漏。
第三类风险是 口径变化。
流程没变 但业务规则变了 比如新增退货处理逻辑 旧脚本继续跑就会出错。
自动化不是写完就永远可用 它需要在上线前留出测试样本 也需要后续版本管理。
案例一：脚本直接覆盖了原始汇总表 后面发现逻辑错了 连回滚都做不到。
容易出错的地方通常出在知道为什么自动化越能跑 越要先守住安全边界。
任何自动化脚本上线前 都先做 备份 样本测试 结构变化检查 三件事。
案例二：门店模板新增 促销折扣 列 Power Query 没更新 毛利计算立刻失真。
第 6 节 · 操作
避免脚本能跑 但一出错就没人敢用。
成熟的自动化需求 不只写 正常流程 还要写 测试方式 和 失败怎么办。
比如 先用 2 个门店文件测试 合并结果要与手工汇总一致。
若字段缺失 则在结果页提示 缺列名单 并停止输出。
若刷新失败 保留上次成功版本 不覆盖旧结果。
你把这些边界条件也一起告诉 AI 它给出的方案才更接近实际可用。
财务自动化最怕的不是报错 而是默默错了很久没人发现。
所以测试和回滚 不是附属项 而是需求本身。
案例一：没有回滚方案 一次错误刷新把整月汇总覆盖 后面只能重新从原始文件做。
容易出错的地方通常出在避免脚本能跑 但一出错就没人敢用。
以后每份自动化需求 都加两段 如何测试 失败后如何回退。
案例二：提前定义 缺列就停止执行 即使脚本没跑完 也比出错数据流进报表安全。
第 7 节 · 小结
把自动化学习落成一个以后持续可用的模板。
这节课最重要的成果 不是立刻写出多复杂的脚本 而是你开始会写一份清楚的自动化需求模板。
建议模板至少包含 业务场景 当前手工步骤 输入源 处理动作 输出结果 工具选择 测试方案 回滚方案 八块。
以后你不管是找 AI 帮你生成 Power Query 步骤 还是让同事支持 VBA 都可以直接把这份模板拿出来填。
能把需求说清楚的人 才真正配得上自动化带来的效率。
案例：本次模板先用来合并门店销售表 下次换成 月度报销台账整理 你也能快速沿用同一骨架重新描述。
容易出错的地方通常出在把自动化学习落成一个以后持续可用的模板。
今天就把你最想自动化的一个任务 填进模板里 至少写到能让别人看懂并开始动手。
课内练习