44 KiB
44 KiB
AI 费用闭环与价值证明 概念文档
更新时间:2026-07-14
文档路径:document/development/2026-07-13/feature/ai-expense-closed-loop-and-value-proof/CONCEPT.md
功能一句话
把申请、消费、票据、报销、审批、付款、入账、分析和持续学习连接成同一个费用事件,让员工少填表、审批人只处理例外、财务能确认真实节省,并让 AI 在可控边界内越用越准确。
背景与问题
- 当前现状:项目已经具备费用申请、AI 建单、票据夹、OCR、预算检查、风险预审、动态审批、员工画像、财务看板、知识库、Agent trace、反馈表和 few-shot 样本等较完整的功能骨架。容器运行时 OpenAPI 已覆盖 156 个业务操作,功能广度已经足够。
- 用户痛点:申请、票据、报销、审批和分析仍以多个页面、多个服务和多套状态存在。用户需要在不同入口之间理解系统,而不是由系统主动接住费用事件;移动端主流程仍有 mock;审批通过后的真实付款、回执、ERP 凭证和对账没有形成完整闭环。
- AI 痛点:当前系统能够记录会话、运行轨迹、风险反馈和员工画像,但没有统一记录“AI 建议了什么、用户改了什么、后来是否退回、最终是否付款或产生节省”。AI 能看到历史,却不能稳定把业务结果转化为下一次的个性化、自动化和风险校准。
- 企业痛点:现有看板主要回答花了多少、预算用了多少、发现了多少风险,尚不能可信回答省了多少钱、为什么省、哪些建议被执行、哪些费用仍可优化。
- 工程问题:旧
ReimbursementRequest与当前ExpenseClaim能力重叠,申请与报销又复用部分字段和 JSON 标记;审批、预算、付款、归档和关系引用部分混入risk_flags_json,不利于事务一致性、事件追溯和持续演进。 - 商业影响:如果不能持续证明处理效率、风险改善和真实节省,产品只能按“报销工具”定价;如果能形成价值闭环,则可以扩展为智能风控、预算经营、价值洞察和企业集成平台。
- 为什么现在需要做:现有模块已经足够支撑一条完整费用闭环,下一阶段继续横向新增页面会扩大编排和数据割裂。应先收口费用领域、业务事件、AI 决策、学习记忆和节省归因,再逐步开放自动化。
相关既有方案:
document/development/2026-07-03/feature/ai-data-flywheel/CONCEPT.md:作为本功能的 AI 样本回流、评测门禁、Prompt 版本和 Canary 子能力,不重复建设。document/development/AI意图规划器/UNIFIED_GATE_PIPELINE.md:作为 AI 场景识别和后端唯一编排入口的架构前置,不在前端继续增加影子门控。
目标与非目标
目标
- [G1] 建立统一
Expense Case,把一次费用从需求表达、申请、票据、报销、审批、付款、入账到归档视为同一业务事件。 - [G2] 建立零录入报销体验,自动匹配申请、预算、票据、费用类型、项目、成本中心和历史偏好,让用户主要核对异常项。
- [G3] 建立按动作授权的安全自动化等级,从解释、建议、预填、可逆自动化逐步升级到低风险直通。
- [G4] 建立“AI 决策 → 用户反馈 → 工作流结果 → 分层记忆 → 再决策”的学习闭环。
- [G5] 建立节省机会、执行任务、实际结果和财务确认组成的 Savings Ledger,区分风险暴露、预计节省和已实现节省。
- [G6] 建立从描述性统计到异常归因、预算预测、供应商分析、政策模拟和节省任务的费用经营分析能力。
- [G7] 建立企业租户、用量计量、模型成本和客户价值指标,为年度订阅、用量超额和增值模块提供可审计基础。
- [G8] 保持高风险动作、资金支付、制度发布和敏感主数据变更的人为授权、审计和回滚能力。
非目标
- [NG1] 本轮不自建商旅、企业卡、银行或支付供应链网络,只定义标准连接器和业务事件契约。
- [NG2] 本轮不一次性替换所有现有报销接口;先建立统一费用事件和旁路事件账本,再分阶段迁移旧模型。
- [NG3] 本轮不做模型微调或无监督自训练,优先使用结构化反馈、few-shot、规则学习、Prompt 版本和回归门禁。
- [NG4] 本轮不允许 AI 无人值守执行资金支付、高风险批准/驳回、制度发布和收款账户变更。
- [NG5] 本轮不同时覆盖所有费用场景,首个试点只选择一个高频、可测量、可闭环的场景。
- [NG6] 本轮不做未经授权的跨租户学习和企业间明细 Benchmark;后续只允许严格聚合、隐私保护并获得授权的对标能力。
- [NG7] 本轮不把风险关联单据总额、暂缓付款金额或未采纳建议直接计为企业节省。
用户与场景
目标用户
- 报销人/申请人:少填字段、少整理票据、少补件、少追问进度。
- 审批人:只处理必要性、例外和高风险问题,快速获得证据与建议。
- 财务运营:减少重复审核、退回、对账和月末整理,集中处理异常。
- CFO/管理层:了解费用增长原因、预算趋势、节省机会和实际 ROI。
- 风控/审计:查看规则依据、风险证据、算法版本、人工覆盖和审计结果。
- 系统管理员/IT:配置租户、组织、权限、连接器、数据保留、模型成本和自动化上限。
使用入口
- AI 工作台自然语言入口。
- 统一费用事件详情页。
- 移动端拍票、报销和审批入口。
- 票据夹和自动票据收件箱。
- 审批例外工作台。
- CFO 费用价值看板。
- AI 记忆与自动化策略设置。
核心场景
- 员工说“下周去上海出差三天”,系统自动生成合规申请、预算影响和可选节省方案,用户核对后提交。
- 消费期间,邮箱发票、拍照票据、企业卡或商旅订单进入统一票据收件箱,系统按时间、金额、地点和商户自动归集到费用事件。
- 行程结束后,系统自动生成报销草稿,只要求用户处理缺票、归属或异常金额。
- 提交前,系统按事实、规则、证据和风险等级给出绿色通过、黄色修正、红色复核结果。
- 审批人看到预算影响、历史相似单、政策依据、风险证据和建议意见,低风险单据进入快速通道。
- 财务完成付款、回执、ERP 凭证和对账,所有结果回写费用事件并形成审计链。
- 月末系统识别预算超支、供应商价格漂移、重复采购、异常路线和流程瓶颈,生成有负责人和目标金额的节省任务。
- 用户修正字段、审批人覆盖建议、财务确认误报或节省结果后,系统更新用户、部门和企业记忆,下次减少重复操作。
异常场景
- OCR、模型、向量检索或外部连接器不可用时,回退到人工录入或稳定规则,不阻塞草稿保存和主链路。
- 票据、申请或费用事件匹配置信度不足时,只展示候选,不自动绑定。
- 企业规则与个人偏好冲突时,企业规则优先,必须解释冲突原因。
- 高风险、超金额阈值、敏感账户变更或证据不足时,强制人工确认。
- 自动化动作失败时必须幂等、可重试、可撤销,并保留错误状态和操作证据。
- 预计节省没有财务确认或实际结果时,只能标记为机会,不得计入客户 ROI。
功能能力
- [C1] 费用事件能力:统一表达申请、消费、票据、报销、审批、付款、入账和归档关系。
- [C2] 零录入能力:自动抽取并匹配申请、预算、票据、费用类型、项目、成本中心、参与人和历史偏好。
- [C3] 预审与修复能力:输出事实、规则、证据、判断和建议动作,并提供一键补件、修正和解释入口。
- [C4] 审批例外能力:风险分级、证据摘要、预算影响、推荐路由、意见草稿、批量处理、委托、转交、加签和超时升级。
- [C5] 支付入账能力:以连接器方式接收付款批次、支付回执、ERP 凭证、银行流水和对账结果。
- [C6] 学习记忆能力:记录 AI 建议、用户修改、审批覆盖、退回、付款和审计结果,形成用户、部门、企业三级记忆。
- [C7] 自动化策略能力:按动作、金额、场景、风险、置信度、证据、可逆性和抽检率配置自动化等级。
- [C8] 节省价值能力:把节省机会、建议动作、负责人、目标时间、预计节省、实际节省和财务确认形成闭环。
- [C9] 费用经营能力:费用结构、预算预测、异常归因、供应商分析、政策模拟、流程成本和客户 ROI。
- [C10] 商业计量能力:企业租户、套餐、配额、用量、模型/OCR 成本、增值模块、客户贡献毛利和价值证明。
- [C11] 状态与权限:服务端认证、租户隔离、角色权限、动作授权、审计日志和敏感数据保留策略。
- [C12] 边界与降级:外部依赖失败时主链路可用;高风险动作始终保留人工控制;所有学习与自动化可关闭、遗忘或回滚。
方案设计
前端
统一费用事件
- 新增或重构费用事件详情容器,不再让用户理解申请单、票据夹、报销草稿、审批单和付款状态之间的内部关系。
- 页面按“计划 → 消费 → 报销 → 审批 → 付款/入账 → 复盘”展示时间线和当前待办。
- 每个 AI 填充字段显示来源、置信度和修改入口;低置信度字段集中进入“需要确认”区。
- 退回、补件和断点续办直接回到对应问题,不要求用户重新开始对话。
移动端
- 把拍照、相册选票、报销列表、审批列表和 AI 助手接入真实后端。
- 支持离线拍票、失败重试和后台上传状态。
- 未实现能力必须隐藏或明确标为不可用,不保留无响应的主按钮。
审批例外工作台
- 以风险、金额、预算影响、等待时长和证据完整度排序。
- 支持批量处理低风险事项,行内保留真实按钮和键盘可访问入口。
- 高风险审批展示模型版本、规则版本、政策依据、证据和人工覆盖原因。
CFO 价值看板
- 首页优先展示财务确认现金节省、已核验工时价值、安全智能直通率和重大风险护栏。
- 支持按部门、项目、费用类型、供应商、城市、时间和费用事件下钻。
- 每项节省可打开来源、基线、建议、执行、确认和去重证据。
AI 记忆与自动化设置
- 用户可以查看“系统记住了什么、为什么记住、在哪里使用”,并支持修改、忘记和关闭个性化。
- 企业管理员配置部门/企业记忆边界、有效期、敏感等级和自动化上限。
后端
费用领域与编排
- 新增
ExpenseCaseService作为跨阶段编排入口,避免继续扩大万能ExpenseClaimService。 ExpenseCaseService只负责阶段协调,申请、票据、报销、审批、支付、入账、记忆和节省由独立协作者负责。- 复用统一 AI 场景注册与 LangGraph 编排,前端只按后端返回的 plan/action 渲染,不再增加业务门控。
业务事件与 AI 决策
- 所有关键动作写入 append-only
business_events,使用correlation_id串联同一费用事件、Agent run、审批和外部连接器事件。 - 业务状态变更与对应 Outbox 事件必须在同一数据库事务中持久化;消费者按事件 ID 幂等处理,避免审计、学习和 ROI 数据因异步失败永久丢失。
- 只有画像刷新、分析聚合和消息通知等可重建派生任务允许异步失败并重试,不得把申请、提交、退回、审批、支付和入账事件降级为可丢弃旁路日志。
- 每个 AI 输出写入
ai_decisions,记录建议值、置信度、证据、模型、Prompt、规则、政策版本、风险等级和自动化模式。 - 用户接受、修改、拒绝或忽略写入
ai_decision_feedback;审批、退回、付款和审计写入workflow_outcomes。
记忆与学习
memory_entries支持用户、部门、企业作用域,以及 candidate/active/suppressed 状态。memory_evidence_links保留记忆与业务事件、决策、反馈、结果的来源关系。- 企业制度优先于部门基线,部门基线优先于个人偏好;冲突时返回解释。
- 复用既有 AI 数据飞轮的 few-shot、golden case、Prompt 版本、Canary 和回归门禁。
节省与价值
savings_opportunities记录基线、风险暴露、建议动作、预计节省、负责人和截止时间。savings_realizations记录执行结果、实际节省、财务确认人、证据、归因状态和去重键。- 风险关联金额、暂缓付款和未采纳建议不得自动转为实际节省。
连接器
- 定义统一
ExpenseConnector协议,覆盖票据邮箱、税务验真、企业卡、商旅、支付、银行流水、ERP、HR、SSO、企微/钉钉。 - 外部事件必须具备幂等键、来源系统、原始事件 ID、发生时间、处理状态、错误码和重试次数。
商业计量
- 以租户、套餐、模块和时间窗口记录模型、OCR、文档、分析任务、连接器与人工实施用量。
- 成本事件与客户价值事件分开记账,支持计算客户贡献毛利、实施成本摊销和私有部署成本。
- 套餐与配额只控制商业权益,不改变安全规则、租户隔离和高风险人工复核边界。
算法与规则
自动化决策
- 自动化等级按动作计算,不按 Agent 整体授权。
- 动作风险、模型置信度、证据完整度、历史命中率、金额阈值、可逆性、企业上限和抽检率共同决定是否执行。
- L0 只读解释;L1 建议;L2 预填;L3 可逆自动化;L4 低风险直通;L5 资金支付和高风险决策始终保留人工。
记忆激活
- 明确偏好可由用户确认后立即激活。
- 隐式偏好必须达到最小一致证据数,并通过时间衰减、敏感性、企业规则冲突和异常值检查。
- 错误标注、违规习惯和一次性例外不能直接变为默认记忆。
风险与预审
- 统一输出事实、规则、证据、风险、建议和可执行修复动作。
- 使用已确认正/负样本校准误报与漏检;规则或 Prompt 发布前运行 golden case。
- 新策略先进入 shadow,再 Canary,最后按动作开放自动化。
费用分析与节省
- 描述性分析回答“发生了什么”;诊断分析回答“为什么”;建议分析回答“做什么”;价值闭环回答“是否执行并产生了多少结果”。
- 供应商、费用类型、城市、项目和部门基线必须保存数据窗口、样本量、算法版本和政策版本。
- 节省归因必须区分现金节省、可释放工时价值和不可货币化效率改善。
数据与契约
核心数据对象
expense_cases:统一费用事件和当前阶段。expense_case_links:连接申请、报销、票据、审批、付款、凭证和外部对象。business_events:append-only 业务事件账本。ai_decisions:结构化 AI 建议与版本证据。ai_decision_feedback:接受、修改、拒绝和忽略。workflow_outcomes:退回、补件、审批、付款、审计和最终结果。memory_entries/memory_evidence_links:分层记忆和来源。automation_policies/automation_grants:动作级自动化策略和授权。profile_baseline_snapshots:持久化员工、部门、供应商、费用和流程基线。savings_opportunities/savings_realizations:节省机会和实现结果。usage_meter_events:租户、模块、模型、OCR、文档和分析用量。
最小事件词典
expense_case_createdhistorical_claim_imported:迁移前旧单的当前快照;只证明已纳入统一费用事件,不重建或伪造迁移前审批历史。application_generated/application_submitted/application_approvedreceipt_received/receipt_verified/ocr_correctedfield_suggested/field_accepted/field_edited/field_rejectedattachment_associated/draft_saved/claim_submittedclaim_returned/supplement_completedrisk_flagged/risk_confirmed/risk_false_positiveroute_suggested/route_overriddenclaim_approved/payment_requested/payment_completedaccounting_entry_created/reconciliation_completedsaving_opportunity_created/saving_action_completed/saving_confirmed
状态枚举
- Expense Case:
planning/approved_to_spend/spending/claiming/reviewing/paying/accounting/closed/cancelled。 - AI Decision:
suggested/accepted/edited/rejected/ignored/executed/rolled_back。 - Memory:
candidate/active/suppressed/expired/revoked。 - Automation:
explain/recommend/prefill/reversible_auto/low_risk_straight_through/human_only。 - Savings:
identified/accepted/in_progress/realized/verified/rejected/expired。
兼容策略
- 迁移初期可用 shadow 事件校验现有
ExpenseClaim的映射;某个状态一旦正式纳入事件模型,其业务写入与 Outbox 事件必须进入同一事务。 - 迁移前已有
ExpenseClaim通过显式维护命令写入一条historical_claim_imported快照事件:事件发生时间使用真实回填时间,原创建、发生、提交和更新时间只进入内部 payload;history_reconstructed=false,不得按当前状态反推并伪造历史提交、审批或付款动作。 - 历史回填默认 dry-run,必须显式提供租户、创建时间边界和数据库目标;apply 还要求精确目标确认、迁移 head、advisory lock 和分批事务。稳定幂等键、源快照指纹、已有 Link 跳过及孤立 Event 冲突拒绝共同保证可审计重跑。
- 历史快照事件使用
delivery_status=suppressed,供时间线和分析读取,但不进入实时 Outbox 投递;用户态 API 仍只返回事件白名单,不暴露回填批次、源指纹、幂等键和投递状态。 - 旧
ReimbursementRequest进入只读兼容和迁移状态,停止新增第二套业务编排。 - 现有
risk_flags_json保持读取兼容,新审批、付款、归档和关系事件写入结构化表。 - API 新字段优先追加,不在同一阶段破坏现有前端契约。
- 迁移桥接期集中维护 migration-owned 表集合;所有 legacy bootstrap 只能创建集合之外的表。标准启动在
alembic upgrade head前只读核对 revision 与自有表集合,发现漂移时拒绝启动,不自动猜测、stamp 或修复。 - 所有表结构通过 Alembic 迁移,不继续在请求路径执行 DDL。
版本与审计
- 事件记录 actor、tenant、source、run、model、Prompt、rule、policy 和 schema 版本。
- 记忆、自动化策略、规则、Prompt 和基线均支持 supersede、有效期和回滚。
- 高风险人工覆盖必须记录原因、证据和审批主体。
权限与安全
- 登录后签发服务端可验证会话或 JWT,服务端从会话和数据库解析用户、租户、角色和数据范围。
- 移除客户端
X-Auth-*作为授权事实来源;管理面、Bootstrap、设置和模型连通性接口必须受平台管理员保护。 - P0 采用不透明 Bearer 会话:明文 token 仅在登录成功时返回,数据库只保存 SHA-256 摘要;每次请求从服务端会话和员工数据重新解析当前身份与角色,过期、撤销或不存在的 token 统一拒绝。
- Web 端只在
sessionStorage保存 token 和过期时间,普通请求、流式请求及页面关闭收尾统一携带 Bearer;任一401触发本地会话清理,登出时会话指标与 token 撤销在同一事务完成。 - 已初始化系统的 Bootstrap 状态只返回脱敏信息,Bootstrap 写入、系统设置、模型连通性、缓存、审计与系统日志等敏感管理面由平台管理员权限保护;Vite 本地 Setup 桥在初始化完成后锁定重新配置入口。
- P0 数据契约即引入最小
tenant_id、数据库约束、行级过滤、向量库命名空间和对象存储前缀隔离;删除传播、数据导出和私有部署加固可在商业化阶段继续完善。 - Expense Case 用户态查询只返回流程摘要:Case 基础状态、关系类型、事件类型、操作人、发生时间及白名单业务载荷;不返回关联资源 ID、幂等键、correlation、causation、聚合标识或 Outbox 投递状态。有权查看入口单据的本人、当前审批人、财务和管理员可查看整 Case 的安全摘要,无权限与跨租户查询继续以 404 隐藏资源存在性。
- 自动化权限按动作、金额、场景、风险和有效期授予,不使用全局“允许 Agent 自动执行”开关。
- 收款账户变更、资金支付、制度发布、高风险驳回和敏感主数据变更执行双人或更高等级复核。
降级策略
- LLM 不可用:回退到规则和人工填写。
- OCR 不可用:文件保留并进入待识别队列,用户可手工补录。
- Qdrant/few-shot 不可用:使用 stable Prompt 和基础规则,不阻塞主流程。
- 外部支付/ERP/税务连接器不可用:事件进入 retryable 状态,保留人工处理入口和幂等键。
- 记忆冲突或可信度不足:只展示建议,不自动应用。
- Savings 证据不足:保留机会状态,不进入已实现节省。
算法与公式
自动化资格分数
automation_score
= w1 * model_confidence
+ w2 * evidence_completeness
+ w3 * historical_precision
+ w4 * reversibility
- w5 * action_risk
- w6 * amount_risk
变量说明:
model_confidence:模型或规则对当前建议的置信度。evidence_completeness:发票、申请、预算、合同、订单和政策证据完整度。historical_precision:相同租户、场景、动作和版本的历史正确率。reversibility:动作是否可以无损撤销或回滚。action_risk:动作类型风险,支付和制度发布最高。amount_risk:金额相对企业阈值和历史基线的风险。w1...w6:按企业和动作配置的权重。- 适用边界:分数只决定候选自动化等级,仍需满足企业硬性白名单、金额上限、抽检率和人审要求。
记忆激活置信度
memory_confidence
= consistent_evidence_weight
+ outcome_success_weight
+ explicit_confirmation_weight
- conflict_weight
- age_decay
变量说明:
consistent_evidence_weight:多次一致修改或选择产生的证据。outcome_success_weight:建议最终一次通过、付款或审计确认的权重。explicit_confirmation_weight:用户或管理员明确确认的权重。conflict_weight:与企业制度、部门规则或其他记忆冲突的惩罚。age_decay:记忆随时间衰减。- 适用边界:敏感信息、一次性例外和违规行为不得依赖分数自动激活。
安全智能直通率
safe_straight_through_rate
= qualified_completed_cases_without_manual_correction_or_return
/ eligible_completed_cases
分子还必须满足必要审批完成,且事后抽样审计未发现重大问题。
客户可验证 ROI
verified_value
= verified_cash_savings
+ verified_releasable_labor_value
customer_roi
= (verified_value - customer_total_cost) / customer_total_cost
变量说明:
verified_cash_savings:客户财务确认的重复支付阻止、超标准调整、采购或预算优化等实际现金节省。verified_releasable_labor_value:基于上线前后人工分钟、单据量和角色完全成本计算,并经客户认可的工时价值。customer_total_cost:订阅、用量、实施、集成和客户内部运营成本。- 适用边界:现金节省和工时价值分开披露;风险暴露、未采纳建议和暂缓付款不得计入。
客户贡献毛利
customer_contribution_margin
= subscription_revenue
+ usage_revenue
+ module_revenue
+ verified_savings_share
- llm_ocr_storage_cost
- third_party_cost
- support_cost
- amortized_implementation_cost
用于判断高收入但高度定制或私有部署客户是否实际盈利。
测试方案
后端
- Expense Case 状态机、关系绑定、幂等和非法状态跃迁单元测试。
- 历史 ExpenseClaim 回填的 dry-run 零写、租户/时间边界、快照真实性、批次回滚、冲突拒绝、重复执行和数据库目标防误连测试。
- Business Event、AI Decision、Feedback、Outcome、Memory、Automation Policy、Savings Ledger service 单元测试。
- 服务端会话、租户隔离、角色和动作权限的正向/越权测试。
- 连接器事件幂等、重试、回执、失败恢复和重复支付防护测试。
- Alembic baseline、升级、回滚边界和旧数据迁移测试。
- 现有报销、预算、风险、知识库和 Agent 回归测试。
前端
- 费用事件时间线、异常确认、断点续办和操作反馈视图模型测试。
- 移动拍票、上传失败恢复、真实列表和审批 mutation 测试。
- 审批例外工作台键盘操作、焦点管理和权限态测试。
- CFO 价值看板对预计/实际/确认节省的展示和下钻测试。
- AI 记忆查看、修改、忘记和关闭个性化测试。
- 生产构建、lint、typecheck 和浏览器关键流程测试。
算法与规则
- 自动化分数、硬阈值、金额上限、动作白名单和抽检策略测试。
- 记忆候选、激活、冲突、过期、撤销和污染样本测试。
- 风险规则、Prompt、few-shot 和 golden case 回归门禁测试。
- Savings 去重、基线、归因和确认状态测试。
集成
- 一句话申请 → 票据归集 → 自动报销 → 预审 → 审批 → 付款事件 → 入账 → 归档端到端。
- 持久开发库只读流式克隆 → Alembic 升级 → 历史回填 dry-run/apply/重复 apply → 服务端登录 → 旧单时间线查询 → 持久库不变验证。
- AI 建议 → 用户修改 → 退回/通过 → 记忆候选 → 下次建议变化闭环。
- 风险命中 → 人工确认/误报 → few-shot → 新版本回放 → Canary/回滚闭环。
- 节省机会 → 负责人执行 → 实际结果 → 财务确认 → ROI 看板闭环。
- 多租户同名员工、同号单据、向量检索和对象存储隔离测试。
容器验证
所有后端、集成、数据库迁移和外部依赖验证必须在项目容器内执行,单条测试命令最大超时 60s:
docker exec -w /app -e SERVER_VENV_DIR=/tmp/x-financial-server-venv \
x-financial-local-linux \
/tmp/x-financial-server-venv/bin/pytest -q server/tests/test_expense_case_service.py
如果本地 Compose 使用不同容器名,先通过 docker ps 确认当前主应用容器,不得改为宿主机直接运行后端测试。
手工验证
- 在真实容器页面完成申请、拍票、报销、退回补件、审批、付款和价值看板流程。
- 检查每个 AI 建议是否能展示来源、置信度、修改结果和后续业务结果。
- 检查用户能否查看、修改和忘记 AI 记忆。
- 检查高风险动作无法绕过人工,低风险可逆动作能够撤销和回放。
- 检查每项实际节省能够追溯到基线、建议、执行、确认人和证据。
指标与验收
以下目标在缺少真实客户基线前均为首轮试点的方向性目标,正式数值必须在试点基线采集后冻结。
- [A1] 全流程验收:任一费用事件可以从申请追溯到票据、报销、审批、付款、凭证、归档、AI 决策和节省结果。
- [A2] 体验指标:首个试点场景报销创建时间 P50 目标不超过 60 秒。
- [A3] 自动化指标:可结构化字段的自动填充率方向性目标不低于 85%,且字段修改率持续下降。
- [A4] 质量指标:首次提交完整率方向性目标不低于 90%,退回率和每单人工触点低于试点基线。
- [A5] 智能指标:AI 字段采纳率、重复纠正率、建议接受率和记忆复用成功率可按租户、场景、版本统计。
- [A6] 风险护栏:重大风险漏检率、误报干扰率、人工覆盖率和抽样审计结果可计算;自动化提升不得以护栏恶化为代价。
- [A7] 价值指标:每项节省区分机会、预计、执行、实现和财务确认;客户月度 ROI 可回放。
- [A8] 商业指标:早期可计算付费试点转年度合同率、持续产生可验证价值的客户率和按客户贡献毛利;成熟后计算 NRR。
- [A9] 性能指标:同步页面接口 P95、AI 预填 P95、OCR 队列等待、后台任务恢复和连接器重试达到试点 SLA,具体阈值在基线后确定。
- [A10] 安全指标:客户端无法伪造管理员、跨租户访问返回拒绝、敏感动作具备二次授权和审计。
- [A11] 可观测性:每个费用事件、AI 决策、工具调用、连接器事件、自动化执行和失败重试使用统一 correlation ID。
- [A12] 工程验收:相关后端定向测试、前端测试、lint、typecheck、构建和端到端验证在容器事实环境中通过。
风险与开放问题
风险
- 范围过大:费用闭环、AI 学习、价值分析和商业化不能同时全量实现,需要按 P0/P1/P2 阶段交付。
- 领域模型迁移:旧
ReimbursementRequest、ExpenseClaim和 JSON 状态并存,必须旁路记录、小步迁移和双读校验。 - 历史证据边界:旧单快照只表达回填时可确认的当前状态,迁移前逐节点办理过程仍以原单据和既有审计为准;后续分析不得把快照事件误当成历史审批事实。
- 认证和租户:当前客户端身份头不适合自动化和 SaaS,多租户、记忆和高风险动作开发前必须修复。
- 会话运维:不透明会话已经替代客户端身份头,但仍需补充定时清理、活跃会话查看/全部退出、密钥轮换策略、登录限流和企业 SSO;当前
tenant_id仍是最小契约,不代表跨租户查询守卫已经完成。 - 费用事件读取边界:用户态精简 DTO 和首批 HTTP 权限测试已完成;剩余风险是同一 URL 若已有外部客户端依赖旧内部字段会产生契约变更,且未来新增敏感 payload 字段必须继续显式进入白名单,不能恢复任意字典透传。
- 反馈投毒:一次点击或违规习惯不能直接成为记忆,需要候选态、最小样本、制度约束和结果权重。
- 自动化失控:高准确率不代表高风险动作可以无人值守,必须按动作授权并支持 shadow、Canary、抽检和回滚。
- 虚假节省:风险暴露金额、暂缓付款和工时估算容易被夸大,必须由客户财务确认并执行去重。
- 外部依赖:税务、支付、银行、商旅、ERP 和消息平台连接器存在可用性、资质和交付周期风险。
- 移动端成熟度:拍票基础已有,但主业务仍有 mock,必须先完成真实登录、列表、草稿和审批闭环。
- 成本失控:高频 LLM、OCR、向量检索和私有部署可能降低毛利,需要按租户和模块计量成本。
- 数据稀疏:本地开发库缺少报销、反馈、风险和 golden 样本,正式目标必须来自真实试点而不是演示数据。
已处理依赖
- 已有预算、票据夹、OCR、报销草稿、风险规则、审批路由、知识库、员工画像、Agent trace、few-shot 和财务看板可复用。
- 已有 AI 数据飞轮概念与阶段 1 few-shot 实现,不重复建设样本检索底座。
- 已有统一门控管道设计,可作为 AI 场景收口依据。
待确认
- 首个目标客户规模和部署形态:中小 SaaS、中大型企业 SaaS 或集团私有部署。
- 首个 90 天付费试点场景:差旅报销、业务招待、日常费用或预算风控。
- 是否进入企业支付、商旅预订或公司卡领域;如果不进入,应明确聚焦 AI 费控与经营分析。
- 客户是否接受工时价值进入 ROI,以及对应角色完全成本口径。
- L3/L4 自动化允许的动作、金额阈值、抽检率和授权主体。
- 税务验真、银行、ERP、企微/钉钉等连接器的首批合作范围。
- SaaS 定价的员工档位、包含用量、超额计价和增值模块边界。
降级策略
- 首期只选择一个费用场景做完整闭环,其他场景保留现有流程。
- 正式切换前允许 shadow 事件用于一致性校验;正式切换后的关键业务状态与 Outbox 事件必须原子提交,失败时整体回滚并向用户返回可重试状态。
- 画像刷新、分析聚合、消息通知等可重建派生任务失败时进入重试/死信队列,不阻塞已成功提交的关键业务状态。
- 自动化默认停留在 L1/L2,只有试点评估和风险护栏通过后才逐项开放 L3/L4。
- 外部连接器未完成前保留人工导入、确认和对账入口,但状态语义和审计事件按正式契约记录。
本轮实现记录
- 2026-07-13:完成产品能力、端到端费用旅程、AI 学习飞轮、KPI 和商业模式分析,形成总功能概念文档。
- 2026-07-13(规划阶段):只沉淀功能规划,没有修改业务代码、数据库结构或现有接口。
- 2026-07-13(P0 基础切片):新增
ExpenseCase、ExpenseCaseLink、BusinessEvent模型与ExpenseCaseService,提供/api/v1/expense-cases/by-claim/{claim_id}时间线查询接口。 - 2026-07-13(P0 基础切片):草稿、提交、退回、审批、申请转报销、付款和申请归档开始旁写结构化事件;事件具备租户字段、correlation、causation、幂等键和待投递状态,并与业务状态在同一事务提交。
- 2026-07-13(事务修复):关联申请归档/解绑的内部审计改为
flush,由外层业务事务统一提交,避免审计日志提前提交付款或归档状态。 - 2026-07-13(迁移桥接):新增第一条 migration-owned schema revision;服务启动先执行 Alembic,旧
create_all明确排除三张迁移表。完整历史 schema baseline、正式数据库 upgrade/rollback 和停止旧 DDL 仍未完成。 - 2026-07-13(验证):容器内新增测试与既有差旅主链路回归共 24 项通过;Alembic PostgreSQL upgrade/downgrade 离线 SQL、启动脚本语法、OpenAPI 路由和新增文件静态检查通过。未对持久化开发数据库执行迁移。
- 2026-07-13(P0 认证安全切片):新增
AuthSession不透明 Bearer 会话及20260713_0002_auth_sessions.py,登录 token 只返回一次、数据库只保存摘要;/auth/me、会话结束和登出均从服务端会话解析身份,登出与使用指标收尾原子提交。 - 2026-07-13(管理面收口):移除生产代码中的
X-Auth-*授权来源,保护 Settings、模型连通性、缓存、员工、分析、Agent 运行/轨迹、风险观测、审计及系统日志;已初始化 Bootstrap 返回脱敏状态并拒绝匿名重配置,Vite Setup 桥同步锁定。 - 2026-07-13(前端会话):Web 请求、流式响应和页面关闭收尾统一使用 Bearer,token 与过期时间只保存在
sessionStorage,集中处理401、空闲过期和服务端过期;业务经理不再被前端视为平台管理员。 - 2026-07-13(认证验证):容器内认证/Bootstrap/费用事件/OpenAPI 定向测试 21 项通过,受保护业务端点回归 13 项通过,全量测试收集 805 项成功;前端会话、请求、Setup 锁和权限测试 17 项通过,生产构建通过。迁移仅生成并检查 upgrade/downgrade 离线 SQL,未写入持久化开发数据库。
- 2026-07-13(P0 提交一致性补缝):AI 新建费用申请并直接提交时,先持久化为草稿,再统一委托
ExpenseClaimService.submit_claim;提交校验、预算预占、申请提交风险标记、application_submitted事件和审批状态不再由 AI 入口分别维护。 - 2026-07-13(事务边界修复):预算表运行时就绪检查改为复用当前 Session 连接,避免通过 Engine 执行 metadata 检查时隐式提交已
flush的申请;即使预算预占后 Expense Case 事件写入失败,申请、预算额度、预算流水、预占和 Case 数据也会整体回滚。 - 2026-07-13(提交一致性验证):容器内 AI 申请直接提交、失败回滚、保存草稿副作用、申请提交主链路及预算/Expense Case 回归共 21 项通过,
ruff --select F,I通过;未修改数据库结构,未对持久化开发数据库执行迁移。 - 2026-07-13(P0 前端时间线):申请/报销详情在原有横向进度下接入真实
/api/v1/expense-cases/by-claim/{claim_id},新增稳定排序、中文事件语义、状态迁移、退回原因、操作人和发生时间展示;未知事件使用通用文案,不暴露 correlation、幂等键或 Outbox 投递状态。 - 2026-07-13(前端兼容与验证):单据切换时清空旧时间线并通过请求序列防止乱序覆盖;未纳入 Expense Case 的 404 显示非阻断兼容态,其他接口错误支持重试且不影响原有进度与单据操作。容器内 99 条定向前端测试和 Vite 生产构建通过。
- 2026-07-13(P0 用户态事件契约):Expense Case 响应收口为 Case 基础状态、关系类型和事件安全摘要,事件载荷采用递归白名单;关联单据 ID、聚合信息、幂等与关联链、Outbox 投递字段及未知嵌套内部字段不再通过用户接口返回。
- 2026-07-13(P0 草稿事件补缝):AI 工作台与小财管家新建/更新费用申请草稿分别写入
claim_draft_created/claim_draft_updated;租户从服务端身份透传,事件、Case、Link 与草稿同事务提交,失败整体回滚。动作幂等组合租户、操作人、run ID 与稳定草稿快照:完全相同的 HTTP 保存重放复用同一草稿和事件,并发竞争由稳定聚合 ID 与数据库主键仲裁,同一 run 内的真实内容变化仍保留独立事件。 - 2026-07-13(AI 申请身份边界):申请预览快速入口不再接受请求体中的
user_id、管理员标记、角色、员工编号或其他身份字段作为授权事实,全部强制绑定服务端会话;伪造管理员身份编辑他人退回申请会返回 400,且原申请与费用事件不发生变化。 - 2026-07-13(安全与事务验证):容器内受影响后端定向回归 36 项、Expense Case 前端兼容测试 9 项和 Python
ruff --select F,I通过;覆盖本人、当前审批人、财务、管理员、无权限、跨租户、整 Case 安全摘要、草稿新建/更新、失败回滚、HTTP 创建重放、相同快照去重、不同快照留痕、Steward 重放及伪造身份越权。未修改数据库结构,未执行持久化开发数据库迁移。 - 2026-07-13(联调边界):当前持久化开发数据库尚无
auth_sessions、expense_cases、expense_case_links和business_events表,浏览器登录无法获得有效认证凭证,因此本轮未声称完成真实页面端到端联调,也未擅自执行数据库迁移。计划、消费/票据、入账、对账和复盘事件仍待后续补齐。 - 2026-07-14(迁移所有权加固):新增统一
schema_ownership.py,七个运行时初始化入口只创建 legacy 表;标准启动在 Alembic upgrade 前执行只读漂移预检,revision 与 migration-owned 表集合不一致时 fail-fast,且不会自动 stamp 或修改数据库。 - 2026-07-14(真实迁移验证):在主应用容器连接的一次性 tmpfs PostgreSQL 17 中完成空库升级、重复升级、关键约束/索引、真实外键级联、降级到 base、legacy 哨兵保留、无版本自有表漂移拒绝和再次升级,
test_alembic_migrations.py4 项通过,最终 revision 为20260713_0002;临时容器已自动清理,持久化开发数据库复查仍未迁移。 - 2026-07-14(剩余边界):当前两条 revision 只覆盖 Expense Case、Business Event 和 Auth Session,完整 legacy schema baseline 及停止其余运行时 DDL 仍未完成;本轮受影响服务回归 46 项通过,既有员工目录历史部门归一化用例仍单独失败,未混入本次迁移安全范围。
- 2026-07-14(历史旧单接入):新增独立
ExpenseCaseLegacyBackfillService和backfill_legacy_expense_claim_cases.py。命令只读取显式DATABASE_URL,默认 dry-run;apply 强制目标核验、精确确认、迁移 head、advisory lock 和批次事务。每张旧单只创建一条historical_claim_imported系统快照,保留源时间和指纹、明确不重建历史,并以suppressed阻止实时投递。 - 2026-07-14(克隆库联调):将持久开发库以只读
pg_dump流式恢复到一次性 tmpfs PostgreSQL 17,原 40 张表、4 张费用单、105 名员工、248 条预算和 62 个 Agent 资产完整保留。升级到20260713_0002后首次 dry-run 识别 4 张旧单,apply 创建 4 组 Case/Link/Event,重复 apply 创建 0 条;隔离后端完成登录、/auth/me、旧单时间线 200 和登出,内部回填字段未出现在 API。临时数据库和隔离进程已清理,持久库复查仍为原数据签名且没有 migration-owned 表。 - 2026-07-14(安全复核与质量验证):交叉审查后补齐超长租户幂等键稳定哈希、Link/Case 租户一致性、孤立 Case 冲突、URL 路由参数覆盖防护和部分批次失败进度摘要;前端将快照语义明确为“纳入时状态/节点”。容器内 65 项后端定向测试、11 项前端测试、Ruff 和 Vite 生产构建通过。全库代码体积门禁仍被本次未修改的
RiskRuleGenerationService807 行存量问题阻断,未混入当前功能提交。 - 2026-07-14(AI 行为闭环首个切片):新增
AIDecision、AIDecisionFeedback和WorkflowOutcome三类独立事实,把申请预填建议、用户确认或显式字段纠正、草稿保存或申请提交结果通过稳定decision_id关联。只有已认证的申请预览快速入口显式传入服务端CurrentUserContext时才写账本;通用 User Agent、模板预览和单据详情编辑路径均不写入,避免伪造身份和非 AI 操作污染样本。 - 2026-07-14(字段纠正与隐私边界):申请表编辑器在当前会话中维护首次建议值与最终显式编辑值,多次修改保留最初建议,改回原值会移除差异;日期调整同时记录
time与派生days。服务端最终值始终从解析后的申请 facts 重建,不信任客户端finalValue;持久化层只保存字段名和 SHA-256 值指纹,不复制事由、地点、人员、金额等原始值,原始对话、Prompt、模型全文、附件和支付敏感信息也不进入学习账本。 - 2026-07-14(可信度边界):浏览器编辑轨迹统一标记为
verification_status=client_observed、trust_level=behavioral_analytics_only且training_eligible=false,只能用于受限的产品行为统计和后续人工核验,不能直接作为模型训练、审计结论、风险自动放行或企业记忆激活依据。后续需增加服务端预览登记并返回不可伪造的decision_id,再实现拒绝/忽略、审批/退回/付款结果追踪、记忆候选与下次建议变化。 - 2026-07-14(事务与一致性):学习三表与申请、预算及 Business Event 使用同一 Session,在最终 commit 前
flush,失败整体回滚;提交场景通过提交服务的事务内回调关联真实application_submitted事件。Case、Business Event 和 Decision 使用包含tenant_id + expense_case_id的复合外键,既拒绝跨租户,也拒绝同租户跨 Case 串联。前端估算使用消息级请求版本和输入指纹,只合并估算派生字段,旧响应不会覆盖后续编辑。 - 2026-07-14(0003 迁移与验证):新增
20260714_0003_ai_learning_loop.py,三张学习账本表纳入集中迁移所有权;AgentRun 与旧 ExpenseClaim 保持带索引软引用以兼容空库迁移顺序。一次性 tmpfs PostgreSQL 17 的升级、重复升级、跨租户/同租户跨 Case 外键拒绝、降级和再次升级 4 项通过;容器内学习账本、入口边界和迁移所有权定向 29 项,日期联动及异步估算关键场景 5 项通过。持久开发库只读复查仍为40|4|105|248|62,7 张 migration-owned 表数量为 0。