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 微调服务配置
This commit is contained in:
caoxiaozhu
2026-06-24 10:42:57 +08:00
parent ee730aa31c
commit f9553a6a1a
58 changed files with 1551 additions and 1404 deletions

View File

@@ -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. 找不到草稿、低置信度、源文件缺失时,消息能给出明确原因。

View File

@@ -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` 返回自定义任务失效提示。

View File

@@ -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个人工作台和报销助手页面均已接入“继续关联草稿”和“独立新建报销单”的后续提示。

View File

@@ -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: 功能一句话] 确认最终实现没有偏离原始目标。
证据:新草稿命中态固定为查看草稿、继续关联草稿、独立新建报销单三个入口。

View File

@@ -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 的自我进化应先让分析变强,再让规则变强。
分析变强是低风险、高收益的第一步:它通过反馈、回放和影子运行持续校准风险分、置信度、动作建议和解释质量。
规则变强是第二步:只有当分析结论经过足够样本验证后,才沉淀为正式规则、规则修订或参数版本,并通过测试、人审和灰度发布进入生产。
最终目标不是“系统自己随便改规则”,而是形成一条可审计、可回放、可控发布的学习链路,让系统越用越懂企业自己的财务控制口径。

View File

@@ -0,0 +1,3 @@
user1: caoxiaozhu@xf.com / 123456
User2: xiangwanhong@xf.com / 123456
Admin: admin/ admin

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.5 MiB

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 183 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 266 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 206 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 209 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 172 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 138 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 135 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 149 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 153 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 296 KiB

View File

@@ -1,18 +0,0 @@
# Work Log - 2026-05-06
## 今日工作
### 下午
- **修复了 Windows Git Bash 启动脚本报错问题**
- 问题:虚拟环境指向不存在的 python3
- 解决:添加检测函数,无效则重建
- **创建了 work-log 技能**
- 自动记录工作日志
---
# 待处理
- [ ] 安装 PostgreSQL
- [ ] 创建 x_financial 数据库

View File

@@ -1,36 +0,0 @@
# Work Log - 2026-05-07
## 今日工作
- **提交 c00db75** (11:50)
- feat: add employee management, backend health check, and UI improvements
- 完成了员工管理模块(后端 + 前端)
- 添加了后端健康检查
- 整理了 UI 资源
- **提交 2d56bc2** (13:48)
- feat: enhance employee CRUD with search, filters, and security module
- 增强了员工搜索和筛选功能
- 添加了安全模块security.py
- 添加了单元测试
- **提交 b8ba0ea** (14:32)
- feat: add auth module with login and access control
- 为系统实现了完整的登录认证功能
- 后端使用 FastAPI 搭建了 auth 服务,支持管理员密钥验证
- 前端对接了登录接口,实现了 Token 存储和自动登录逻辑
- 设计并实现了基于角色的访问控制RBAC区分超级管理员和普通员工
- **提交 e8f3d97** (15:18)
- feat: add settings page with navigation and access control updates
- 搭建了系统设置页面,支持管理员配置系统参数
- 优化了侧边栏导航交互,增加了收起/展开的流畅动画
- 将访问控制规则统一收敛到 accessControl.js避免散落各处
- 统一了 useSystemState 和 useNavigation 两个 composable 的职责
---
# 待处理
- [ ] 安装 PostgreSQL
- [ ] 创建 x_financial 数据库

View File

@@ -1,30 +0,0 @@
# Work Log - 2026-05-08
## 今日工作
- **提交 adda87a** (08:56)
- feat: add system settings with model connectivity and encrypted storage
- 为系统设置页面新增了配置管理功能,支持管理员修改 AI 模型连接参数
- 引入加密存储方案secret_box.py对敏感配置如 API Key使用对称加密保护
- 后端新增 settings 端点、repository 层和 service 层,实现配置的增删改查
- 新增 model_connectivity.py 服务,支持测试 AI 模型连接是否正常
- 前端设置页面大幅重构,增加了模型配置表单和连接测试功能
- 新增数据库表 system_setting 和 system_setting_secret 存储配置和加密值
- 编写了 settings 相关的单元测试,确保配置持久化和服务逻辑正确
- **提交 c5486dd** (10:52)
- feat: 启用后端自动启动与 Setup 引导流程增强
- 启用了后端自动启动功能,用户访问前端时后端自动拉起,无需手动启动 server
- 增强了 Setup 引导流程,新增后端启动进度追踪,分 5 步展示config → deps → server → health → done
- 网络绑定从 127.0.0.1 扩展到 0.0.0.0,支持远程浏览器访问部署的系統
- API URL 动态化,通过 localStorage 持久化配置,支持运行时修改
- 新增后端启动探针probe自动检测后端就绪状态后才允许浏览器继续操作
- Setup 表单智能判断浏览器 host将本地地址自动转换为 0.0.0.0 供远程访问
- **提交 8656866** (11:14)
- feat: 重构模型配置存储与 API Key 加密管理
- 新增 SystemModelSetting 模型slot 为 PK支持 main/backup/vlm/embedding 四个模型槽位配置
- 废弃旧的加密存储方案,改用更规范的数据库表存储加密的 API Key
- 兼容旧版 admin secret 格式,将历史密码记录迁移到标准 scrypt 哈希格式
- 前端 API URL 智能解析,当后端配置为回环地址但浏览器非回环时,自动使用浏览器 host 访问
- 改进 API Key 输入体验,聚焦时自动清除遮罩显示,并提示已从数据库加载密钥

View File

@@ -0,0 +1,17 @@
# 2026-05-23 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`575f093`
## 工作内容
- 新增风险规则生成引擎,支持从知识、规则资产和业务上下文中生成风险规则草案。
- 增强知识图谱可视化能力,补充知识摄取日志图谱节点、证据和运行信息展示。
- 扩展审计页、日志详情页和归档中心交互,便于追踪规则生成、知识索引和报销会话链路。
- 补充风险规则生成、知识摄取日志、报销引导流程等测试覆盖。
## 提交记录
- `575f093` feat: 新增风险规则生成引擎与知识图谱可视化

View File

@@ -0,0 +1,18 @@
# 2026-05-24 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`50b1c3f`
## 工作内容
- 增强规则资产管理能力,引入规则测试、规则流图和运行时调试相关页面能力。
- 新增 Hermes Agent 相关架构、数据库、风险扫描、报销报告和部署说明文档。
- 扩展 Hermes 配置、报告、风险扫描、调度等后端模型和服务。
- 新增文档中心页面与时间工具,优化审计页、日志页、设置页和导航交互。
- 清理旧风险规则文件并补充知识解析、RAG、规则生成和用户代理服务测试。
## 提交记录
- `50b1c3f` feat: 增强规则资产管理与审计页面运行时调试

View File

@@ -0,0 +1,18 @@
# 2026-05-25 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`d0e946c`
## 工作内容
- 完善文档中心和报销申请链路,新增首页参考稿并优化侧边栏结构。
- 抽取用户代理申请服务,增强报销单、申请单、本体识别和编排流程。
- 强化文档中心未读状态、侧边栏入口、详情提醒和申请预填能力。
- 优化报销创建页、差旅详情页和小财管家会话状态。
- 补充文档中心、申请提交确认、助手建议动作、侧边栏折叠等测试。
## 提交记录
- `d0e946c` feat: 完善文档中心与报销申请交互及侧边栏重构

View File

@@ -0,0 +1,20 @@
# 2026-05-26 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`0e861d8``df49103`
## 工作内容
- 增强风险规则生成引擎和预算中心页面,打通预算中心本体、风险规则评分和预算后端服务。
- 新增差旅风险规则库,补充预算实体、预算服务、预算图表和预算中心视图。
- 完善预算中心图表展示、确认对话框和费用管控交互。
- 扩展规则资产、员工、报销申请、审批和预算相关测试,覆盖新引擎与预算链路。
## 提交记录
- `0e861d8` feat: 增强风险规则生成引擎与预算中心页面
- `e1e515e` feat: 新增预算中心本体与风险规则评分回填
- `e7bef08` feat: 新增预算后端服务与差旅风险规则库
- `df49103` feat: 完善预算中心图表与确认对话框交互

View File

@@ -0,0 +1,22 @@
# 2026-05-27 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`2dcc721``d4d5d40`
## 工作内容
- 重构全局 UI 主题皮肤与样式模块,统一页面视觉基线。
- 优化报销创建页面样式和洞察面板交互,提升申请与报销过程的可读性。
- 新增预算助手报告组件,补强预算报告、报销交互细节和申请关联能力。
- 完善审批退回流程与报销申请关联逻辑。
- 新增预算费控模型和报销审批流引擎,为后续动态审批与预算分析打基础。
## 提交记录
- `2dcc721` style: 全局 UI 主题皮肤重构与样式模块化
- `b1a9c8a` fix: 优化报销创建页面样式与洞察面板交互
- `7d32eae` feat: 新增预算助手报告组件并优化报销交互细节
- `cbb98f4` feat: 完善审批退回流程与报销申请关联
- `d4d5d40` feat: 新增预算费控模型与报销审批流引擎

View File

@@ -0,0 +1,21 @@
# 2026-05-28 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`04cd6d0``064eeb6`
## 工作内容
- 重构工作台首页,新增数字员工管理页面和员工行为画像算法。
- 引入费用风险标签体系、员工画像标签分页和 ECharts 统一图表能力。
- 在列表详情页面引入共享 shell并逐步拆分审计列表、详情和模型逻辑。
- 备份列表详情 shell 重构前工作区,降低大规模 UI 抽取风险。
## 提交记录
- `04cd6d0` feat: 新增数字员工管理页面与工作台首页重构
- `8a4a777` feat: 新增员工行为画像算法与费用风险标签体系
- `e384318` feat: 引入 ECharts 统一图表并完善员工画像标签分页
- `b383244` chore: backup workspace before list detail shell refactor
- `064eeb6` refactor(ui): introduce shared list detail shells

View File

@@ -0,0 +1,21 @@
# 2026-05-29 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`99e9079``4c59941`
## 工作内容
- 拆分审计列表详情流程和模型,复用共享列表 shell降低重复 UI 结构。
- 完成共享 shell 与加载状态收口,统一页面加载、空态和列表体验。
- 统一后端分页查询接口与前端服务层适配。
- 新增票据夹模块,优化 OCR、员工画像和票据相关服务。
## 提交记录
- `99e9079` refactor(audit): split list detail flows
- `64cc76c` refactor(audit): reuse list shells and split models
- `e080105` feat(ui): finalize shared shells and loading states
- `678f64d` feat: 统一后端分页查询与前端服务层适配
- `4c59941` feat: 新增票据夹模块并优化 OCR 与员工画像服务

View File

@@ -0,0 +1,18 @@
# 2026-05-30 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`7989f3a`
## 工作内容
- 新增风险图谱算法能力,围绕风险节点、关系和来源构建设计与实现文档。
- 扩展系统仪表盘和操作反馈体系,提升风险与业务操作的可解释性。
- 增强规则资产、风险规则模拟、员工、申请和审批相关服务。
- 更新前端预算中心、审计、工作台、差旅申请和详情页等模块。
- 补充文档、测试和运行资产,支撑风险图谱与仪表盘演示。
## 提交记录
- `7989f3a` feat: 新增风险图谱算法与系统仪表盘及操作反馈体系

View File

@@ -0,0 +1,18 @@
# 2026-06-01 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`92444e7`
## 工作内容
- 扩展风险规则体系,增强规则生成、规则执行、复合规则和本体字段治理能力。
- 新增审批动态路由能力,补强申请审批、报销审批和流程转派场景。
- 推进预算中心列表化改造,配套更新预算、审计、文档中心和工作台页面。
- 更新项目协作规范、环境配置和规则表资产。
- 补充风险规则、本体、审批、文档中心和申请流程相关测试。
## 提交记录
- `92444e7` feat: 扩展风险规则体系、审批动态路由与预算中心列表化改造

View File

@@ -0,0 +1,18 @@
# 2026-06-02 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`ca691f3``0c74b4a`
## 工作内容
- 优化差旅报销预审流程和个人工作台 UI 体系,增强申请、报销和智能助手联动。
- 重构财务看板口径,补充半年模拟数据和报销状态注册表。
- 扩展财务看板、风险看板、员工画像、工作台、差旅详情和申请创建页面。
- 补充模拟数据、状态口径、看板展示和报销流程相关测试。
## 提交记录
- `ca691f3` feat: 优化差旅报销预审流程与个人工作台 UI 体系
- `0c74b4a` feat: 财务看板口径重构与半年模拟数据及报销状态注册表

View File

@@ -0,0 +1,49 @@
# 2026-06-03 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`faa39e6``87da5df`
## 工作内容
- 建设数字员工财务报告体系、定时提醒和看板快照调度能力。
- 优化风险看板、数字员工看板、预算与风险卡片、共享加载态和仪表盘展示。
- 完善工作台费用进度、费用统计详情弹窗、分布图、画像雷达和个人工作台标签展示。
- 推进本体字段治理和风险规则模板执行器重构。
- 优化申请与报销流程,包括申请关联限制、交通方式显式要求、手工明细入口收口和管理员工作台权限。
- 完善文档中心未读状态、铃铛通知、排序、全部已读和顶部通知持久化。
- 细化风险可见性和审核人风险提示,修复规则标准调整后的风险说明保留问题。
## 提交记录
- `faa39e6` test(dashboard): cover shared loading overlay
- `d060f89` style(dashboard): reuse shared loading overlay
- `0d6327a` feat(dashboard): polish risk and digital employee boards
- `15006a0` feat: 数字员工财务报告体系与定时提醒及看板快照调度
- `27dd2f0` feat(dashboard): reorganize budget and risk cards
- `6fc5e66` feat(workbench): show progress update time first
- `3130c42` feat(workbench): separate stale progress items
- `20cb60e` feat(workbench): add expense stats detail modal
- `31052d0` feat(workbench): keep progress detail return context
- `74d488a` fix(workbench): center progress expense type
- `18d716b` feat(workbench): show expense distribution as donut chart
- `e12b140` fix(workbench): show single expense distribution chart
- `34457f9` feat: 本体字段治理与风险规则模板执行器重构
- `8887cf5` fix(workbench): stretch profile tag card
- `04f0951` fix: restrict application linking for reimbursement drafts
- `59d3bf0` fix(auth): keep admin out of personal workbench
- `9219854` fix: require explicit transport mode for applications
- `513ff90` fix: remove manual expense detail add action
- `4717ee6` fix(documents): refine unread badges and mark all read
- `8c2f301` fix(documents): sort newest rows first
- `c73178b` fix(documents): move unread notice into bell
- `95956af` fix(notifications): refine bell notification center
- `9c24a85` fix(workbench): remount expense stats chart on reopen
- `67b81a1` fix(workbench): replay profile radar animation
- `8e24775` fix: handle risk explanation standard adjustment
- `cb36d78` fix: 优化顶部导航栏布局与工作台摘要展示并清理旧票据数据
- `0f8bc40` fix: preserve reviewer risk notice after standard adjustment
- `b9826a1` fix: keep adjusted risks visible to reviewers
- `75d5c17` feat(workbench): persist topbar notification state
- `87da5df` feat: 风险可见性控制与差旅详情页交互优化

View File

@@ -0,0 +1,18 @@
# 2026-06-04 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`1cbf3fe``f60ceba`
## 工作内容
- 增强报销预审会话状态管理,优化工作台与报销创建页交互。
- 完善小财管家意图规划、管家计划和报销提交编排。
- 扩展用户代理、编排器、差旅报销会话、提交组合器和申请预填相关能力。
- 补充小财管家计划、报销预审、提交编排和工作台交互测试。
## 提交记录
- `1cbf3fe` feat: 报销预审会话状态管理与工作台交互增强
- `f60ceba` feat: 小财管家意图规划与报销提交编排增强

View File

@@ -0,0 +1,18 @@
# 2026-06-06 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`e124e4b`
## 工作内容
- 重构报销审批流,贯通小财管家计划、报销预审、申请提交和审批链路。
- 扩展管家计划流式接口、报销单服务、申请草稿、风险提示和上下文工具。
- 优化工作台 AI 模式、差旅报销创建页、申请详情页和文档中心交互。
- 更新 Docker、环境配置和忽略规则配合新流程运行。
- 补充大量后端、前端和端到端测试,覆盖审批流、预算分析、申请确认和工作台入口。
## 提交记录
- `e124e4b` feat: 报销审批流重构与管家计划全链路贯通

View File

@@ -0,0 +1,18 @@
# 2026-06-09 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`25724c3`
## 工作内容
- 同步报销流程和工作台近期改动,继续完善申请、报销、风险建议与工作台协同。
- 调整 Docker、GPU、Postgres 和环境配置,适配本地与容器化运行。
- 补充移动端相关资源和前端页面改动。
- 更新服务端报销、员工、本体、规则、用户代理和审批链路实现。
- 扩展工作台、申请详情、报销创建、审计和文档中心相关测试。
## 提交记录
- `25724c3` feat: 同步报销流程与工作台改动

View File

@@ -0,0 +1,15 @@
# 2026-06-12 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`336fee9`
## 工作内容
- 更新仓库忽略规则,将 `.superpowers` 工具缓存目录排除出版本管理。
- 降低本地代理工具缓存误入库风险。
## 提交记录
- `336fee9` chore: 忽略 .superpowers 工具缓存目录

View File

@@ -0,0 +1,17 @@
# 2026-06-13 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`8b952c9`
## 工作内容
- 拆分差旅报销创建工作流,降低单页脚本和流程模型复杂度。
- 抽取差旅报销草稿、提示动作、附件、会话状态和提交组合等前端逻辑。
- 强化报销创建页的可维护性,为后续 AI 工作台与报销流程复用做准备。
- 补充报销创建、会话状态、建议动作和附件流程测试。
## 提交记录
- `8b952c9` refactor(travel): split reimbursement create workflow

View File

@@ -0,0 +1,19 @@
# 2026-06-15 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`5747e85``9f7b8b4`
## 工作内容
- 恢复上传阶段规则中心复核,确保附件上传时的风险识别链路有效。
- 修正报销明细和风险建议对齐问题,让风险提示能对应到具体费用行。
- 细化差旅报销小财管家流程,覆盖申请、报销、计划、回显和提交流程。
- 更新规则表、后端服务、前端工作台和差旅报销创建页,补齐流程测试。
## 提交记录
- `5747e85` fix(risk): restore upload-time rule center review
- `7927417` fix(claim): align risk advice with expense rows
- `9f7b8b4` Refine travel reimbursement steward flow

View File

@@ -0,0 +1,26 @@
# 2026-06-17 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`470f343``b8915a2`
## 工作内容
- 收窄差旅路线风险指标,减少误报并统一风险标记口径。
- 调整 Web 端口配置,补充工具临时目录忽略规则。
- 重构报销审批流,优化差旅详情、风险建议卡片和文档中心交互。
- 更新财务差旅与通信费用规则表。
- 同步报销审批流和预算分析测试。
- 归档用户报销票据附件,清理运行资产边界。
## 提交记录
- `470f343` fix(expense): narrow travel route risk indicators
- `0d525fa` chore: 忽略 .codex-temp 工具临时目录
- `09a66c7` chore: 将 web 端口由 5173 调整为 5273
- `1f4681f` feat(claim): 重构报销审批流并收敛风险标记
- `a3e5295` feat(rules): 更新财务差旅与通信费用规则表
- `0fac8b6` feat(web): 优化差旅详情、风险建议卡片与文档中心交互
- `4199feb` test: 同步报销审批流与预算分析测试
- `b8915a2` chore(storage): 归档用户报销票据附件

View File

@@ -0,0 +1,32 @@
# 2026-06-18 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`cce19e4``4d04f4e`
## 工作内容
- 完善 Steward 业务无关输入拦截,支持 `off_topic` 计划、前端引导话术和场景细分。
- 增强服务端启动 bootstrap、缓存预热和登录目录并发幂等控制。
- 仅放行财务业务相关问题的信号校验,强化业务边界。
- 更新差旅、通信等财务规则表,并清理用户历史报销票据附件。
- 优化工作台 AI 模式、差旅/风险建议交互、用户消息气泡和引用图标。
- 新增 X-Financial 改进路线图,补充未来改进方向。
- 更新忽略规则,避免 `.env``.nezha``.omo` 等本地或敏感配置入库。
## 提交记录
- `cce19e4` feat(steward): 拦截业务无关输入返回 off_topic 计划
- `4343253` feat(steward): 前端支持 off_topic 与引导话术
- `c28e99b` chore(gitignore): 忽略 .nezha/ 与 .omo/ 本地工具目录
- `38653fa` chore(storage): 清理用户历史报销票据附件
- `35372c6` feat(rules): 更新差旅与通信费用等财务规则表
- `59ba76c` feat(startup): 服务端启动 bootstrap 与缓存预热
- `3f17619` fix(auth): 登录目录就绪幂等化与并发控制
- `127d603` feat(ontology): 仅放行财务业务相关问题的信号校验
- `a6674a1` feat(steward): off_topic 场景细分与引导回复
- `0cde1f8` feat(web): 工作台 AI 模式与差旅/风险建议交互优化
- `a2f67af` docs: 新增 X-Financial 改进路线图
- `3131112` style(web): 调整 AI 模式用户消息气泡布局与引用图标
- `4d04f4e` chore(gitignore): 忽略 .env 防止敏感配置入库

View File

@@ -0,0 +1,27 @@
# 2026-06-20 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`3d69f85``3b74a33`
## 工作内容
- 细化申请单阶段风险可见性并更新规则表。
- 拆分工作台 AI 模式报销预审和文档查询模型。
- 新增申请核对预览快速建单接口,并统一平台管理员判定。
- 接入 AI 工作台申请预览动作,支持申请单草稿保存和删除权限统一。
- 将单号规则收紧为 `A/R/D + 8 位` 紧凑格式,并适配后端测试。
- 增强 AI 工作台会话、文档卡片渲染和 AI 文档查询卡片。
## 提交记录
- `3d69f85` feat(risk): 申请单阶段风险可见性细化与规则表更新
- `304bbe1` feat(web): 工作台 AI 模式报销预审与文档查询模型拆分
- `729d833` feat(server): 新增申请核对预览快速建单接口与平台管理员判定统一
- `96c2e10` feat(web): 统一平台管理员判定与 AI 工作台申请预览动作接入
- `47c6a4b` refactor(server): 单号规则收紧为 A/R/D+8 位紧凑格式
- `81e990a` feat(server): 申请单支持草稿保存并统一删除权限口径
- `0cda750` feat(web): AI 工作台会话与文档卡片渲染增强
- `8158716` test(server): 适配 A/R/D 紧凑单号格式
- `3b74a33` feat(web): AI 文档查询卡片重构与单号判定统一

View File

@@ -0,0 +1,24 @@
# 2026-06-21 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`8b34954``08a4fa3`
## 工作内容
- 增强 AI 文档详情引用解析和查询卡片展示。
- 优化差旅申请详情进度 viewer、审批信息、加载态和领导意见事件样式。
- 移除顶栏 AI 快捷操作区,让非首页顶栏更收敛。
- 优化 OCR 处理PDF 文本层可用时跳过 worker 调用,并补装 `poppler-data`
- 将 AI 工作台附件改为卡片化展示,支持单项移除并适配卡片样式与交互。
## 提交记录
- `8b34954` feat(web): AI 文档详情引用解析与查询卡片增强
- `24b5b71` feat(web): 差旅申请详情进度 viewer 与审批/加载态组件增强
- `1986b0d` style(web): 移除顶栏 AI 快捷操作区并优化差旅领导意见事件样式
- `88e91a5` feat(ocr): PDF 文本层可用时跳过 worker 调用并补装 poppler-data
- `669d22e` feat(web): 差旅领导意见事件结构化与申请审批信息增强
- `d660a96` feat(web): AI 工作台附件改为卡片化展示并支持单项移除
- `08a4fa3` style(web): AI 工作台附件卡片样式与交互适配

View File

@@ -0,0 +1,28 @@
# 2026-06-22 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`6d33ba5``bc743ad`
## 工作内容
- 执行 800 行源码限制重构拆分服务、组件、composable、工具函数和测试辅助模块。
- 拆分 Docker 主应用编排和完整本地栈,补充 Docker 说明、重构计划和 UI 参考图。
- 更新差旅、交通、通信等财务规则表。
- 恢复差旅详情子组件样式。
- 扩展报销单输出工号/邮箱,并支持申请人邮箱前缀匹配。
- 新增报销单关联申请单门控和草稿检测流程。
- 增强申请单预览编辑器和报销流程细节。
## 提交记录
- `6d33ba5` refactor: enforce 800 line source limits
- `607e127` chore(docker): 拆分主应用编排与完整本地栈
- `e42deda` docs: 同步 Docker 编排说明并补充重构计划与 UI 参考
- `103f225` chore(rules): 更新差旅/交通/通信等财务规则表
- `1b04ee1` fix(web): restore travel detail child component styles
- `aa965da` feat(server): 报销单输出工号/邮箱并扩展申请人邮箱前缀匹配
- `ba444a5` feat(web): 报销单新增关联申请单门控与草稿检测流程
- `ded8b39` feat(web): 申请单预览编辑器增强与报销流程细节适配
- `bc743ad` chore(rules): 更新公司通信费报销规则表

View File

@@ -0,0 +1,28 @@
# 2026-06-23 工作日志
## 远端依据
- 分支:`origin/main`
- 提交:`84a8998``73966b3`
## 工作内容
- 新增票据文件夹资产缓存和统一文档预览生成,完善 OCR、票据夹和附件分析链路。
- 前端接入票据夹资产缓存,完善 AI 工作台附件流程、智能入口识别和草稿附件选择。
- 统一 `WEB_PORT` 回退到 `5173`,并让烟雾检查支持开关。
- 更新交通、通信、差旅、出差等财务规则表。
- 重构通知中心列表行布局和时间标签格式。
- 移除误跟踪的 `expense_claims` 运行时票据文件。
- 修复孤儿申请预览消息,触发重新生成可编辑表格。
- 合并财务工作流模块抽取申请事实解析、Steward 计划拆分、可信 HTML、加载状态和文档协议常量。
## 提交记录
- `84a8998` feat(server): 票据文件夹资产缓存与文档预览统一生成
- `e725b7f` feat(web): 票据夹资产缓存接入与 AI 工作台附件流程完善
- `dc4cad2` chore(env): WEB_PORT 统一回退为 5173 并烟雾检查改为可开关
- `0122f3b` chore(rules): 更新交通/通信/差旅/出差等财务规则表
- `8094333` style(web): 通知中心列表行布局重构与时间标签格式化
- `f17098a` chore(repo): 移除误跟踪的 expense_claims 运行时票据文件
- `1f40ce3` fix(web): 孤儿申请预览消息触发重新生成可编辑表格
- `73966b3` refactor: consolidate finance workflow modules

View File

@@ -0,0 +1,138 @@
# 2026-06-24 工作日志
## 当日工作内容
- 09:41我开始为 X-Financial 补一个专门写修改日志的项目级 Skill目标是让后续每次 bugfix、新功能、重构或配置/文档修改之后,都能留下有时间、有操作、有判断的增量记录。
- 修改:新增 `agent-change-log` Skill约定触发场景、每日日志位置、三段式结构、TODO 勾选规则和拟人化记录方式。
- 修改:新增 Skill 展示元数据,方便后续通过 `$agent-change-log` 识别和调用。
- 修改:准备把 `AGENTS.md` 接上强触发规则,避免后续代理只记得“写代码”而忘了“写修改记录”。
- 操作:沿用既有 `document/work-log/YYYY-MM-DD.md` 日志目录,不另起一套新路径,避免历史记录分裂。
- 验证09:42 已补做结构检查,见下一条记录。
- 影响:后续修改会从“最终总结”升级为“过程可追踪”,当天工作内容、遗留问题和 TODO 会随着每轮修改持续增长。
- 09:42我按刚写好的 `agent-change-log` 规则做了第一次自检,并把验证结果回填到当天日志里。
- 操作:运行 `git diff --check` 检查本轮涉及文件的空白问题。
- 操作:用 `rg` 检查 Skill frontmatter、`AGENTS.md` 触发规则,以及日志中的 `当日工作内容``遗留问题``TODO` 三个固定标题。
- 验证:`git diff --check` 无输出,说明补丁没有空白错误;`rg` 能命中 `agent-change-log`、日志路径和三段式标题。
- 影响:这个日志 Skill 已经有了可执行的触发条件、固定记录位置和第一次样例记录,后续修改可以直接照这个格式增量追加。
- 09:43我继续检查了新 Skill 的版本管理可见性,确认它已经落在本机项目目录,但默认会被 `.gitignore` 忽略。
- 操作:运行 `git check-ignore -v` 检查 `.codex/skills/agent-change-log/SKILL.md``agents/openai.yaml` 的忽略来源。
- 验证:命中 `.gitignore:10:.codex/`,说明普通 `git status` 不会显示这个新 Skill`ls` 已确认两个文件真实存在。
- 影响:本机后续可以使用这个 Skill但如果要把它随仓库交付需要后续显式调整忽略规则或强制加入版本管理。
- 09:44我收紧了 `.gitignore` 规则,让新建的 `agent-change-log` Skill 能进入普通版本管理视野,同时继续保护 `.codex` 下其他本地状态。
- 修改:把 `.codex/` 改成 `.codex/*`,再只放行 `.codex/skills/agent-change-log/**`
- 操作:保留 `.codex` 其他内容默认忽略,避免把本地运行缓存、临时状态或其他未审查 Skill 一起暴露出来。
- 验证:`git status --short` 已能看到 `agent-change-log` 的两个新增文件;`git diff --check` 仍然无输出。
- 影响:后续提交这个 Skill 时不需要强制添加,普通 `git status` 就能看到相关文件。
- 10:01我按你的补充要求把“先拉取/检查 Git分析其他智能体提交”纳入 `agent-change-log` 的硬流程。
- Git 提交检查:已运行 `git fetch --all --prune``HEAD..origin/main` 未发现 upstream 新提交。当前本地 `main` 显示 ahead 1后续在 10:02 单独补充分析本地 ahead 提交。
- 修改:更新 `agent-change-log`,新增 `Required Git Check`,要求写日志前执行 `git fetch --all --prune``git status -sb`、上游分支识别和 `git log HEAD..@{u}`
- 修改:更新 Skill 展示提示,把 upstream commit check 也列入触发场景。
- 修改:更新 `AGENTS.md`,明确每次日志更新前先做 Git 拉取检查;工作区干净且只落后上游时可 `git pull --ff-only`,脏工作区或可能冲突时只 fetch 并记录风险。
- 操作:没有在当前脏工作区执行自动 merge/rebase避免把其他大量未提交改动和远端提交混在一起。
- 验证:`rg` 已命中 `Required Git Check``git fetch --all --prune``HEAD..@{u}``git pull --ff-only``git diff --check` 无输出。
- 影响:后续日志会同时记录“我改了什么”和“其他智能体已经提交了什么”,不会只盯着本地 diff。
- 10:02我把本地 ahead 提交也纳入日志 Skill因为当前仓库已经出现 `origin/main..HEAD` 的本地提交。
- Git 提交检查:`origin/main..HEAD` 发现 `9321260 chore(skills): add git checkpoint commit loop`,提交时间为 2026-06-24 09:47:05内容包括新增 `git-checkpoint-commit` Skill、展示元数据、`checkpoint_commit.py` 脚本,并调整 `.gitignore`
- 修改:更新 `agent-change-log`,要求同时检查 `HEAD..@{u}``@{u}..HEAD`,分别识别 upstream 新提交和本地 ahead 新提交。
- 修改:更新 `AGENTS.md`,把本地 ahead 提交也纳入“其他智能体提交摘要”的记录范围。
- 操作:用 `git show --stat``git show --name-only` 查看 `9321260` 的文件清单与提交信息,没有改写该提交。
- 验证:`rg` 已命中 `@{u}..HEAD``本地 ahead``9321260``git diff --check` 无输出。
- 影响:后续即使其他智能体只做了本地 commit、还没 push也会被日志 Skill 捕捉并分析。
- 10:21自动记录 `9321260` 提交后的工作日志。auto-log:9321260
- Git 提交检查fetch 失败error: cannot open '.git/FETCH_HEAD': Operation not permittedupstream `origin/main`upstream 新提交:未发现;本地 ahead 提交9321260 (HEAD -> main) chore(skills): add git checkpoint commit loop。
- 修改:最近提交为 `9321260 chore(skills): add git checkpoint commit loop`
- 操作manual 验证自动日志脚本 触发 `tools/agent-change-log/update_change_log.py`,自动读取 Git 状态并写入当天日志。
- 验证:自动脚本只记录提交和 Git 状态,不替代业务测试;业务验证仍以本次任务实际运行结果为准。
- 影响:提交后即使执行代理忘记手动写日志,也会留下最低限度的时间、提交和分支状态记录。
- 10:21我排查了“修改 bug 或新增功能后不会自动写日志”的根因,并补上可执行自动化入口。
- Git 提交检查:当前权限下 `git fetch --all --prune` 会失败,错误是 `.git/FETCH_HEAD` 不允许写入;`origin/main..HEAD` 仍显示本地 ahead 提交 `9321260`
- 修改:新增 `tools/agent-change-log/update_change_log.py`,用于自动生成并追加当天工作日志,包含 Git 双向提交检查、最近提交摘要、重复提交去重和 fetch 失败遗留问题记录。
- 修改:新增 `.githooks/post-commit`,提交后调用日志脚本,作为真正的自动触发点。
- 修改:新增 `tools/agent-change-log/install_post_commit_hook.sh``README.md`,说明如何把版本化 hook 安装到本地 `.git/hooks/post-commit`
- 修改:更新 `AGENTS.md`,明确 Skill/AGENTS 只是规则,自动触发必须安装 post-commit hook如果当前环境无法写 `.git`,必须如实记录限制。
- 操作:尝试执行 `tools/agent-change-log/install_post_commit_hook.sh`,当前沙箱返回 `mkdir: .git/hooks: Operation not permitted`,所以本轮不能实际安装本地 hook。
- 验证:`update_change_log.py --dry-run --no-fetch` 能输出日志条目;默认 dry-run 能捕获 fetch 权限错误并输出遗留问题;真实运行脚本已成功追加 10:21 的 `auto-log:9321260` 记录。
- 影响:现在仓库里已经有可执行自动日志链路;等环境允许写 `.git` 后,安装 hook 即可实现“提交后自动写日志”。未提交的普通文件变更仍无法由 Git 自动判断,需要代理在任务结束前主动调用日志 Skill。
- 10:24我修正了 PDF 票据 OCR 的转图链路,避免“预览图丢中文但仍继续 OCR”的假成功。
- Git 提交检查:`git fetch --all --prune` 失败,错误是 `.git/FETCH_HEAD: Operation not permitted``git status -sb` 显示当前 `main...origin/main [ahead 1]``HEAD..@{u}` 未输出 upstream 新提交;`@{u}..HEAD` 显示本地 ahead 提交 `9321260 chore(skills): add git checkpoint commit loop`
- 修改:`document_preview.py` 把 PDF 渲染器标识升级为 `pdf-raster-cjk-safe-v3`,新增 `render_pdf_pages()`,按 `pdftoppm -> mutool -> gs -> pdftocairo` 尝试生成 PNG遇到 `Missing language pack``Unknown font tag``No font in show` 这类会丢中文的输出时,不再接受该 PNG。
- 修改:`ocr.py` 删除“PDF 文本层可用就直接构建识别结果”的分支PDF 现在必须先转图片,再进入 Paddle OCR worker文本层仅作为后续纠错/兜底材料,不再绕过图片 OCR。
- 修改:`docker-compose.yml``docker-compose.full.yml``bootstrap_paddleocr_mobile.sh``bootstrap_paddleocr_gpu.sh` 增加 `mupdf-tools`,让容器里有 `mutool` 作为中文安全转图 fallback。
- 修改:`test_ocr_service.py` 增加回归测试,覆盖运行时依赖包含 `mupdf-tools`、Poppler 字体映射失败时尝试下一个渲染器、坏转图不再调用 OCR worker、以及 PDF 文本层可用时仍必须调用 OCR worker。
- 操作:执行 `python3 -m py_compile``git diff --check``rg` 残留检查;尝试按项目规范执行容器内定向 pytest。
- 验证:`py_compile``git diff --check`、残留搜索均通过;容器 pytest 未能执行,原因是当前 Codex 进程访问 Docker socket 被拒绝:`permission denied while trying to connect to the docker API at unix:///Users/caoxiaozhu/.docker/run/docker.sock`
- 影响:后续 PDF 票据如果第一轮转图丢中文,会自动切换渲染器;如果所有渲染器都不可用,会明确失败并提示转图问题,而不是把缺中文的坏图送进 OCR。
- 10:28我确认 10:06 上传的票据夹记录当前仍是 PDF 预览,并修正 OCR 文本层纠错会清空 PNG 预览的问题。
- Git 提交检查:`git fetch --all --prune` 失败,错误是 `.git/FETCH_HEAD: Operation not permitted`;当前 `main...origin/main [ahead 1]``HEAD..@{u}` 未输出 upstream 新提交;`@{u}..HEAD` 仍显示本地 ahead 提交 `9321260 chore(skills): add git checkpoint commit loop`
- 发现:`server/storage/receipt_folder/caoxiaozhu_xf.com/f0dd9b4a-f7b7-4784-ade7-4e31b71f0b12/meta.json``preview_kind=pdf``preview_media_type=application/pdf`,前端 `ReceiptFolderView.vue` 因此走 `<iframe>` 而不是 `<img>`
- 根因:`OcrService._finalize_document()` 里旧逻辑在 PDF 文本层参与纠错且 OCR 文本占位符比例较高时,会主动把 `preview_kind``preview_data_url` 清空;票据夹保存时拿不到 `data:image/png`,只能回退到原 PDF 预览。
- 修改:删除这段清空 PNG 预览的旧保护逻辑;转图阶段已经负责识别坏 PNG文本层纠错不再影响预览资产类型。
- 操作:执行 `python3 -m py_compile server/src/app/services/ocr.py server/tests/test_ocr_service.py``git diff --check``rg` 残留检查。
- 验证:语法检查、空白检查和残留搜索均通过;容器 pytest 仍因 Docker socket 权限无法执行。
- 影响:后续 PDF OCR 结果即使使用文本层修正字段,也会保留 OCR 转图得到的 PNG 预览,票据夹应写入 `preview_kind=image``preview_media_type=image/png`
- 10:32我继续排查“重新上传仍是 PDF 识别”的原因,确认最新 10:29 上传命中了旧 OCR 结果,并修正 OCR 内存缓存失效条件。
- Git 提交检查:`git fetch --all --prune` 失败,错误是 `.git/FETCH_HEAD: Operation not permitted`;当前 `main...origin/main [ahead 1]``HEAD..@{u}` 未输出 upstream 新提交;`@{u}..HEAD` 仍显示本地 ahead 提交 `9321260 chore(skills): add git checkpoint commit loop`
- 发现:最新两条票据夹记录 `e9e3c0be-...``9ecee0d8-...` 上传时间为 10:29但仍是 `preview_kind=pdf``ocr_line_count=0``ocr_text` 仍是只有英文和数字的旧坏结果。
- 根因:`OcrService._build_cache_key()` 只使用 OCR 语言、设备、模型和文件 digest没有包含 PDF 转图/识别管线版本;同一 PDF 重新上传时可能复用旧的内存缓存,导致新转图逻辑没有机会执行。
- 修改:新增 `OCR_RESULT_CACHE_PIPELINE_VERSION`,把当前 PDF 渲染器标识 `DocumentPreviewAssets.PDF_RENDERER_ID``no-pdf-direct` 策略写入 OCR cache key。
- 修改:`test_ocr_service.py` 增加 `test_ocr_cache_key_includes_pdf_render_pipeline_version`,防止以后改转图管线但继续吃旧缓存。
- 操作:执行 `python3 -m py_compile server/src/app/services/ocr.py server/tests/test_ocr_service.py``git diff --check``rg` 检查;尝试执行容器内定向 pytest。
- 验证:本地语法检查、空白检查和残留搜索通过;容器 pytest 仍因 Docker socket 权限被拒绝,未能执行。
- 影响:后端加载新代码后,同一 PDF 会因为 cache key 变化重新进入 PDF 转 PNG + Paddle OCR 流程,而不是复用旧的 PDF fallback/坏识别结果。
- 10:40我修正了 AI 工作台附件预览弹窗在左侧侧边栏存在时视觉不居中的问题。
- Git 提交检查:`git fetch --all --prune` 失败,错误是 `.git/FETCH_HEAD: Operation not permitted`;当前 `main...origin/main [ahead 1]`;基于本地 ref`HEAD..@{u}` 未输出 upstream 新提交;`@{u}..HEAD` 仍显示本地 ahead 提交 `9321260 chore(skills): add git checkpoint commit loop`
- 修改:`workbench-ai-file-preview-dialog.css` 将预览遮罩改成“侧边栏占位列 + 主内容列”的网格布局,弹窗固定落在第二列并居中;同时保留折叠侧栏变量和 900px 以下移动端单列布局。
- 修改:`workbench-ai-composer-components.test.mjs` 增加回归断言,锁定附件预览必须按主内容区域居中,而不是按整个 viewport 居中。
- 操作:检查本地 `5173` 可达,返回 `HTTP/1.1 200 OK`;检查项目没有现成 Playwright/Puppeteer 依赖,未新增依赖。
- 验证:`node --test web/tests/workbench-ai-composer-components.test.mjs` 通过 8/8`npm --prefix web run build` 构建通过;`git diff --check` 无输出。
- 影响:用户点击附件打开预览时,弹窗会避开左侧 AI 工作台侧边栏,在右侧主工作区内居中展示,截图里的“偏左/不居中”观感会收敛。
- 10:41我补修了票据夹 PDF 保存阶段的预览持久化,避免 OCR 后仍把源 PDF 当成附件预览展示。
- Git 提交检查:`git fetch --all --prune` 失败,错误是 `error: cannot open '.git/FETCH_HEAD': Operation not permitted`;当前 `main...origin/main [ahead 1]`;基于本地 ref`HEAD..@{u}` 未输出 upstream 新提交;`@{u}..HEAD` 显示本地 ahead 提交 `9321260 chore(skills): add git checkpoint commit loop`
- 修改:`receipt_folder.py``document.preview_data_url` 缺失且源文件是 `application/pdf` 时,保存阶段立即调用 `DocumentPreviewAssets.render_pdf_first_page()` 生成 `preview.png`,并把 `preview_kind``preview_media_type``preview_rendered_with` 写成图片预览元数据;只有渲染异常时才回退到源 PDF 预览。
- 修改:`test_receipt_folder_service.py` 新增 `test_receipt_folder_pdf_save_eagerly_renders_image_preview`,覆盖 PDF OCR 结果没有内嵌预览图时,票据夹仍应主动生成图片预览的场景。
- 操作:读取当前票据夹存储里的两条 PDF meta确认旧记录存在 `preview_kind=pdf``preview_media_type=application/pdf` 且没有 `preview.png`,这与前端显示 PDF 预览的问题一致。
- 验证:`python3 -m py_compile server/src/app/services/receipt_folder.py server/tests/test_receipt_folder_service.py` 通过;宿主机缺少 pytest 和后端依赖,容器 pytest 又因 Docker socket 权限被拒绝,暂未完成项目要求的容器定向测试。
- 影响:后续新上传或重新 OCR 保存的 PDF 票据会优先拥有 PNG 图片预览,前端票据夹预览应走 `<img>` 体验;既有已经写成 PDF fallback 的旧 meta 还需要单独刷新。
## 遗留问题
- 09:41当前 Skill 是新建在项目级 `.codex/skills` 目录里,本轮可以通过文件检查验证结构,但是否被未来会话自动加载还依赖 Codex 对项目 Skill 的刷新机制。建议后续新开会话或下一次任务时确认 Skill 列表是否出现 `agent-change-log`
- 09:43`.codex/` 曾被 `.gitignore` 整体忽略,新建的 `agent-change-log` 默认不会进入普通提交范围09:44 已改成只放行该 Skill。建议后续如果还新增其他项目 Skill也按同样方式逐个显式放行别一次性开放整个 `.codex`
- 10:01当前工作区已有大量未提交改动且本地 `main` ahead 1。建议后续如果真的发现 upstream 新提交,先用 fetch 和 `HEAD..@{u}` 写日志;只有在工作区干净、可快进时再执行 `git pull --ff-only`,避免把其他智能体提交和本地半成品混到一起。
- 10:02本地 ahead 提交也可能来自其他智能体,不能只看 upstream behind。建议后续日志固定同时记录 `HEAD..@{u}``@{u}..HEAD` 两个方向。
- 10:21自动日志触发时发现 fetch 未成功失败error: cannot open '.git/FETCH_HEAD': Operation not permitted。建议后续在有 Git 写权限和网络权限的环境里重新执行拉取检查。
- 10:21当前环境不能写 `.git/hooks`,所以 post-commit hook 模板已经入库,但尚未安装到本 checkout。建议在有 `.git` 写权限的环境执行 `tools/agent-change-log/install_post_commit_hook.sh`
- 10:24本轮未能在容器内执行 pytest也未能实际确认容器是否已安装 `mupdf-tools`。建议在 Docker 权限恢复后重建/重启 `x-financial-main`,执行定向 OCR 测试,并在 5173 用真实 PDF 票据确认预览图和 OCR 字段都保留中文。
- 10:2810:06 那条既有票据记录已经写成 PDF fallback代码修复不会自动改写旧 meta。建议重新上传一次同一 PDF或在容器权限恢复后触发票据重识别/重建预览,确认新记录变为 PNG 预览。
- 10:32最新 10:29 上传仍然写成 PDF说明运行中的后端可能还没加载最新代码或本轮上传发生在缓存版本修复之前。建议重启后端/重建容器后再重新上传,确认 OCR cache key 已包含 `pdf-image-ocr:`
- 10:40本轮可以确认 5173 服务可达、结构测试和生产构建通过,但当前环境没有可调用的浏览器自动化插件,项目也没有现成 Playwright/Puppeteer 依赖,所以未生成真实页面截图。建议在具备浏览器自动化的环境回放一次附件预览,确认主内容区居中效果。
- 10:41票据夹 PDF 保存阶段已补主动生成图片预览,但当前沙箱不能访问 Docker socket无法运行容器内 pytest也无法刷新已有 PDF 票据的旧 meta。建议 Docker 权限恢复后先跑定向测试,再对旧记录触发 `resolve_preview` 或重识别来补 `preview.png`
## TODO
- [x] ~~检查 `agent-change-log` 的 frontmatter、触发描述和日志模板是否完整。~~(完成于 09:42证据`rg` 命中 frontmatter、日志路径和三段式标题`git diff --check` 无输出)
- [x] ~~将 `AGENTS.md` 接入“每次修改后调用日志 Skill”的项目级规则。~~(完成于 09:42证据`AGENTS.md` 已新增 `变更日志 Skill 规范`
- [x] ~~如果需要把 `agent-change-log` 随仓库提交,确认是调整 `.gitignore` 放行还是用强制添加方式纳入版本管理。~~(完成于 09:44证据`.gitignore` 已只放行 `.codex/skills/agent-change-log/**`
- [x] ~~把 Git 拉取检查和其他智能体 upstream 提交分析纳入 `agent-change-log`。~~(完成于 10:01证据Skill 已新增 `Required Git Check``AGENTS.md` 已要求日志前运行 `git fetch --all --prune``git log HEAD..@{u}`
- [x] ~~把本地 ahead 提交也纳入 `agent-change-log` 的提交分析范围。~~(完成于 10:02证据Skill 和 `AGENTS.md` 已新增 `git log @{u}..HEAD`,并记录 `9321260` 本地 ahead 提交)
- [x] ~~补上提交后自动写日志的可执行脚本和 hook 模板。~~(完成于 10:21证据`update_change_log.py` dry-run 与真实写入成功,`.githooks/post-commit` 已新增)
- [ ] 在有 `.git` 写权限的环境执行 `tools/agent-change-log/install_post_commit_hook.sh`让提交后自动写日志真正启用。来源10:21 当前沙箱安装失败)
- [ ] 在后续每次 bugfix、新功能、重构或配置/文档修改后,调用 `agent-change-log` 并增量更新当天日志。来源09:41 用户要求)
- [ ] 重建/重启 `x-financial-main`,确认容器内存在 `mutool`,并执行 OCR 定向 pytest。来源10:24 PDF 中文转图链路修复)
- [ ] 在 5173 真页重新上传/预览火车票 PDF确认预览 PNG 不再丢中文OCR 字段不再出现“乘车人/站点”等中文缺失或错位。来源10:24 PDF 中文转图链路修复)
- [ ] 重新上传 10:06 同款 PDF 或触发该票据重识别,确认新的 `meta.json` 写入 `preview_kind=image``preview_media_type=image/png`来源10:28 PNG 预览保留修复)
- [ ] 后端加载缓存版本修复后,重新上传同一 PDF确认不会再命中旧 OCR 缓存,`ocr_line_count` 和 PNG 预览都来自新转图流程。来源10:32 OCR cache key 修复)
- [ ] 在有浏览器自动化能力的环境回放 AI 工作台附件预览弹窗截图确认弹窗按侧边栏右侧主内容区居中。来源10:40 附件预览弹窗布局修复)
- [ ] Docker 权限恢复后运行票据夹 PDF 预览定向测试,并刷新已有 `preview_kind=pdf` 的旧票据 meta。来源10:41 PDF 保存阶段主动生成图片预览修复)