我是一名外部审计从业者。

除了执行审计程序，项目上还有很多琐碎却绕不开的事情，比如每个月的费用报销。

项目成员出差产生的餐饮、住宿、交通等费用，需要整理发票，检查抬头、税号和金额。

核查本身并不复杂，但发票一多，就得反复打开文件、逐张比对。

有时可以请实习生帮忙，却不一定始终有人手；如果核查事项交代不全，错误就可能被带到报销环节，随后又要联系人员修改、重新提交。

如果能把这些要求固定下来，至少常见错误可以先由程序筛一遍，人工再把精力放在异常上。

我当时就在想：既然这些检查有相对明确的规则，能不能让程序分担一部分？这就是我开发发票核查工具的起点。

一、从工作里的问题，迈出第一步

产生这个想法时，我刚好在接触 AI 编程课程，也在学习 CS50。

我开始意识到：或许可以把业务需求交给 AI，让它协助完成代码部分。于是，我把平时接触的餐饮、住宿、高铁、交通等发票样本整理出来，告诉 AI：

我希望做一款工具，自动提取发票信息、按要求核查，再把结果汇总到 Excel，方便检查和复核。

一开始并没有什么特别大的开发计划，我只是想先试一试。

真正动手后才发现，知道自己想做什么，并不等于已经想清楚怎样把它做出来。

二、把想法拆成能执行的规则

“帮我做一个发票核查软件”，听起来是一个明确的要求，但对程序来说还远远不够。

它究竟核查哪些内容？怎样算正确？出错后怎样提示？这些需要我先从实际业务出发，逐项说清楚。

第一步，核查抬头和税号。

部分发票开具时需要手动填写购买方信息，少一个数字、多一个字，都可能影响后续报销。

我希望程序提取发票上的名称和纳税人识别号，再与预先设置的正确公司信息进行核对。

第二步，识别并核验金额。

发票上有多个数字，程序提取到一个金额，并不意味着提取正确。

我想到日常财务工作中的勾稽关系：对于适用的增值税发票，不含税金额加税额应与含税金额相符，税额与税率也应满足相应关系。

不同票据和四舍五入情况，还要分别考虑。

我也明白，不能因为票面出现了某个公司名称，就直接认定它是正确抬头；关键是提取对应字段，再和事先确认的标准信息比对。

对于金额，也不能只看程序抓到了一个数字。

至于 PDF 的文字怎样提取、字段怎样定位、代码怎样编写，我可以让 AI 协助解决。

我不一定知道代码怎么写，但需要知道业务上要检查什么，以及怎样判断结果是否可靠。

这让我想到做审计底稿：拿到数据不是终点，重要的是核实数据是否合理、结果能不能复核。

开发工具也是一样。

既然如此，就先把文本型 PDF 发票的基础核查做好，其他功能再逐步完善。

三、真正的开发，是和 AI 一轮轮磨出来的

第一次让 AI 写出程序，并不代表工具就能直接使用。

我拿真实发票测试，很快碰到各种情况：有的可以正常识别，有的提取不完整；有些发票人工看着没问题，程序却标成异常。

我并不总能判断技术原因，但至少能发现结果是否符合业务预期。

于是，我把发票样本、异常清单以及自己的疑问反馈给 AI，请它分析原因、修改程序，然后再重新测试。

整个过程就是：我提出需求 → AI 协助实现 → 我用实际样本验证 → 发现异常并反馈 → AI 调整 → 再验证。

有时一个小问题也要反复试几轮，需求和判断标准反而是在这些交流中越来越清晰的。

我后来发现，和 AI 沟通时，与其简单说“这里不对”，不如把原始发票、程序提取到的内容、自己期待的结果一起给它。

这样 AI 更容易定位问题，我也能更清楚地判断修改后究竟改善了什么。

这个过程也让我理解，AI 的价值不是按一下按钮就交付成品，而是让我有机会把原本不会编程也难以实现的想法，一步步做出来。

四、测试后才发现，问题不一定在代码

有一次，部分交通票据出现了识别异常。

起初看起来像是程序没有正确识别发票，但进一步检查发现，不同票据的字段设置和校验要求并不完全相同，原先的规则没有覆盖这些情况。

我便重新梳理需要核查的内容，再让 AI 协助调整处理逻辑。

这个经历提醒我：看到“识别失败”，不能马上认定只是提取技术出了问题，也可能是自己的业务规则考虑得不够完整。

另一次是在金额校验中。为了防止程序把票面上其他数字误当成金额，我要求增加交叉验证。

