group_fqcd_jr/开发文档/D1.5-开发前决策清单与阻塞项-2026-09-17.md

开发前决策清单与阻塞项（全量）

体系编号：D1.5　·　域：一、治理与索引　·　编号体系见 D1.1 §4.0

编号：CS-DOC-2026-018　|　版本：v1.0　|　日期：2026-09-17　|　状态：现行（活文档：每项拍板后回填 §7） 性质：开工前唯一的决策登记册。汇总 D2.2 §4.1（T-01T-11）、D2.4 §12.1（T-01T-10 / Q-01Q-13）、D1.4 §8（C-01C-06）、D1.1 §8（D-5D-8）、D1.3 §4（D-1D-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。