zhanghongyu_0626
0e35eb84ba
- Enhanced `ITERATION.md` to include new entries for front-end/API optimizations and Chat session management improvements. - Expanded `TODO.md` with a daily work summary, completed tasks, and upcoming priorities, ensuring clarity on project status and next steps. - Added a new summary document for 2026-09-10, detailing work completed across various components, including front-end fixes and API enhancements. This update improves documentation clarity and provides a comprehensive overview of recent developments and future tasks.
70 lines
5.8 KiB
Plaintext
70 lines
5.8 KiB
Plaintext
================================================================================
|
||
2026-09-10 工作汇总
|
||
分支/环境：merger 为主 · 后端 pytest
|
||
================================================================================
|
||
|
||
【我这边 · 平台 + 前端 + 联调（今天实际干的）】
|
||
|
||
今天主要是在「四角色 Demo 能演示」这条线上收口子，不是新做大功能。
|
||
|
||
前端把 E2E 走查里爆出来的硬伤修了一轮：登录第一次必崩、点退出标签页卡死（都是 auth 没跟着 React 状态走，上了 AuthProvider）；Redis 没起时每个带 token 的接口都慢（鉴权路径连 Redis 超时，代码里把连接超时压到 0.5 秒，但演示前还是得把 6380 起起来）；预警页筛选敲一个字发一次请求（加了防抖）；表格日期和英文枚举（抽了 displayLabels）；对话里 ** 粗体、登录页 a11y、页面标题/lang 这些也顺手改了。
|
||
|
||
客户助手 Chat 是今天另一块：流式对话之前没把 session_id 传给后端，聊几轮刷新就变成好多条「单轮会话」；侧栏高度、分页、用户气泡字看不清、删会话删不掉（其实是 closed 还在列表里、close 接口对 closed 会 409）——修了续聊、sessionStorage 恢复、固定对话框高度、删除/清空；后端加了按 status 筛列表和 close-all 批量关，前端还做了旧后端兜底。文档写在 docs/整体测试/前端整体测试交接.md，优化项和明天干啥写进 docs/memory/TODO.md 了。
|
||
|
||
后端也接了很多缝修了很多合并带来的bug
|
||
|
||
关键结果（我这边）：25 路由能跑的主链路更稳；Chat 续聊和清空在代码里闭环了，但你要重启 uvicorn + 强刷前端才算数；还没 commit，E2E 自动化还在机器本地没进仓库。
|
||
|
||
明天我这边优先：本机把 Chat/清空/登录退出再验一遍；merger 提交；按 TODO 做启动自检（Redis、后端有没有 close-all）、E2E 最小集进仓库；分析对话和问数两条菜单别让用户懵（要么合一要么强引导）；角色改 URL 进别人工作台的前端守卫可以排上。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
【代理人 Agent · 2026-09-10】
|
||
|
||
今天按项目需求把 API 先撸出来了，大概十五个接口，Mock 数据也配好了，单个接口自己测过一轮，能通。
|
||
|
||
明天才开始在接口上面挂 Agent，再做联调和测试。今天算是把「地基和假数据」打牢，Agent 是下一阶段。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
【金融风控 · 2026-09-10 · 主线：转持 convert】
|
||
|
||
今天干的是「基金转持」这条风控场景，不是另起炉灶，还是老套路：先检索规则 → 一条条验 → 汇总结论，没单独再开一条旁路，后面好维护。
|
||
|
||
规则上这次盯住三类：转完份额会不会低于最低持有；目标基金风险等级和投资者承受能力对不上；T 日还有在途交易又转持会不会打架。这三类已经并进主流程，trace 一路带着，结论也进审计日志，以后能查谁因为啥被拦。
|
||
|
||
知识库加了转持相关条目，从 24 条扩到 37 条，按产品拆开写，别一大坨文档检索时信号被稀释。拿 12 条 convert 样例测，命中率从大概七成提到接近九成，主要是拆细规则，不是瞎调向量参数。
|
||
|
||
结果：convert 主链路能端到端出结论；12 条用例过，没有卡死的。
|
||
|
||
还没做的/要确认的：跨管理人转持这次默认不管（费率、份额确认差太多，等产品口径）；知识库离线更新可能过期，短期靠脚本刷，长期想接实时；风险等级匹配要不要叠加高龄等限制，等合规回话。
|
||
|
||
明天：跨管理人规则先出草稿；补边界（份额刚好等于最低持有、目标货基、同一天多次转持）；催合规口径。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
【数据分析 Agent · 2026-09-10 · 主线：schema 进知识库 + 问数检索】
|
||
|
||
让问数 Agent 别靠人脑记表结构，表从 DDL 自动生成「唯一真相」，再灌进 Milvus，问 SQL 前先检索该查哪几张表。
|
||
|
||
第 0 步（今天方向 · A 方案落地）：写脚本扫 core/agent 的 DDL，不连库，吐出 schema_catalog.py；人再补 DDL 写不出来的口径（比如 trade 只算 confirmed、C/R 等级别混、持仓快照不能做趋势）；schema_meta 还是从 catalog 拼提示词，analyst 那边 import 不用改；pytest 保证 catalog 和 DDL 对得上，提示词里出现的表都在 sql_guard 白名单里。
|
||
|
||
第 1 步（知识库）：Milvus 文档里加 schema 专用 collection，一张表一条 chunk（表名、注释、别名、关键列、口径）；入库脚本放 scripts/sync/，id 固定方便重灌。
|
||
|
||
第 2 步（检索接上问数）：embedding → milvus → rag 按现有分层接；在生成 SQL 前加检索，用「候选表 + 完整表名兜底」别硬 Top-K 裁太狠导致查空还不报错；检索结果建议进 analytics_query_log 的 meta 方便排障。
|
||
|
||
怎么验：第 0 步 pytest test_schema_meta；第 1 步重跑入库看条数；第 2 步用 run_query_battery 对比改前改后命中率（报告仍不入库）。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
【合起来看 · 明天各线大概干啥】
|
||
|
||
· 我：验证 + commit + 前端优化 TODO 里 P0（自检、E2E、Chat 回归）
|
||
· 代理人：接口之上接 Agent + 测试
|
||
· 风控：convert 边界 + 跨管理人草稿 + 合规跟进
|
||
· 分析：schema 知识库入库 + 问数检索链路 + battery 对比
|
||
|
||
【演示前共同提醒】
|
||
|
||
Redis 6380、uvicorn 要带 close-all/status 的新代码、前端强刷；风控/demo 数据 often 要 prepare_all 或模拟交易才有预警故事线；分析问数要灌 metric/template 种子。
|