张胜宇
bc61d5c579
## 为什么做这一步 权威文档 74 份此前**只在本机**，评审者 clone 分支后看不到任何设计文档；而仓库里那两份同名目录 是 **2026-09-16 之前的过期副本，连文件名都是旧的**（无体系编号）。本次按「**权威覆盖过期**」入库。 ## 入库内容 | 目录 | 文件数 | 体积 | 说明 | |---|---|---|---| | `客服agent/` | 24 | 0.77 MB | `D2.1`~`D2.6` 对外交付四件套 + 演示脚本/答辩报告 + `_build` 构建工具 | | `开发文档/` | 50 | 2.16 MB | `D1.x` 索引与决策、`D3.x` 方案、`D4.x` 清除与重构留痕、`D5.x` 业务流程、`D6.x` 业务事实基座、`D7.x` 交付物、`D8.x` 规范 | **旧的过期副本整体移除**（`客服Agent执行Todolist.md` → `D2.1-客服Agent执行Todolist.md` 之类 的改名 + 新增 `D2.5`/`D2.6`），入库后目录内容与权威副本**逐文件一致（零差异，已复核）**。 ## 入库前的安全扫描（必须留痕） - 扫描规则：`sk-` 类密钥 / `Bearer` 长串 / `password=`、`api_key=` 赋值 / 会话中出现过的两把明文 key 片段。 - 结论：**真实密钥只出现在 `.env`**（已被 `.gitignore` 命中，未入库）；`.env.example` 与 `config/risk.env.example` 只有**空占位**。 - 文档内唯一命中是 `D3.1` 里一处**截断的示例 JWT**（`Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...`）， 末尾带省略号，是接口文档的示意值，**不是可用凭据**。
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`。**
|