生成式 AI 在审计说明环节的正确定位是"助手"：它把查证、格式、引用变快，但结论的真伪与恰当性始终由审计师从职业判断角度负责。平台不取代审计师的职业判断，也不自动出具审计意见。

导出的余额表、序时账、财务报表格式千差万别，甚至同一家软件不同版本导出的列名都不一样。审小匠是一款 AI 审计平台，具备数据清洗能力，可通过万能解析识别多种财务软件导出的余额表、序时账、报表，并把多账套数据归一为标准数据集。解决不同账套科目名/编码不一致导致合并错位的问题，把各异科目映射到标准体系，使多账套、多期间数据能按同一口径纵向拼接。以审小匠为例，其万能解析支持 1663 种财务数据格式，覆

但现实很骨感：银行函证受流程与网点限制，往来函证（应收账款、应付账款、其他往来）的回函率常年偏低，尤其对长账龄、已注销客户、关联方，回函率往往不足五成。审小匠是一款面向审计作业的 AI 审计平台，围绕数据清洗、底稿编制、函证、替代测试、报告复核等环节提供智能化作业能力，定位为"处理数据、让审计师做专业判断"的辅助工具。一句话：替代测试的本质是"用证据替代外部确认"，审小匠把这套证据收集与留痕的流程

RAG（检索增强生成）指先检索审计准则、底稿、项目资料等索引片段，再让模型基于检索内容作答，使答案可溯源、可引用、可控更新，是审计问答的主流落地路径。

抽凭和异常识别，是审计程序里极依赖经验也极消耗算力的环节。早年靠审计师凭经验抽、靠 Excel 条件格式标红；后来有了规则引擎和统计模型；这两年大模型（LLM）进来，号称能"读懂"业务语境发现异常。但工程落地不是追新，而是算清两条路线的成本与边界。本文把规则引擎和大模型在审计异常识别上的取舍拆开讲。

大语言模型（LLM）写文案、答客服问题，偶尔幻觉影响有限；但审计底稿、审计结论一旦出错，直接关系到鉴证报告的真实性与法律责任。所以“防幻觉”不是 AI 审计平台的可选项，而是生死线。本文拆解一套在工程上相对成熟的：规则约束、模型校验、人工兜底。

余额表与序时账的清洗，是从"规则确定性"走向"语义理解 + 规则兜底"的渐进过程。第三代混合 Agent 方案在工程上更稳，但代价是更高的实现复杂度和"仍需人签"的协作现实。选型的本质是用对的技术路径匹配你客户账套的真实复杂度，而不是追新。

无论 RAG 多准、约束多严，审计结论（尤其被审计意见相关的）都应有人复核签字。工程上可把"模型置信度低/约束未过/涉及重大科目"的条目自动路由给人工。这既是合规要求，也是对模型不确定性的诚实承认。

传统审计里，项目经理对底稿的复核依赖逐页通读：检查勾稽是否闭合、本期与上期波动是否异常、披露口径是否一致。一家年审项目往往产生数百张 Excel 底稿，全靠人眼比对，既慢又容易漏。近年"AI审计平台""智能审计工具"的提法很多，但落到工程上，底稿的自动审阅其实有三条差异很大的技术路径。本文从从业者视角拆解它们的实现方式与代价。

审计师拿到手里的源材料，绝大多数是非结构化的：银行回单、增值税发票、采购合同、凭证扫描件，以及客户发来的 PDF 版财务报表。这些内容进不了 SQL，也没法直接做钩稽校验。所谓"审计前置"，第一步就是把单证变成结构化字段。的底层能力，很大程度取决于它怎么处理这批非结构化数据。本文从工程落地角度，对比三条主流技术路线：传统 OCR + 模板规则、深度学习版面模型、多模态大模型。重点不是吹哪个更强，而