企业官网建设流程全解析

银行和金融服务机构的内部审计，一直是个“文档密度极高、证据要求极严、时间窗口极紧”的场景。我见过不少团队想用 AI workflow 来改造内部审计流程，结果第一版方案都卡在同一个地方：以为把审计资料丢给大模型，就能自动产出审计底稿。实际上，AI workflow 真正值得做的是另一件事——把审计人员花在通读文件、抽取关键信息、初步筛查风险点、整理证据引用上的时间压下来，同时保证每一步处理都可回溯、可复核、可导出。

这篇文章我从内部审计的原始场景出发，拆一个适合银行和金融服务机构的 AI workflow 落地方案。内容包括流程骨架怎么设计、单条任务怎么跑通、批量任务怎么工程化、输出质量怎么验证、常见问题怎么排查。适合内部审计、合规、风险管理团队，也适合正在做 AI Agent 和 workflow 设计的产品、技术同学。先说结论：想在银行内部落地 AI 审计工作流，最关键的不是模型能力，而是流程中是否设置了人的复核节点、证据是否可追溯、以及每一步的输出是否稳定可复现。

1. 内部审计的真实痛点，决定了 AI workflow 的边界

1.1 审计不是在“看报表”，而是在做证据链管理

很多人对内部审计的理解是“查账”“看报表”，但真在银行或金融公司做过审计就会知道，相当大一部分工作量是处理非结构化文档。

一笔贷款审批要查什么？信贷政策文件、客户尽调材料、审批意见书、放款条件清单、贷后检查记录。一个采购事项要查什么？招标公告、评标记录、合同文本、供应商资质、付款审批单。一个员工费用报销要查什么？发票、行程单、审批流截图、制度依据。这些材料分散在 OA 系统、影像平台、邮件附件、共享目录里，格式有 PDF、Word、扫描件、Excel、图片，很多扫描件甚至没有文字层。

审计人员的时间主要花在两件事上：第一，通读这些材料，找到和审计问题相关的关键段落；第二，把关键段落摘出来，标注来源，形成底稿。前者是体力活，后者是证据链工作。AI workflow 能解决的，是前者的大部分和后者的一小部分。

这里要先给 AI 的作用定边界：它适合做“识别、抽取、归类、初筛、起草”，不适合做“判断、决策、定责”。审计结论必须由人来做，AI 的价值是让做结论之前的信息准备变快、变整齐。

1.2 AI workflow 能做什么，不能做什么

结合银行内部审计的常见场景，AI workflow 可以承担的任务大致有四类：

• 文档分类与检索：把几百份文件按业务类型、审计事项、时间范围自动归类，审计人员输入问题，直接定位到相关文件和相关段落。
• 关键信息抽取：从合同、审批单、制度文件中抽取金额、日期、审批人、授权层级、条款生效条件等结构化字段。
• 风险线索初筛：在交易流水、报销明细、审批记录中，按预设规则做异常识别，比如拆分报销、授权交叉、频率异常、金额接近阈值等。
• 底稿素材生成：把抽取结果、风险线索和文件引用整理成初稿格式，供审计人员修改和补充。

不适合做的事也要明确写下来。不要用模型直接生成“违规结论”，不要在缺少原文引用的情况下输出“疑似问题”，不要用 AI 替代抽样逻辑。金融服务机构的内部审计最终要面对监管检查，所有结论都必须能追溯到原始证据。一旦流程里少了这一步，前面做得再快都没用。

2. 先设计审计工作流的骨架，再谈选型

2.1 从审计底稿的流向反推流程

我见过不少团队是先选模型，再想流程，结果流程被模型能力带着走，最后变成“有什么模型就做什么功能”。更稳妥的做法是反过来：先看一份审计底稿是怎么产出的，它需要哪些输入、经过哪些加工、产出什么结构，再决定哪些环节交给 AI。

一份典型的内部审计底稿，通常包含以下信息：

• 审计事项名称和对应的审计程序
• 抽样范围和抽样方法
• 检查发现的事实描述
• 相关证据的文件名、页码、原文引用
• 初步风险评估和审计人员意见

顺着这个结构往前推，AI workflow 需要完成的是：把一堆原始文件变成“文件清单 + 关键字段表 + 风险线索表 + 带引用的证据包”。只要这四个输出物是结构化、可校验的，审计人员就能在此基础上快速完成底稿撰写和结论判断。

2.2 五段式主流程：采集、解析、分析、复核、出稿

在银行内部落地，我建议把流程切成五段，每一段都有明确的输入输出，而不是一个“大模型一口吞”的黑盒：

