WorkBuddy 实战：我把年报审计最耗时的"填表"做成了一条流水线

一、痛点：审计的难点不在判断，在"搬运"

做年报审计的人大概都有同感：真正需要职业判断的部分，可能只占两成时间；剩下八成，花在把数字从一张表搬到另一张表上。

把财务报表的期末数搬进审计 TB 表；把科目余额表的数搬进几十上百张实质性底稿；往来科目还要一家一家拆账龄；调整做完后，再把审定数搬回审计报告的附注表格。

一家中小企业的底稿动辄上百个 sheet，往来明细动辄几百家单位。换一家客户，同样的动作原样再来一遍。每次开新底稿，那种"又来了"的疲惫感，做过的都懂。

我用 WorkBuddy 把这件事改造了一遍。关键不在于"让 AI 帮我填一次表"——那个用任何大模型对话都能凑合完成；真正的差别在于把这套流程固化成一个技能（Skill）：表式结构、字段位置、判定口径、易错点全部写进去，实现"下一年不用重新教它一遍"。

二、整体思路：先教会它，再让它自动跑

WorkBuddy 的技能机制本质就是一个可复用的文件夹，结构上分三块：

• SKILL.md——写清工作流程和"铁律"（哪些绝不能动）；
• references/——写清表式结构、单元格坐标、公式逻辑、判定特例；
• assets/——放空模板。

我的做法是先拿一套完整资料"学"一遍——以 A 公司（一家制造企业）某年度的年报审计为例：财务报表、审计 TB、各科目底稿、科目余额表、序时账、往来辅助核算明细，以及上一年的审计报告。学的过程就是逐张 sheet 记录表头位置、公式逻辑、索引号归属，写成参考文档。

之后每接一家新客户，我只提供资料，它按同一套规则执行。

这里有条经验：技能里最值钱的不是"怎么做"，而是"不许做什么"。比如"绝不修改任何已有公式""绝不调整字体和行列结构""审计报告里的会计政策原文一字不动"。AI 很乐于"顺手帮你优化格式"，而审计底稿一旦公式被覆盖，整套勾稽就废了。把禁令写在技能最前面，比事后检查有效得多。

三、四个环节的具体做法

环节 1：填 TB 表

TB 表是整套工作的枢纽，规则要点：

1. 财务报表的期末数，填到审计 TB 工作表的「期末未审数」列。这是整张表里唯一需要填值的列。
2. 审计调整不要写进 TB，而是逐笔录入「审计调整」工作表（序号、索引号、摘要、科目索引、一级科目、明细科目、借方、贷方），由 TB 用 SUMIF 按科目索引自动汇总生成审定数。千万不要手填审定数。
3. 审定数公式：资产类 F=C+D-E；负债、权益、损益类 F=C-D+E（D 为借方调整、E 为贷方调整）。
4. 上年审定数从上一年的 TB 取，不要用今年报表的"年初数"（原因见第四节）。
5. 填完必须看平衡行：F107 = ROUND(F106-F69, 2)，结果等于 0 才算平。

对应的提示词可以这么写：

读取《202512财务报表.xls》中的资产负债表和利润表，把期末数填入《审计TB》的「审计TB-2025」工作表 C 列对应科目行。不要修改任何公式，不要调整任何格式和字体。填完后汇报平衡行 F107 的值。

环节 2：填各科目实质性工作底稿

数据源是科目余额表加往来辅助核算明细。科目的余额表列语义是固定的，先建立映射再填：

A 科目编号 | B 科目名称 | C/D 期初余额（借/贷）| E/F 本期发生额（借/贷）| G/H 期末余额（借/贷）

几个特别容易错的科目：

• 往来科目（应收、应付、其他应收、其他应付）：期末未审数必须拆成「1 年以内 / 1 年以上」两栏。基础判定口径是：某往来单位期初余额 = 期末余额，说明当年无发生额，全额归入 1 年以上。
• 固定资产：余额表的借方发生额对应底稿的"本期增加"，贷方发生额对应"本期减少"。
• 应交税费：底稿列结构是「期初数 / 本期已交数 / 本期计提数 / 期末数」，逻辑关系为 期末 = 期初 − 已交 + 计提，其中已交对应借方发生、计提对应贷方发生。
• 期间费用：默认取本期发生额，但损益类科目按月结转本年利润，导致借方发生额与贷方发生额相等，不能直接取单边。利息收入、汇兑损益这类冲减项按负数填列；管理费用还需按报表口径单独拆出研发费用。

