【Skill 创作】收入细节测试审计自动化工作台 — 把审计师最头疼的底稿核查交给 AI

1、Skill 简介

名称 ：收入细节测试审计自动化与智能化工作台（Audit Income Detail Test）

这是一个面向审计从业者的 AI-Ready 自动化工作台，专门解决审计"收入细节测试"中出库单 OCR 匹配、报关单 6 维信息提取、发票验证、底稿索引编制、批量打印与格式设置等全流程自动化。

一句话概括 ：把原来需要审计师手动翻 PDF、肉眼对单号、逐行填 Excel 的重复劳动，变成 AI 一键执行的标准化工序。

适合谁用 ：会计师事务所审计师、财务尽调人员、内审部门，尤其是每年年审季被大量底稿核查压得喘不过气的从业者。

2、使用场景

我为什么想做它？

我在研究生阶段参与审计实务时发现，"收入细节测试"是实质性程序中工作量最大的一环。一个项目动辄涉及：

几百张出库单图片需要肉眼识别出货单号 → 与 ERP 销售订单逐一匹配

几百份报关单 PDF 需要逐份打开、人工摘录 6 项信息（出口日期、贸易方式、目的地、提单号……）→ 填入 Excel

几百张发票 PDF 需要验证金额、日期、发票号 → 区分国内增值税发票和国外发票两套规则

最后还要给所有底稿编索引号、加页眉、统一格式、批量打印归档

之前的麻烦 ：一个熟练的审计员处理 300 笔订单的底稿，至少需要 2-3 个工作日，而且纯手工操作极易出错（看串行、漏填、索引号重复）。

做出来之后省掉了什么 ：上述所有工序变成 6 个可编排的 Phase，运行一次约 30 分钟（不含 OCR API 调用时间），审计员只需做最终的异常复核。

3、创作过程

核心方法论：Vibe Coding + 五层 Agent 架构

这个 Skill 的创作遵循了我总结的"Vibe Coding 四步循环"：

隐性知识显性化 → 精确 Prompt 生成 → AI 代码生成 → 人工调试迭

代

↑ |

└──────────────────────────────────────────────┘

第一步：把审计隐性知识"翻译"成规则

审计师脑子里有很多"潜规则"——比如"税务局端的发票 PDF，/Author 元数据通常是 China Tax"、“出口日期在报关单上通常以 8 位数字出现”。我先花了大量时间把这些隐性知识写成可校验的规则系统（27 个 Python 脚本、6 组正则表达式多模式 fallback）。

第二步：设计五层架构，每一层对应 AI Agent 的一个能力维度

我参考了自动驾驶的感知-规划-执行架构，设计了审计自动化五层模型：

层级 定位 做什么 感知层 系统"眼睛" pdfplumber+PyPDF2 双引擎读 PDF，Qwen3-VL 多模态 OCR 识别出库单图片 认知层 系统"大脑" 6 组正则多模式 fallback 提取报关单/发票信息，日期格式归一化 逻辑层 系统"神经" 订单号→PDF→索引号的关联映射，一对多匹配 执行层 系统"双手" COM 操作 Excel 页眉/格式/打印，SumatraPDF 静默打印 反馈层 系统"守门人" 异常分拣、双通道日志、结构化 JSON 处理报告

每一层都封装为独立的 Tool，为未来"自然语言驱动的 AI Agent"做好了准备。

第三步：用 SOLO 把 27 个脚本+参考文档+模板打包成结构化 Skill

最终产出了一个包含 52 个文件 的完整 Skill 目录：架构参考文档、提取规则库、API 接口规范、性能基线、异常处理指南、6 个 Phase 工作流模板、4 个辅助脚本、单元测试、配置示例等——所有内容按 SKILL.md 主文件 → references/ → templates/ → examples/ → tests/ → scripts/ 六层组织。

关键设计决策（创作中的思考）：

双引擎容错 ：pdfplumber 读 PDF 失败自动回退 PyPDF2，COM 对象崩溃自动销毁重建，API 429 自动指数退避——任何单点故障不导致流程中断。

AI + 规则双重校验 ：Qwen3-VL 做 OCR 模糊识别，正则做精确校验，AI 输出必须经过规则二次过滤才被采纳。

单文件异常隔离 ：一个文件处理失败，不影响其余几百个文件继续跑，失败的被分拣到 UNMATCHED 文件夹等待人工复核。

三段式版本演进 ：基础版（顺序执行）→ 增强版（+重试+COM 重建）→ 终极版（多 Worker+线程 COM），打印模块按这个模式实现三级版本。