1. 采集：从 OA、影像系统、共享目录收集文件，记录文件来源、上传时间、归属项目。
2. 解析：统一转成可处理的文本。PDF 和 Word 直接提取文字，扫描件走 OCR，表格文件转成结构化数据。
3. 分析：对文本做分类、抽取、规则匹配和风险初筛。这一步可以拆成多个小任务，每个任务一个模型调用或一个规则模块。
4. 复核：把所有 AI 输出送到人工复核台。审计人员逐条确认，有问题直接修正，系统记录修改痕迹。
5. 出稿：根据复核通过的数据生成底稿素材和审计报告初稿。

这五段里，最容易被忽略的是“解析”和“复核”。很多 AI 审计项目效果不好，不是因为模型不够智能，而是文件解析阶段丢字、乱码、表格错位，导致后面所有抽取和判断都建立在错误输入上。复核阶段如果不做，AI 的“自信输出”会直接变成审计风险。

2.3 安全和合规约束要前置

银行和金融服务机构的数据安全要求，决定了这个 workflow 不能按普通互联网应用的思路来搭。原始审计资料通常涉及客户信息、员工信息、交易明细，属于高敏数据。

在设计流程时，有几条约束建议提前定好：

• 数据访问要按角色授权，内部审计人员看到的范围，和模型服务能访问的范围，要按最小权限原则划分。
• 如果使用外部大模型 API，先确认数据是否允许出域。不允许的话，就要走私有化部署或者本地模型方案。
• 所有模型调用记录、输入输出日志、人工修改记录都要保留，方便事后审计。
• 涉及敏感字段，先做脱敏或掩码处理，再进入分析流程。

这些约束看着麻烦，但它们是审计工作流能不能真正上线的前提。技术团队如果一开始不考虑，后面每次安全评审都会返工。

3. 单条审计任务如何跑通：最小可运行流程

3.1 环境准备与依赖确认

不管最终是团队内部工具还是产品化系统，我都建议先用“最小可运行版本”验证流程。先跑通一条任务，再处理复杂度。

环境上，一套通用的本地验证环境可以这样准备：

# Python 版本建议 3.10 以上 # 常用依赖：文件解析、数据处理、日志 pip install pypdf pdfplumber python-docx openpyxl pip install pandas

如果涉及扫描件 OCR，可以根据你的环境选择 OCR 引擎。实测时要注意，扫描件质量直接影响 OCR 结果，倾斜、反光、印章遮挡都会造成文字识别错误。建议先用清晰扫描件做基准测试，再测试低质量样本，否则很难判断是 OCR 的问题还是后续模型的问题。

模型服务这块，有两种选择：

• 外部大模型 API：接入快，效果稳定，但要确认数据合规和网络条件。
• 本地部署开源模型：数据不出域，但需要 GPU 资源，模型效果和推理速度要看机器配置。

原始材料没有给出明确的部署规格，落地时需要根据实际模型版本确认。一般来说，本地跑一个 7B 到 14B 量级的模型，建议准备 16GB 以上的显存；如果内存只有 16GB 且没有独立 GPU，就要把任务拆得更细，或者改用 API 方案。

3.2 输入准备的四个规范

AI 审计工作流最怕“脏输入”。同样的文件，人工看没问题，模型处理可能就乱了。在进入流程之前，建议对输入做四个检查：

• 格式统一：把 PDF、扫描件、Word、Excel 统一转成中间文本格式，并保留原始文件路径。
• 编码正确：中文文档要注意编码问题，转出来的文本如果出现乱码，先检查解析库和原始文件的字体嵌入情况。
• 路径无特殊字符：文件名和目录不要带空格、中文括号、emoji 等特殊字符，否则在批量脚本里很容易出问题。
• 文件来源留痕：每个文件都要有唯一 ID 和来源信息，方便后续输出引用。

我第一次搭这种流程时，就在文件名上踩过坑。几十个 PDF 文件名里带着中文全角括号，解析脚本跑了一半报错，排查了半天才发现是路径问题。后来统一改成“项目编号_文件类型_序号.pdf”的命名规范，问题一下就少了。

3.3 模型和提示词的选择

在内部审计场景，模型选择有三个原则：

• 抽取类任务优先用低温度：温度参数放在 0.1 左右，尽量减少随机性。审计抽取最怕同一份文件跑两次结果不一样。
• 长文档优先看上下文长度：合同、制度文件动辄几十页，如果模型的上下文窗口不够，就要做切分，切分粒度要能保证关键条款不被人为截断。
• 复杂推理任务用更强模型，简单抽取用轻量模型：不要把每一类任务都压在一个模型上，成本和稳定性都要考虑。

提示词设计上，建议每个任务写清楚三件事：输入是什么、输出结构是什么、遇到不确定内容时怎么处理。比如抽取审批金额时，要求输出 JSON 格式：

