一、背景引入（Context）

AI工作流搭完了，Prompt库超过10条了，月度汇报提速了。

下一个战场，是Excel自动化。

财务工作里有大量的Excel任务：多个工作表合并汇总、格式化银行流水、批量生成凭证记录表、费用分类统计……这些任务有一个共同特征：每月都要做，规则固定，手工操作枯燥，但你就是离不开它。

DAY 43的任务，是找出一个每月手工操作超过1小时的Excel任务，用三句话把需求说清楚：

① 原始数据是什么样的？ ② 你现在怎么手工处理？ ③ 你希望最终输出什么？

写清楚需求，是写出好脚本的前提。

不是今天就要写脚本，而是今天把需求搞清楚——这一步做对了，后面的自动化才有成功的可能。

二、直面问题（Problem）

为什么Excel自动化失败率这么高？很多人的第一反应是"AI写的脚本跑不起来"——但根本原因往往在更前面：

问题1：把"模糊的痛苦"当成了需求

"每个月合并Excel很麻烦"——这不是需求，这是感受。真正的需求是：我有12个月份的工作表，每个表有相同的列结构，我需要把它们合并成一张表，同时在第一列加上"月份"标识。感受和需求之间，差着三倍的精确度。 用感受去驱动脚本开发，AI只能猜，猜出来的脚本80%跑不起来。

问题2：跳过了"现在怎么做"这个关键步骤

很多人描述需求时，直接从"原始数据"跳到"期望输出"，略过了"现在手工怎么处理"——但手工处理过程里，往往藏着最关键的业务规则：为什么某些行要过滤、为什么某个字段要重新命名、为什么合并时某列需要求和而不是简单拼接……手工操作步骤是业务规则的显性化，跳过它，脚本就会遗漏关键逻辑。

问题3：对"输出"的描述停留在"一张新表"的层面

"输出一张汇总表"——这不够。字段顺序是什么？日期格式是什么？需要排序吗？按什么列排？有没有需要特别处理的异常值？输出到新工作表还是新文件？每一个未被描述的输出细节，都是脚本出错后你发现"怎么和我想要的不一样"的根源。

三、拆解步骤（Solution）

Step 1：选出你的第一个Excel自动化目标

从日常Excel工作里，用"三高标准"筛选目标任务：

目标筛选标准：高频率：每月至少执行1次高耗时：单次手工操作≥1小时高重复：每次执行的步骤基本相同，        规则没有本质变化典型候选任务：□ 多个工作表/文件合并汇总  （月度：12个分公司→1张汇总表）□ 格式化银行流水  （银行导出→标准格式→   科目分类→记账用表）□ 批量生成凭证记录表  （报销单据→会计凭证格式）□ 费用分类统计  （明细流水→按部门/科目/月份   的分类汇总）□ 应收账款账龄分析  （应收明细→账龄分组→   逾期预警标注）□ 其他：___

选择原则：选你最熟悉、最确定规则的任务，不要选边界模糊的复杂任务作为第一个。

Step 2：用"三句话框架"精准描述需求

这是DAY 43最核心的动作。不要写段落，强制用三句话——句数的限制会逼你提炼出最关键的信息。

三句话框架模板：

句子①：原始数据描述"我有[数量/来源描述]的Excel文件/ 工作表，数据格式为[描述格式]， 包含[关键字段列举]， [有/没有]表头， [有/没有]特殊的格式或合并单元格。"句子②：当前手工处理步骤"现在我的处理方式是： 第一步[动作]， 第二步[动作]， 第三步[动作]…… 整个过程大约需要[时长]， 最容易出错/最耗时的环节是[具体环节]。"句子③：期望输出描述"我希望最终得到一个[文件/工作表]， 包含字段[字段列表]， 按[字段]排序， 格式要求[具体格式]， 输出位置为[新文件/原文件新工作表/ 指定位置]。"

Step 3：三句话写完后做"精确度自检"

写完三句话，用以下问题逐一检验精确度：

对句子①（原始数据）的追问：

□ 说清楚了有多少个文件/工作表吗？□ 字段名称用的是实际名称，  还是模糊描述？□ 数据类型说清楚了吗？  （日期格式是YYYY-MM-DD还是其他？   金额有没有货币符号？）□ 有没有"脏数据"需要说明？  （空行、合并单元格、隐藏行等）