环节 3：审计调整

先做最低限度的重分类，不越界做职业判断：

• 应收账款出现贷方余额 → 重分类至预收账款；
• 应付账款出现借方余额 → 重分类至预付账款；
• 其他应收款与其他应付款中同一单位方向相反的 → 互抵重分类。

另外注意：同一往来单位如果同时挂在应收与应付（或应收与其他应收），要合并后再调整，否则账龄会被拆散，审定数虽然在总额上没错，明细却不可用。

应交税费的调整涉及口径判断，不要让 AI 自动做，先自己定方案再让它执行。

环节 4：审计报告

报告正文的文字性内容原则上一律不动——会计政策、审计准则表述、责任段原文保留，只做字段级替换：公司名称、审计年度、报告文号、批准报出日期、注册资本、注册地址、统一社会信用代码、法定代表人、经营范围、股东构成。附注中的数字表格，按审定后的底稿数更新。

格式和字体不要动。给 AI 的指令里把这一条写死：只替换文本内容，不改变样式。

四、三个真正值钱的坑

这三条是我在实际操作中撞出来的，也是我认为最能体现"技能固化"价值的地方。

坑一：报表的"年初数"不等于上年审定数。

上一年的审计调整通常没有回写到被审计单位的账里，所以今年报表的年初数是"未审的年初数"。往来科目尤其明显——差额往往就是上一年重分类调整的金额，量级可能很大。

因此，底稿里的"上期末审定数"必须取自上年 TB 的上年审定数列（或上年 TB 的审定数列），绝对不能直接引用余额表的年初数。这一条如果搞错，账龄表整张都会错，且不容易自查出来。

坑二：账龄判定不能机械套用"期初 = 期末"。

"期初余额 = 期末余额 → 归入 1 年以上"这个口径在多数情况下成立，但有例外：如果某单位期初等于期末，同时本期借贷双方都有发生额（本期先收款后付款，或相反），那它并不属于"无发生额"，只是余额碰巧回到原点。这种情况必须按实际发生额的时间逻辑单独处理，不能一刀切。

我是在核对某家往来单位时发现的：期初与期末余额分毫不差，但本期借贷双方各有几十万的发生额。如果按"无发生额"处理，账龄就会算错整整一年。

教训是：任何"简单规则"都要在技能里标注它的例外，并且明确要求遇到边界情况时停下来问人。

坑三：管理费用要拆研发费用，期间费用别取错方向。

本机实务中常见的情况是：科目余额表里的管理费用是合并口径，而报表已经把研发费用单独列示。填底稿时要按报表口径拆分，否则两份资料的数字对不上。

同理，损益类科目因为按月结转，借贷双方发生额相等，看单边会得到一个漂亮的错误答案。

五、效果，说实话版

第一次配置大概花了几小时：把资料读一遍、把表式结构和规则写成参考文档、把禁令写进技能。这部分是一次性投入。

之后的收益在于——每接一家新客户，填表环节从"以天计"压缩到"以小时计"，我能把省下来的时间放回复核和职业判断上，而不是消耗在搬运数字上。

但要泼一盆冷水：AI 会犯错，而且错在口径和方向上的概率，远高于错在算术上。 数字搬错一个能一眼看出来，口径错了整张表看起来却是自洽的。所以勾稽校验必须做，人工复核这一步一步都不能省。我的做法是让它填完必须汇报三个校验结果：报表与余额表是否一致、余额表与 TB 未审数是否一致、TB 平衡行是否为 0。对不上就回头查，而不是硬填。

六、给同类场景的三条通用经验

1. 把流程写成技能，而不是每次重新对话。 一次性说清规则，比每次重复解释省太多，而且规则是累积的。
2. 先写"不许做什么"。 在强约束场景（财务、审计、法律）里，边界比能力更重要。
3. 要求它汇报校验结果，而不是汇报"已完成"。 前者你能验证，后者你只能相信。

如果你的工作里也有大量"把数从 A 表搬到 B 表"的重复劳动，值得花几个小时把它固化下来。一次投入，年年受益。