X-Financial Model Proposal

预算费用规划推荐模型方案

这个模型不只是给审批页打一个分，而是把“预算是否够、费用是否合理、是否影响预算节奏、下一步该怎么处理”整理成可解释、可审计、可持续迭代的推荐结果。

规则模型优先硬约束可审计 LLM 只做解释层审批反馈可回流

模型主目标 帮预算管理者快速判断是否可承接

Recommend

第一版边界 不替代人工审批，不让 LLM 直接做硬判断

Guarded

核心口径 扣除当前申请已预占，避免重复计算

Traceable

迭代方向 规则评分 + 历史基准 + 解释生成

V1 → V3

方案结论

建议把模型定位为“预算审批辅助决策引擎”，输出结构化推荐和解释依据，而不是单纯的页面分数。

Executive Summary

推荐动作

4 类

建议通过、谨慎通过、需要复核、不建议直接通过。

核心评分

100 分

预算安全优先，费用必要性与信息完整度共同影响。

硬性约束

3 条

超预算、强阻断控制、预算池无法匹配必须显式处理。

上线策略

分阶段

先确定性规则，再接入历史基准和解释层。

推荐采用的产品口径： 分数不是结论本身，结论应由“推荐动作 + 风险等级 + 触发依据 + 可执行建议”共同表达。

需要避免的方向： 不要让 LLM 直接判断是否通过，也不要只用一个综合分覆盖预算、业务必要性、历史异常等不同原因。

业务闭环

模型要服务完整预算链路：预算池建立、申请预占、审批推荐、报销核销、结果反馈。

Business Loop

1 预算计划建立 按部门、项目、科目、成本中心形成预算池和预警线。

2 费用申请预占 申请提交后先占用预算，避免后续审批期间额度被重复使用。

3 预算审批推荐 预算管理者看到风险等级、计算依据、建议动作和补充要求。

4 报销与核销 申请通过后生成报销草稿，实际报销后转为已核销金额。

5 结果反馈回流 记录审批采纳、驳回原因、实际报销差异，反哺后续规则。

模型架构

采用“上下文构建 → 特征计算 → 硬约束判定 → 综合评分 → 推荐解释 → 反馈沉淀”的分层结构。

Model Layers

上下文层

统一组装申请单、预算池、历史费用、项目计划和审批身份，形成模型输入快照。

复用 build_claim_budget_context() 的预算上下文。
补充申请事由、地点、费用类型、项目编号、附件摘要。
保留计算时刻的预算快照，方便事后审计。

特征层

把业务数据转换成可解释特征，而不是直接把原始字段丢给模型。

预算容量：审批前可用、审批后使用率、超预算金额。
单笔影响：本次金额占预算比例、是否突破预算节奏。
必要性证据：事由、项目、地点、附件、业务场景是否完整。
历史基准：同部门、同项目、同费用类型的历史均值和波动。

决策层

先执行硬规则，再计算综合分，确保强管控场景不会被其他维度“平均掉”。

硬规则：超预算、预算池阻断、预算无法匹配、关键字段缺失。
综合评分：预算安全、费用影响、规划匹配、历史异常、信息完整。
分档输出：recommended、caution、review、block、reference。

解释层

第一版直接用模板解释；后续允许 LLM 改写语气，但不能改写分数、等级和硬性结论。

解释必须引用结构化依据，不允许凭空补充原因。
建议要能变成审批动作，例如补充材料、拆分费用、调整预算。
所有展示文案保留对应的 basis_code，方便追踪。

数据与特征

模型输入需要覆盖“预算是否够”和“费用是否该花”两条线，避免只看额度、不看业务必要性。

Feature Design

预算上下文

budget_applicable：是否纳入预算管控。
matched：是否匹配到预算池。
total_amount、reserved_amount、consumed_amount。
current_reserved_amount：当前申请已预占金额。
warning_threshold、control_action。

申请单主数据

申请金额、费用类型、申请事由。
业务地点、项目编号、成本中心。
直属领导意见、附件摘要。
申请时间、期望发生时间、是否紧急。

增强特征

