Neo-ZQYY/docs/audit/changes/2026-05-06__w1_ai_closure_step1_matrix.md

2026-05-06 · W1-AI-CLOSURE Step 1 — AI 9 APP 全链路现状矩阵

关联:architecture-evolution-backlog §七 #14 + §十

工作量:S / 1h(2 个并行子代理深度调研 + Bash 实证 + 整合)

触发:Neo 2026-05-06 反思时提出 AI 9 APP 高优先级未完成,本次按 §3 Step 1 调研流程,出"全链路现状矩阵"作为 wave 拆分依据。

调研方法

并行 2 个 Explore 子代理:

• 子代理 A(后端视角):接口 / 入库 / 后端处理 3 环节实证(含 Bash 直连测试库 SELECT app_type COUNT)
• 子代理 B(前端视角):小程序 + admin-web + tenant-admin 3 端展示实证

9 APP × 4 环节现状矩阵

APP	接口	入库	后端处理	小程序	admin-web	综合
app1_chat	✅ /xcx/chat/*	✅ ai_conversations / ai_messages	✅ chat_service 完整	🔄 SSE 流(非缓存)	✅ AIRunLogs / AIDashboard	90%
app2_finance	❌ 无独立端点	✅ ai_cache	✅ dispatcher 8 time_dim	✅ board-finance fetchAICache	✅ AIPrewarm 72 组合监控	80%
app2a_finance_area	❌ 无独立端点	✅ ai_cache	✅ dispatcher 64 area 组合	✅ board-finance(area 切换)	🔄 AIPrewarm 缺区域独立监控	75%
app3_clue	❌ 无独立端点	✅ ai_cache	✅ dispatcher + references	❌ 完全无展示	✅ AIOperations	55%
app4_analysis	❌ 无独立端点	✅ ai_cache	✅ dispatcher + assistant_id 联动	❌ UI 占位无数据绑定	✅ AIOperations	60%
app5_tactics	❌ 无独立端点	✅ ai_cache	✅ dispatcher + app4 依赖	❌ UI 占位无数据绑定	✅ AIOperations	60%
app6_note	❌ 无独立端点	✅ ai_cache	✅ dispatcher + score 字段	❌ notes 页无洞察卡片	✅ AIOperations	55%
app7_customer	❌ 无独立端点	✅ ai_cache	✅ dispatcher + references	✅ customer-detail fetchAICache	✅ AIOperations	80%
app8_consolidation	❌ 无独立端点	✅ ai_cache + member_retention_clue	✅ dispatcher 幂等写入	❌ 完全无展示	✅ AIOperations	55%

关键缺口(按严重度)

P0 — 用户感知(小程序前端 5 APP 展示残缺)

• ❌ app3_clue / app8_consolidation:完全无展示
• ❌ app4_analysis / app5_tactics:coach-detail / task-detail 已有 UI 占位 (ai-title-badge),但无 fetchAICache 调用,无数据绑定
• ❌ app6_note:notes 页纯列表无 AI 卡片

P1 — 架构标准化(后端)

• 8 APP 无独立 OpenAPI 端点(只通过 dispatcher 后台调度,前端无标准调用入口,僵尸 APP 嫌疑均已排除但调用入口不规范)
• 缺 WS 告警推送(circuit_open / rate_limited / timeout 仅记 alert_status)

P2 — 完善

• app1_chat 缺 AIOperations 手动操作面板
• app2a_finance_area 缺 AIPrewarm 中区域维度的独立监控
• chat 与 dispatcher 双线路架构不统一(app1 走 chat_service,app2~8 走 dispatcher)

整体评分

维度	评分
后端就绪度	78/100
admin-web 管理面板	95/100
小程序展示	40/100
tenant-admin	0/100(无 AI 页面,确认不需要)
综合	~70/100

僵尸 APP 排查

全部健康 ✅ — 子代理 A Bash 直连测试库实证,9 APP 在 ai_cache / ai_run_logs 都有真实写入,无入库为零或代码孤立的 APP。

demo-miniprogram MOCK 标杆

❌ 不能作为 AI 展示完整性参考基线 — demo-miniprogram board-finance 仅内联 MOCK 数据,TODO 注释未完成联调,内容残缺。结构参考可,内容完整性参考不可。

W1-AI-CLOSURE wave 推荐拆分(6 sprint)

按"P0 用户感知 → P1 架构 → P2 收尾"顺序:

Sprint	范围	工作量	依赖
1	小程序 app3_clue 维客线索展示	M ~ 2h	接口定义 / 找展示位(覆盖现有 retention-clue 页或新建)
2	小程序 app4+5 助教分析/策略(coach-detail/task-detail UI 占位激活 + 数据绑定)	L ~ 3h	UI 占位已有
3	小程序 app6_note 备注分析展示(notes 页扩展)	M ~ 2h	notes 页改造
4	小程序 app8 消费链整合展示(新展示位 / 复用 board)	M ~ 2h	新展示位决策
5	后端 8 APP 统一 OpenAPI 端点 + 文档同步	L ~ 3h	架构 spec
6	收尾对账 + WS 告警推送 + admin-web 缺口补齐(app1 manual / app2a 独立预热)	M ~ 2h	上述完成

总估算:14h(超出之前 8-12h 初判,前端补全工作量比预想大)

影响范围

端	影响	验证
文档(audit/changes)	新建本文件	—
代码 / 数据库 / 配置	无改动(本次仅 Step 1 调研)	—

风险与未覆盖

• 接口设计未定(P1 Sprint 5):是否真的需要 8 APP 各 1 个独立 OpenAPI 端点?还是统一 /api/ai/run/{app_type} 一个端点?需 Neo 拍板架构方向
• 小程序展示位置(P0 Sprint 1-4):每个 APP 在小程序的具体展示位置需对照 PRD 定(可能涉及新增页面或扩展现有页面)
• 沙箱时光机集成:F1-5a/F1-5b/F1-6 已注入 ctx_snapshot 到 dispatcher,小程序展示这些 AI 洞察时是否需要同步透出"sandbox 状态"标识(参考 admin-web sandbox 透出)?

下一步

1. Neo 确认 wave 拆分方向(6 sprint 顺序是否合理)
2. Neo 确认接口设计方向(8 APP 独立端点 vs 统一端点)
3. 启动 Sprint 1 §3 调研(小程序 app3_clue 展示位置 + 接口对接)

后续

• backlog §七 #14 状态从 ⏳ 高优先级未启动 → 🔄 Step 1 调研完成,等 Neo 确认拆分

Co-Authored-By

Claude Opus 4.7 (1M context) noreply@anthropic.com