对句子②（手工步骤）的追问：

□ 步骤是否按执行顺序列出？□ 有没有条件判断步骤？  （"如果A条件，则执行X；    否则执行Y"）□ 有没有需要人工判断的环节？  （这类环节自动化难度高，    需要单独标注）□ 手工过程中有没有"顺手做的"但  未意识到的步骤？  （如：删除某列、统一日期格式）

对句子③（期望输出）的追问：

□ 字段顺序有没有要求？□ 日期、金额的格式是否明确？□ 是否需要排序？按什么排？□ 需要汇总/合计行吗？□ 输出文件名有没有命名规则？□ 是否需要同时输出多个格式？  （如：Excel + CSV）

Step 4：把三句话扩展为"需求说明书"

三句话通过自检后，把它扩展为一份结构完整的需求说明书——这是给AI写脚本时的输入文档：

════════════════════════════════════Excel自动化需求说明书任务名称：[3-5字的任务名称]编写日期：[YYYY-MM-DD]════════════════════════════════════【原始数据描述】文件数量/来源：数据格式（工作表结构）：关键字段清单：  - [字段名]：[数据类型/格式/示例值]  - [字段名]：[数据类型/格式/示例值]已知的数据质量问题：  - [问题1]  - [问题2]【当前手工处理流程】步骤1：[具体动作]（约___分钟）步骤2：[具体动作]（约___分钟）步骤3：[具体动作]（约___分钟）...最耗时步骤：步骤___，原因：___最容易出错步骤：步骤___，原因：___包含人工判断的步骤：步骤___  判断规则：___【期望输出规格】输出格式：□ .xlsx  □ .csv  □ 两者都要输出位置：□ 新文件  □ 原文件新工作表字段清单（按顺序）：  [列1：字段名 - 数据类型 - 格式要求]排序规则：___汇总行：□ 需要  □ 不需要命名规则：___【成功验收标准】脚本运行完成后，满足以下条件即视为成功：□ [可量化的验收条件1]□ [可量化的验收条件2]□ [可量化的验收条件3]════════════════════════════════════

Step 5：用AI验证需求的完整性（反向测试）

需求说明书写完后，做一次反向验证：

把需求说明书发给Claude，使用以下Prompt："以下是我的一个Excel自动化需求， 请你不要写脚本， 而是帮我检查这份需求说明书 是否足够清晰：① 有没有你无法理解的表述？② 有没有让你需要猜测的信息？③ 有没有明显遗漏的重要细节？④ 如果你现在就写脚本，   最可能在哪里卡住？[粘贴需求说明书]"

这个反向测试的价值： AI指出的"无法理解"和"需要猜测"，精确地告诉你需求说明书的哪些地方还不够精确。在还没有写脚本之前修复这些模糊点，比在脚本写完后发现错误要高效得多。

四、底层逻辑（Underlying Logic）

逻辑1：自动化的质量上限，由需求的精确度决定

写脚本是执行层的工作，定义需求是战略层的工作。一份模糊的需求说明书，即使交给最好的程序员，也只能产出"大概正确"的脚本——因为开发者会在你没有说清楚的地方做假设，而他的假设大概率和你的期望不同。需求的精确度，是整个自动化项目的天花板。

逻辑2："手工步骤"是业务规则的最可靠载体

你手工操作的每一个动作，背后都有一个原因——这个原因，就是业务规则。手工步骤是业务规则被执行的物理轨迹，是目前最可靠的业务规则文档来源。把手工步骤写清楚，本质上是把隐性的业务规则显性化——这不只对AI有价值，对你自己理解这件工作、对新人培训、对将来的流程审计，都有价值。

逻辑3：成功验收标准是防止"自以为完成"的关键机制

没有验收标准的任务，只有两种状态：做完了和没做完。有了验收标准，才有第三种状态：做完了，且达标。Excel脚本在验收时最容易出现的问题，是"跑完了但数字不对"——因为脚本处理了所有行，没有报错，看起来成功了，但某列的汇总逻辑错了，或者日期格式不对……可量化的验收标准，是区分"脚本运行成功"和"任务真正完成"的唯一工具。

