ModelMonkey Logo
数据分析

Sheet Monkey：2026年哪些工作该交给AI

Marc Sean2026年4月18日阅读约 2 分钟

如果你曾花三个小时把 ERP 导出数据整理成能对接利润表的格式，那就是典型的 sheet monkey 场景。值得追问的不是这件事发生过，而是在工具已经改变的今天，它还应该占用你多少时间。

标签页改名噩梦：改造前后对比

我们财务团队的 Remy 分享过这样一个场景：接手一个模型，前任同事把三个标签页全部重命名——P&L 改成了 Income Statement，Assumptions 改成了 Inputs，Returns 改成了 Returns Analysis——结果工作簿里约40个公式全部报错。所有使用旧标签名称的跨表引用，此刻都返回 #REF!。

Returns Analysis 标签页里的报错：

=('P&L'!C15-'P&L'!C8)/'Assumptions'!$B$3        → #REF!
=SUMIFS('P&L'!C:C,'P&L'!B:B,">="&'Assumptions'!$B$3)  → #REF!
='P&L'!C22*'Assumptions'!$D$14                   → #REF!

手动修复的思路是查找替换，但前提是改名本身没有拼写错误——如果新名称有笔误，或者插入行时区间发生了位移，你就只能逐个单元格地排查。

在 ModelMonkey 中修复这一问题的提示词：

"三个标签页已被重命名：'P&L' 现在叫 'Income Statement'，'Assumptions' 现在叫 'Inputs'，'Returns' 现在叫 'Returns Analysis'。请找出工作簿中所有断裂的跨表引用，并用正确的标签名称重写它们。"

返回的结果： 侧边栏识别出分布在 Returns Analysis、LBO Summary 和 Debt Schedule 三个标签页共43处断裂引用。在执行任何写入操作之前，先输出一份差异对比——原公式与新公式逐单元格展示：

Returns Analysis!B12
  修改前: =('P&L'!C15-'P&L'!C8)/'Assumptions'!$B$3
  修改后: =('Income Statement'!C15-'Income Statement'!C8)/'Inputs'!$B$3

Returns Analysis!B13
  修改前: =SUMIFS('P&L'!C:C,'P&L'!B:B,">="&'Assumptions'!$B$3)
  修改后: =SUMIFS('Income Statement'!C:C,'Income Statement'!B:B,">="&'Inputs'!$B$3)

43处修改全部提案、逐一审阅、确认执行。总耗时：含审阅过程约4分钟。手动查找替换的等效时间：25-35分钟，且事后仍需复核有无遗漏。

差异审阅中有一个关键细节：43处引用中有3处在 Q3 有人插入行时同时发生了行号位移。这3处被标记为"可能需要人工复核"，而不是直接套用名称替换的逻辑——这个边界的含义，下文详细展开。

sheet monkey 哪些工作可以交给 AI

标签页改名只是这类问题的典型代表：逻辑清晰、模式重复，一旦出错代价不只是损失几分钟，而是触发一轮对账审计。以下是 AI 在财务模型中真正能兑现价值的场景：

任务节省时间需警惕的失效模式
标签页改名后跨表引用修复25-35分钟 → 4分钟仅扫描名称无法捕获行/列位移
日期格式标准化（Salesforce 导出）45分钟 → 8分钟源数据无前导零时单位数月份解析错误
将 ERP 导出数据写入利润表时间减少约60-80%科目代码年中变更时的映射错误
跨5000行写入 ARRAYFORMULA近乎即时公式本身无误，假设有问题
跨8个标签页构建 SUMIFS5分钟 → 30秒标题行识别错误

表格中没有列出的内容：对标同类公司验证 WACC 假设、对终值增长率做压力测试、判断退出倍数是否符合行业水位。这些工作仍然需要一个真正理解数字含义的人来完成。

最危险的失效模式：公式跑通了但数字错了

