1. 财务团队为什么需要一个AI记账工具财务团队每天面对的工作外行看起来就是记记账、对对数但真正做过的人都知道这里面藏着大量重复、琐碎、又必须零差错的劳动。发票录入、科目匹配、银行流水核对、月末结账、报表生成每一个环节都在消耗人力而且越是月底月初越容易出错。我见过不少中小型财务团队三五个人要处理上千笔交易靠的全是Excel和手工核对加班到深夜是常态。这就是AI accounting harness for finance teams这个项目要解决的问题。所谓harness直译是马具、挽具在软件工程里通常指一套把底层能力套住并驱动起来的框架层。放到财务场景里它指的是一套把AI能力封装成财务团队可以直接使用的记账辅助系统——不是让AI取代会计而是让AI承担那些规则明确、重复度高、但需要判断力的环节比如从一张发票图片里提取金额、税额、供应商、日期再自动匹配到正确的会计科目最后生成凭证草稿供人工复核。这个定位很关键。市面上很多AI财务产品走的是两条极端路线要么是纯OCR工具只做文字识别识别完还得人工一条条录入要么是号称全自动做账的黑盒系统结果财务人员根本不敢用因为不知道它为什么这么记出了问题无法追溯。而这个harness的思路是人在环中——AI负责提速和初筛财务人员负责最终判断和签字。这个平衡点恰恰是财务团队真正能接受、也真正能落地的方案。适合读这篇内容的人有三类一是财务团队的技术负责人想评估AI能不能接入现有流程二是财务从业者想了解AI到底能帮自己省多少事、哪些环节还不能放手三是做企业级AI应用的开发者想看看财务这个垂直场景的harness该怎么设计。下面我会从架构、核心模块、实操落地、踩坑经验几个角度把这个项目拆开讲透。2. 拆解这个harness的架构分层2.1 为什么财务AI不能做成一个大模型直连很多人第一反应是现在大模型这么强直接把发票丢给模型让它输出会计分录不就行了我实测过这条路结论是——能跑通demo但上不了生产。原因有三个。第一是确定性。财务记账要求同样的输入必须得到同样的输出而大模型的输出带有随机性同样的发票今天识别成办公费明天可能识别成管理费用-其他这在财务上是不可接受的。第二是可审计性。每一笔账都要能追溯到依据模型说我觉得这是差旅费审计的时候没法交代。第三是成本与延迟。每张发票都调用大模型做全量推理token消耗和响应时间都撑不住日均上千笔的量。所以这个harness的核心设计思想是分层把确定性任务和判断性任务分开确定性任务用规则和轻量模型解决判断性任务才交给大模型而且大模型的输出必须经过校验层。2.2 四层架构的实际划分我把这套harness的架构归纳成四层从下往上依次是层级职责典型技术选型接入层接收发票、流水、单据等多源输入文件上传、邮件解析、API对接提取层从非结构化数据中抽取结构化字段OCR 版面分析 字段抽取模型映射层把字段映射到会计科目与凭证结构规则引擎 向量检索 大模型兜底校验层校验凭证合法性、平衡性、合规性借贷平衡、科目白名单、历史比对这个分层的价值在于每一层都可以独立替换和升级。比如OCR引擎从A换成B不影响上面的映射逻辑映射规则调整也不用动提取层。财务团队最怕的就是牵一发动全身分层让系统变得可维护。2.3 接入层多源输入的统一抽象财务数据来源非常杂有扫描的纸质发票、有电子发票PDF、有银行导出的流水Excel、有ERP系统里的采购单。如果每个来源写一套处理逻辑代码会爆炸。harness的做法是定义一个统一的Document抽象不管来源是什么进来之后都转成带元数据的标准文档对象。class Document: def __init__(self, source_type, raw_content, metadata): self.source_type source_type # invoice / bank_flow / purchase_order self.raw_content raw_content # 原始字节或文本 self.metadata metadata # 来源、时间、上传人等 self.extracted None # 提取层填充 self.entries [] # 映射层填充的凭证草稿这个抽象看起来简单但它是整个系统可扩展的基础。新增一种单据类型只需要实现对应的解析器把它转成Document后面的流程完全复用。我在实际项目里踩过的坑是一开始没做这层抽象结果每加一个数据源就要改一遍下游代码维护成本极高。3. 提取层从发票到结构化字段的关键细节3.1 OCR不是终点版面分析才是分水岭很多人以为发票识别就是OCR把图片转成文字就完事了。但真实发票的难点不在认字而在认位置。一张增值税发票上金额和税额两个数字长得差不多位置也接近纯OCR出来的文本流根本分不清哪个是哪个。所以提取层必须做版面分析先定位每个字段在版面中的坐标再结合坐标和标签做字段绑定。具体做法是先用检测模型框出所有文本区域得到每个文本块的坐标和内容然后用规则或小模型判断这个文本块是标签还是值比如价税合计是标签它右边或下方的数字就是值。这一步的准确率直接决定了后面所有环节的质量。我见过太多项目在OCR上追求99%的字符准确率却忽略了字段绑定的准确率结果字段错位后面全错。3.2 字段抽取的置信度机制提取层输出的每个字段都应该带一个置信度分数这是harness设计里非常关键的一点。为什么因为下游要根据置信度决定自动通过还是转人工。{ field: total_amount, value: 1130.00, confidence: 0.97, bbox: [120, 340, 280, 370] }置信度高的字段直接进入映射层置信度低的字段标记出来在人工复核界面高亮显示。这样财务人员不用逐字检查只需要看系统标红的部分效率提升非常明显。置信度阈值怎么定我的经验是先用一批历史数据跑一遍画出准确率-覆盖率曲线找到那个再降低阈值准确率就明显下滑的拐点通常设在0.85到0.92之间比较稳妥。3.3 处理特殊票种的实战经验标准增值税发票好处理真正麻烦的是这几种出租车票金额小、数量多、格式乱、火车票有身份信息需要脱敏、境外发票多语言、多币种、手写收据识别率天然低。针对出租车票我的做法是批量合并处理不追求单张100%准确而是允许一定误差因为金额小人工复核成本低。针对境外发票关键是先做币种识别再走对应的汇率换算绝不能默认人民币。手写收据则要设置更低的自动通过阈值基本全部转人工AI只做预填。这些细节产品文档里通常不会写但实际落地时全是坑。4. 映射层AI判断会计科目的正确姿势4.1 规则引擎打底大模型兜底映射层的任务是把提取出来的字段供应商、金额、摘要、商品明细翻译成会计科目和借贷方向。这一步是财务AI最核心、也最容易翻车的地方。我的设计原则是规则优先、检索其次、大模型兜底。具体来说规则引擎处理高频、明确的场景。比如摘要包含加油且供应商是加油站→借管理费用-车辆费用。这类规则覆盖了日常80%的交易速度快、结果稳定、可解释。向量检索处理规则没覆盖但历史上有类似记录的场景。把历史凭证的摘要做向量化新来的摘要去检索最相似的历史凭证复用它的科目。这招对同一供应商反复采购同类商品特别有效。大模型兜底处理全新的、规则和检索都搞不定的场景。这时候才调用大模型让它基于科目表和业务描述做判断但输出必须经过校验层。这个顺序不能反。我见过有团队一上来就用大模型做全量映射结果成本高、速度慢、还不稳定最后又退回规则引擎重做。4.2 科目表的向量化与检索向量检索要跑得好科目表的组织方式很关键。不能只把科目名称向量化那样信息量太少。我的做法是把每个科目拼成一段描述再向量化def build_subject_text(subject): return f{subject.code} {subject.name} {subject.description} 常见场景:{subject.examples}比如管理费用-差旅费这个科目描述里会带上出差、住宿、机票、火车票、市内交通这些常见场景词。这样新来的摘要员工张三报销去上海的高铁票就能检索到差旅费科目。检索返回Top-3候选如果第一名相似度明显高于第二名就自动采用如果几个候选分数接近就转人工选择。这个分数接近就转人工的策略能挡掉大量模棱两可的情况。4.3 大模型提示词的设计要点兜底调用大模型时提示词的设计直接决定输出质量。我的经验是提示词里必须包含四样东西完整的科目表让模型只能从给定科目里选、业务背景公司行业、常见业务类型、输出格式约束强制JSON包含科目代码、借贷方向、理由、少样本示例给两三个正确映射的例子。PROMPT 你是财务记账助手。根据以下交易信息从给定科目表中选择最合适的科目。 科目表 {subject_list} 交易信息 摘要{summary} 供应商{vendor} 金额{amount} 请输出JSON格式 {{subject_code: ..., direction: 借/贷, reason: ...}} 示例 摘要购买办公用A4纸供应商XX文具店 输出{{subject_code: 660201, direction: 借, reason: 办公用品属于管理费用-办公费}} 注意reason字段它不只是给模型看的更是给财务人员复核时看的。有了理由复核效率高很多也方便后续审计追溯。这一点是很多AI财务产品忽略的——它们只给结果不给理由财务人员不敢用。5. 校验层让AI记账结果敢被签字5.1 借贷平衡只是最低要求校验层的第一道关是借贷平衡这是会计的铁律任何凭证借贷必须相等。但光有平衡远远不够。我总结了几类必须校验的规则科目合法性科目代码必须在公司启用的科目表里不能是模型编造的。方向合理性资产类科目通常借方增加负债类贷方增加方向反了要报警。金额合理性单笔金额超过历史同类交易均值N倍标记异常。时间合理性凭证日期不能晚于当前日期也不能早于太离谱的时间。重复检测同一供应商、同一金额、相近时间的凭证可能是重复录入。这些规则用配置化的方式管理财务主管可以自己增删改不用改代码。这一点很重要因为不同公司的财务规则差异很大硬编码的校验规则没法通用。5.2 异常分级与人工介入策略校验不通过的凭证不能简单丢弃要分级处理。我把它分成三级级别触发条件处理方式提示轻微异常如金额略高于均值正常流转界面标注警告中等异常如科目方向可疑转人工确认后流转阻断严重异常如借贷不平、科目不存在禁止流转必须人工修正这个分级让系统既能挡住严重错误又不会因为一点小异常就卡住整个流程。实际用下来阻断级别的凭证占比通常不到2%警告级别约10%其余都能自动流转人工只需要处理这12%左右效率提升非常可观。5.3 可追溯的审计日志财务系统必须能回答这笔账是怎么来的。所以harness要记录完整的处理链路原始文档、提取的字段及置信度、映射用的规则或模型、校验结果、人工修改记录。这些日志结构化存储随时可以按凭证号、时间、操作人检索。audit_log { entry_id: V20240115001, source_doc: invoice_20240115_001.pdf, extracted_fields: {...}, mapping_method: rule_engine, # 或 vector_search / llm mapping_reason: 摘要含加油命中规则R023, validation_results: [...], human_edits: [ {field: subject_code, from: 660201, to: 660202, operator: 张三} ] }有了这个日志审计的时候任何一笔账都能还原出完整的决策过程。这也是财务团队敢用AI的前提——不是信任AI永远正确而是信任出了问题能查清楚。6. 落地部署时绕不开的几个现实问题6.1 数据安全与本地化部署财务数据是企业的核心机密很多公司根本不允许数据出内网。所以这套harness在设计上必须支持本地化部署大模型也要能跑在本地或私有环境里。这就涉及到模型选型的问题本地部署的模型能力通常不如云端大模型但胜在数据不出门。我的建议是分级用模型提取层用轻量OCR和字段抽取模型本地跑完全够用映射层的规则和向量检索也是本地的只有兜底的大模型判断如果公司允许可以用能力更强的模型如果不允许就用本地部署的中等规模模型接受一定的准确率下降用更高的人工介入率来补偿。这个取舍没有标准答案取决于公司对数据安全和效率的优先级排序。6.2 与现有ERP/财务软件的对接财务团队不可能抛弃现有的财务软件所以harness的定位是前置处理层处理完生成凭证草稿再通过API或文件导入的方式送进现有系统。对接时最常见的坑是科目编码体系不一致——harness里用的科目表和ERP里的科目表对不上。解决办法是在映射层加一个科目映射表把内部科目代码翻译成ERP的代码这个映射表由财务人员维护一次之后基本不用动。另一个坑是凭证格式差异。不同财务软件对凭证的字段要求不同有的要求辅助核算项有的要求项目号。这些都要在导出环节做适配。我的做法是定义一个中间凭证格式然后为每个目标系统写一个导出适配器这样新增一个财务软件只需要加一个适配器。6.3 冷启动阶段的历史数据利用系统刚上线时规则库是空的向量库也是空的这时候AI的判断准确率会很低。解决办法是用历史数据冷启动把过去一到两年的凭证导进来一方面用它们训练和填充向量库另一方面从历史凭证里挖掘高频规则。比如发现摘要含餐费的90%都记入了业务招待费就可以自动生成一条规则候选让财务人员确认后启用。这个冷启动过程通常需要一到两周期间人工介入率会比较高但一旦规则库和向量库积累起来自动化率会快速上升。我实测过一个中等规模的团队冷启动两周后自动通过率能从最初的30%提升到70%以上。7. 我踩过的坑和几条实在建议7.1 不要追求100%自动化这是我最大的体会。一开始我也想着把自动化率做到极致结果发现最后那10%的疑难凭证为了自动化要投入的精力是前面90%的好几倍而且准确率还上不去。后来我转变思路把目标定在自动化处理80%人工高效处理20%反而整体效率最高。因为人工处理那20%时系统已经做好了预填和候选推荐财务人员只需要点几下确认速度也很快。7.2 置信度阈值要动态调整固定阈值在不同时期效果不一样。月初凭证多、类型杂阈值可以适当降低让更多凭证自动流转月末结账时对准确性要求高阈值调高多转一些人工。这个动态调整可以做成配置项让财务主管根据当期情况自己调。我见过有团队把阈值写死在代码里结果旺季天天爆人工队列淡季又浪费了自动化能力。7.3 人工复核界面比模型更重要很多人把精力全花在模型上却忽略了复核界面的设计。实际上财务人员每天面对的就是这个界面界面好不好用直接决定系统能不能推下去。好的复核界面应该做到异常字段高亮、候选科目一键选择、历史相似凭证可查、键盘快捷键支持。我做过对比优化复核界面带来的效率提升有时候比换个更强的模型还明显。7.4 让财务人员参与规则维护规则库不能只由技术人员维护要让财务人员参与进来。因为最懂业务的是他们哪些场景该记什么科目他们比任何模型都清楚。我的做法是提供一个简单的规则配置界面财务人员用自然语言描述规则系统辅助转成可执行的规则。这样规则库能持续进化而且财务人员有了参与感对系统的信任度也更高。7.5 从小场景切入别一上来就全流程最后一条建议不要一上来就想把整个财务流程都AI化。选一个最痛、最标准化的场景先做比如发票录入跑通了、用顺了再扩展到银行流水核对、费用报销。小场景见效快能快速建立团队信心也能积累经验。我见过太多项目想一口吃成胖子结果半年都没上线团队信心耗尽项目就黄了。这套harness的思路说到底就是把AI放在它擅长的位置把判断权留给专业的人用工程化的分层和校验保证结果可靠。财务这个场景对准确性要求极高任何花哨的功能都比不上稳和可追溯两个字。把这两点做扎实AI在财务团队里才真正站得住脚。
1. 财务团队为什么需要一个AI记账工具财务团队每天面对的工作外行看起来就是记记账、对对数但真正做过的人都知道这里面藏着大量重复、琐碎、又必须零差错的劳动。发票录入、科目匹配、银行流水核对、月末结账、报表生成每一个环节都在消耗人力而且越是月底月初越容易出错。我见过不少中小型财务团队三五个人要处理上千笔交易靠的全是Excel和手工核对加班到深夜是常态。这就是AI accounting harness for finance teams这个项目要解决的问题。所谓harness直译是马具、挽具在软件工程里通常指一套把底层能力套住并驱动起来的框架层。放到财务场景里它指的是一套把AI能力封装成财务团队可以直接使用的记账辅助系统——不是让AI取代会计而是让AI承担那些规则明确、重复度高、但需要判断力的环节比如从一张发票图片里提取金额、税额、供应商、日期再自动匹配到正确的会计科目最后生成凭证草稿供人工复核。这个定位很关键。市面上很多AI财务产品走的是两条极端路线要么是纯OCR工具只做文字识别识别完还得人工一条条录入要么是号称全自动做账的黑盒系统结果财务人员根本不敢用因为不知道它为什么这么记出了问题无法追溯。而这个harness的思路是人在环中——AI负责提速和初筛财务人员负责最终判断和签字。这个平衡点恰恰是财务团队真正能接受、也真正能落地的方案。适合读这篇内容的人有三类一是财务团队的技术负责人想评估AI能不能接入现有流程二是财务从业者想了解AI到底能帮自己省多少事、哪些环节还不能放手三是做企业级AI应用的开发者想看看财务这个垂直场景的harness该怎么设计。下面我会从架构、核心模块、实操落地、踩坑经验几个角度把这个项目拆开讲透。2. 拆解这个harness的架构分层2.1 为什么财务AI不能做成一个大模型直连很多人第一反应是现在大模型这么强直接把发票丢给模型让它输出会计分录不就行了我实测过这条路结论是——能跑通demo但上不了生产。原因有三个。第一是确定性。财务记账要求同样的输入必须得到同样的输出而大模型的输出带有随机性同样的发票今天识别成办公费明天可能识别成管理费用-其他这在财务上是不可接受的。第二是可审计性。每一笔账都要能追溯到依据模型说我觉得这是差旅费审计的时候没法交代。第三是成本与延迟。每张发票都调用大模型做全量推理token消耗和响应时间都撑不住日均上千笔的量。所以这个harness的核心设计思想是分层把确定性任务和判断性任务分开确定性任务用规则和轻量模型解决判断性任务才交给大模型而且大模型的输出必须经过校验层。2.2 四层架构的实际划分我把这套harness的架构归纳成四层从下往上依次是层级职责典型技术选型接入层接收发票、流水、单据等多源输入文件上传、邮件解析、API对接提取层从非结构化数据中抽取结构化字段OCR 版面分析 字段抽取模型映射层把字段映射到会计科目与凭证结构规则引擎 向量检索 大模型兜底校验层校验凭证合法性、平衡性、合规性借贷平衡、科目白名单、历史比对这个分层的价值在于每一层都可以独立替换和升级。比如OCR引擎从A换成B不影响上面的映射逻辑映射规则调整也不用动提取层。财务团队最怕的就是牵一发动全身分层让系统变得可维护。2.3 接入层多源输入的统一抽象财务数据来源非常杂有扫描的纸质发票、有电子发票PDF、有银行导出的流水Excel、有ERP系统里的采购单。如果每个来源写一套处理逻辑代码会爆炸。harness的做法是定义一个统一的Document抽象不管来源是什么进来之后都转成带元数据的标准文档对象。class Document: def __init__(self, source_type, raw_content, metadata): self.source_type source_type # invoice / bank_flow / purchase_order self.raw_content raw_content # 原始字节或文本 self.metadata metadata # 来源、时间、上传人等 self.extracted None # 提取层填充 self.entries [] # 映射层填充的凭证草稿这个抽象看起来简单但它是整个系统可扩展的基础。新增一种单据类型只需要实现对应的解析器把它转成Document后面的流程完全复用。我在实际项目里踩过的坑是一开始没做这层抽象结果每加一个数据源就要改一遍下游代码维护成本极高。3. 提取层从发票到结构化字段的关键细节3.1 OCR不是终点版面分析才是分水岭很多人以为发票识别就是OCR把图片转成文字就完事了。但真实发票的难点不在认字而在认位置。一张增值税发票上金额和税额两个数字长得差不多位置也接近纯OCR出来的文本流根本分不清哪个是哪个。所以提取层必须做版面分析先定位每个字段在版面中的坐标再结合坐标和标签做字段绑定。具体做法是先用检测模型框出所有文本区域得到每个文本块的坐标和内容然后用规则或小模型判断这个文本块是标签还是值比如价税合计是标签它右边或下方的数字就是值。这一步的准确率直接决定了后面所有环节的质量。我见过太多项目在OCR上追求99%的字符准确率却忽略了字段绑定的准确率结果字段错位后面全错。3.2 字段抽取的置信度机制提取层输出的每个字段都应该带一个置信度分数这是harness设计里非常关键的一点。为什么因为下游要根据置信度决定自动通过还是转人工。{ field: total_amount, value: 1130.00, confidence: 0.97, bbox: [120, 340, 280, 370] }置信度高的字段直接进入映射层置信度低的字段标记出来在人工复核界面高亮显示。这样财务人员不用逐字检查只需要看系统标红的部分效率提升非常明显。置信度阈值怎么定我的经验是先用一批历史数据跑一遍画出准确率-覆盖率曲线找到那个再降低阈值准确率就明显下滑的拐点通常设在0.85到0.92之间比较稳妥。3.3 处理特殊票种的实战经验标准增值税发票好处理真正麻烦的是这几种出租车票金额小、数量多、格式乱、火车票有身份信息需要脱敏、境外发票多语言、多币种、手写收据识别率天然低。针对出租车票我的做法是批量合并处理不追求单张100%准确而是允许一定误差因为金额小人工复核成本低。针对境外发票关键是先做币种识别再走对应的汇率换算绝不能默认人民币。手写收据则要设置更低的自动通过阈值基本全部转人工AI只做预填。这些细节产品文档里通常不会写但实际落地时全是坑。4. 映射层AI判断会计科目的正确姿势4.1 规则引擎打底大模型兜底映射层的任务是把提取出来的字段供应商、金额、摘要、商品明细翻译成会计科目和借贷方向。这一步是财务AI最核心、也最容易翻车的地方。我的设计原则是规则优先、检索其次、大模型兜底。具体来说规则引擎处理高频、明确的场景。比如摘要包含加油且供应商是加油站→借管理费用-车辆费用。这类规则覆盖了日常80%的交易速度快、结果稳定、可解释。向量检索处理规则没覆盖但历史上有类似记录的场景。把历史凭证的摘要做向量化新来的摘要去检索最相似的历史凭证复用它的科目。这招对同一供应商反复采购同类商品特别有效。大模型兜底处理全新的、规则和检索都搞不定的场景。这时候才调用大模型让它基于科目表和业务描述做判断但输出必须经过校验层。这个顺序不能反。我见过有团队一上来就用大模型做全量映射结果成本高、速度慢、还不稳定最后又退回规则引擎重做。4.2 科目表的向量化与检索向量检索要跑得好科目表的组织方式很关键。不能只把科目名称向量化那样信息量太少。我的做法是把每个科目拼成一段描述再向量化def build_subject_text(subject): return f{subject.code} {subject.name} {subject.description} 常见场景:{subject.examples}比如管理费用-差旅费这个科目描述里会带上出差、住宿、机票、火车票、市内交通这些常见场景词。这样新来的摘要员工张三报销去上海的高铁票就能检索到差旅费科目。检索返回Top-3候选如果第一名相似度明显高于第二名就自动采用如果几个候选分数接近就转人工选择。这个分数接近就转人工的策略能挡掉大量模棱两可的情况。4.3 大模型提示词的设计要点兜底调用大模型时提示词的设计直接决定输出质量。我的经验是提示词里必须包含四样东西完整的科目表让模型只能从给定科目里选、业务背景公司行业、常见业务类型、输出格式约束强制JSON包含科目代码、借贷方向、理由、少样本示例给两三个正确映射的例子。PROMPT 你是财务记账助手。根据以下交易信息从给定科目表中选择最合适的科目。 科目表 {subject_list} 交易信息 摘要{summary} 供应商{vendor} 金额{amount} 请输出JSON格式 {{subject_code: ..., direction: 借/贷, reason: ...}} 示例 摘要购买办公用A4纸供应商XX文具店 输出{{subject_code: 660201, direction: 借, reason: 办公用品属于管理费用-办公费}} 注意reason字段它不只是给模型看的更是给财务人员复核时看的。有了理由复核效率高很多也方便后续审计追溯。这一点是很多AI财务产品忽略的——它们只给结果不给理由财务人员不敢用。5. 校验层让AI记账结果敢被签字5.1 借贷平衡只是最低要求校验层的第一道关是借贷平衡这是会计的铁律任何凭证借贷必须相等。但光有平衡远远不够。我总结了几类必须校验的规则科目合法性科目代码必须在公司启用的科目表里不能是模型编造的。方向合理性资产类科目通常借方增加负债类贷方增加方向反了要报警。金额合理性单笔金额超过历史同类交易均值N倍标记异常。时间合理性凭证日期不能晚于当前日期也不能早于太离谱的时间。重复检测同一供应商、同一金额、相近时间的凭证可能是重复录入。这些规则用配置化的方式管理财务主管可以自己增删改不用改代码。这一点很重要因为不同公司的财务规则差异很大硬编码的校验规则没法通用。5.2 异常分级与人工介入策略校验不通过的凭证不能简单丢弃要分级处理。我把它分成三级级别触发条件处理方式提示轻微异常如金额略高于均值正常流转界面标注警告中等异常如科目方向可疑转人工确认后流转阻断严重异常如借贷不平、科目不存在禁止流转必须人工修正这个分级让系统既能挡住严重错误又不会因为一点小异常就卡住整个流程。实际用下来阻断级别的凭证占比通常不到2%警告级别约10%其余都能自动流转人工只需要处理这12%左右效率提升非常可观。5.3 可追溯的审计日志财务系统必须能回答这笔账是怎么来的。所以harness要记录完整的处理链路原始文档、提取的字段及置信度、映射用的规则或模型、校验结果、人工修改记录。这些日志结构化存储随时可以按凭证号、时间、操作人检索。audit_log { entry_id: V20240115001, source_doc: invoice_20240115_001.pdf, extracted_fields: {...}, mapping_method: rule_engine, # 或 vector_search / llm mapping_reason: 摘要含加油命中规则R023, validation_results: [...], human_edits: [ {field: subject_code, from: 660201, to: 660202, operator: 张三} ] }有了这个日志审计的时候任何一笔账都能还原出完整的决策过程。这也是财务团队敢用AI的前提——不是信任AI永远正确而是信任出了问题能查清楚。6. 落地部署时绕不开的几个现实问题6.1 数据安全与本地化部署财务数据是企业的核心机密很多公司根本不允许数据出内网。所以这套harness在设计上必须支持本地化部署大模型也要能跑在本地或私有环境里。这就涉及到模型选型的问题本地部署的模型能力通常不如云端大模型但胜在数据不出门。我的建议是分级用模型提取层用轻量OCR和字段抽取模型本地跑完全够用映射层的规则和向量检索也是本地的只有兜底的大模型判断如果公司允许可以用能力更强的模型如果不允许就用本地部署的中等规模模型接受一定的准确率下降用更高的人工介入率来补偿。这个取舍没有标准答案取决于公司对数据安全和效率的优先级排序。6.2 与现有ERP/财务软件的对接财务团队不可能抛弃现有的财务软件所以harness的定位是前置处理层处理完生成凭证草稿再通过API或文件导入的方式送进现有系统。对接时最常见的坑是科目编码体系不一致——harness里用的科目表和ERP里的科目表对不上。解决办法是在映射层加一个科目映射表把内部科目代码翻译成ERP的代码这个映射表由财务人员维护一次之后基本不用动。另一个坑是凭证格式差异。不同财务软件对凭证的字段要求不同有的要求辅助核算项有的要求项目号。这些都要在导出环节做适配。我的做法是定义一个中间凭证格式然后为每个目标系统写一个导出适配器这样新增一个财务软件只需要加一个适配器。6.3 冷启动阶段的历史数据利用系统刚上线时规则库是空的向量库也是空的这时候AI的判断准确率会很低。解决办法是用历史数据冷启动把过去一到两年的凭证导进来一方面用它们训练和填充向量库另一方面从历史凭证里挖掘高频规则。比如发现摘要含餐费的90%都记入了业务招待费就可以自动生成一条规则候选让财务人员确认后启用。这个冷启动过程通常需要一到两周期间人工介入率会比较高但一旦规则库和向量库积累起来自动化率会快速上升。我实测过一个中等规模的团队冷启动两周后自动通过率能从最初的30%提升到70%以上。7. 我踩过的坑和几条实在建议7.1 不要追求100%自动化这是我最大的体会。一开始我也想着把自动化率做到极致结果发现最后那10%的疑难凭证为了自动化要投入的精力是前面90%的好几倍而且准确率还上不去。后来我转变思路把目标定在自动化处理80%人工高效处理20%反而整体效率最高。因为人工处理那20%时系统已经做好了预填和候选推荐财务人员只需要点几下确认速度也很快。7.2 置信度阈值要动态调整固定阈值在不同时期效果不一样。月初凭证多、类型杂阈值可以适当降低让更多凭证自动流转月末结账时对准确性要求高阈值调高多转一些人工。这个动态调整可以做成配置项让财务主管根据当期情况自己调。我见过有团队把阈值写死在代码里结果旺季天天爆人工队列淡季又浪费了自动化能力。7.3 人工复核界面比模型更重要很多人把精力全花在模型上却忽略了复核界面的设计。实际上财务人员每天面对的就是这个界面界面好不好用直接决定系统能不能推下去。好的复核界面应该做到异常字段高亮、候选科目一键选择、历史相似凭证可查、键盘快捷键支持。我做过对比优化复核界面带来的效率提升有时候比换个更强的模型还明显。7.4 让财务人员参与规则维护规则库不能只由技术人员维护要让财务人员参与进来。因为最懂业务的是他们哪些场景该记什么科目他们比任何模型都清楚。我的做法是提供一个简单的规则配置界面财务人员用自然语言描述规则系统辅助转成可执行的规则。这样规则库能持续进化而且财务人员有了参与感对系统的信任度也更高。7.5 从小场景切入别一上来就全流程最后一条建议不要一上来就想把整个财务流程都AI化。选一个最痛、最标准化的场景先做比如发票录入跑通了、用顺了再扩展到银行流水核对、费用报销。小场景见效快能快速建立团队信心也能积累经验。我见过太多项目想一口吃成胖子结果半年都没上线团队信心耗尽项目就黄了。这套harness的思路说到底就是把AI放在它擅长的位置把判断权留给专业的人用工程化的分层和校验保证结果可靠。财务这个场景对准确性要求极高任何花哨的功能都比不上稳和可追溯两个字。把这两点做扎实AI在财务团队里才真正站得住脚。