4、使用步骤

前置条件 ：安装 SOLO，将 Skill 目录放入 .trae/skills/ 。

调用方式 ：在 SOLO 对话中提及审计收入细节测试相关关键词即可触发，例如：

“帮我做收入细节测试，先检查环境配置”

“帮我处理这批复关单 PDF，提取 6 项信息”

“帮我给这批发票底稿编制索引号”

推荐执行顺序 （按审计程序依赖关系）：

Phase 1 (出库单 OCR 匹配)

→ Phase 2 (报关单 6 维提取) ─┐

→ Phase 3 (发票验证) ├─ 可并行

→ Phase 4 (底稿索引编制)

→ Phase 5 (批量页眉/格式/打印)

首次运行建议 ：

先运行 scripts/preflight_check.py 一键检查所有依赖（Python 版本、pip 包、SumatraPDF、COM、打印机、磁盘空间）

用 examples/config_samples/ 下的配置模板填充真实路径

从小批量开始验证（5-10 个文件），确认无误后再跑全量

5、效果展示

处理能力对比 ：

环节 人工耗时（300笔订单） Skill 自动化 出库单匹配 ~4 小时（肉眼看图+Excel填单号） ~5 分钟（OCR+正则校验+自动回填） 报关单提取 ~6 小时（逐份打开PDF+摘录6字段） ~8 分钟（全文搜索+正则提取+自动填充） 发票验证 ~4 小时（国内/国外两套规则手动判断） ~5 分钟（三级搜索+自动识别+批量回填） 索引+页眉+格式+打印 ~3 小时（逐个改名+页眉设置+格式调整） ~10 分钟（COM批量操作+多线程打印） 合计 ~17 小时（2.1个工作日） ~28 分钟

输出物 ：

已重命名的底稿 PDF（带索引号）

已回填的 Excel 工作表（6 列报关信息/发票信息完整）

Processing_Report.json — 结构化处理报告（成功率、跳过文件清单、异常明细）

双通道日志文件 — 完整审计追踪

6、Skill 链接

Skill 完整目录位于本地，包含 52 个文件、6 大目录层级。后续将发布至 GitHub 仓库（按 PUBLISH.md 中的指引），届时可通过 npx skills add 一键安装。

目录结构一览 ：

audit-income-detail-test/

├── SKILL.md # 主文件

├── README.md / PUBLISH.md / CHANGELOG.md

├── references/ # 架构/提取规则/集成/运维

4 子目录 10 文档

├── templates/ # Phase1-6 工作流模板

├── examples/ # 配置示例+输出样例+排错指

南

├── tests/ # 日期/索引/提取 单元测试

└── scripts/ # 预检/基准/备份/日志分析

4 辅助脚本

7、总结与思考

最大的收获：

这件事让我对"AI 到底能替代审计师的什么"有了重新认识。AI 不是替代审计师的判断力，而是替代"重复性认知劳动"——那些规则明确但繁琐的信息提取和匹配工作。审计师的时间应该花在看异常、做判断上，而不是花在翻 PDF、抄数字上。

效率提升 ：从 17 小时手工操作 → 28 分钟自动化处理，效率提升约 36 倍 。更重要的是，错误的类型从"人容易犯的看串行、漏填"变成了"规则覆盖不到的特殊格式需要人工确认"——后者更容易被系统性发现和修复。

这个 Skill 目前最满意的地方：

五层架构设计。它不是为当前的正则+OCR 做的，而是为未来的 AI Agent 做的——每一层都预封装为 Tool，当 LLM 发展到可以直接编排 Tool 时，这个 Skill 可以直接从"脚本驱动"升级到"自然语言驱动"，无需重写。

后续想优化的方向：

Phase 2 演进：用 LLM JSON Mode 替代当前的正则提取，提升对非常规格式报关单的覆盖率

增加离线 OCR fallback（Tesseract 作为 Qwen3-VL 之外的第三引擎）

将 IndexGenerator 的数据累积为 RAG 知识库，让 Agent 能"记住"历史项目的映射关系

增加 Phase 0（预检）和 Phase 6.5（流程审查）工作流

希望别人怎么体验或给建议：

如果你是审计从业者，欢迎拿你手头真实的报关单 PDF、发票 PDF、出库单图片来测试——我特别想知道正则 fallback 链在你们事务所的实际文件格式上的覆盖率。如果你是 AI 开发者，欢迎对五层 Agent 架构的 Tool 封装粒度提建议。