Files
Neo-ZQYY/docs/_overview/04b-feedback/00-P1-feedback-response-summary.md
Neo 509cf43284 chore(docs): Wave 0 调研产出 + P0/P1/P2 反馈调研
建立项目级标杆文档 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 残留, 已修 commit 17f045a)
- P0-5 致命 2 (JWT aud 缺失, 已修 commit 17f045a)
- P0-6 clearAllTasks 守卫 (Wave 3)
- P0-8 DBViewer 黑名单漏 (已修 commit 17f045a)
- 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
2026-05-04 07:38:28 +08:00

10 KiB
Raw Blame History

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 同意接受方案AWave你来定
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 修复(customerNamememberId),原描述过时 → 判定从 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/triggers AI 子集,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_at
  • apps/backend/app/schemas/member_retention_clue.py ClueCategory 字典仍是"客户基础信息",但 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 问题。两条线并行不冲突。