逻辑4：第一个自动化目标的选择，决定了你对自动化的信心

如果第一个选的任务太复杂（含大量条件判断、多来源数据、异常处理逻辑），脚本开发会非常曲折，失败概率高，你可能因此对Excel自动化产生"太难了、不值得"的错误认知。第一个目标，应该选规则最清晰、逻辑最简单、但耗时最大的任务——让成功发生，让你看到投资回报，建立信心和动力，才是开始自动化之路的正确姿势。

【思考视窗】

🔍 知识块拆解：哪些内容可以独立沉淀？

① "Excel自动化需求说明书"通用模板把Step 4的模板存为固定文档格式，每次有新的自动化想法时，先填这张表再去找AI写脚本。这张表同时也是一份"Excel手工流程文档"——即使不做自动化，光是把手工步骤写清楚，对工作交接和新人培训也有很高的价值。

② "三句话需求框架"作为快速评估工具在日常工作中，每当你感觉某个Excel任务"太费时了、应该能自动化"，先用三句话框架快速描述一遍。能用三句话说清楚的，是可以自动化的候选；说不清楚的，说明还需要先把业务规则梳理清楚。 这个测试可以防止你把精力投入到规则不清晰的任务上。

③ "反向测试"作为需求验证的标准步骤把Step 5的反向测试（让AI检查需求完整性）做成每次开始写脚本前的必做步骤——不是"如果有空就做"，而是"没做就不开始写脚本"。这个步骤的时间成本很低（5分钟），但它能把脚本返工率从50%以上降低到10%以下。

🕳️ 漏洞与深化：我想向你追问几个问题

Q1： 你选定的第一个Excel自动化目标是什么？能不能用一句话说清楚这个任务的核心操作（比如"把12个月份的费用表按相同格式合并成一张汇总表"）？如果一句话说不清楚，可能说明这个任务还需要进一步拆分，或者还没想清楚边界。

Q2： 在你描述"当前手工处理步骤"时，有没有出现"根据情况判断……""有时候需要……""如果数据异常……"这类表述？这类条件判断是自动化的难点所在——它们不是不能自动化，但需要把判断条件精确到"当A字段为空时执行X，否则执行Y"的程度，而不是留给AI去猜。

Q3： 你设定的"成功验收标准"是否有可量化的条件？比如"合并后的行数应等于所有源表行数之和减去表头行数"，或者"金额列的合计值应等于原始各表金额列合计之和"。如果验收标准是"看起来对了"，那这个自动化任务的可靠性就无法被真正验证。

💡 更优解推荐

"最小可行脚本"策略——先跑通核心路径，再处理边缘情况

很多人期望第一版脚本就处理所有情况——包括空值、格式异常、文件不存在……这样的脚本需求最复杂、开发时间最长、出错概率最高。

更有效的策略是分两阶段开发：

第一阶段：最小可行脚本（MVP）→ 只处理"标准情况"→ 假设数据是干净的、格式是规范的→ 目标：核心路径跑通，输出正确→ 验收：用一份标准格式的数据测试第二阶段：健壮性增强→ 加入异常处理→ 处理空值、格式不统一、  文件缺失等边缘情况→ 目标：在任意真实数据下稳定运行→ 验收：用真实生产数据测试

MVP策略的价值： 你更快地看到一个能运行的脚本，建立信心；同时，真实的MVP运行结果会暴露你在需求说明书里没有想到的细节问题，让第二阶段的开发更有针对性，而不是基于想象的边缘情况做过度设计。

终极准备：在写需求说明书的同时，准备一份"测试数据集"

最好的脚本测试数据，是一份你精心构造的小型数据集，同时包含：

① 标准情况（最常见的数据格式）② 边缘情况A（某字段为空时）③ 边缘情况B（日期格式不统一时）④ 异常情况（金额为负数时）⑤ 期望输出的"标准答案"   （你手工处理后的正确结果）

有了这份测试数据集，你不需要每次都用真实数据测试——避免了测试脚本时意外修改生产数据的风险，同时也让脚本验收变得精确：用测试数据集跑出的结果，和你手工得到的"标准答案"逐字段对比，差异为零才算通过。