docs: 清理过期计划文档并补全 work-log 与开发/用户文档

- 删除已落地的 improvement-roadmap、superpowers 计划与 ui-mockups 参考稿，删除早期 work-log（2026-05-06~08） - 新增 2026-05-23 起的 work-log 与 attachment-association-background-job、reimbursement-draft-action-branching 等开发文档及用户文档 - docker-compose(.full).yml 微调服务配置
2026-06-24 10:42:57 +08:00
parent ee730aa31c
commit f9553a6a1a
58 changed files with 1551 additions and 1404 deletions
--- a/document/development/attachment-association-background-job/CONCEPT.md
+++ b/document/development/attachment-association-background-job/CONCEPT.md
@@ -0,0 +1,144 @@
+# 附件自动关联后台任务方案
+
+## 背景
+
+小财管家 AI 模式里，用户上传票据后会先做 OCR。当前附件自动关联报销草稿的后半段仍依赖前端会话内存：
+
+- 前端保留浏览器里的 `File` 对象。
+- 前端在当前会话里完成草稿匹配。
+- 用户点击“确认自动关联”后，再用这些 `File` 上传到报销单明细。
+
+这会带来一个核心问题：用户发送消息后，如果刷新页面、切换会话或退出当前会话，浏览器内存里的附件原件会丢失，历史消息中的关联动作就无法继续执行。
+
+票据夹已经能持久化 OCR 结果和源文件，并且 OCR 返回里已经带有 `receipt_id`。所以正式方案应该把“附件关联”从前端内存任务调整为后端可查询任务。
+
+## 目标
+
+1. 用户一上传附件即触发 OCR，附件卡片显示“识别中”，识别完成后显示“当前附件已识别”。
+2. 用户点击发送后，前端不再依赖 `File` 原件做后续归集，而是把 OCR 产生的 `receipt_id` 提交给后端。
+3. 后端创建附件关联任务，并在后台继续匹配、复制票据夹源文件、关联报销单明细。
+4. 用户退出或刷新当前会话后，前端可通过保存下来的 `job_id` 查询任务状态并更新消息。
+5. 如果匹配失败、置信度不足或找不到可编辑草稿，系统给出清晰提示，引导用户补充说明、上传附件或新建草稿。
+
+## 非目标
+
+第一版不承诺后端服务进程重启后任务状态仍可恢复。
+
+本次实现使用轻量内存任务池，解决“用户离开前端会话导致连接断开”的问题。后续如果要做到服务重启、横向扩容、任务审计都可恢复，再新增数据库任务表。
+
+## 核心流程
+
+```text
+用户上传票据
+  → 前端立即调用 OCR
+  → OCR 写入票据夹并返回 receipt_id
+  → 附件卡片显示“当前附件已识别”
+  → 用户点击发送
+  → 前端 POST 创建附件关联任务
+  → 后端后台任务继续运行
+  → 前端轮询 job_id
+  → 成功：消息显示已关联，并刷新报销单详情
+  → 失败：消息显示失败原因和下一步动作
+```
+
+## 后端设计
+
+### API
+
+新增接口：
+
+- `POST /api/v1/reimbursements/attachment-association-jobs`
+- `GET /api/v1/reimbursements/attachment-association-jobs/{job_id}`
+
+创建任务请求只传持久化引用，不传浏览器文件：
+
+```json
+{
+  "receipt_ids": ["receipt-1", "receipt-2"],
+  "prompt": "请帮我处理已上传的附件。",
+  "conversation_id": "inline-xxx"
+}
+```
+
+状态返回：
+
+```json
+{
+  "job_id": "job-xxx",
+  "status": "running",
+  "message": "正在匹配可关联的报销草稿...",
+  "receipt_ids": ["receipt-1", "receipt-2"],
+  "claim_id": "",
+  "claim_no": "",
+  "uploaded_count": 0,
+  "skipped_count": 0,
+  "error": ""
+}
+```
+
+状态枚举：
+
+- `queued`：任务已创建，等待后台执行。
+- `running`：正在匹配和归集。
+- `succeeded`：已完成自动归集。
+- `failed`：无法自动完成，返回可读错误。
+
+### 任务执行
+
+后端任务执行步骤：
+
+1. 按 `receipt_ids` 读取票据夹明细和源文件。
+2. 从票据 OCR 文本、结构化字段、日期、城市提取匹配信号。
+3. 查询当前用户可见且可编辑的报销草稿，排除申请单和已归档单据。
+4. 对候选草稿按日期、城市、事由、草稿状态评分。
+5. 置信度足够时选择目标草稿。
+6. 为每份票据找到可用费用明细，没有合适明细时创建空明细。
+7. 从票据夹源文件复制到报销单附件目录，并沿用 `source_receipt_id` 回填 OCR 信息。
+8. 更新票据夹状态为 `linked`。
+9. 写入任务最终状态。
+
+## 前端设计
+
+### 会话消息
+
+AI 消息需要持久化 `attachmentAssociationJob`：
+
+```json
+{
+  "jobId": "job-xxx",
+  "status": "running",
+  "receiptIds": ["receipt-1", "receipt-2"]
+}
+```
+
+这样历史会话恢复后，不再需要浏览器里的 `File` 对象，只要消息里仍有 `jobId`，就可以继续查询后端状态。
+
+### 发送行为
+
+当用户上传附件并点击发送：
+
+1. 前端确认 OCR 已完成。
+2. 从 OCR 结果里提取 `receipt_id`。
+3. 创建后端任务。
+4. 立即持久化带 `job_id` 的 pending 消息。
+5. 页面仍打开时轮询任务状态。
+6. 页面恢复或打开历史会话时，对未完成任务继续轮询。
+
+## 异常处理
+
+- 未完成 OCR：禁止发送，提示“附件 OCR 识别中，请稍等，识别完成后再继续对话。”
+- OCR 失败：禁止发送，提示“请先移除识别失败的附件或重新上传。”
+- 没有 `receipt_id`：提示“当前附件没有持久化票据记录，请重新上传后再试。”
+- 没有可编辑草稿：任务失败，提示用户先新建或选择草稿。
+- 多个候选置信度接近：第一版不自动归集，提示补充说明或手动选择。
+- 服务重启导致内存任务丢失：返回任务不存在，前端提示“后台任务状态已失效，请重新发送附件关联请求。”
+
+## 验收标准
+
+1. 上传附件后必须先进入 OCR 识别中状态，识别完成前不能发送对话。
+2. 发送附件关联请求后，前端能收到并保存 `job_id`。
+3. 用户离开当前会话后，后端任务仍会继续执行。
+4. 用户回到历史会话后，前端可以根据 `job_id` 查询并更新最终状态。
+5. 成功后报销单明细出现附件，票据夹状态变为已关联。
+6. 找不到草稿、低置信度、源文件缺失时，消息能给出明确原因。
+
--- a/document/development/attachment-association-background-job/TODO.md
+++ b/document/development/attachment-association-background-job/TODO.md
@@ -0,0 +1,22 @@
+# 附件自动关联后台任务 TODO
+
+- [x] 梳理当前前端内存任务断链原因。
+- [x] 明确第一版边界：页面/会话退出可恢复，服务进程重启暂不承诺恢复。
+- [x] 新增后端任务 schema。
+- [x] 新增后端后台任务服务。
+- [x] 新增任务创建和查询接口。
+- [x] 补后端任务测试。
+- [x] 新增前端任务 service。
+- [x] 调整 AI 模式附件关联流程为创建后端任务。
+- [x] 持久化消息里的 `attachmentAssociationJob`。
+- [x] 历史会话恢复时继续轮询未完成任务。
+- [x] 更新前端源码断言测试。
+- [x] 容器内运行后端定向测试。
+- [x] 运行前端定向测试和构建。
+
+## 验证记录
+
+- `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_attachment_association_jobs.py server/tests/test_ocr_endpoints.py server/tests/test_reimbursement_endpoints.py::test_claim_item_attachment_upload_preview_and_delete server/tests/test_openapi_schema.py`
+- `node --test web/tests/workbench-ai-mode-switch.test.mjs web/tests/ai-attachment-association-model.test.mjs`
+- `npm --prefix web run build`
+- 已重启 `x-financial-local-linux`，并确认 `/api/v1/reimbursements/attachment-association-jobs/not-exist` 返回自定义任务失效提示。
--- a/document/development/reimbursement-draft-action-branching/CONCEPT.md
+++ b/document/development/reimbursement-draft-action-branching/CONCEPT.md
@@ -0,0 +1,137 @@
+# 报销草稿分支动作收口 概念文档
+
+更新时间：2026-06-23
+
+## 功能一句话
+
+当用户发起报销且系统命中可继续的报销草稿时，只提供“查看草稿、继续关联草稿、独立新建报销单”三个明确入口，让用户能看详情、补附件/说明，或确认另起一张新草稿。
+
+## 背景与问题
+
+- 当前现状：AI 工作台和报销助手在“我要报销”后会先查询可继续报销草稿；命中草稿时，当前按钮把“继续草稿”和“打开详情”混在一起，并把跳过草稿描述成“关联申请单新建报销单”。
+- 用户痛点：按钮语义不清，用户无法判断点击“继续草稿”是打开详情、继续补附件，还是进入申请单关联。
+- 业务影响：报销草稿与新建报销单的路径混杂，容易造成重复草稿、附件归集错误或用户误以为已继续处理。
+- 为什么现在需要做：截图中的草稿分支是报销入口的第一屏决策，需要先把按钮数量、文案和后续状态固定下来，再继续开发。
+
+## 目标与非目标
+
+### 目标
+
+- [G1] 命中可继续报销草稿时，快捷按钮固定为三个：查看草稿、继续关联草稿、独立新建报销单。
+- [G2] “查看草稿”只负责跳转详情页，不承担继续上传或新建逻辑。
+- [G3] “继续关联草稿”只负责把当前会话切到“等待上传附件或补充说明”的状态，并锁定目标草稿。
+- [G4] “独立新建报销单”先提示用户确认是否新建草稿单据，再进入新草稿创建流程。
+
+### 非目标
+
+- [NG1] 本轮不改后端草稿保存、附件 OCR、风险审核和审批流规则。
+- [NG2] 本轮不改变申请单关联命中时的“选择申请单 / 单独新建报销单”逻辑。
+- [NG3] 本轮不重做报销助手整体 UI，只收口草稿命中态的按钮和动作流。
+
+## 用户与场景
+
+- 目标用户：普通员工在个人工作台 AI 模式或报销助手中发起报销。
+- 使用入口：快捷操作“发起报销”、输入“我要报销 / 发起报销 / 新建报销”。
+- 核心场景：
+  1. 系统查到可继续报销草稿，展示草稿卡片和三个按钮。
+  2. 用户点击“查看草稿”，打开对应单据详情页。
+  3. 用户点击“继续关联草稿”，系统提示上传相关附件或补充说明。
+  4. 用户点击“独立新建报销单”，系统询问是否新建草稿单据。
+- 异常场景：
+  - 草稿缺少 `claim_id` 时，“查看草稿”和“继续关联草稿”不能提交无目标动作。
+  - 历史会话里的旧动作仍可兼容处理，不影响新生成提示。
+
+## 功能能力
+
+- [C1] 输入能力：读取报销草稿候选单据，识别 `claim_id`、`claim_no`、状态、金额、时间和事由。
+- [C2] 处理能力：将草稿命中态动作拆成查看、继续关联、独立新建三条互斥分支。
+- [C3] 输出能力：输出固定三按钮，并在点击后生成明确的用户回显和助手提示。
+- [C4] 状态与权限：继续关联时记录目标草稿，后续上传附件或补充说明应围绕该草稿继续。
+- [C5] 边界与降级：保留旧 `skip_reimbursement_draft_check` 动作兼容，避免历史会话按钮失效。
+
+## 方案设计
+
+### 前端
+
+- 页面/组件：
+  - `travelReimbursementAssociationGateModel.js` 负责生成草稿命中态文案和三个动作。
+  - `useWorkbenchAiActionRouter.js` 负责个人工作台 AI 模式的动作分流。
+  - `useWorkbenchAiExpenseFlow.js` 负责个人工作台中的继续关联提示和独立新建确认提示。
+  - `useTravelReimbursementSuggestedActions.js` 负责报销助手页面中的相同动作分流。
+- 交互状态：
+  - 查看草稿：沿用 `open_application_detail`，只跳转详情。
+  - 继续关联草稿：新增动作类型，点击后提示“请上传相关附件，或补充说明”，并记录目标草稿。
+  - 独立新建报销单：新增动作类型，点击后提示“是否新建草稿单据”，确认后进入现有单独新建流程。
+- 展示规则：
+  - 草稿命中态只显示三个按钮，不再出现“继续草稿”或“不用草稿，关联申请单新建报销单”。
+  - 按钮文案携带草稿编号，方便用户辨认目标。
+- 降级处理：
+  - 历史旧动作仍走原有分支。
+  - 缺少草稿 ID 时给出 toast，不继续进入无目标关联。
+
+### 后端
+
+- 接口/服务：当前不新增接口。
+- 权限与校验：沿用现有详情页与草稿操作权限。
+- 持久化：当前不改后端持久化结构。
+- 降级处理：后续上传附件或保存草稿仍使用现有 orchestrator 与附件归集能力。
+
+### 算法与规则
+
+- 输入：已筛选出的报销草稿候选。
+- 流程：按更新时间排序后取首个草稿作为三按钮默认目标；草稿卡片仍展示候选详情。
+- 输出：三个动作对象及后续提示文案。
+- 解释：本轮不是匹配算法改造，只是草稿命中后的动作语义收口。
+
+### 数据与契约
+
+- 核心字段：`claim_id`、`claim_no`、`original_message`、`draft_claim_id`、`selected_claim_no`。
+- 状态枚举：新增前端动作类型 `continue_reimbursement_draft_association`、`create_standalone_reimbursement_draft`、`cancel_standalone_reimbursement_draft`。
+- 兼容策略：保留 `open_application_detail` 和旧跳过动作分支。
+- 版本/审计：通过前端测试锁定动作数量、文案和路由行为。
+
+## 算法与公式
+
+当前功能不涉及显式数学公式。
+
+## 测试方案
+
+后端：
+
+- 当前不新增后端测试；本轮没有修改后端服务或接口。
+
+前端：
+
+- 扩展 `workbench-ai-reimbursement-association-gate.test.mjs`，验证草稿命中态只输出三个动作和新文案。
+- 扩展 `workbench-ai-action-router.test.mjs`，验证继续关联、独立新建确认的路由行为。
+- 扩展 `travel-reimbursement-guided-flow.test.mjs` 或既有报销助手动作测试，验证旧报销助手使用相同动作语义。
+
+集成：
+
+- 运行相关 Node 测试，确认 AI 工作台和报销助手入口没有回退到旧按钮。
+
+手工验证：
+
+- 在个人工作台 AI 模式输入“我要报销”，命中草稿后检查按钮数量和点击行为。
+
+## 指标与验收
+
+- [A1] 功能验收：草稿命中态固定显示三个按钮，且第一个按钮跳详情，第二个按钮提示上传附件/说明，第三个按钮提示是否新建草稿单据。
+- [A2] 性能指标：不增加额外接口查询；仍复用一次单据列表查询。
+- [A3] 质量指标：定向前端测试通过，旧动作兼容测试不失效。
+- [A4] 安全/权限指标：不绕过详情页和草稿操作原有权限。
+- [A5] 可观测性：对话消息中能看到用户选择了哪个分支。
+
+## 风险与开放问题
+
+- 风险：多个草稿同时命中时，三个按钮默认指向最新草稿；用户如需其他草稿，可先通过卡片查看信息后进入详情页处理。
+- 风险：全量 `code-size-limits` 当前仍会被既有 `TopBar.vue:824` 阻断；本轮新增和修改的文件均已控制在 800 行内。
+- 已处理依赖：复用现有详情页跳转、报销场景选择和草稿保存链路。
+- 待确认：后续是否要在草稿卡片内为每张草稿提供独立按钮；本轮先按截图中的三按钮入口收口。
+- 降级策略：旧历史会话按钮保持可点击，不强制迁移旧消息。
+
+## 本轮实现记录
+
+- 2026-06-23：先落本文档和 TODO，再按测试驱动修改前端草稿分支动作。
+- 2026-06-23：新增 `travelReimbursementDraftBranchModel.js` 承载草稿三分支动作，避免继续放大 `travelReimbursementAssociationGateModel.js`。
+- 2026-06-23：个人工作台和报销助手页面均已接入“继续关联草稿”和“独立新建报销单”的后续提示。
--- a/document/development/reimbursement-draft-action-branching/TODO.md
+++ b/document/development/reimbursement-draft-action-branching/TODO.md
@@ -0,0 +1,73 @@
+# 报销草稿分支动作收口 开发 TODO
+
+更新时间：2026-06-23
+
+## 使用规则
+
+- 每个 TODO 必须对应 `CONCEPT.md` 中的目标、能力、方案或验收点。
+- 只有完成并验证后，才能把 `[ ]` 改成 `[x]`。
+- 勾选时在任务后补充简短证据，例如文件、接口、命令或验证结果。
+- 如果需求发生变化，先更新 `CONCEPT.md`，再调整本 TODO。
+
+## 1. 调研与边界
+
+- [x] [CONCEPT: 背景与问题] 阅读相关页面、动作模型和测试，确认当前“继续草稿”实际走详情打开，“不用草稿”走申请单关联。
+  证据：`travelReimbursementAssociationGateModel.js`、`useWorkbenchAiActionRouter.js`、`useWorkbenchAiExpenseFlow.js`、`workbench-ai-reimbursement-association-gate.test.mjs`。
+- [x] [CONCEPT: 目标与非目标] 确认本轮只改草稿命中态按钮与点击流，不改后端草稿保存和风险审核。
+  证据：`CONCEPT.md` 的目标与非目标章节。
+- [x] [CONCEPT: 风险与开放问题] 标记多草稿命中时默认指向最新草稿，历史旧动作保留兼容。
+  证据：`CONCEPT.md` 的风险与开放问题章节。
+
+## 2. 契约与设计
+
+- [x] [CONCEPT: 功能能力] 定义三个动作分支：查看草稿、继续关联草稿、独立新建报销单。
+  证据：`CONCEPT.md` 的功能能力和方案设计章节。
+- [x] [CONCEPT: 方案设计] 明确个人工作台 AI 模式与报销助手页面共用动作模型，但分别在各自 action router 中处理点击。
+  证据：`CONCEPT.md` 的前端方案设计章节。
+- [x] [CONCEPT: 算法与公式] 明确本轮不涉及显式数学公式。
+  证据：`CONCEPT.md` 的算法与公式章节。
+- [x] [CONCEPT: 指标与验收] 把验收标准拆成按钮数量、按钮文案、点击后提示和旧动作兼容。
+  证据：`CONCEPT.md` 的指标与验收章节。
+
+## 3. 后端实现
+
+- [x] [CONCEPT: 后端] 本轮不新增后端 schema、service、endpoint、权限和持久化逻辑。
+  证据：`CONCEPT.md` 明确当前不新增接口。
+- [x] [CONCEPT: 数据与契约] 后端响应结构不变，新增内容仅为前端动作类型。
+  证据：`CONCEPT.md` 的数据与契约章节。
+
+## 4. 算法/规则实现
+
+- [x] [CONCEPT: 算法与规则] 本轮不改候选单据筛选算法，只改命中后的动作分支。
+  证据：`CONCEPT.md` 的算法与规则章节。
+- [x] [CONCEPT: 功能能力] 明确旧动作保留兼容，不删除历史会话能力。
+  证据：`CONCEPT.md` 的边界与降级说明。
+
+## 5. 前端实现
+
+- [x] [CONCEPT: 前端] 在草稿分支模型中新增动作类型和三按钮生成逻辑。
+  证据：`travelReimbursementDraftBranchModel.js` 定义 `CONTINUE_REIMBURSEMENT_DRAFT_ACTION`、`CREATE_STANDALONE_REIMBURSEMENT_DRAFT_ACTION` 和三按钮构造；`travelReimbursementAssociationGateModel.js` re-export 保持兼容。
+- [x] [CONCEPT: 前端] 在个人工作台 AI 模式中处理继续关联草稿、独立新建确认和取消新建。
+  证据：`useWorkbenchAiActionRouter.js` 分流新动作；`useWorkbenchAiExpenseFlow.js` 追加上传附件/说明提示和新建草稿确认提示。
+- [x] [CONCEPT: 前端] 在报销助手页面中处理同一批新动作，保持与工作台一致。
+  证据：`useTravelReimbursementSuggestedActions.js` 接入继续关联、独立新建确认和取消新建；`TravelReimbursementCreateView.js` 传入 `draftClaimId` 与 `composerUploadIntent`。
+- [x] [CONCEPT: 前端] 保留旧动作兼容，不破坏历史会话按钮。
+  证据：`SKIP_REIMBURSEMENT_DRAFT_CHECK_ACTION` 和 `SKIP_REQUIRED_APPLICATION_LINK_ACTION` 仍由原路径处理；相关旧链路测试通过。
+
+## 6. 测试与验证
+
+- [x] [CONCEPT: 测试方案] 先补充失败的前端单元测试，覆盖三按钮生成和路由行为。
+  证据：RED 阶段 `workbench-ai-reimbursement-association-gate.test.mjs` 和 `workbench-ai-action-router.test.mjs` 因缺少 `CONTINUE_REIMBURSEMENT_DRAFT_ACTION` 导出失败。
+- [x] [CONCEPT: 测试方案] 实现后运行定向前端测试，记录通过结果。
+  证据：`node --test web/tests/workbench-ai-reimbursement-association-gate.test.mjs`、`node --test web/tests/workbench-ai-action-router.test.mjs`、`node --test web/tests/travel-reimbursement-guided-flow.test.mjs`、`node --test web/tests/travel-reimbursement-review-drawer-switch.test.mjs`、`node --test web/tests/expense-attachment-draft-selection.test.mjs`、`node --test web/tests/attachment-association-confirmation.test.mjs` 均通过。
+- [x] [CONCEPT: 指标与验收] 回看验收点，确认没有旧文案继续出现在新草稿命中态。
+  证据：`workbench-ai-reimbursement-association-gate.test.mjs` 断言新草稿命中态有且仅有三个动作，并不再出现“跳过草稿后再关联申请单”。
+
+## 7. 文档收尾
+
+- [x] [CONCEPT: 指标与验收] 实现完成后更新本 TODO 的证据。
+  证据：本 TODO 已回填实现文件和测试命令。
+- [x] [CONCEPT: 风险与开放问题] 根据实现结果更新剩余风险。
+  证据：`CONCEPT.md` 已记录全量 `code-size-limits` 仍被既有 `TopBar.vue:824` 阻断；本轮文件行数为 `travelReimbursementAssociationGateModel.js:714`、`travelReimbursementDraftBranchModel.js:143`。
+- [x] [CONCEPT: 功能一句话] 确认最终实现没有偏离原始目标。
+  证据：新草稿命中态固定为查看草稿、继续关联草稿、独立新建报销单三个入口。
--- a/document/development/自我进化学习闭环/CONCEPT.md
+++ b/document/development/自我进化学习闭环/CONCEPT.md
@@ -0,0 +1,490 @@
+# X-Financial 自我进化学习闭环方案
+
+更新日期：2026-06-23
+
+## 功能一句话
+
+把 X-Financial 从“规则 + 图谱 + Agent 的智能费控系统”升级为“可持续学习的费控智能体平台”：先通过反馈、回放和影子运行让分析能力变强，再把稳定结论沉淀为可审核、可测试、可回滚的规则、参数和知识资产。
+
+## 背景与问题
+
+当前系统已经具备费用申请、报销、审批、规则中心、知识库、小财管家、数字员工、风险观察、员工画像和财务行为图谱。现有能力已经不是单一算法，而是由多类算法共同形成判断：
+
+- 规则引擎负责执行已上线的制度口径和风险 DSL。
+- 风控图谱负责识别重复票据、拆单、高频、跨部门聚集、同组偏离等风险信号。
+- 员工画像和申请人画像负责建立同组基线、流程质量和历史行为特征。
+- 知识库负责制度检索、引用和政策解释。
+- Agent 编排负责意图识别、流程确认、工具调用和可视化交互。
+
+但如果这些模块只各自运行，系统仍然只是“更自动化的费控工具”。要变成自我进化系统，必须解决几个核心问题：
+
+- 每次命中风险后，系统是否知道人工最终确认、驳回、误报还是漏报。
+- 新规则、新阈值、新权重上线前，是否能用历史样本回放验证。
+- 系统是否能从反复出现的人工反馈中形成候选规则或候选参数。
+- 知识库制度变更后，是否能定位受影响的规则、流程和问答。
+- Agent 回答错误或流程误判后，是否能沉淀为可复盘样本，而不是只改一处文案。
+
+因此，自我进化不是让大模型直接改生产代码或发布规则，而是建立一条受控学习链路：
+
+```text
+运行数据
+  -> 人工反馈 / 审批结果 / 用户纠错
+  -> 标签样本与回放集
+  -> 分析能力校准
+  -> 候选规则 / 候选参数 / 候选知识修订
+  -> 影子运行与历史回放
+  -> 人审发布
+  -> 上线后持续监控
+```
+
+## 核心判断
+
+学习闭环同时让两类能力变强，但顺序不同。
+
+第一层是分析变强。
+
+分析变强指系统越来越知道：
+
+- 哪些风险信号真的值得阻断。
+- 哪些风险只适合提醒或补充说明。
+- 哪些规则在某些部门、费用类型、职级或场景下误报率高。
+- 哪些历史相似单据最终被退回、确认或通过。
+- 哪些同组基线更适合当前单据，而不是简单使用全局均值。
+
+这一层优先影响风险分、置信度、推荐动作、抽检策略、自动化模式和解释质量。
+
+第二层是规则变强。
+
+规则变强指当某类分析结论被足够多的反馈和回放证明稳定后，再沉淀为正式规则、规则修订、例外条件或阈值配置。规则变强必须经过测试和审核，不能由模型直接上线。
+
+推荐顺序是：
+
+```text
+分析先学习
+  -> 形成候选结论
+  -> 回放证明有效
+  -> 人审沉淀为规则或参数
+  -> 规则上线后继续接受反馈
+```
+
+这样可以避免系统过早把偶然反馈固化为生产规则。
+
+## 目标与非目标
+
+### 目标
+
+- 建立统一的学习闭环总纲，串联风险观察、规则反馈、Agent 反馈、审批结果、回放评测和规则中心。
+- 明确“分析进化”和“规则进化”的边界。
+- 让风险分、置信度、推荐动作、抽检策略和自动化模式具备反馈校准依据。
+- 让候选规则、候选参数和候选知识修订进入待审核流程，而不是自动生效。
+- 通过历史回放、影子运行和灰度发布降低自我进化风险。
+- 为后续实现算法评估中心、反馈样本池和候选规则工厂提供架构依据。
+
+### 非目标
+
+- 不让大模型直接修改生产规则、生产数据或核心代码。
+- 不让系统绕过财务、风控或管理员审核自动发布规则。
+- 不把员工画像作为惩罚标签；画像只服务于风险解释、排序和复核辅助。
+- 不把所有学习结果都固化为规则；低置信反馈只进入分析校准和样本池。
+- 不在第一阶段引入复杂机器学习训练平台，优先把样本、标签、回放和门控做稳。
+
+## 现有基础
+
+### 风控图谱
+
+`evaluate_financial_risk_graph()` 已经把单据、员工、部门、费用类型、地点、票据和本体解析合成风险图谱，并输出贡献分、证据、风险等级、置信度、采样策略和决策 trace。
+
+当前贡献分包括：
+
+- `S_rule`：规则信号。
+- `S_anomaly`：同组金额异常。
+- `S_graph`：图谱异常。
+- `S_policy`：制度关联。
+- `S_history`：历史反馈。
+
+这说明系统已经具备“分析可解释”和“反馈可进入评分”的基础。
+
+### 规则中心
+
+风险规则已经支持自然语言生成 JSON 风险规则、DSL 校验、风险评分、样例测试、真实场景试运行、测试报告确认、审核发布、反馈记录和修订版本。
+
+这说明系统已经具备“规则可生成、可测试、可审核、可发布”的基础。
+
+### 风险观察反馈池
+
+`RiskObservation` 和 `RiskObservationFeedback` 已经能记录风险观察、反馈状态、反馈历史、算法版本和证据数据。
+
+这说明系统已经有学习闭环的核心样本载体。
+
+### 回放评测雏形
+
+`AlgorithmReplayCase` 和 `AlgorithmReplaySet` 已经定义了历史单据、本体版本、规则版本、算法版本和反馈标签的回放契约。
+
+这说明系统已经具备把历史风险观察转为评测样本的基础。
+
+### 数字员工
+
+数字员工已有风险图谱巡检、员工画像扫描、反馈样本积累、算法回放评估等任务概念。
+
+这说明后台定时分析能力可以成为学习闭环的执行入口。
+
+## 学习对象分层
+
+### L1. 交互与意图学习
+
+学习对象：
+
+- 用户是否选择了正确流程。
+- 小财管家是否误判申请 / 报销。
+- 直接提交、保存草稿、附件关联、关联申请单等动作是否被用户纠正。
+
+可进化内容：
+
+- 意图识别提示词。
+- 澄清问题策略。
+- 流程确认门控。
+- 推荐动作排序。
+- 前端快捷动作默认项。
+
+禁止直接进化内容：
+
+- 不根据单次对话自动修改规则中心。
+- 不把用户一句话纠错直接变成生产规则。
+
+### L2. 风险分析学习
+
+学习对象：
+
+- 风险观察是否被人工确认。
+- 命中后是否被退回、补件、通过、忽略。
+- 哪些风险信号误报率高。
+- 哪些风险在相似场景下总是漏报。
+
+可进化内容：
+
+- 风险分权重。
+- 置信度计算。
+- 自动化模式门槛。
+- 抽检和回放采样策略。
+- 同组基线选择策略。
+- 风险解释优先级。
+
+禁止直接进化内容：
+
+- 不让系统自动把高风险改成阻断。
+- 不让模型直接替代人工确认违规。
+
+### L3. 规则学习
+
+学习对象：
+
+- 多次确认的风险观察。
+- 反复出现的漏判反馈。
+- 规则测试中的真实场景命中差异。
+- 制度变更引起的规则失配。
+
+可进化内容：
+
+- 候选规则。
+- 规则修订草稿。
+- 例外条件。
+- 阈值建议。
+- 规则适用范围。
+
+必须经过：
+
+- 样例测试。
+- 真实场景试运行。
+- 回放评测。
+- 人工审核。
+- 灰度或发布确认。
+
+### L4. 知识学习
+
+学习对象：
+
+- 知识库问答命中错误。
+- 制度引用缺口。
+- 规则和制度条款不一致。
+- 用户追问中反复出现的政策盲点。
+
+可进化内容：
+
+- 知识文档结构化摘要。
+- 制度条款引用。
+- 问答检索关键词。
+- 规则与制度条款绑定。
+
+禁止直接进化内容：
+
+- 不让模型编造制度。
+- 不让模型用未审核知识覆盖正式制度。
+
+## 闭环架构
+
+### 1. 事件采集层
+
+统一采集以下事件：
+
+- 风险观察生成。
+- 规则命中和未命中。
+- 审批通过、退回、驳回、补件。
+- 风控人员反馈确认、误报、漏报、不清楚。
+- 用户对 Agent 回答的低分反馈。
+- 规则测试、试运行和发布结果。
+- 知识库检索命中和无结果。
+
+每个事件都应绑定：
+
+- 业务对象：申请单、报销单、票据、员工、部门、规则。
+- 版本信息：算法版本、规则版本、本体版本、知识版本。
+- 执行上下文：run_id、conversation_id、task_id。
+- 处理结果：人工动作、审批状态、反馈标签。
+
+### 2. 标签与样本层
+
+将原始事件转为标准标签：
+
+- `confirmed`：风险被确认。
+- `false_positive`：误报。
+- `false_negative`：漏报。
+- `unclear`：证据不足。
+- `over_blocked`：阻断过度。
+- `manual_override`：人工覆盖系统建议。
+- `policy_changed`：制度变化导致旧判断失效。
+
+同时形成三类样本池：
+
+- 分析校准样本：用于调整风险分、置信度和推荐动作。
+- 回放评测样本：用于新算法、新规则、新权重上线前验证。
+- 规则候选样本：用于生成或修订规则草稿。
+
+### 3. 离线评估层
+
+定期对候选算法、候选规则、候选参数运行回放。
+
+关键指标：
+
+- 确认率：命中后被人工确认的比例。
+- 误报率：命中后被标记误报的比例。
+- 漏报率：人工发现风险但系统未命中的比例。
+- 阻断准确率：阻断动作最终被确认合理的比例。
+- 人工负担：进入人工复核的单据比例。
+- 解释完整率：风险观察是否包含规则、证据、基线和相似案例。
+- 数据质量通过率：字段完整性、票据 OCR、申请关联等基础数据质量。
+
+### 4. 候选生成层
+
+系统只能生成候选，不直接生效。
+
+候选类型：
+
+- 候选规则：来自反复确认的风险观察或漏判样本。
+- 候选规则修订：来自误报较高的规则反馈。
+- 候选参数：来自权重、阈值、置信度、自动化门槛的评估结果。
+- 候选知识修订：来自制度引用缺口或知识问答低分反馈。
+
+每个候选必须包含：
+
+- 来源样本。
+- 触发原因。
+- 预期改善指标。
+- 可能副作用。
+- 回放结果。
+- 推荐发布方式。
+
+### 5. 发布门控层
+
+发布顺序：
+
+```text
+候选
+  -> 样例测试
+  -> 历史回放
+  -> 影子运行
+  -> 人工审核
+  -> 灰度启用
+  -> 全量发布
+  -> 上线后监控
+```
+
+影子运行期间，新规则或新参数只记录“如果启用会发生什么”，不影响真实审批。
+
+灰度启用期间，只对指定部门、费用类型或测试公司生效。
+
+全量发布后，必须持续监控误报、漏报、阻断和人工覆盖。
+
+## 数据与版本要求
+
+每条学习样本至少保留：
+
+- `sample_id`
+- `sample_type`
+- `subject_type`
+- `subject_id`
+- `business_stage`
+- `risk_signal`
+- `rule_code`
+- `algorithm_version`
+- `rule_version`
+- `ontology_version`
+- `knowledge_version`
+- `input_snapshot`
+- `decision_trace`
+- `expected_label`
+- `actual_label`
+- `feedback_source`
+- `feedback_actor`
+- `created_at`
+
+每次算法或规则评估至少保留：
+
+- `evaluation_id`
+- `candidate_type`
+- `candidate_version`
+- `baseline_version`
+- `replay_set_id`
+- `sample_count`
+- `metrics_before`
+- `metrics_after`
+- `regression_cases`
+- `approval_status`
+
+## 推荐实施路径
+
+### 第一阶段：补齐评估地基
+
+目标是让系统知道自己判断得好不好。
+
+- 统一风险观察反馈标签。
+- 把审批结果、退回原因、补件动作写入风险样本池。
+- 将 Agent 低分反馈归因到意图识别、流程路由、知识问答、规则解释、附件处理等类别。
+- 建立回放集生成任务，把风险观察和反馈状态转成评测样本。
+- 在数字员工工作记录中展示反馈样本摘要和回放评估摘要。
+
+### 第二阶段：分析进化
+
+目标是先让判断更稳。
+
+- 将风险图谱权重、置信度门槛、自动化模式门槛迁移到版本化配置。
+- 基于反馈样本计算规则、风险信号、费用类型、部门维度的误报率和确认率。
+- 对高误报规则降低默认动作等级，对高确认规则提高抽检优先级。
+- 增强同组基线选择，优先使用部门、职级、费用类型、供应商等可解释维度。
+- 引入影子参数评估，只记录差异，不直接影响生产。
+
+### 第三阶段：规则进化
+
+目标是把稳定结论沉淀为规则资产。
+
+- 从 confirmed 和 false_negative 样本中生成候选规则。
+- 从 false_positive 样本中生成候选例外条件或适用范围收缩建议。
+- 候选规则自动进入规则中心草稿，不自动发布。
+- 草稿必须完成样例测试、真实场景试运行和测试报告确认。
+- 已上线规则只能通过修订版本替换。
+
+### 第四阶段：知识进化
+
+目标是让制度、规则和问答保持一致。
+
+- 对知识库无结果、低分反馈和制度引用缺口做聚类。
+- 自动生成知识修订建议或制度引用补充建议。
+- 标记受影响规则和问答范围。
+- 由制度管理员确认后再更新知识库或规则引用。
+
+### 第五阶段：灰度自进化
+
+目标是在受控范围内逐步提高自动化程度。
+
+- 为低风险、高置信、高证据完整度场景开放自动提醒或自动补件建议。
+- 为高风险场景继续保持人工复核或阻断确认。
+- 每个自动化动作都必须可解释、可撤回、可追踪。
+- 自动化范围随反馈质量逐步扩大。
+
+## 产品边界
+
+自我进化系统里，人和系统的职责要明确。
+
+系统负责：
+
+- 发现模式。
+- 聚合证据。
+- 生成候选。
+- 运行回放。
+- 计算指标。
+- 提醒风险。
+- 记录全链路证据。
+
+人负责：
+
+- 确认制度口径。
+- 审核规则发布。
+- 判断复杂业务例外。
+- 决定阻断、退回或放行。
+- 对候选改进做最终确认。
+
+大模型负责：
+
+- 语义理解。
+- 候选规则草稿。
+- 解释生成。
+- 知识摘要。
+- 反馈归因辅助。
+
+大模型不负责：
+
+- 最终违规判定。
+- 自动发布规则。
+- 自动修改生产代码。
+- 绕过审核执行高风险动作。
+
+## 验收指标
+
+第一阶段验收：
+
+- 风险观察反馈、规则反馈、Agent 反馈能统一进入样本池。
+- 回放集能按算法版本、规则版本、本体版本构建。
+- 风险看板能展示确认率、误报率、反馈样本数和待回放样本数。
+
+第二阶段验收：
+
+- 风险分、置信度和自动化动作的调整都有反馈证据。
+- 新参数可以影子运行并产生差异报告。
+- 高误报规则能被识别并生成修订建议。
+
+第三阶段验收：
+
+- 系统能从反馈样本生成候选规则或候选修订。
+- 候选规则能进入规则中心草稿。
+- 候选规则必须通过测试报告确认后才允许发布。
+
+第四阶段验收：
+
+- 知识问答低分反馈能定位到知识缺口。
+- 制度变更能提示受影响规则和问答范围。
+- 知识修订必须保留来源和审核记录。
+
+## 风险与防护
+
+- 反馈噪音：单次反馈不能直接改规则或参数，必须聚合后进入候选。
+- 误报固化：规则上线前必须跑历史回放和影子运行。
+- 模型幻觉：所有制度、规则和风险结论必须绑定来源证据。
+- 自动化越权：阻断、退回、发布规则等高风险动作必须人工确认。
+- 数据漂移：长期监控样本量、字段缺失率、费用分布和 OCR 质量。
+- 版本混乱：算法、规则、本体、知识和回放集必须带版本号。
+
+## 与现有文档关系
+
+- `document/development/hermes-risk-graph-algorithm/CONCEPT.md`：负责风险图谱算法和风险观察模型。
+- `document/development/risk-rule-explainable-flow/CONCEPT.md`：负责风险规则 DSL、解释、测试和发布流程。
+- `document/development/数字员工能力库扩展/CONCEPT.md`：负责数字员工技能边界和后台分析任务。
+- 本文档负责把上述能力串成“自我进化学习闭环”的总体路线。
+
+## 结论
+
+X-Financial 的自我进化应先让分析变强，再让规则变强。
+
+分析变强是低风险、高收益的第一步：它通过反馈、回放和影子运行持续校准风险分、置信度、动作建议和解释质量。
+
+规则变强是第二步：只有当分析结论经过足够样本验证后，才沉淀为正式规则、规则修订或参数版本，并通过测试、人审和灰度发布进入生产。
+
+最终目标不是“系统自己随便改规则”，而是形成一条可审计、可回放、可控发布的学习链路，让系统越用越懂企业自己的财务控制口径。