#REF! 报错是可见的——打开文件就能发现。真正危险的是另一类错误：公式在技术上完全正确，甚至能通过所有常规的合理性检验，但汇总方向有误。

一个典型场景：提示词里写的是"汇总本季度收入"，但没有明确起止日期的包含逻辑。AI 有时会在 >= 与 > 之间做出与你预期相反的边界选择。公式本身没有报错，这个偏差会一直潜伏，直到 CFO 问你为什么收入比管理账高出近300万元——这时你才开始倒查，才发现是季度边界的包含/排除逻辑写反了。

以下是触发这类静默错误的三种常见情形：

  1. 区间边界选择错误的 SUMIFS： 提示词描述不清时，AI 对"包含期末日"还是"不含期末日"的判断可能与业务逻辑相反。
  2. 插入行引发的区间静默截断： 原公式引用 C2:C100，插入行发生在第101行之后。Google Sheets 不会自动扩展区间，末尾数据被静默截断，公式正常执行，数字悄悄偏小。
  3. 科目代码年中变更的映射错误： ERP 变更科目代码后，AI 按旧代码写的 VLOOKUP 或 SUMIFS 会正常执行但返回零或错误金额，而不是报错。

这类错误的共同特征是：公式结构完全正确，错的是业务逻辑的表达。这也是为什么差异审阅是必要但不充分的——它需要配合你对模型逻辑的理解才能真正发挥作用。

"先审阅再写入"能发现什么，发现不了什么

这是一个值得直接回答的问题：差异对比流程对名称替换类错误的检测是确定性的。旧标签名 → 新标签名，逐单元格列出，你可以在写入前逐一确认。标签页改名案例中的43处修复，这类错误一个不漏。

对行号位移类错误，情况不同。当有人在 Q3 插入行时，位移可能导致原本正确的区间引用偏移。差异对比能展示公式修改前后的样子，但它无法独立判断"C15应该引用毛利润还是收入"——这个判断依赖于你理解模型的逻辑结构。这也是为什么案例中那3处被标记为"需要人工复核"：工具识别到了位移的存在，但没有自动修正，因为自动修正在这里等于猜测。

对逻辑正确但假设有误的公式，差异对比无能为力。如果提示词本身描述了一个错误的业务逻辑，AI 会精确地执行那个错误的逻辑。这不是工具的失效，而是提示词的失效。

实操结论： 差异审阅把"逐格手动操作"变成"批量提案 + 人工确认"，把遗漏风险从"没注意到"变成"看到了但没标出来"。这是有意义的改进，但不是铁板。它不能替代你对模型逻辑的理解，只能让那个理解在更小的操作量下得到应用。

WACC 计算的正确做法

以2026年一家 B 轮 SaaS 公司为例，完整的 WACC 计算参考输入参数如下：

  • 无风险利率： 4.35%（10年期美国国债，来源：美联储2026年4月数据；适用于美元计价融资分析）
  • 权益风险溢价： 4.7%（Damodaran 2026年1月对美国市场的估计）
  • Beta： 1.35（中型 SaaS 可比公司原始 Beta，去杠杆后按20%债务/权益比重新加杠杆）
  • 规模溢价： 1.8%（市值2亿-5亿美元区间适用，来源：Duff & Phelps 规模溢价研究）
  • 债务成本： 7.2%（当前环境下 B/B+ 评级信用的优先有担保利率）
  • 税率： 21%

由此得出的 WACC 约为12.5%-13.0%，而非经常被引用的9%。仅用 Damodaran 的权益风险溢价是不够的——规模溢价不可或缺，而对于尚未盈利的 SaaS 公司，Beta 假设的影响举足轻重。选取8-12家 EBITDA 为负的上市 SaaS 可比公司，根据增长曲线的不同，有杠杆 Beta 通常落在1.2-1.6之间。

