在个人理财与小型企业财务管理场景中，收据、发票与交易记录的结构化提取一直是自动化处理的难点。传统基于正则表达式的解析方案在面对格式多样、语言差异、票据损毁等复杂情况时往往力不从心。TaxHacker 作为一款开源自托管 AI 会计应用，通过将大语言模型引入收据解析流程，实现了从非结构化票据图像到结构化财务数据的端到端自动化。本文将深入剖析其 Prompt 工程策略与分类管道架构，为构建类似系统提供可落地的工程参考。
TaxHacker 系统架构概览
TaxHacker 采用现代化的技术栈构建：前端与 API 层基于 Next.js 15+，数据持久化使用 PostgreSQL 配合 Prisma ORM，AI 能力则通过可插拔的 LLM 提供商实现 [1]。系统支持 OpenAI、Google Gemini 和 Mistral 三大主流模型，用户可根据成本与隐私需求灵活选择。这种架构设计确保了核心业务逻辑与具体模型实现的解耦 —— 当新模型发布或现有模型定价策略调整时，只需更换适配器而无需改动上层业务代码。
在数据流层面，TaxHacker 的处理管道遵循清晰的阶段划分：用户上传收据图片或 PDF 文档后，系统首先通过 OCR 引擎提取原始文本，随后进入 AI 增强的解析阶段，由 LLM 根据预定义或自定义的提示词从原始文本中抽取关键字段，最后进行数据验证、货币转换与分类归集。这一流程的每个阶段都设计为可独立配置与扩展的模块，使得系统既能满足开箱即用的简单需求，也能适应高度定制化的专业场景。
Prompt 工程策略：从系统提示到字段级抽取
TaxHacker 在 Prompt 工程方面提供了极为灵活的分层配置机制。系统级别的提示词模板定义了 AI 如何理解财务文档的通用框架，用户可以在设置中修改这一基础提示以适配特定的业务规范。更为强大的是，系统支持为特定字段或项目创建专属的抽取规则，这意味着不同类型的文档可以采用完全不同的解析策略。
在实际的收据解析场景中，有效的 Prompt 设计通常包含以下几个核心要素：首先是明确的任务指令，清晰告知模型需要从文档中提取哪些信息；其次是输出格式规范，强制要求模型以 JSON 结构返回结果，便于后续程序解析；再者是上下文约束，通过示例或规则边界帮助模型理解特殊情况的处理方式。例如，针对商户名称字段，提示词可以包含「标准化商户名称，统一使用官方注册名称而非简称」这样的约束条件；针对金额字段，则可以指定「优先识别小计栏金额，若无小计则使用总计，并标注识别置信度」的处理逻辑。
TaxHacker 还引入了自定义字段的概念，用户可以像在 Excel 中添加新列一样创建任意数量的扩展字段，并为每个字段编写独立的 AI 抽取规则 [1]。这一设计极大地拓展了系统的适用性 —— 无论是提取特定的税务编号、项目代码，还是记录与特定行业相关的自定义信息，都可以通过 Prompt 配置来实现。
模块化分类管道：渐进式数据 enriching
TaxHacker 的分类管道采用了渐进式数据 enriching 的架构思路，将复杂的收据解析任务拆解为多个独立但协同的子任务。每个子任务专注于处理特定维度的信息，通过流水线式的处理逐步将原始 OCR 输出转化为结构化的财务记录。这种设计的优势在于降低了单个 Prompt 的复杂度，提高了每个阶段的可测试性与可维护性，同时便于针对特定类型的错误进行定向优化。
具体而言，分类管道通常包含以下核心阶段：商户信息标准化阶段负责将识别出的商户名称进行规范化处理，统一使用官方注册名称或行业通用简称；日期时间解析阶段负责将各种格式的日期字符串转换为 ISO 标准格式，同时处理时区与夏令时等边缘情况；金额与税费提取阶段负责从复杂的票据布局中准确定位总额、税费、折扣等财务字段，并处理多币种识别与汇率转换；项目明细抽取阶段负责从发票中提取具体的商品或服务明细，包括数量、单价、行总计等信息。
在分类层面，TaxHacker 提供了完全可自定义的分类体系 [1]。系统内置了常见的支出类别如餐饮、交通、办公用品等，但用户可以根据自身业务需求创建任意数量的自定义分类。更重要的是，分类决策同样由 AI 驱动 —— 模型会根据收据内容自动判断所属类别，用户也可以为特定类别编写专属的分类提示词以提高准确性。这种 AI 驱动的自动分类机制大大减轻了手工归集的工作量，同时通过持续的人工校正反馈可以不断提升分类准确率。
货币转换与多币种处理
TaxHacker 的多币种支持是其差异化亮点之一。系统能够自动识别票据中使用的货币类型，并基于交易发生日期的历史汇率将其转换为基础货币 [1]。这一功能对于跨境业务或经常接触外币票据的自由职业者尤为实用。系统支持超过 170 种法定货币以及 14 种主流加密货币，包括 BTC、ETH、LTC 和 DOT 等。汇率数据的来源与更新机制确保了转换结果的准确性，用户也可以在自动转换结果不满意时进行手动调整。
部署与配置参数
对于希望自托管 TaxHacker 的用户，系统提供了开箱即用的 Docker 部署方案。生产环境推荐使用 PostgreSQL 17 及以上版本，核心环境变量包括：数据库连接字符串 DATABASE_URL、上传文件存储路径 UPLOAD_PATH、应用端口 PORT（默认 7331）以及认证密钥 BETTER_AUTH_SECRET（至少 16 字符）。在自托管模式下，系统启用自动登录与自定义 API Key 等增强功能，同时支持禁用新用户注册以控制访问范围。
LLM 提供商的配置同样通过环境变量或应用内设置完成。OpenAI 用户需要设置 OPENAI_MODEL_NAME 与 OPENAI_API_KEY；Google Gemini 用户需要配置 GOOGLE_MODEL_NAME 与 GOOGLE_API_KEY；Mistral 用户则对应 MISTRAL_MODEL_NAME 与 MISTRAL_API_KEY。这种配置方式的灵活性使得用户可以在不同模型之间进行 A/B 测试，以找到成本与准确性的最佳平衡点。
实践建议与监控要点
在生产环境中部署类似的 LLM 收据解析系统时，建议关注以下监控指标：OCR 阶段的识别置信度分布，当低置信度结果占比超过阈值时应考虑优化图像预处理或更换 OCR 引擎；LLM 解析阶段的字段缺失率与格式错误率，这反映了 Prompt 设计的有效性；分类决策的一致性与人工校正比例，用于持续优化分类提示词。此外，实现异步任务队列处理机制可以有效应对 OCR 或 LLM 服务的临时不可用情况，通过重试与升级策略确保系统的可靠性。
TaxHacker 作为开源项目的实践表明，基于 LLM 的收据解析方案已经在工程成熟度上达到了可生产使用的水平。其模块化的管道设计、分层的 Prompt 配置机制以及完善的自托管支持，为构建同类应用提供了值得借鉴的架构参考。随着模型能力的持续提升与推理成本的进一步下降，AI 驱动的财务文档自动化处理有望成为小型企业财务管理的主流选择。
资料来源：本文技术细节主要参考 TaxHacker GitHub 仓库文档 [1]。