{ "task_id": "2025-AUDIT-001", "file_name": "loan_approval_20250312.pdf", "extracted_fields": [ { "field_name": "loan_amount", "field_value": "5000000", "source_page": 3, "source_text": "同意发放贷款人民币伍佰万元整" } ], "uncertainty": "无" }

这里的关键不是让模型“自由发挥”，而是让输出结构化，每一字段都带上原文引用页码。这样复核人员能快速核验，后续生成底稿也能直接引用。

3.4 成功标准怎么定

单条任务跑通，不等于流程可用。我建议用 10 到 20 份已经结案的审计样本做测试，每份样本包含原文、已有底稿、已知结论。测试时要逐个核对：

• 文档能否被正确解析，乱码率是否超过 1%。
• 关键字段抽取的准确率，是否达到人工复核能接受的水平。
• 每个风险线索是否都带上了原文引用，有没有凭空生成的内容。
• 同一份文件跑两次，输出差异是否在可接受范围内。

如果这些指标不达标，先不要急着扩批量，回到解析、切分、提示词这几个环节去调。很多问题在单条任务阶段解决，成本最低。

4. 关键参数和判断标准，别只看速度

4.1 与输出质量直接相关的参数

在审计场景，这些参数对结果影响最大：

• temperature：建议 0 到 0.3。审计抽取和风险初筛是低随机性任务，温度太高会出现同样的输入输出不一致。
• 上下文窗口和切分大小：切分大小建议根据文档类型调整。合同类按章节切，审批单按整页切，避免在句子中间截断。
• max_tokens：输出长度要足够容纳结构化结果。如果返回内容被截断，优先增加输出长度，而不是压缩提示词。
• 检索相关度阈值：如果用了知识库检索，相关度阈值太低会混入无关内容，太高会漏掉关键信息。建议先用测试集跑一遍，看阈值在哪个区间错误最少。

这些参数没有通用的万能值。不同银行、不同审计事项，文档风格差异很大。关键是建立“参数变更-输出质量”的对照记录，每次调整都留痕。

4.2 与成本、资源和稳定性相关的参数

除了质量，还要关注成本。大模型 API 一般按 token 或 credits 计费，处理一份几十页的合同，输入 token 可能上万。批量跑几十个审计事项，费用会迅速积累。

判断成本是否可控，不要只看单次价格，要看这几个指标：

• 单份文件的平均 token 消耗。
• 每万条记录的风险初筛耗时。
• 失败重试的比例。重试次数多，说明输入或参数有问题，不是在解决业务问题。

并发和批量参数同样要留神。不要一上来就开最大并发。API 服务有速率限制，本地部署有显存和内存约束。比如本地跑模型，批量推理时显存占用会随 batch size 上升，超过上限直接 OOM。建议先用小 batch 验证稳定性，再逐步加大。

4.3 怎么定义“审计结论可用”

速度不是首要指标，一致性、可追溯性、可复核性才是。我认为一条 AI 输出达到“可用”状态，至少要满足四条：

• 所有事实性陈述都有原始文件引用，能定位到具体页码或段落。
• 风险提示是“线索”而非“结论”，不预设某个行为一定违规。
• 同一份输入重复执行，关键结果基本一致，允许的波动范围要提前说清楚。
• 人工复核时，能看到模型输出的完整推理依据，而不是只给一个结论。

如果做不到这四条，输出再快也不能进正式底稿。这一点在银行内部尤其不能妥协。

5. 从单任务到批量审计事项，工程化才是关键

5.1 批量任务的输入清单和输出命名

单条任务跑通之后，要处理的就不是一份文件，而是几十个项目、上百份文件。批量场景下，第一个要解决的是输入清单管理。

我建议维护一份 CSV 或表格，作为批处理的任务清单，至少包含这些字段：

• 任务编号
• 审计项目名称
• 文件路径
• 文件类型
• 处理优先级
• 状态（待处理、处理中、成功、失败）

输出文件也要有规范命名。不要用模型输出临时文件名，而是按“任务编号_处理阶段_结果类型.json”来存。比如2025-AUDIT-001_extract_result.json。这样后续拼接底稿和追溯证据都方便。

5.2 失败重试、日志和断点续跑

批量任务一定会遇到失败。文件解析失败、模型超时、权限不足、输出格式不对，都可能发生。关键不是避免失败，而是失败后能快速定位、恢复、继续。

日志要记录四个信息：处理到哪个文件、用了哪个参数、模型返回了什么、失败原因是什么。日志级别至少要有 info 和 error 两种，方便排查。

断点续跑也值得提前设计。一个审计项目几千份文件，跑到一半中断是常见事。如果脚本没有记录已处理文件清单，重跑就要全部再来。建议每处理完一份文件，就把它的 ID 写入“已完成”清单；重启任务时先读清单，跳过已完成项。

