建立项目级标杆文档 docs/_overview/ 作为产品全景索引, 解决"PRD 零碎、文档膨胀、跨子系统调研无入口"的问题。 主要内容: - 00-index 总索引 + 维护协议 + 与 CLAUDE.md 关系 - 01-product-overview 产品全景脑图(6 角色 / 6 子系统 / 数据流 / 7 业务概念 / 8+1 AI 矩阵 / 22 术语) - 02a-miniprogram-page-matrix 小程序 21 页业务指纹 - 02b-adminweb-page-matrix admin-web 19 路由业务指纹 - 03-test-spec 测试规范 (L1-L5 分层 + 走查模板 + 75-95 case 估算) - 04-doc-conflicts 39 条冲突索引(P0×8 / P1×13 / P2×13 + 5 子项) - 04a/b/c-conflicts-*-detail 业务故事卡(7 字段:关联/逻辑/影响/选项/判定) - 05-orphan-pages-cleanup admin-web 6 孤儿页面处置(1 归档 + 4 保留) - WAVES-MASTER-PLAN.md 全 Wave 主计划(0-5,共 22-32 工作日) - WAVE-1-KICKOFF.md Wave 1 实施 kickoff - GLOBAL-DECISION-DASHBOARD.md 全局决策仪表板 反馈调研产物: - 04a-feedback/ P0 两轮反馈(8+8 项决策 + D-1/2/3 + F-1/2 子代理产出) - 04b-feedback/ P1 两轮反馈(13+1+5 项 + E-1/2/3/4 + G-1/2 子代理产出) - 04c-feedback/ P2 反馈(13 项 + 5 子项 + H-1/2/3 子代理产出) - NEO-DECISIONS-LOG 累积决策记录 关键追加发现 8 处 D Bug(原蓝本 0): - P0-3 看板沙箱接入(Wave 1 W1-T1) - P0-5 致命 1 (4 处 fdw_etl 残留, 已修 commit17f045a) - P0-5 致命 2 (JWT aud 缺失, 已修 commit17f045a) - P0-6 clearAllTasks 守卫 (Wave 3) - P0-8 DBViewer 黑名单漏 (已修 commit17f045a) - P1-3 task-detail 跳转传 task_id 而非 customer_id - P2-7 board-finance 隐式 null - 2 个独立 Bug (page_context.created_at + ClueCategory 字典) 参考: docs/_overview/00-index.md
10 KiB
10 KiB
P1 反馈响应总报告
日期:2026-05-04 / 触发:Neo 在 04b-conflicts 13 条 P1 + 1 条额外需求 上写下斜体反馈 主线 + 4 个子代理(E-1/2/3/4)调研整合产出 / 状态:调研完成,等 Neo 拍板进入实施
一、13 条 P1 + 1 额外需求 处理状态总览
| # | Neo 反馈 | 调研产出 | 关键发现 / 推荐 | 等待 Neo 决策 | 反馈 |
|---|---|---|---|---|---|
| P1-1 | 选 A 迁移到 biz,要风险评估 | P1-1-schema-migration-risk.md | 85 文件影响 / 后端 11 处硬编码 SQL / 测试库 44 行无 RLS 无 FK / 推荐方案 A 一次性 9 人时与 Wave 2 协同 | 接受方案 A?何时入 Wave | 同意,接受方案A,Wave你来定 |
| P1-2 | 选 A + 检查残留 | P1-2-mvp-cleanup-result.md | 无 mvp 残留代码,只 README 历史记录 / Wave 5 改 3-4 处文档即可 | 已确认,纳入 Wave 5 | 同意 |
| P1-3 | 同意 + 深入调研跨页传值 | P1-3-4-cross-page-params.md | 53 跳转矩阵 / P0×2 P1×4 P2×4 / 建议 SPEC 化 cross-page-params-spec.md | 接受 SPEC 化建议? | 同意,接受 |
| P1-4 | 同 P1-3 | 同上 | 重大发现:已于 2026-03-25 修复(performance.ts 现传 memberId),04b 描述过时 | 判定改为 A 改文档,无需再修代码 | |
| P1-5 | 调研规范化方案 + AI 标记 | P1-5-ai-cache-type-spec.md | AI 不需要返回标准标记(违反权威源原则) / 推荐 packages/shared 跨包枚举,TS 编译期校验 | 接受"AI 不返标记 + 跨包枚举"方案? | 同意,接受 |
| P1-6 | 倾向合并,要可行性 | P1-6-trigger-api-merge.md | 实际 3 API 不是 2;PATCH 字段互补;推荐方案 A 完全合并,扩展 /trigger-jobs PATCH + 业务触发器禁用守卫,保留 /admin/triggers/unified 跨表只读 |
接受方案 A? | 同意,接受方案A |
| P1-7 | 选 A 完整 PRD + 评估 | P1-7-admin-api-prd-evaluation.md | 60-65 小时大工程;推荐方案 B 分批 + D 自动生成 混合,8-10 工作日分散到 5 Wave | 接受 B+D 混合?Wave 1 起批 1? | 同意,接受 |
| P1-8 | 选 A,Token 可接受 | (本报告 §四确认) | 应用 4 触发条件 3 种为准(新结算 + 优先召回 + 高优先召回任务分配) | 已确认,Wave 1-3 实施 | 同意 |
| P1-9 | 选 A,同意 | (本报告 §四确认) | userId 对外 / User_ID 对百炼,改文档明文 | 已确认,纳入 Wave 5 | 同意 |
| P1-10 | 重新调研 customer-detail 入口 | P1-10-customer-detail-entries.md | 根本不跳 customer-service-records,原冲突命题不存在 | 判定改为 B 现状对,从冲突清单移除 | |
| P1-11 | 选 A | E-2 报告(P1-3+4 合并) | 前端已 6 分支修了,只剩后端契约待核 | 工作量小,Wave 1 内修后端契约 | 同意 |
| P1-12 | 调研 DB 实际值 | P1-12-scattered-memberid.md | 测试库 27742 行散客全部 member_id=0,飞球 API 文档明文 0=散客 / 推荐统一 0=散客 + API 加 isScattered: bool |
接受方案?Wave 4 ETL 验证时校 | 同意,接受 |
| P1-13 | 是它么? | P1-13-prerequisite-fixes-found.md | 是的:docs/specs/p4-prerequisite-fixes/(Kiro 三件套);6 修复点 3 完成 3 待做(T3/T4/T5/T6) |
剩余 T3/4/5/6 纳入 Wave 1-3? | 可以,但我隐约觉得这块还要深挖并再进行调研,其牵扯的前后依赖和程序执行的上下文会比看起来的更复杂,关联性更高,别轻易修改。 |
| extra | dev-trace 性能 | extra-dev-trace-perf.md | 零业务使用 / 1500-2000 + 760 行代码 / 111MB 落盘 / 推荐 Drop 移除,1-2h 一个 PR | 接受 Drop?何时执行? | 接受 Drop,排在任务列表中吧,Wave 排序你来确认。 |
二、5 件 Neo 必须知道的事
1. P1-4 已修过期、P1-10 命题不存在 — 2 条冲突可消除
E-2 / E-4 调研发现:
- P1-4:performance.ts 已于 2026-03-25 修复(
customerName→memberId),原描述过时 → 判定从 D Bug 改为 A 改文档(改 04b P1-4 描述) - P1-10:customer-detail 实际只跳
customer-records+chat,根本不跳 customer-service-records → 判定从 C 待补改为 B 现状对(从冲突清单移除)
冲突清单 39 条 → 实际 37 条待处理。
2. P1-5 AI 不应返回标准标记(直接回答 Neo 的疑问)
Neo 原问:"修改是否需要让 AI 返回一些标准的标记,以进行信息对齐?"
E-3 答:不需要。理由:
- cache_type 是数据存储分类,后端
dispatcher.py在调用百炼之前就已经决定(area==all → app2_finance / 其他 → app2a_finance_area) - 两个 APP 的输出 schema 完全相同,差异在"输入路由",不在"输出内容"
- 让 AI 决定存储类型 = 违反"权威源在后端"原则;且 AI 输出的字段值是不可信的(模型偶尔会幻觉)
- 现有
_references元数据已实现等同效果(后端写入时打标) - "信息对齐"的最佳路径是 TS 类型系统编译期校验,不是运行时 AI 字段
推荐方案 A:在 packages/shared/ 新增 ai_cache_types.py(Python)+ aiCacheTypes.ts(TS),前后端共享枚举常量。
3. P1-6 实际是 3 个 API,不是 2 个
E-3 调研发现 admin-web 触发器相关有 3 个 API(原 04b 只列 2 个):
/trigger-jobs全量,PATCH 改cron_expression / interval_seconds/admin/ai/triggersAI 子集,PATCH 改status / description/admin/triggers/unified跨表只读聚合(本次新发现,合并时不应删除)
PATCH 字段集互补:/admin/ai/triggers 与 /trigger-jobs 95% 重合 + 各自独占字段。合并必须先扩展 /trigger-jobs PATCH 字段集 + 加业务触发器(task_generator 等)禁用守卫(避免 admin-web 误改业务触发器的 cron)。
4. dev-trace 推荐 Drop 移除
E-4 实证:
- 零业务使用(grep 全后端 / 全前端无依赖)
- 后端 1500-2000 行 + 前端 760 行
- 已落盘 111 MB,retention=7 实际未生效
- 性能消耗本身不算高(非 xcx 路径接近零,xcx +0.5~2ms),但维护成本和认知负担显著
- 替代方案充足:pg_stat_statements / nginx log / loguru / OpenTelemetry
- 删除影响面清晰:无数据库表,无业务依赖,1-2h 一个 PR
强烈推荐 Drop。
5. P1-13 文件存在,P1 调研顺带挖出 2 个独立 Bug
P1-13 你提的路径 docs/specs/p4-prerequisite-fixes 正确(Kiro 三件套),不是 P5.2:
- 6 个修复点中 T1/T2/T6(种子已改) 已完成
- T3/T4/T5/T6(代码默认值)未完成,推荐 Wave 1-3 一并修
E-1 调研维客线索 schema 时顺带挖出 2 个独立 Bug:
apps/backend/app/services/page_context.py:243— 用了created_at但应为recorded_atapps/backend/app/schemas/member_retention_clue.pyClueCategory 字典仍是"客户基础信息",但 BD 手册 2026-03-08 已对齐到"客户基础"(更短的中文名)
推荐:作为 P1 补充 Bug 单独处理,Wave 1-2 修。
三、按 Wave 重新分配的执行清单(整合 P0 + P1)
| Wave | 主题 | P0 + P1 反馈分配 |
|---|---|---|
| Wave 1 | Runtime Context 沙箱 | P0-3 看板接入(必修)+ P0-7 SPEC 投入 + 20 todos(P0×5)+ P0-1 SPI 改 3 处文档 + P1-11 后端契约修(chat 多入口) + P1-13 T5 触发器事务安全 |
| Wave 1-3 | 代码 D Bug | P0-8 DBViewer 白名单 + P0-6 临时守卫 + P1-3 后端 customer_id 字段 + P1-13 T3 备注重分类 / T4 回访完成条件 / T6 cron 默认值 + 2 个独立 Bug(page_context 字段 / ClueCategory 字典) |
| Wave 2 | admin-web AI 套件 + P1-1 schema 迁移协同 | P1-1 维客线索 public→biz 迁移(9 人时,与 Wave 2 后端 PR 合并)+ P1-6 触发器 API 合并 + P1-5 packages/shared 枚举 |
| Wave 4 | DWS / RLS / 数据正确性 | 4.1 财务看板 5 项 P2 修复 + P0-7 todos(P1×8)+ P1-12 散客 0 约定校验 + API 加 isScattered |
| Wave 5 | 部署 + 文档收尾 | P0-1 / P0-2 / P0-4 / P0-5 / P0-7(P2×7)文档 + P1-2 mvp 文档改 3 处 + P1-9 User_ID 文档 + P1-10 移除冲突 + P1-13 文件名修正 |
| 跨 Wave | admin API PRD | P1-7 方案 B+D 混合:Wave 1 起批 1,后续每 Wave 一批 |
| 额外 | 移除 dev-trace | Wave 1-3 任意时点,1-2h 一个 PR |
四、Neo 已确认 / 直接归档的项
| # | 简述 | 状态 |
|---|---|---|
| P1-8 | 应用 4 触发条件 3 种为准(成本可接受) | 已确认,Wave 1-3 实施 |
| P1-9 | userId / User_ID 文档明文映射 | 已确认,Wave 5 改文档 |
| P1-2 | mvp 残留代码无,只改 3-4 处文档 | 已确认,Wave 5 改文档 |
| P1-11 | 选 A,前端已 6 分支,只补后端契约 | 已确认,Wave 1 修 |
五、给 Neo 的决策提问(本会话剩余可处理的项)
| 问题 | 类型 | 建议 |
|---|---|---|
| P1-1 接受方案 A 一次性迁移 9 人时 + Wave 2 协同 Y/N | 路径 | Y |
| P1-3 接受 SPEC 化"cross-page-params-spec.md" Y/N | 文档 | Y |
| P1-4 / P1-10 改判定为 A / B,从冲突清单移除 Y/N | 校准 | Y |
| P1-5 接受"AI 不返标记 + packages/shared 跨包枚举" Y/N | 方案 | Y |
| P1-6 接受方案 A 完全合并(扩展 PATCH + 加守卫,保留 unified) Y/N | 方案 | Y |
| P1-7 接受 B+D 混合,Wave 1 起批 1 Y/N | 路径 | Y |
| P1-12 接受统一 0=散客 + API 加 isScattered Y/N | 方案 | Y |
| P1-13 剩余 T3/T4/T5/T6 纳入 Wave 1-3 Y/N | 范围 | Y |
| dev-trace Drop 移除 Y/N | 路径 | Y |
| 2 个独立 Bug 是否进 Wave 1-2 的 D Bug 清单 Y/N | 工单 | Y |
回答这 10 个 Y/N 后,P1 全部进入实施轨道。
六、产出文件索引
docs/_overview/04b-feedback/
├── 00-P1-feedback-response-summary.md (本文)
├── P1-1-schema-migration-risk.md (E-1)
├── P1-2-mvp-cleanup-result.md (主线)
├── P1-3-4-cross-page-params.md (E-2)
├── P1-5-ai-cache-type-spec.md (E-3)
├── P1-6-trigger-api-merge.md (E-3)
├── P1-7-admin-api-prd-evaluation.md (主线)
├── P1-10-customer-detail-entries.md (E-4)
├── P1-12-scattered-memberid.md (E-4)
├── P1-13-prerequisite-fixes-found.md (主线)
└── extra-dev-trace-perf.md (E-4)
04c 反馈处理由 Neo 自行进行 + P0 反馈待 Neo 答 6 问题。两条线并行不冲突。