92444e7eae
- 新增 25+ 条风险规则（预算/报销/申请/通用类），完善风险规则模拟与反馈发布机制 - 引入费用审批动态路由、平台风险分级、预审与风险阶段管理 - 预算中心列表化改造，优化票据夹仪表盘与数字员工工作看板 - 新增 Hermes 风险线索收集器、Agent 链路追踪中心 - 扩展数字员工能力库（18 个领域 Skill）与交通费用自动预估 - 完善报销申请快速预览、权限控制与前端测试覆盖
5.3 KiB
5.3 KiB
申请交通费用自动预估概念文档
功能一句话
在费用申请预览阶段，系统自动生成交通票价 mock 估算，并叠加现有住宿与补助标准，形成申请预估总费用，替代用户手动填写预估金额。
背景与问题
当前申请流程要求用户补充“用户预估费用”。对差旅申请来说，用户在申请阶段往往只能确认出行方式、目的地和天数，交通票价又暂时缺少正式票务接口支持，因此让用户手填金额会降低流程顺畅度。
本期先用系统估算补齐申请金额：
- 交通费用：按火车、飞机、轮船三类 mock 票价生成稳定估算。
- 住宿与补助：前端申请预览继续调用现有差旅规则测算，复用住宿上限和补助标准。
- 后端对话：当没有前端预览上下文时，用同口径的兜底估算生成金额，避免选择交通方式后继续追问金额。
目标与非目标
目标：
- 申请预览不再要求用户手动填写预估费用。
- 用户选择火车、飞机或轮船后，系统能生成交通费用估算。
- 预估总费用 = mock 交通费 + 住宿标准小计 + 补助标准小计。
- 预览、提交文本和后端对话统一展示“系统预估费用”。
- 保留用户明确输入金额时的兼容能力，不破坏历史提交链路。
非目标：
- 本期不接入真实机票、火车票、船票接口。
- 本期不做票价实时波动、余票、舱等、席别、折扣和路线中转算法。
- 本期不把 mock 估算作为最终报销金额，报销阶段仍应结合真实票据复核。
用户与场景
主要用户：
- 员工：在“申请/事前审批”环节快速发起差旅费用申请。
- 财务/审批人：查看申请金额是否由系统按标准测算生成。
典型场景：
- 用户输入“去上海出差 3 天，火车”。
- 系统识别地点、天数、出行方式。
- 系统 mock 生成火车往返票价。
- 系统调用现有差旅测算拿到住宿与补助小计。
- 系统在申请预览中展示系统预估费用，并允许进入确认提交。
功能能力
输入：
- 地点：用于差旅规则匹配和交通 mock 城市层级判断。
- 天数：用于住宿与补助小计。
- 出行方式：火车、飞机、轮船。
- 职级：沿用现有差旅测算接口的标准匹配入参。
输出：
- 交通费用口径：说明当前是 mock 票价估算，报销阶段按真实票据复核。
- 规则测算参考：展示交通、住宿、补助拆分与合计。
- 系统预估费用：写入申请金额字段，用于后续申请提交。
- 估算来源字段：记录 mock 交通估算和规则测算结果，便于后续审计解释。
边界：
- 缺少地点或天数时，仍不能完成住宿与补助测算，需要继续补齐基础字段。
- 缺少出行方式时，仍需用户选择火车、飞机或轮船。
- 后端纯对话流程没有前端规则测算结果时，使用保守的 mock 住宿/补助兜底。
方案设计
前端：
- 新增申请估算工具模块，集中维护交通 mock 票价、金额格式化和总额合成。
expenseApplicationPreview在差旅规则测算返回后，将交通 mock 金额叠加到住宿与补助小计。- 将
amount字段改为“系统预估费用”，并设为非手动必填字段。 - 申请提交文本使用系统生成的金额。
后端：
- 新增申请系统预估服务模块，避免继续向已经超过 800 行的
user_agent_application.py堆业务算法。 - 后端对话在基础字段和出行方式齐全时自动补
amount、transport_policy、policy_estimate。 - 缺失字段追问只保留基础字段和出行方式，不再追问预估金额。
数据与接口：
- 不新增数据库字段。
- 不新增外部接口。
- 申请详情仍通过现有
risk_flags_json.application_detail保存展示字段。
算法与公式
交通费用采用稳定 mock：
transport\_amount = round\_10(base(mode, location) \times 2)
其中 mode 为火车、飞机、轮船，location 用于判断一线/远途/沿海等粗粒度场景，默认按往返估算。
总费用：
estimated\_total = transport\_amount + lodging\_amount + allowance\_amount
前端的 lodging_amount 和 allowance_amount 来自现有差旅规则测算结果；后端兜底时按 mock 标准生成。
测试方案
- 前端单测：验证交通 mock、规则测算合计、行标签和提交文本。
- 后端单测：验证选择交通方式后不再追问金额，而是直接生成预览。
- 编排流测试：验证申请会话从补充出行方式直接进入确认，再提交成功。
- 回归测试：用户明确输入金额时仍能提交，并保留兼容链路。
指标与验收
- 用户选择出行方式后，系统不再提示“用户预估费用”缺失。
- 申请预览中出现“系统预估费用”。
- 规则测算参考包含交通、住宿、补助三项拆分。
- 前端定向测试和后端申请流程测试通过。
风险与开放问题
- mock 票价不代表真实票价，只适合作为申请阶段预算参考。
- 后端兜底住宿/补助不能完全替代规则中心，前端有规则测算结果时应优先使用规则中心。
- 后续接入真实票务接口后，应替换交通 mock 模块，不改变申请预览和提交的数据契约。