308 lines
30 KiB
Markdown
308 lines
30 KiB
Markdown
# 开发前决策清单与阻塞项(全量)
|
||||
|
|
|
|||
|
|
> **体系编号**:`D1.5` · 域:一、治理与索引 · 编号体系见 `D1.1` §4.0
|
|||
|
|
|
|||
|
|
> **编号**:CS-DOC-2026-018 | **版本**:v1.0 | **日期**:2026-09-17 | **状态**:**现行(活文档:每项拍板后回填 §7)**
|
|||
|
|
> **性质**:开工前**唯一**的决策登记册。汇总 `D2.2 §4.1`(T-01~T-11)、`D2.4 §12.1`(T-01~T-10 / Q-01~Q-13)、`D1.4 §8`(C-01~C-06)、`D1.1 §8`(D-5~D-8)、`D1.3 §4`(D-1~D-4 / E-1~E-4)中**尚未关闭**的全部事项,并按「是否阻塞开工」重排。
|
|||
|
|
> **读法**:先看 **§1 速览表**(32 项一眼过)→ 只看 **§2 的 P0**(5 项,决定能不能开工)→ §5 是**要你交的东西**。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 0. 阻塞分级与「最晚决策时点」
|
|||
|
|
|
|||
|
|
| 灯 | 含义 | 判据 | 最晚决策时点 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 🔴 **P0 关键阻塞** | 不定就不能动对应代码 | 决策错会**静默出错**(不报错)或**返工全盘**;或属**安全/会签**纪律前置 | **开工前**(G-00 完成前) |
|
|||
|
|
| 🟠 **P1 重要** | 可并行,但会卡住某个批次 | 影响范围限于单批次 | 进入该批次前 |
|
|||
|
|
| 🟡 **P2 可延后** | 不影响开工与演示 | 文档治理 / 优化类 | 演示前或演示后 |
|
|||
|
|
|
|||
|
|
> **一句话结论**:真正卡住开工的是 **12 项 P0**(`DEC-01`~`DEC-12`),其余 **16 项**(P1 10 / P2 6)可并行或延后。
|
|||
|
|
> 而这 12 项里,**真正要你在「方案之间二选一」的只有 7 项**(`DEC-02`/`03`/`05`/`06`/`08`/`09`/`11`)——
|
|||
|
|
> - **3 项是「授权我连库实测」而非选择**:`DEC-01`(Embedding 维度)/ `DEC-04`(三集合现状)/ `DEC-10`(元数据表现状)⇒ 对应 **`E-3`(你已授权,只差发令)**;
|
|||
|
|
> - **1 项是「发令」**:`DEC-07`(G-00 测试环境就位)⇒ 对应 **`E-1`(你已授权)**;
|
|||
|
|
> - **1 项是「交凭据」**:`DEC-12`(`DASHSCOPE_API_KEY`)。
|
|||
|
|
> ⚠️ **`DEC-11`(交付节奏)建议最先拍板**——它直接决定其余 27 项的取舍。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. 速览表(32 项)
|
|||
|
|
|
|||
|
|
| # | 事项 | 类别 | 我的建议 | 灯 | 最晚时点 |
|
|||
|
|
|---|---|---|---|---|---|
|
|||
|
|
| **DEC-01** | Embedding 模型与**向量维度**(T-01) | 技术选型 | 以底座实况为准,**先实测不接受假定** | 🔴 | 开工前 |
|
|||
|
|
| **DEC-02** | 向量库:起 Milvus 还是用 in-memory fallback | 技术选型 | 起 Milvus(fallback 撑不起三档) | 🔴 | 开工前 |
|
|||
|
|
| **DEC-03** | RAG 基础设施落位:改造既有签名 vs 新建入口(T-03) | 架构 | **改造既有**,绝不新建第二检索入口 | 🔴 | 开工前 |
|
|||
|
|
| **DEC-04** | 三集合:一次性按含档位字段的最终结构创建 vs 改造既有(T-02/T-06) | 数据结构 | 一次性创建(风险由高降为低) | 🔴 | 开工前 |
|
|||
|
|
| **DEC-05** | 访客身份单点化:方案乙先做(改 4 个底座文件,3 个原在「零改动清单」内) | 架构/会签 | 先乙后甲(乙行为零变化) | 🔴 | 开工前 |
|
|||
|
|
| **DEC-06** | 一期安全路由删除前的**关键词 diff**(T-04) | 安全 | 先 diff 再删(唯一带安全性的删除) | 🔴 | 开工前 |
|
|||
|
|
| **DEC-07** | G-00 测试环境就位方式:建 venv + 装依赖 + 跑基线(当前**依赖零安装、无 venv**) | 部署/运维 | 建 venv + 装依赖 + 记录基线 | 🔴 | 开工前 |
|
|||
|
|
| **DEC-08** | 「金融行业基础信息」知识源归属(T-04/Q-01,**游客线唯一内容缺口**) | 功能范围 | 新增第 4 集合 `fin_basic_collection` | 🔴 | 开工前 |
|
|||
|
|
| **DEC-09** | 三档可见性(G-08)本轮是否实现 | 功能范围 | 做(否则访客问答范围不可控) | 🔴 | 开工前 |
|
|||
|
|
| **DEC-10** | 知识元数据表:新建 vs 复用(T-10) | 数据结构 | 先实测再定 | 🔴 | 开工前 |
|
|||
|
|
| **DEC-11** | 交付节奏:7 批次全做 vs 只做 P0 路径保演示 | 成本/时间 | 以「演示跑通」为唯一验收,可裁剪 | 🔴 | 开工前 |
|
|||
|
|
| **DEC-12** | `DASHSCOPE_API_KEY`(当前**为空**) | 第三方依赖/输入 | 需你提供 | 🔴 | 开工前 |
|
|||
|
|
| DEC-13 | 会签:组 1(6 文件 8 处)/ 组 2(批次 G 4 文件)的**会签人与受理口径** | 流程/输入 | 需你指定 | 🟠 | 批次 A 末 |
|
|||
|
|
| DEC-14 | 一期安全路由:保守「不删」是否可接受 | 安全 | 覆盖不全则先不删 | 🟠 | 批次 C 前 |
|
|||
|
|
| DEC-15 | 「不生成交易指令」落为**入库审查规则**(J-03) | 安全/合规 | 加(红线 3 的入库侧落点) | 🟠 | 入库前 |
|
|||
|
|
| DEC-16 | B-01 语料入库门禁(四查)本轮是否实现(D-7) | 安全/合规 | 实现,白名单用 `南方基金`+`nffund.com` | 🟠 | 入库前 |
|
|||
|
|
| DEC-17 | `visibility` vs `audience` 两套字段的唯一口径 | 数据结构 | 以 `visibility` 为准 | 🟠 | 批次 D 前 |
|
|||
|
|
| DEC-18 | 检索参数(**三档阈值 + 档位边界**)是否按真实语料校准(T-08)〔🔁 2026-09-19 措辞更新:`over-fetch` 因子已随分区键改造取消,不再是校准对象〕 | 技术 | ✅ **已校准并结项**(`乙-19`):46 条金标实测,`MIN_GAP` 实测谷 (0.0649, 0.0759),现值 0.07;**结论=维持现值、未改行为** | ✅ | 已结项 2026-09-19 |
|
|||
|
|
| DEC-19 | **记忆三分口径**:短期会话记忆(开)/ 长期记忆召回(关)/ 画像字段级只读(开,不进生成上下文) | 架构/合规 | ✅ **已裁定 (a)**(2026-09-18)——详见本文档 §5 行 | 🟠 | 批次 C 前 |
|
|||
|
|
| DEC-20 | LLM key 是否统一(DeepSeek 主 key vs `DEEPSEEK_API_KEY_NL2SQL`) | 技术/成本 | 统一一把,控成本 | 🟠 | 批次 A 末 |
|
|||
|
|
| DEC-21 | `config_release` 白名单是否清 5 个已摘投顾工具名(T-11,已授权) | 运维 | 清 | 🟠 | 批次 A |
|
|||
|
|
| DEC-22 | 演示账号与数据(T-09) | 输入 | 需你提供 | 🟠 | 演示前 |
|
|||
|
|
| DEC-23 | `D6.1.4-公司新人指南.md` 是否入库(C-01) | 功能范围 | **不入库**(含薪酬/考勤/晋升) | 🟡 | 入库前 |
|
|||
|
|
| DEC-24 | 高净值规范第三章改写后是否入库(C-02) | 功能范围 | 维持只入一、二章 | 🟡 | 入库前 |
|
|||
|
|
| DEC-25 | 底稿定值表是否回改(C-06) | 治理 | 只修 G-01 用到的白名单 | 🟡 | G-01 时 |
|
|||
|
|
| DEC-26 | 早期文档同步品牌 + **系统名统一**(D-2 遗留 / D-6) | 治理 | 统一为「南方基金·智能服务系统」 | 🟡 | 演示前 |
|
|||
|
|
| DEC-27 | 前端 24 + 风控 5 处 `南方财富`(D-5,**评审肉眼可见**) | 合规/前端 | 改 | 🟡 | **演示前**(建议升 P1) |
|
|||
|
|
| **DEC-28** | `CLAUDE.md` 是否改 `D8.1-项目语言规范.md` + 存根 | 治理 | 做(两全) | 🟡 | 任意 |
|
|||
|
|
| **DEC-29** | 🆕 **知识向量库:是否 drop 三个 `fin_*` 集合重建重灌**(`A-03` 实测:实库 52 行、错误品牌「奶龙基金责任有限公司」、schema 与两套脚本都不同、无 `visibility`) | 数据结构/数据 | **drop 重建重灌** | 🔴 | **`T1` 开工前(等你会签)** |
|
|||
|
|
| **DEC-30** | 🆕 **重灌前是否先修 `_chunks.jsonl` 的 `南方科技` 品牌错字**(441 处) | 数据/合规 | **先修再灌**(`B-01`/`B-02` + 串行约束 `S-1`) | 🔴 | **`T1` 开工前** |
|
|||
|
|
| **DEC-31** | 🆕 **FAQ 交付口径**:「64 组」 vs `_chunks.jsonl` 125 行 vs 实库 15 行 | 口径对齐 | 以 `_chunks.jsonl` 为源真相;「组数」与「行数」不同量纲,**写入 `D1.4` 换算关系**即可 | 🟡 | `T1` 前 |
|
|||
|
|
| **DEC-32** | 🆕 **两处 `tools` 脚本的 Embedding 模型名/密钥名收敛**(`qwen3.7-text-embedding-flash` + `env:QWEN_EMBEDDING_API_KEY` → `text-embedding-v3` + `env:QWEN_API_KEY`) | 技术选型/收敛 | **统一到 `text-embedding-v3`**(实测两者都可用且都 1024 维,故非致命,但必须一种口径) | 🟡 | `T1` 前 |
|
|||
|
|
|
|||
|
|
### 1.1 与各文档原编号的交叉映射(便于按旧编号追查)
|
|||
|
|
|
|||
|
|
> 本表解决一个问题:**同一件事在不同文档里有不同编号**(`D2.2 §4.1` 叫 `T-xx`、`D1.4 §8` 叫 `C-xx`、`D1.3 §4` 叫 `D-x`/`E-x`、`D1.1 §8` 叫 `D-x`)。下表给出唯一对应关系,**回填 §7 后我按 `DEC-` 号执行**。
|
|||
|
|
|
|||
|
|
| `DEC-` | 原编号 / 出处 | `DEC-` | 原编号 / 出处 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| DEC-01 | `T-01`(`D2.2 §4.1`)+ `E-3` | DEC-15 | `J-03`(`D2.2 §4.2`) |
|
|||
|
|
| DEC-02 | 🆕 本册新增(向量库形态) | DEC-16 | `B-01` / `D-7`(`D1.1 §8`) |
|
|||
|
|
| DEC-03 | `T-03` | DEC-17 | `D-02`(`D1.4 §4` 两套字段) |
|
|||
|
|
| DEC-04 | `T-02` / `T-06` | DEC-18 | `T-08` |
|
|||
|
|
| DEC-05 | `T-05`(=`D1.3 §4` 的方案甲/乙) | DEC-19 | `D2.2` 附录第 12 项 |
|
|||
|
|
| DEC-06 | `T-04`(安全路由) | DEC-20 | `D2.2 §4.3`(`P-xx` 配置项) |
|
|||
|
|
| DEC-07 | **`E-1`**(G-00) | DEC-21 | `T-11` + `E-2` |
|
|||
|
|
| DEC-08 | `T-04` / `Q-01` / `J-04` | DEC-22 | `T-09` |
|
|||
|
|
| DEC-09 | **`G-08`**(`D1.4 §4`) | DEC-23 | `C-01`(`D1.4 §8`) |
|
|||
|
|
| DEC-10 | `T-10` + `E-3` | DEC-24 | `C-02` |
|
|||
|
|
| DEC-11 | 🆕 本册新增(范围控制) | DEC-25 | `C-06` |
|
|||
|
|
| DEC-12 | 环境搭建记录(`docs/superpowers/handoff/2026-09-10`) | DEC-26 | `D-2 遗留` / `D-6`(`D1.1 §8`) |
|
|||
|
|
| DEC-13 | `D2.1` **P-5 会签门**(组 1 / 组 2) | DEC-27 | **`D-5`** / `G-02` / `G-05` |
|
|||
|
|
| DEC-14 | `D1.3 D-4` 的 B 面 | DEC-28 | `D1.1 §4.0` 的 `CLAUDE.md` 例外 |
|
|||
|
|
|
|||
|
|
> 🔑 **两处「已授权、只差发令」**:`E-1`(= `DEC-07`)与 `E-3`(= `DEC-01`/`DEC-04`/`DEC-10`)。
|
|||
|
|
> 🔑 **一处「已授权但需排在种子重跑之前」**:`E-4` 重跑 `seed_test_rbac.py` —— **必须先跑**,否则 `admin` 的 16 条投顾域绑定会被种子按 `ADMIN_PERMISSIONS` 重新种回(`D-3` 白做)。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 🔴 P0 关键阻塞项(12 项,逐项展开)
|
|||
|
|
|
|||
|
|
### DEC-01|Embedding 模型与向量维度(T-01)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:它不是选择题,而是**你必须授权我去实测**的底座事实。若维度与集合 Schema 不一致,Milvus **不报错**、只是返回无意义结果(静默错误)——这是本项目最危险的一类失败。
|
|||
|
|
- **选项与权衡**:
|
|||
|
|
|
|||
|
|
| 选项 | 代价 | 风险 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| (a) 以底座实况(`settings.EMBEDDING_MODEL` / `EMBEDDING_DIM`)为准 | 0(只是实测) | 若底座配的是小维度模型,检索质量受限 |
|
|||
|
|
| (b) 改用通义 `text-embedding-v3`(1024 维) | 需 `DASHSCOPE_API_KEY` + 全量重灌 | 与既有集合不兼容 ⇒ **必须重建集合** |
|
|||
|
|
|
|||
|
|
- **我的建议**:**(a) 先实测;实测结果若与 1024 维不符,再定 (b)**。启动自检须校验「集合 Schema 维度 == `EMBEDDING_DIM`」,不符即**拒绝启动**。
|
|||
|
|
- **不定则**:全部检索功能**无法验证**,D 批次全停。
|
|||
|
|
|
|||
|
|
### DEC-02|向量库:起 Milvus 还是用 in-memory fallback
|
|||
|
|
|
|||
|
|
- **为何必须你定**:`MILVUS_URI=http://127.0.0.1:19530` 当前**不可用**(服务未起);既有代码有 in-memory cosine fallback。
|
|||
|
|
- **选项与权衡**:
|
|||
|
|
|
|||
|
|
| 选项 | 优点 | 代价/风险 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| (a) 起 Milvus | 支持**三集合 + 标量过滤**(`visibility` 档位过滤**只能在向量库侧做**);可演示真实链路 | 需你授权安装/启动服务(Docker 或本地二进制) |
|
|||
|
|
| (b) 只用 in-memory fallback | 零依赖 | **撑不起三档**——fallback 无 `expr` 过滤能力,档位隔离会退化为「应用层自觉」,与 `D2.4 §5.4` 硬隔离冲突 |
|
|||
|
|
|
|||
|
|
- **我的建议**:**(a)**。理由:三档隔离是本项目**合规底线**(访客不得见产品参数),fallback 结构上做不到。
|
|||
|
|
- **联动**:与 `DEC-07`(环境就位)、`DEC-11`(交付节奏)同批决定。
|
|||
|
|
|
|||
|
|
### DEC-03|RAG 基础设施落位:改造既有 vs 新建入口(T-03)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:**影响面最大**。底座已存在检索/向量化/解析/编排能力(`knowledge_search_service.py` 等)。若新建第二入口,将违反 `docs/14`「不新增架构层」,并产生两条真值路径。
|
|||
|
|
- **选项与权衡**:(a) **改造既有签名**(把检索签名从「布尔 / 无限定」改为**档位集合** fail-closed)——改底座、须会签;(b) 新建独立检索入口——免会签,但**架构违规 + 长期双路径**。
|
|||
|
|
- **我的建议**:**(a)**。`D2.4 §5.4` 已把「档位集合」写进签名;这是**唯一正确落点**。
|
|||
|
|
- **不定则**:D 批次(检索层)**不能开工**——这是「绝不能绕过」的典型。
|
|||
|
|
|
|||
|
|
### DEC-04|三集合:一次性创建 vs 改造既有(T-02 / T-06)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:决定要不要写「变更脚本 + 档位回填」。
|
|||
|
|
- **选项与权衡**:(a) 三集合**尚不存在** ⇒ 由业务侧按「含 `visibility` 字段的最终结构」一次性创建 —— 风险由高降为低,**无需回填脚本**;(b) 集合已存在且无档位字段 ⇒ 必须写 Schema 变更 + 回填,且**回填期存在漏档窗口**。
|
|||
|
|
- **我的建议**:先实测(`DEC-23`)确认现状;若不存在,**按 (a) 一次性创建**并把这个结构**写进 `knowledge_schema.py`**。
|
|||
|
|
- **不定则**:入库第 7 步(元数据写入)与检索改造方向都不确定。
|
|||
|
|
|
|||
|
|
### DEC-05|访客身份单点化:方案乙(T-05)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:方案乙要改 **4 个底座文件**,其中 **3 个原本在「零改动清单」内** ⇒ 属**主动扩张**,`D2.1 P-5` 规定必须**单独一个 PR + 单独会签**。
|
|||
|
|
- **选项与权衡**:(a) **方案乙先做**:新增 `app/core/actor.py` 作访客判定/三元组的**唯一来源**,改 6 处调用点,**对外行为逐字不变** ⇒ 免风险、可先落地;(b) 直接上**方案甲**(新增 `subject_type` 身份轴,终态):一步到位但改动面大、须会签、阻塞时间长。
|
|||
|
|
- **我的建议**:**(a) 先乙后甲**;甲落地时只需改 `actor.py` 一处(`knowledge_tier.py` 调 `actor.is_anonymous()`)。
|
|||
|
|
- **不定则**:**访客权限无法实时收紧**,且受理与执行身份可能不一致(安全缺口)。
|
|||
|
|
- **附带确认**:`security.py` 被 `docs/33/34` 逐行实证过,本组改动会**使行号漂移** ⇒ 你会签单里需确认「行号漂移后那些逐行结论仍成立」。
|
|||
|
|
|
|||
|
|
### DEC-06|一期安全路由删除前的关键词 diff(T-04)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:这是全部重构动作中**唯一带安全性的删除**。一期 `classify()` 承载提示词注入拦截(8 条词)、凭据披露短语、安全关键词路由;二期有 P0 + 零容忍词(11 条),但**未逐条比对**。
|
|||
|
|
- **选项与权衡**:(a) **先做关键词 diff,确认二期完整覆盖后再删**;(b) 保守**不删**(保留一期路由,双路径并存直到补齐)。
|
|||
|
|
- **我的建议**:**(a)**;若 diff 发现覆盖不全 ⇒ 转 (b) 并把缺口写进 Todolist。
|
|||
|
|
- **不定则**:**红队 RT-009/010 必败**(安全回归)。
|
|||
|
|
|
|||
|
|
### DEC-07|G-00 测试环境就位方式(E-1)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:当前本机**依赖零安装、无 venv**,只能做语法层验证(`py_compile` + AST 悬空 import 扫描)。而 G-01 要改**鉴权入口**与 **Worker 执行路径**、D 批次要改**检索层** —— **没有可运行的测试套件时,这些改动等于盲改**。
|
|||
|
|
- **选项与权衡**:(a) 建 venv + 装依赖 + 跑一遍基线并**记录基线**(门禁可运行);(b) 维持语法层验证。
|
|||
|
|
|
|||
|
|
⚠️ 投顾清除后**失去了第二条回归业务线**,底座改动的回归验证只剩客服一条 ⇒ (b) 的风险比清除前**更高**。
|
|||
|
|
- **我的建议**:**(a)**,且列为**最优先**。
|
|||
|
|
- **状态**:**你已授权(E-1),只差一句发令。**
|
|||
|
|
|
|||
|
|
### DEC-08|「金融行业基础信息」知识源归属(T-04 / Q-01 / J-04)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:MVP 游客线明确要求「可查金融行业基础信息」,但**三集合不含此类、也没有源文件** ⇒ **游客线唯一内容缺口**。
|
|||
|
|
- **选项与权衡**:
|
|||
|
|
|
|||
|
|
| 选项 | 优点 | 代价 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| (a) 新增第 4 集合 `fin_basic_collection` | 语义最干净;与「政策 / 产品 / FAQ」并列 | 多一个集合(检索面多一路) |
|
|||
|
|
| (b) 并入 `fin_policy_collection` | 不新增集合 | 语义混杂(监管条文 vs 行业常识) |
|
|||
|
|
| (c) 砍掉游客线该能力、改需求 | 最省工作量 | **改 MVP 范围**,需同步改 D2.2/D2.4/D2.1 三处 |
|
|||
|
|
|
|||
|
|
- **我的建议**:**(a)**;源文件由我按公开常识编写(概念、术语、T+N 时限、风险等级含义等,**不含任何产品参数**),经你复核后入库。
|
|||
|
|
- **不定则**:游客线在演示时**答不出基础金融问题**。
|
|||
|
|
|
|||
|
|
### DEC-09|三档可见性(G-08)本轮是否实现
|
|||
|
|
|
|||
|
|
- **为何必须你定**:`tools/build_knowledge_chunks.py` 对**所有**来源硬编码 `visibility: "public"` ⇒ 文档里的「public 54 / registered 10」**在工程上不存在**;`_chunks.jsonl` 全 public ⇒ **访客与客户召回完全相同**,「三档已接通」**不可证伪**。
|
|||
|
|
- **选项与权衡**:(a) 本轮实现(改灌库脚本 + 造一条 `registered` 测试块);(b) 与 D-01/D-02/D-04 同批。
|
|||
|
|
- **我的建议**:**(a)**。不做则「访客不得问产品参数」这条**业务硬要求**在检索层无法落地。
|
|||
|
|
- **不定则**:**访客会看到产品参数**(合规事故)。
|
|||
|
|
|
|||
|
|
### DEC-10|知识元数据表:新建 vs 复用(T-10)
|
|||
|
|
|
|||
|
|
- **为何必须你定**:决定入库第 7 步是 `CREATE TABLE` 还是 `INSERT INTO` 既有表;并牵涉集合命名是否沿用 `fin_*` 前缀。
|
|||
|
|
- **我的建议**:**先实测**(`E-3` 已授权)再定;沿用 `fin_*` 前缀保持一致性。
|
|||
|
|
|
|||
|
|
### DEC-11|交付节奏:7 批次全做 vs 只做 P0 路径
|
|||
|
|
|
|||
|
|
- **为何必须你定**:`D2.1` 是 **51 项 / 7 批次 / 12 步关键路径**。以当前剩余时间,**全做不现实**。
|
|||
|
|
- **选项与权衡**:(a) 全做(质量最完整,但逾期风险高);(b) **只做「G-00 → G-01 → 检索层 → 演示链路」的 P0 路径**(保「演示跑通」);(c) 只做演示脚本覆盖的功能(最小可用)。
|
|||
|
|
- **我的建议**:**(b)**。依据:`D5.1` 已定「**演示跑通为唯一验收方式**」⇒ 其余项可标注为「已识别、未实施」写进答辩材料。
|
|||
|
|
- **不定则**:范围失控,P0 项被 P2 项挤占。
|
|||
|
|
- ⚠️ 这一项**直接决定其余 27 项的取舍**,建议**最先拍板**。
|
|||
|
|
|
|||
|
|
### DEC-12|`DASHSCOPE_API_KEY`
|
|||
|
|
|
|||
|
|
- **为何必须你定**:`docs/superpowers/handoff/2026-09-10-环境搭建记录.md` 记载该变量**当前为空**,标注「子项目 A 的 embedding 端点密钥,**待用户提供**」。
|
|||
|
|
- **影响**:没有 key ⇒ **无法向量化 ⇒ 无法灌库 ⇒ 无法检索**。属**硬阻断**。
|
|||
|
|
- **需要你做的**:提供 key(或指定用哪个账号/额度)。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 🟠 P1 重要项(10 项)
|
|||
|
|
|
|||
|
|
| # | 事项 | 选项与权衡 | 我的建议 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| **DEC-13** | 会签人与受理口径 | (a) 你本人会签;(b) 指定「底座 owner」代签 | 明确**组 1 / 组 2 各自的会签人**,并写明「不受理则走降级」——否则 G-01 永远排不上队 |
|
|||
|
|
| **DEC-14** | 安全路由是否可保守不删 | (a) 先 diff 再定;(b) 一律不删 | 若 diff 显示覆盖不全 ⇒ 保留(`DEC-06` 的 B 面) |
|
|||
|
|
| **DEC-15** | 「不生成交易指令」入库审查规则(J-03) | (a) 在入库 SOP 增「可执行要素检查」(产品代码+金额+份额+确认动作 → 改写或剔除);(b) 只在生成侧拦 | **(a)**——红线 3 单靠生成侧不够 |
|
|||
|
|
| **DEC-16** | B-01 入库门禁(四查)是否实现(D-7) | (a) 实现(占位符/品牌白名单/禁止类目/`visibility` 显式声明);(b) 延后 | **(a)**,且白名单值**必须**用 `南方基金` + `nffund.com`(旧文档里的 `南方财富` + `nanfangwm.com` 会放行错误品牌) |
|
|||
|
|
| **DEC-17** | `visibility` vs `audience` 唯一口径 | (a) 以 `visibility` 为准,`audience` 仅留在 preflight 校验;(b) 反之 | **(a)**——检索层用的是 `visibility`,且 `knowledge_schema.py` 的 `FIELD_CANDIDATES` 无 `audience` |
|
|||
|
|
| **DEC-18** | 检索参数是否校准(T-08)〔🔁 2026-09-19 措辞更新:`over-fetch` 因子已取消,校准对象=**三档阈值 + 档位边界**〕 | (a) 在真实语料上校准三档阈值与档位边界;(b) 沿用推断值 | **(a)**,否则召回/兜底率不可控。**已执行**:见 `D1.6` §4.34 与 `docs/evidence/20260919-t9-threshold-calibration.json` |
|
|||
|
|
| **DEC-19** | **记忆三分口径** | (a) **短期开(读/写)/长期召回关/画像字段级只读且不进生成上下文**;(b) 画像完全不可读(按 `D2.2` 附录第 12 项字面);(c) 仅演示期开画像只读 | ✅ **已裁定 (a)**(2026-09-18)。**理由**:① 长期记忆(`user_facts`)的唯一用途是喂画像,而画像的下游消费者是投顾与风控——投顾已于 2026-09-17 整体清除,Neo4j 图读侧调用点一并删除,留着召回等于为已不存在的场景保留数据出口;② 把 `memory_unit` / `user_facts` 注入生成上下文会产生**检索证据之外的内容**,与 `DEC-I2` 证据约束生成及 `D3.7`「无出处数字」零容忍直接冲突;③ 画像若按字面完全关闭,会同时废掉**画像问答**、`FR-CS-024` 画像标签、§3.5.2 适当性过滤三处;④ 访客侧无 `customer_id`,本就只能硬禁(`FR-CS-046` 基类兜底)。**落地**:`D2.2` §1.7 范围表 + 附录第 12 / 18 项(并补第 21 项)、`D3.1` §3.5 三层权限表已同步;矛盾登记见 `D1.6` §3.3 `Q-1.8` |
|
|||
|
|
| **DEC-20** | LLM key 是否统一 | (a) 统一 DeepSeek 一把 key;(b) NL2SQL 用独立 key(限额隔离) | 演示期 **(a)**;若你更在意配额隔离则 (b) |
|
|||
|
|
| **DEC-21** | `config_release` 清 5 个已摘投顾工具名(T-11 / E-2,已授权) | (a) 清;(b) 不清 | **(a)**——不清则以「工具未注册」失败(fail-closed,不静默) |
|
|||
|
|
| **DEC-22** | 演示账号与数据(T-09) | (a) 用既有种子账号(`cust_t` / `admin_t` 等);(b) 你另给 | 需你确认可用性与可外演示性 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. 🟡 P2 可延后项(6 项)
|
|||
|
|
|
|||
|
|
| # | 事项 | 建议 | 备注 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| **DEC-23** | `D6.1.4-公司新人指南.md` 是否入库(C-01) | **不入库**(含薪酬/考勤/晋升等内部 HR 信息);如要入,只入 §1—§3 | 现行灌库脚本本就不含它 |
|
|||
|
|
| **DEC-24** | 高净值规范第三章是否入库(C-02) | 维持只入「一、二」两章 | 传承/信托属咨询类,入库收益低 |
|
|||
|
|
| **DEC-25** | 底稿定值表是否回改(C-06) | 只修 G-01 用到的白名单,底稿**保持溯源** | 底稿是「当时的事实」 |
|
|||
|
|
| **DEC-26** | 早期文档品牌 + **系统名统一**(D-6) | 统一为「**南方基金·智能服务系统**」(现母本用「智能财富管家系统」、`knowledge\` 镜像与交付文档用「智能服务系统」,**同源两版打架**) | 涉及约 13 处 |
|
|||
|
|
| **DEC-27** | 前端 24 + 风控 5 处 `南方财富`(D-5) | **改** | 🔴 **评审唯一用眼睛看到的品牌面**——文档再干净,打开页面还是「南方财富」。**建议升为 P1** |
|
|||
|
|
| **DEC-28** | `CLAUDE.md` 是否带号 | 做 `D8.1-项目语言规范.md` + 三行存根 `CLAUDE.md` | 兼顾工具约定与编号统一 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. 📌 需要你提供的输入 / 凭据(7 项)
|
|||
|
|
|
|||
|
|
| # | 需要什么 | 用于 | 阻塞级 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 1 | **`DASHSCOPE_API_KEY`** | Embedding 向量化(灌库 + 检索) | 🔴 硬阻断 |
|
|||
|
|
| 2 | **`DEEPSEEK_API_KEY`**(是否另给 NL2SQL 专用 key) | LLM 推理 | 🔴 硬阻断 |
|
|||
|
|
| 3 | `MILVUS_TOKEN`(**仅**当用远程/托管 Milvus 时) | 向量库连接 | 🟠 |
|
|||
|
|
| 4 | **会签人 + 受理口径**(组 1 / 组 2 各一份) | 底座件改动的合法性 | 🟠 |
|
|||
|
|
| 5 | **授权**:建 venv + 装依赖 + 启动 Milvus + 连库实测(E-1/E-3) | G-00 / T-01·02·03·10 | 🔴 硬阻断 |
|
|||
|
|
| 6 | 演示账号与数据可用性确认(T-09) | 演示脚本 | 🟠 |
|
|||
|
|
| 7 | 答辩的**确切时间与形式** | 决定 `DEC-11` 的裁剪力度 | 🟠 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. ✅ 已定 / 已授权(**不需再拍板,仅供对照**)
|
|||
|
|
|
|||
|
|
| 项 | 结论 | 出处 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 访客是否可见产品参数 | ✅ **不可见**;判据=答案是否含「具体数值型产品要素」 | `D2.2` T-07(2026-09-17 定案) |
|
|||
|
|
| 品牌口径 | ✅ 全部统一为**南方基金**(热线 `400-889-8899` / `nffund.com`) | `D1.2` CS-CONTENT-2026-015 v1.1 |
|
|||
|
|
| C—R 匹配矩阵 | ✅ C1→R1—R2 / C2→R1—R3 / C3→R1—R4 / C4→R1—R5 / C5→全部 | `D1.2` §4.4 · `D2.2` §1.6.1 |
|
|||
|
|
| 数据三分法 | ✅ A 类真值 / B 类公开量级(截止 2026-06-30)/ C 类虚构(`9xxxxx`) | `D1.2` §4.2 |
|
|||
|
|
| 三条红线与验收方式 | ✅ 演示跑通为唯一验收 | `D5.1` |
|
|||
|
|
| 交付文档品牌与系统名 | ✅ 系统名「智能服务系统」 | `D1.1` §7.1(D-1 已执行) |
|
|||
|
|
| 文档体系编号 | ✅ `D<域>.<序>`,编号进文件名(46 份),`CLAUDE.md` 例外 | `D1.1` §4.0/§5 R7/§11 |
|
|||
|
|
| `admin` 投顾域残留权限 | ✅ 已清 16 条,保留 5 条(有存活消费者) | `D1.1` §7.2(D-3 已执行) |
|
|||
|
|
| 代码侧品牌 3 处 | ✅ 已改(热线 / 话术 / 补「股份」) | `D1.1` §7.3(D-4 已执行) |
|
|||
|
|
| 早期系统文档处置 | ✅ 加状态标注;`记忆架构设计.html` 撤销归档 | `D1.1` §7.1(D-2 已执行) |
|
|||
|
|
| 开发文档可删性 | ✅ 核查结论:**无可删文档**(43+4 全部被引用) | `D1.1` §10 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. 决策回填表(供你逐项批注)
|
|||
|
|
|
|||
|
|
> 回填方式:直接在「你的决定」列写 `A` / `B` / `同意建议` / 备注。我按此表执行。
|
|||
|
|
>
|
|||
|
|
> 🔴 **2026-09-18 已于本列全部回填**:`DEC-01`~`DEC-28` 28 项**无一改写**,与 `D1.6` §4.6「八、乙类 29 项批复结果」一致。
|
|||
|
|
|
|||
|
|
| # | 事项 | 我的建议 | 你的决定 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| DEC-01 | Embedding 维度(T-01) | 先实测,不接受假定 | ✅ 同意——先实测,并入 `E-3` |
|
|||
|
|
| DEC-02 | 向量库 | 起 Milvus | ✅ 同意 (a)——起 Milvus(`乙-3`) |
|
|||
|
|
| DEC-03 | RAG 落位 | 改造既有签名 | ✅ 同意 (a)——改造既有签名(`乙-4`) |
|
|||
|
|
| DEC-04 | 三集合 | 一次性按最终结构创建 | ✅ 同意——一次性按最终结构创建(并入 `乙-16` / `H-05`) |
|
|||
|
|
| DEC-05 | 访客身份单点化 | 先方案乙后方案甲 | ✅ 同意 (a)——先方案乙后方案甲(`乙-5`) |
|
|||
|
|
| DEC-06 | 安全路由 | 先 diff 再删 | ✅ 同意 (a)——先 diff 再删(`乙-6`) |
|
|||
|
|
| DEC-07 | G-00 环境 | 建 venv + 装依赖 + 记录基线 | ✅ 同意——建 venv + 装依赖 + 记录基线(`G-00`) |
|
|||
|
|
| DEC-08 | 金融行业基础信息 | 新增第 4 集合 | ✅ 同意 (a)——新增第 4 集合(`乙-7`) |
|
|||
|
|
| DEC-09 | 三档可见性 | 本轮实现 | ✅ 同意 (a)——本轮实现(`乙-8`);复查收紧为「机制 + 最小样本」 |
|
|||
|
|
| DEC-10 | 知识元数据表 | 先实测 | ✅ 同意——先实测(并入 `H-05` 前置) |
|
|||
|
|
| DEC-11 | **交付节奏(最先拍板)** | 只做 P0 路径保演示 | ✅ 同意 (a)——只做 P0 路径保演示(`乙-2`) |
|
|||
|
|
| DEC-12 | `DASHSCOPE_API_KEY` | 需你提供 | ✅ 已提供——存 `group_fqcd_jr\.env`,不入文档 |
|
|||
|
|
| DEC-13 | 会签人与口径 | 需你指定 | ✅ 已定 (b)——你本人会签 + 逐项留痕(`甲-3`) |
|
|||
|
|
| DEC-14 | 安全路由是否可不删 | diff 不全则不删 | ✅ 同意——diff 覆盖不全则不删(`乙-6`) |
|
|||
|
|
| DEC-15 | 入库审查规则 | 加 | ✅ 同意 (a)——入库 SOP 增「可执行要素检查」(`乙-17`) |
|
|||
|
|
| DEC-16 | B-01 门禁 | 实现 | ✅ 同意 (a)——实现四查(`乙-18`) |
|
|||
|
|
| DEC-17 | `visibility`/`audience` | 以 `visibility` 为准 | ✅ 同意 (a)——以 `visibility` 为准(`乙-9`) |
|
|||
|
|
| DEC-18 | 检索参数校准 | 校准 | ✅ **已校准并结项**(`乙-19`,2026-09-19);措辞已更新为「三档阈值 + 档位边界」(`over-fetch` 取消)。**实测结论=维持现值**:`MIN_GAP` 谷 (0.0649, 0.0759) ⊃ 0.07;`HIGH_SCORE` 0.75 裕度 0.22 |
|
|||
|
|
| DEC-19 | 记忆三分口径 | ✅ 短期开 / 长期召回关 / 画像字段级只读 | ✅ 已裁定 (a)——短期开 / 长期召回关 / 画像字段级只读(`乙-20`) |
|
|||
|
|
| DEC-20 | LLM key | 统一 | ✅ 已定 (a)——统一一把 DeepSeek key(`甲-2`) |
|
|||
|
|
| DEC-21 | `config_release` 清理 | 清 | ✅ 同意 (a)——清 5 个已摘投顾工具名(`乙-21`) |
|
|||
|
|
| DEC-22 | 演示账号 | 用既有种子账号 | ✅ 已定 (a)——既有种子账号(`甲-5`) |
|
|||
|
|
| DEC-23 | 新人指南入库 | 不入库 | ✅ 同意 (a)——不入库(`乙-22`) |
|
|||
|
|
| DEC-24 | 高净值第三章 | 只入一、二章 | ✅ 同意 (a)——维持只入一、二章(`乙-23`) |
|
|||
|
|
| DEC-25 | 底稿定稿 | 只修白名单 | ✅ 同意 (a)——只修 `G-01` 用到的白名单(`乙-24`) |
|
|||
|
|
| DEC-26 | 系统名统一 | 统一为「南方基金·智能服务系统」 | ✅ 同意 (a)——统一为「南方基金·智能服务系统」(`乙-25`) |
|
|||
|
|
| DEC-27 | 前端品牌面 | 改(建议升 P1) | ✅ 同意 (a)——改,并升为 P1(`乙-26`) |
|
|||
|
|
| DEC-28 | `CLAUDE.md` | 带号 + 存根 | ✅ 同意 (a)——做 `D8.1` + 三行存根(`乙-27`) |
|
|||
|
|
| DEC-29 | 三集合 drop 重建重灌 | drop 重建重灌 | ✅ 已批复(2026-09-18)——**不用旧数据,全部用新数据**(`丁-1`) |
|
|||
|
|
| DEC-30 | 重灌前修 `南方科技` 错字 | 先修再灌 | ✅ 已批复——先修再灌(`丁-2`) |
|
|||
|
|
| DEC-31 | FAQ 交付口径 | 以 `_chunks.jsonl` 为源真相 | ✅ 已批复——以 `_chunks.jsonl` 为源真相(`丁-3`) |
|
|||
|
|
| DEC-32 | 两处 `tools` 脚本模型名收敛 | 统一到 `text-embedding-v3` | ✅ 已批复——统一到 `text-embedding-v3` + `env:QWEN_API_KEY`(`丁-4`) |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
> **编制**:项目文档组 | **审核**:合规稽核部 | **日期**:2026-09-17
|
|||
|
|
> **同步义务**:本表任一项拍板后,须同步回填本文件 §7,并更新对应的 `D2.1` / `D2.2` / `D2.4` 待确认清单状态。
|
|||
|
|
|
|||
|
|
> 🆕 **2026-09-18 第三轮新增(丁类 4 项,已批复)**:`DEC-29`~`DEC-32` 由 `A-03` 取证结果派生(见 `D1.6` §4.7)。其中 `DEC-29` / `DEC-30` 是 `T1` 的**硬前置**:`DEC-29` 不批则官方建表脚本持续 `exit 2`(实测三个集合全部「结构不同」),`DEC-30` 不修则重建等于把错字原样灌回。**已于 2026-09-18 全部批复(「不用旧数据,全部用新数据」),`T0` 已收口,现进 `T1`。**
|