5.3 并发控制与资源调度

批量任务的并发，不是越大越好。外部 API 有配额限制，本地模型有显存瓶颈，磁盘 IO 也可能成为瓶颈。

稳妥的推进方式是分步放大：

1. 先用 1 个并发跑 10 份文件，看耗时和错误率。
2. 再按 2 倍、3 倍逐步增加，观察失败率和响应时间。
3. 找到成功率开始下降的临界点，回退一档作为日常并发上限。

如果任务量大，建议再配置一个简单队列，控制同时执行的任务数。队列的好处是，某个任务卡住时不会拖垮整个批处理，还能单独重试。

6. 常见问题和排查链路

6.1 输出内容不完整或明显错误

这类问题的排查顺序，我建议先看输入，再看解析，最后看模型：

1. 原始文件是否完整，PDF 是否加密、缺页、扫描倾斜。
2. 解析出的文本是否准确，有没有乱码、表格错位、文字丢失。
3. 切分是否合理，关键信息是不是被截断在片段之间。
4. 提示词是否明确，输出结构要求是否清晰。
5. 模型输出是否被长度限制截断。

这里最容易犯的错是直接改提示词。实际上大量“模型效果差”的问题，根源在文件解析和切分阶段。先确认输入文本是干净的，再调模型才有意义。

6.2 证据缺失和引用不准确

这是审计场景最致命的错误。模型输出看起来很有道理，但引用的页码和原文对不上，或者引用了不存在的内容，也就是常说的 AI 幻觉。

处理办法有三个层面：

• 在提示词里强制要求“不确定时标注 uncertainty，不要编造引用”。
• 在代码层面做校验：模型输出的 source_text，必须能在原始文本中找到对应片段，找不到就标记为“引用校验失败”。
• 在人工复核界面，把引用段落高亮出来，让审计人员一眼看到原文。

不要轻信模型的自信输出。抽取结果必须经过“原文匹配”校验，这是审计 workflow 和普通 AI 工具的底线区别。

6.3 环境层面的排查顺序

如果任务卡住、进程被杀、显存溢出，按这个顺序排查：

1. 看系统资源：显存、内存、磁盘空间、CPU 占用。
2. 看日志和退出码，确认是模型部署问题还是数据处理问题。
3. 确认依赖版本：Python 版本、库版本、模型版本是否匹配。
4. 检查权限：输入文件是否可读，输出目录是否可写。
5. 检查路径：有没有特殊字符、超长路径、挂载盘未生效。

很多“程序跑不起来”的问题，其实是环境和路径问题。把环境排清楚，再判断是不是业务逻辑的问题。

7. 边界、落地节奏和后续优化

7.1 哪些情况不要硬上 AI workflow

AI 审计工作流不是每个场景都适合。下面几种情况，我建议先缓一缓：

• 原始文件质量极差，扫描件模糊、表格复杂、书写体多，OCR 都很难保证准确。
• 审计事项涉及高度主观判断，比如对管理层诚信度的评估，不适合用模型生成初筛结论。
• 团队没有能力维护模型输出质量和复核流程，上线后很容易失控。
• 数据合规问题没有确认清楚，外部 API 和数据出境风险没有结论。

在这些情况下，先把数据处理规范做起来，比上模型更有价值。AI workflow 是建立在干净数据之上的。

7.2 上线前必须完成的验证清单

如果你准备把 AI 审计 workflow 推给团队使用，建议至少完成这些验证：

• 用历史结案项目做回测，AI 抽取结果和人工底稿结论比对。
• 做一次全流程演练：从文件采集到出稿，所有环节在真实数据上跑通。
• 确认复核环节的职责和记录机制，AI 输出的修改历史是否完整保留。
• 明确事故兜底方案：模型输出错误导致底稿出问题时，由谁负责判断和纠正。
• 建立模型升级和提示词变更的版本管理，避免调整后结果无法回溯。

这些不是额外工作，而是内部审计工具能合规使用的必要条件。

7.3 后续迭代方向

等基础流程稳定了，可以从这几个方向迭代：

• 把风险初筛的规则库沉淀成可配置项，让审计人员自己调整阈值，不用每次改代码。
• 把人工复核的修正记录作为反馈数据，持续优化抽取精度。
• 增加抽样辅助能力，基于历史数据和风险特征给出建议抽样范围，但最终抽样决策仍由审计人员确认。
• 把底稿生成和现有审计管理系统打通，减少复制粘贴。

我个人更建议先把单任务跑稳，再考虑批量和接口。AI 在内部审计里的真正价值，不是替代审计人员，而是把审计人员从重复阅读和摘录中解放出来，让他们把精力留给判断和沟通。这个过程不需要一步到位，但每一步都要可追溯、可复核、可验证。