AI 在这一计算中的作用： 构建可比公司 Beta 查找公式。如果你的 Comps 标签页有12行 ticker 数据，需要提取去杠杆 Beta、按目标资本结构重新加杠杆并取均值，这套公式逻辑不复杂，但写起来极为繁琐。AI 工具可以在你打完字之前就把完整的 AVERAGE(ARRAYFORMULA(...)) 结构写好。但它无法告诉你这12家可比公司选得对不对。

ARRAYFORMULA 日期解析的坑

Salesforce 导出的日期格式是 M/D/YYYY——没有前导零。2026年1月5日导出的是 1/5/2026，而不是 01/05/2026。用 MID(A2,4,2) 提取月份的做法，在单位数月份时会因字符位置偏移而直接出错。

将3000行导出数据统一规范为 YYYY-MM-DD 格式的健壮写法：

=ARRAYFORMULA(
  IF(A2:A="","",
    TEXT(DATEVALUE(A2:A),"YYYY-MM-DD")
  )
)

DATEVALUE 原生支持 M/D/YYYY 格式，不在乎有没有前导零。外层 TEXT 转换为 ISO 格式，方便在利润表中进行日期区间的 SUMIFS 比较：

=SUMIFS('Income Statement'!C:C,
        'Income Statement'!B:B,">="&TEXT(Inputs!$B$3,"YYYY-MM-DD"),
        'Income Statement'!B:B,"<="&TEXT(Inputs!$B$4,"YYYY-MM-DD"))

这里真正值得留意的风险不是 DATEVALUE 的语法，而是 >= 和 <= 的边界选择——季度起止日期是包含还是排除，直接决定汇总数字是否准确。这是公式之外的业务逻辑，AI 照着提示词写，你来确认逻辑是否符合你的意图。

2026年的 sheet monkey：该做与不该做

机械性工作——跨表引用修复、日期格式标准化、多标签页模型的公式批量生成——现在交给 AI 的成本已低于亲手去做。判断性工作——假设验证、可比公司筛选、敏感性分析结构设计——仍然是你的领地。一个6小时的建模任务和一个2小时的建模任务之间的差距，主要就在于前一类工作节省下来的时间。

该做的是： 把具体、可验证的机械性任务交出去，保留差异审阅的控制权，对 AI 生成的每一个公式的业务逻辑负责。

不该做的是： 因为公式在技术上跑通了就跳过逻辑验证，或者用一个模糊的提示词期待 AI 猜出你的业务意图。

常见问题

AI 修复跨表引用能捕获行号位移引起的逻辑错误吗？

名称替换类错误（标签页改名、列标题变更）可以被可靠捕获。行号位移引发的逻辑错误——例如插入行导致区间边界偏移——通常会被标记为"需要人工复核"，而不是自动修正，因为正确的修复方式依赖于对模型逻辑结构的理解，不是纯粹的字符串替换。如果位移发生在区间边界之外（例如在 C2:C100 的第101行之后插入），Google Sheets 本身不会更新引用，末尾数据被静默截断。这类错误是公式审阅中最需要人工介入的场景。

哪些 sheet monkey 工作 AI 真的做不了？

可比公司筛选是否合理、WACC 的 Beta 假设是否适用于目标公司的资本结构、终值增长率的压力区间是否符合行业现实——这些判断依赖于对行业和公司基本面的理解，不是计算问题。AI 能写出正确的 Beta 查找公式，但无法告诉你这12家可比公司选得对不对。假设验证这件事，在2026年仍然是你的工作。

如何避免 AI 生成"技术正确但逻辑错误"的公式？

两个实操习惯：第一，提示词里明确业务逻辑而非只描述操作——"汇总本季度（含首末日）已确认收入，季度起止日期分别在 Inputs!B3 和 B4"比"汇总C列"要精确得多；第二，对每一个 AI 生成的公式，手动验证一个已知结果的单元格，确认数字符合预期再批量写入。差异审阅是第一道防线，但不是最后一道。

查看 ModelMonkey 方案——同时支持 Google Sheets 和 Excel。