实际运行时，却出现了一批不符合预期的提示。

我把原始发票和异常结果交给 AI 分析，发现其中涉及小额金额的舍入差异，再通过调整和测试逐步完善判断方式。

不过，异常变少不等于核查一定更准确。

如果为了减少提示而放宽规则，也可能漏掉真正的问题。

所以我始终希望保留能够回头检查的结果，而不是让程序只输出一句“通过”。

目前，工具会把异常清单和金额汇总输出到 Excel。

我希望看到的不只是最终结论，还包括哪些发票需要关注，便于回头找到原始文件核对。

程序负责辅助筛查，遇到无法识别或存在疑问的发票，仍需要人工复核。

五、从一个尝试，到可以交给同事使用

随着反复修改，工具从最初能运行的程序，逐渐有了图形界面、文件夹选择、结果导出等功能，后来又打包成可以直接双击使用的程序，并写了使用说明。

这样，同事不需要懂 Python，也不用自己运行代码，只需选择文件、执行核查，再打开 Excel 查看结果。

后来我还考虑了操作中的细节，比如记住上次选择的路径、保留每次的核查结果，让软件更符合日常使用习惯。

对我来说，这个变化很有意义：它不再只是一道编程练习，而是一个能够放进实际工作流程的辅助工具。

当然，它并不是能处理所有发票的成熟产品。

先解决当前最常见、规则相对明确的问题，比第一版就追求面面俱到更实际。

六、没做的功能，也有下一步的思路

目前还有两个方向，是我想在以后继续探索的。

这一部分只是未来功能设想，并非已经实现。

其一，是图片型发票的识别。

现在工具主要处理可以直接提取文本的 PDF，对扫描件、拍照图片还不能完成同样的识别。

可以考虑引入 OCR：云端服务使用方便，但可能需要将发票上传到第三方服务器；本地离线方案则要考虑集成和维护成本。

发票中可能包含个人和企业信息，因此是否使用云端服务，必须先考虑数据安全。

目前大多数实际样本是文本型 PDF，基础功能已能覆盖一部分主要需求，所以我没有急着扩展图片识别。

不是能做的功能，都必须现在做。

其二，是让工具逐渐适应新的发票格式。

这让我想到不同银行的流水：文件格式各不相同，但我们最终要提取的日期、金额、交易对方等字段有共性。

发票也是如此，核心仍是抬头、税号、金额等信息和相应核查规则。

我希望以后建立统一的识别配置模板。

当遇到特殊发票时，可以通过与 AI 对话，让它辅助分析格式、生成候选规则；再经过样本测试和人工确认，把新规则加入工具。

至于通过大模型 API 或其他工具调用方式怎样实现，还需要继续探索。

这些设想未必马上落地，却让我感受到：随着自己不断学习，以前遇到的问题，可能会出现新的解决思路。

七、先做出来，才能谈得上继续完善

回头看，发票核查工具带给我最大的收获，不是掌握了某种编程技术，也不是做出了多么强大的产品，而是让我更具体地理解了怎样把想法落实。

一开始，我并没有考虑到所有特殊发票、图片识别或未来的 AI 规则配置。

如果非要等这些问题全部解决才开始，工具可能至今还停留在计划里。

正因为先从抬头、税号和金额做起，我才能在实际测试中发现问题，再与 AI 一起逐步改进。

我也越来越觉得，学习 AI 不只是学会提问、让它生成代码。

发现真实问题、拆解需求、判断结果、验证修改效果，这些能力才是自己需要持续锻炼的。

AI 能协助完成我暂时不擅长的技术工作，但不能代替我理解业务、决定目标和把关结果。

这也是我想开始记录这些实践经历的原因。

其实，做公众号分享这件事，我也考虑过一段时间，总想着再准备充分一点、再把内容打磨好一点。

但回头一想，这和当初做软件时的犹豫何尝不是一样？

我不想等到技术学得足够好、软件做得足够完善才分享，因为在学习和实践的过程中，那些遇到的问题、产生的想法，以及不断调整的思路，本身就是值得记录的东西。

目前工具主要支持文本型 PDF 发票的抬头、税号和票面金额核验。扫描件及部分特殊票据仍需人工复核，软件结果仅供辅助检查，不能代替人工判断。

如有需要，软件下载地址（蓝奏云）：

https://wwbuy.lanzouq.com/iyNdW4ekojif

密码：ersv

先把事情做出来，再让它在实践中逐渐变好。