同类费用历史均值与分位数。
部门剩余预算消耗速度。
项目里程碑与预算计划匹配度。
申请人近期预算占用频次。

预算容量单笔影响预算节奏业务必要性历史异常信息完整度审批反馈

计算口径

申请提交时已经发生预算预占，所以审批分析必须扣除当前申请已预占金额，避免重复计算。

Calculation

已使用基数 = 已预占金额 + 已核销金额 - 当前申请已预占金额
审批前可用预算 = 预算总额度 - 已使用基数
审批后占用 = 已使用基数 + 本次申请金额
此次费用占预算 = 本次申请金额 / 预算总额度
审批后使用率 = 审批后占用 / 预算总额度
超预算金额 = max(本次申请金额 - 审批前可用预算, 0)

关键原则 如果当前申请在提交阶段已经进入 reserved_amount，审批页就不能再把它当成新增占用直接叠加。否则预算管理者看到的风险会被放大，尤其是大额申请会明显失真。

评分推荐

建议采用“硬规则优先 + 加权评分”的组合。硬规则决定是否必须复核或阻断，评分用于排序和解释风险程度。

Decision Strategy

建议权重

预算安全：40 分，覆盖可用额度、审批后使用率、超预算金额。
单笔影响：18 分，判断本次费用对预算池的冲击。
规划匹配：16 分，比较项目计划、预算周期和费用发生时间。
历史基准：14 分，识别同类费用异常偏高或频繁占用。
信息完整：12 分，衡量事由、项目、地点、附件是否足够。

recommended

85-100

预算充足、信息完整、费用影响可承接，建议通过。

caution

70-84

预算可承接但影响较明显，建议谨慎通过并关注后续节奏。

review

50-69

存在信息缺口、历史异常或接近预警线，需要复核。

block

0-49

超预算或触发强管控动作，不建议直接通过。

硬规则示例： control_action = block 且超预算时，直接进入 block；预算池未匹配时输出 reference，不能伪装成低风险。

推荐动作要具体： 不只写“需关注”，而要给出“补充业务必要性、拆分费用、调整预算池、发起预算调剂”等可执行动作。

申请人费用画像公式

画像只用于调整复核强度和审核建议，不能直接把申请人定义为“异常人员”。核心是用同组基准解释个人费用节奏是否偏离。

Applicant Profile

申请人画像风险分 =
  高频申请分 * 20%
+ 高金额占用分 * 25%
+ 同组偏离分 * 25%
+ 历史调减退回分 * 15%
+ 本次申请偏离分 * 15%

等级：
0-39   正常
40-59  需关注
60-79  重点复核
80-100 强复核 / 升级审批

同组基准口径 同组不按全公司粗暴比较，而应按 部门 + 岗位 + 费用类型 + 城市等级 + 项目类型 + 近 90/180 天 聚合。销售、项目经理和研发不能混在一个基准池里比较。

出差天数建议

同类基准天数 = peer_group.travel_days_p75
天数偏离率 = 本次出差天数 / 同类基准天数
建议天数 = min(
  本次出差天数,
  同类基准天数 + 业务缓冲天数
)

当偏离率超过 1.5 时，建议补充行程安排或压缩天数；超过 2.0 时进入重点复核。

出差费用建议

本次日均费用 = 本次申请金额 / 本次出差天数
日均费用偏离率 =
  本次日均费用 / 同城市同职级日均基准
建议金额上限 =
  建议天数 * 日均基准 * 容忍系数

容忍系数第一版建议使用 1.15 到 1.20，避免模型因为小幅波动给出过硬建议。

招待费用建议

人均招待金额 = 本次招待金额 / 参与人数
人均偏离率 = 人均招待金额 / 招待标准上限
同客户招待频率 = 近 90 天同客户招待次数
个人招待分位 = 个人近 90 天招待金额在同组分位

人均偏离率超过 1.2 时建议调低标准；同客户 90 天内多次招待时要求补充客户推进阶段。

建议生成公式： 审核建议强度 = max(画像风险等级, 本次偏离等级, 硬规则等级)。展示时必须说明是哪一类指标触发，而不是只给一个结论。

