日常工作知识库

Appearance

58智能报销审批：Dify 工作流与提示词资产自动化流水线标准作业说明 ​

归类：大模型应用开发 / Dify 工作流 / 财务智能审批 发生时间：2026-06-04 状态：✅ 已落地

一、问题背景 ​

在 58 财务智能报销审批（如“市内交通费”、“快递物流费”等场景）的演进过程中，传统以“纯大模型”直接理解庞杂财务规章并进行多指标判定的做法，面临着诸多工程痛点：

  1. 时间校验幻觉严重：大模型对相对日期（如“近3个月效期”）和特定敏感打车时段（如 18:00 - 22:00 全天硬禁）的物理计算极其脆弱。
  2. 规则频繁变更成本高：财务审核规则（比如夜间出行时间的放宽或收紧）调整频繁。如果将规则直接硬编码在 Java/C++ 服务端，每次规则变动都必须经历繁琐的代码修改、测试和发版流程；而直接在 Prompt 中修改，又容易引入大模型推理不稳定的风险。
  3. 资产管理混乱：同一个费用类型的 Dify 工作流在开发、测试和生产线上存在多个零散版本，缺乏统一的版本管理和迭代追溯体系。

二、核心设计思想：Agentic 混合审计架构 ​

为了解决上述痛点，我们设计了 “本地高精度预计算 + 大模型决策网关” (Agentic Hybrid Audit Architecture) 的混合审计架构，将计算部分交由确定性的代码逻辑（如 Python/Java 节点），将决策、敏感词过滤和语义判别部分交由大模型。

1. 混合计算拓扑设计 ​

工作流由以下三大核心节点构成：

  • 入参层：收集报销单申请人、申请日期、发票明细、行程单明细、费用描述、以及控制变量（如 isAuditTime 白名单免审变量）。
  • 计算层 (Python/Java 节点)：通过确定性代码计算金额是否一致、打车单据是否超出 3 个月时效、是否命中休息日及 18:00 - 22:00 硬禁打车窗口，并将这 4 类事实比对结果输出为标准 JSON 格式。
  • 决策层 (LLM 决策网关)：大模型（选用 Lingxi-2.0-Turbo 等模型）不直接做复杂的日期差值计算，而是专注于读取计算层给出的事实 JSON，并结合“费用描述”中的语义（如白名单过滤、敏感词检验），输出最终的决策结论和结构化话术。

三、方法论：双端资产同步与流水线自动化 ​

在开发过程中，为了将“提示词开发”与“平台部署 YML 资产”安全解耦，我们建立了一套规范驱动开发（SDD）与自动化打包流水线。

1. 规范仓与原型仓的双端分工 ​

  • 规范仓 (finance-spec)：作为提示词 Prompt 的唯一真实事实来源。所有提示词的 Markdown 源代码（如 logic_audit_prompt_slim_v2.md）必须在 finance-spec/prompts/ 目录下集中编写和版本化管理。
  • 原型仓 (finance-proto)：作为前端交互原型和测试 YAML 的托管中心。存放用于发布给 Dify 的 YML 配置文件。

2. YAML 自动装配流水线 ​

严禁通过手工复制粘贴 Prompt 到 YML 中！我们通过各费用类型目录下的编译脚本（如 generate_dify_workflow.py）进行自动化编译：

python
# 核心装配逻辑示例
# 1. 自动读取规范仓的 Prompt 源文件
prompt_content = read_file("finance-spec/prompts/市内交通费/logic_audit_prompt_slim_v2.md")

# 2. 读取 Dify 导出的原始工作流模板配置
template_yaml = read_yaml("test-dify/审批/template.yml")

# 3. 定位到 LLM 节点，动态替换其 system_prompt 字段
template_yaml['workflow']['nodes'][llm_node_idx]['data']['prompt_template'] = prompt_content

# 4. 在 YML 的 app.description 和头部注释中动态写入本次编译的业务版本号
template_yaml['app']['description'] = f"【v2.1.1】修复白名单失效缺陷。编译于 {current_time}。"

# 5. 生成对应的测试版、沙箱版 YML 并自动清理旧文件
write_yaml(template_yaml, "test-dify/审批/沙箱版_市内交通费审批_v2.yml")

四、标准化作业说明 (SOP) 与版本管理 ​

SOP 步骤 1：新建或重构费用类型 ​

  1. 在规范仓 finance-spec/prompts/ 下新建对应费用分类（如：差旅报销费）。
  2. 使用 CO-STAR 框架在目录下编写提示词文件。

SOP 步骤 2：规则定义与预计算匹配 ​

  1. 在原型仓中新建对应的预计算引擎代码，确定事实比对字段（如 amountMatched, timeWindowViolation 等）。
  2. 在 Prompt 文件的 Input Data Schema 部分约定该 localCalcResult JSON 协议。

SOP 步骤 3：多环境 YAML 生成与同步 ​

  1. 运行对应目录下的生成脚本：
    bash
    python3 generate_dify_workflow.py
  2. 检查输出路径是否统一规范地存放在 test-dify/审批/ 或 test-dify/提取/ 目录下。

SOP 步骤 4：严格的变更控制与双端 Changelog ​

任何资产更新必须遵循以下版本号递增原则（根据工作区全局规约 GEMINI.md）：

  • 主版本 (X)：流程架构级重构（如 V1 单大模型判决 -> V2 混合审计架构）。
  • 次版本 (Y)：大财务业务规则增减（如新增加班打车 18:00 - 22:00 硬禁限制）。
  • 修订号 (Z)：格式调整或微调（如 Few-Shot 示例补全变量、打错字的文字修正）。

同时必须自动更新并同步追记两端的 CHANGELOG.md：

  • finance-spec/prompts/[费用类型]/CHANGELOG.md
  • finance-proto/.../[费用类型]/test-dify/[审批或提取]/CHANGELOG.md

五、前端对接与逻辑豁免展现最佳实践 ​

在向用户展现报销预计算判定结果时，如果入参激活了白名单免审状态（如 isAuditTime="false"）：

  1. 底层强规避：预计算引擎在底层将违规数组直接返回空（violatingTimes: []），LLM 根据白名单前置分支输出 白名单免审日期与时间 结论。
  2. 前端视觉隔离：前端渲染页面时，应检测 isAuditTime === 'false'。如果是，则将对应的 Rule 2-A/2-B/4 的 Tag 统一渲染为灰色的 “白名单免审” 状态，避免在界面上产生“仍在强行比对”的理解偏向，提升审计流程的公信力。

六、预防建议 ​

  1. Prompt 调试隔离：避免直接在 Dify 在线网页的可视化画布里随意增删 Few-Shot 和修补 Prompt。所有 Prompt 改动必须在规范仓 Markdown 源文件中调试完毕并重新编译，确保配置即代码（Config as Code）。
  2. 慎用金额累加逻辑：针对一笔报销单包含多个明细单据的场景，在提示词中必须写明“严格进行 1:1 单笔对齐”，严禁大模型擅自将多张发票做金额求和后来匹配行程，以防出现金额错配的幻觉。