审核建议示例： “该申请人近 90 天费用占用处于同组 P88，本次出差天数为同类 P75 的 1.67 倍。建议将 5 天调整为 4 天，或补充客户拜访安排和项目阶段说明。”

输出协议

接口输出需要同时服务审批页展示、看板统计和后续审计，因此自然语言必须和结构化字段分开。

API Contract

{
  "score": 82,
  "rating": "caution",
  "risk_level": "medium",
  "recommendation": "cautious_approve",
  "summary": "预算整体可承接，但本次费用对预算池已有明显影响。",
  "metrics": {
    "claim_amount": "12000.00",
    "total_amount": "50000.00",
    "available_before_approval": "38000.00",
    "claim_amount_ratio": "24.00",
    "after_usage_rate": "72.00",
    "over_budget_amount": "0.00"
  },
  "applicant_profile": {
    "profile_score": 66,
    "profile_level": "review",
    "peer_percentile": 88,
    "travel_days_ratio": "1.67",
    "daily_cost_ratio": "1.34",
    "suggested_days": 4,
    "suggested_amount_cap": "6800.00"
  },
  "evidence": [
    {
      "basis_code": "budget.after_usage_rate.warning_near",
      "text": "审批后预算使用率为 72.00%，接近预警区间。"
    }
  ],
  "suggested_actions": [
    {
      "action": "approve_with_note",
      "text": "可继续审批，但建议备注本次费用对应的项目阶段和后续预算节奏。"
    }
  ],
  "explainable_snapshot": {
    "budget_no": "BUD-TEST",
    "control_action": "warn",
    "warning_threshold": "80.00"
  }
}

审批展示

预算管理者最需要看到的是“为什么是这个建议”和“如果要通过，还要补什么”。页面不应只展示一个分数。

Approval UX

顶部结论条 展示推荐动作、风险等级、综合分和一句话摘要，例如“谨慎通过：预算可承接，但审批后使用率接近预警线”。

关键指标 本次金额、预算总额、审批前可用、审批后使用率、超预算金额。

触发依据 逐条展示规则依据，保留 basis_code，方便定位到模型逻辑。

建议动作 通过、谨慎通过、补充材料、拆分费用、预算调剂、退回修改。

申请人费用画像 展示近 90 天频率、金额分位、天数偏离率和建议压缩区间，只作为审批参考。

审批反馈 记录预算管理者是否采纳建议，以及不采纳时的原因。

落地路线

先把确定性口径做稳，再逐步接入历史基准和解释层，避免第一版就变成难以审计的黑盒。

Implementation

P0：口径对齐

确认预算预占、审批前可用、审批后占用的计算口径。

梳理预算上下文字段。
固化不重复计算规则。
定义输出协议。

P1：规则评分

上线可审计的确定性模型，覆盖预算审批主流程。

实现特征计算。
实现硬规则和分档。
补齐单元测试。

P2：历史基准

引入同类费用历史均值、部门消耗速度和预算节奏。

沉淀历史统计任务。
增加异常检测特征。
看板展示采纳率。

P3：解释增强

在结构化依据上增加 LLM 文案层，提升可读性。

LLM 不改分数和等级。
解释引用 basis_code。
增加人工反馈闭环。

验收清单

下面的清单会保存在当前浏览器本地，方便后续评审和开发跟踪。

Checklist

输出协议稳定 评分、等级、推荐动作、指标、依据、建议动作都有结构化字段。 预算预占不重复计算 测试覆盖当前申请已预占、未预占、部分预占三类场景。 硬规则不可被平均抵消 超预算和 block 控制动作必须进入高风险或阻断建议。 审批页展示可解释 预算管理者能看到风险原因、计算指标和可执行下一步。 申请人画像公式可审计 同组基准、偏离率、建议天数、建议金额上限都能追溯到结构化字段。 审批反馈可回流 记录采纳、覆盖、退回、预算调剂等结果，为后续模型迭代准备数据。 LLM 边界清晰 LLM 只改写解释文案，不参与硬性通过、阻断和预算额度计算。