09 · 度量评价与落地路径 · 落地方案

钝悟2026/10/23大约 67 分钟

09 · 度量评价与落地路径 · 落地方案

对应蓝图 §10 + 附录。本文解决：知识库整体如何分阶段建设？如何度量成熟度？如何组织人力？非功能性如何保障？
状态：草案（§6.2 的 LD1–LD11 待确认，其中 LD1 / LD4 / LD7 / LD8 须在 P0 启动前决策且不可逆）
前置依赖：全部 01–08 的建设项与度量口径（本文是总览与收口，任一上游文档的字段或指标变更都须回灌本文）
关联文档：04-知识存储（字段字典 §3.7、重建时长 §7）· 05-知识检索与引用（审计字段 §9.3、延迟预算 §5）· 06-知识维护与治理（边际价值 §2.4、园艺 §3.5）· 07-评测与反馈闭环（工程基线 §2.4、返工口径 §2.4.1）· 08-约束执行（Hook 形态 §2.2、Worktree §2.5）

1. 定位与边界

度量评价与落地路径是整套方案的"总控塔"：它不解决具体技术细节，只解决建设顺序、组织分工、验收标准、非功能性约束四件事。

与 01–08 的关系：01–08 分别解决知识生命周期的八个阶段，本文解决"这八个阶段按什么顺序建设、谁来建设、建到什么程度算完成"。

2. 核心设计决策

2.1 成熟度模型：L0–L5

蓝图 §10.1 定义六级成熟度，安全不是最后阶段的能力：

阶段	建设目标	主要能力	该阶段必须同时具备的安全与审计能力
L0	可搜索	聚合知识、目录、基础检索	`classification` 字段落库；检索前按密级过滤（05 §9.1）
L1	可溯源	来源、版本、Chunk 引用、拒答	检索审计日志开启；引用可解析率可统计
L2	可治理	Owner、生命周期、漂移治理	越权访问告警；Owner 变更留痕
L3	可约束	Hook、Lint、测试、CI 门禁	阻断事件全量留痕并可回溯到 trace_id
L4	变更驱动	MR、API、DDL 自动影响分析	影响分析结果纳入审计，供事故归因
L5	持续自证	评测、反馈、收益和熵治理	评测集含权限越权集，回归门禁覆盖安全用例

为什么密级过滤属于 L0：一旦无过滤的知识先被 Agent 消费，事后补权限无法撤销已经泄露的内容。这是把 05 §9.1 的检索前密级过滤提前到 P0 的原因。

L0–L5 是能力累计层级，不是时间顺序，也不是「后一层可以晚做」的意思。三点必须澄清，否则该表会被误读为路线图：

高层级包含低层级的全部能力。L3「可约束」成立的前提是 L0 的密级过滤与 L1 的溯源仍然生效；任何一层退化都会使其上层失效（例如 L1 的引用不可解析，则 L3 的阻断事件无法回溯到 trace_id）。
层级与建设期（§3 的 P0–P3）不是一一对应。P0 就要求 L0 + L1 的安全与审计能力全部就位（见 §2.7.1 的 10 项硬门禁），而 L5 的评测能力排在 P2。用「我们现在才 L1」来解释「所以还不能上权限过滤」是本表最典型的误用。
表中「该阶段必须同时具备的安全与审计能力」列是准入条件，不是可选增强。某一层的建设项若不具备同层要求的安全能力，则该层不算达成——例如 L4 的影响分析若其结果不进审计，则 L4 未完成，不能记为已达成。

2.2 冷启动路径：C0–C3

蓝图 §10.1 明确先读后写原则——第一批价值来自让存量知识可检索，而不是让团队写新条目。

为什么不能先要求写作：写一条合格知识的成本落在作者身上，收益落在读者身上，而读者通常是未来的、不确定的、看不见的人（§3.2）。冷启动阶段就派发写作任务，收到的必然是凑数内容，而这些内容立刻成为 06 §2.4 定义的负价值知识。

四期推进：

期	目标	做什么	明确不做什么	对应建设期（§3）
C0a	可检索（Git 来源）	Git Markdown 摄入（01 §7.1）+ 元数据最小集由 CI 自动回填 + 只读检索上线	不要求任何人写新条目；不建全量分类体系；不含 Confluence/Wiki/PDF	P0
C0b	可检索（外部来源）	Confluence / Wiki / PDF / Office 解析链路（01 §7.2）+ 权威源绑定（01 §7.4）	不做无权威源绑定的批量导入（fail-closed，01 §7.3）	P1
C1	有需求证据	开启审计日志（05 §9.3），统计 `refusal` 与低召回 query，形成种子知识清单	不靠"哪个团队愿意配合"选题	P0（审计）→ P1（清单产出）
C2	核心域跑通	选 1–2 个种子域补齐知识，打通 Owner 复核与漂移告警闭环	不追求覆盖率指标	P1
C3	规模化	全量摄入、关系图谱（06 §3.4，图谱建模本身在 06 中无独立小节，见 §6.2 LD9）、评测回归门禁（07 §2.5）	—	P2（评测门禁）→ P3（图谱）

为什么把原 C0 拆成 C0a/C0b：原 C0 一行同时要求「Git Markdown 摄入」与「Confluence/Wiki/PDF 解析」都在冷启动首期完成，但 §3.2 明确把「Confluence / Wiki / PDF / Office 解析链路」排在 P1，理由是「存量知识主体，无此链路则知识库只覆盖新增部分」。同一份文档对同一件事给出两个不同的期次，是执行时必然产生分歧的地方——按 C0 读，P0 验收就应包含 PDF 解析；按 §3.2 读，P0 只需 Git 链路。
拆分的依据是两类来源的工程性质不同：Git Markdown 是零转换来源（文件本身即目标格式，CI 可直接读取 frontmatter 与 blob hash），而 Confluence/Wiki/PDF 需要解析服务、结构保留、权威源绑定与 fail-closed 处置（01 §7.2–§7.4），且 Confluence REST 返回的是 XHTML storage format，需要独立的转换与校验链路。把两者捆在一期，等于让 P0 的完成判据依赖一个 P1 才建成的组件。
「对应建设期」列是本次新增：原文 C0–C3 与 §3 的 P0–P3 是两套并行的阶段划分，却没有任何一处说明它们的对应关系。缺了这一列，「C2 阶段只采集不设目标」（§5）这类表述无法落到具体建设期，验收时也无从判定某个 C 期是否完成。对应关系为多对多（一个 C 期可跨多个 P 期），不是简单的一对一。
种子域选择判据（三条同时满足）：

AI Coding 场景在该域的占比高。
该域有明确的 Owner 团队（否则 03 §3.1 的责任制无法落地）。
存量文档相对集中（解析成本可控）。

迁移顺序不按目录树，按 C1 的 query 命中缺口。按目录迁移的结果是：最容易迁的（格式规整的旧设计文档）先被迁完，而这些恰恰是查询最少、最可能已过期的部分。

2.3 冷启动常见反模式

反模式	为什么会失败
先建全量分类体系再填内容	分类体系会随实际内容变形，先建的必然返工，且返工期间目录不可用
先要求每团队交 N 篇	交上来的是凑数内容；配额一旦达成，后续再无人主动写
先上 GraphRAG	无实体无关系可抽取；L4 的变更驱动影响分析能力建立在 L0 的数据与 L1 的溯源之上，跳过前序层级时图谱无输入（§2.1）
把"存量迁移完成"当冷启动完成判据	迁移完成只证明可搜索，不证明有人在用

冷启动完成判据：

审计日志中 refusal 率与低召回 query 数可统计（机制保证——只要有日志即成立）。
种子域的核心问题能引用回源（阈值待实测）。
主动提交信号成立：连续 4 周（周期待实测）内「非平台团队成员主动提交的知识 MR 数 > 0」且累计提交人数 ≥ 3（人数阈值待实测）。

为什么不是「至少一个人提交过一次」：那是一个二元事件（0 或 1），不是可看环比方向的量，不符合附录对「趋势指标」的定义；且 n=1 无统计意义——单次提交可能源于好奇或私人关系，不能证明激励结构跑通。改为「连续 N 周 + 人数 ≥ M」后既是趋势口径，也避免偶然性。
产生该事件的机制必须显式设计，否则判据不可达成：§2.4 原则 2 的自动转化草稿若由平台组的摄入链路提 MR，作者是平台组，不满足「非平台成员主动提交」；而 C0/C1 又明确不派发写作任务、不培训用户。唯一路径是「确认即提交」——见 §2.4 原则 5。

2.4 组织与角色：四类分工

蓝图 §10.2 定义四类角色，写作激励必须与阅读收益解耦：

角色	职责	归属	兼任约束
知识 Owner	单条目内容正确性、周期复核、漂移处理	条目对应模块的负责团队	不得为平台组——平台组不了解业务语义，代管等于无人负责
知识 Steward	目录结构、受控术语表、条目模板、元数据 Schema 演进、CODEOWNERS 维护	每租户各一套	不得同时是该域的审批人，否则自审自批（03 §3.2）
平台组	摄入链路、索引、检索服务、权限过滤、审计、评测流水线	共享	—
知识园艺	周期扫描孤儿/过期/低边际价值条目，产出待处理清单	平台组 Agent + 人工确认	不得有自动删除权（06 §2.4 三重防误删）

激励不对称是知识库衰败的根因，不是"大家不重视"。四条设计原则：

不要把"写知识"当额外任务派发。派发出来的必然是凑数内容（§2.2）。
嵌进本来就要做的动作：MR 描述、ADR、事故复盘、评审结论由摄入链路自动转化为条目草稿（01 §7、02 §4.1），人只做确认与补充，不做从零写作。
收益必须回流到作者与团队两个维度：条目被检索命中次数、被 Agent 引用次数按作者个人与其 owner_group 双维度可见。数据源已存在——05 §9.3 的审计日志含 retrieved_chunks（命中）与 generated_claims（被引用），无需新增埋点，但聚合管道与看板需单独建设（工作量不可忽略，已计入 §2.6.6 治理人力）。
- 原文只写「按 Owner 可见」不足以解决激励不对称：§2.3 的论证前提是「写作成本落在作者个人身上」，而 Owner 是团队（owner_group）。收益只聚合到团队维度，作者个人仍无收益，激励不对称未被消除。因此需要 frontmatter 新增 author 字段（个人，与 owner_group 并存）——该字段是否纳入 P0 Schema 见 §6.2 LD8。
- 反博弈约束：命中次数只做团队级趋势展示，不做个人排名；单条目命中数须与 06 §2.4 的边际价值公式联立展示（避免只看分子不看分母）；明确不得作为绩效考核输入。否则可预见的博弈是拆条提高计数、把 owner_group 挂到高频域、堆砌热门关键词——这与原则 4「正向指标可被凑数刷高」是同一个问题。
- 合规约束：看板只含聚合计数与 knowledge_id，不含 query_text 原文（05 §9.3 纪律 3：日志本身有密级）。
反向指标的凑数成本更高："因知识缺失导致的返工与事故"比"写了多少篇"更能说明价值，也更容易获得管理层持续投入。正向指标（篇数）可以零成本刷高；反向指标要压低则需隐瞒一次真实事故，而事故有独立上报渠道（安全/质量事件系统），因此反向指标的下限受外部系统约束。
但这不等于反向指标不可操纵——它依赖归因，而 07 §2.3 规定归因是「AI 提议 + Owner 确认」，确认权在 Owner 手上，Owner 又恰是知识库质量的被考核方。若 Owner 倾向把失败归因为 Generation Failure（模型问题）而非 Business Understanding Failure（知识缺失），反向指标就被系统性压低。07 §3.2 的 Cohen's Kappa 只度量标注者之间的一致性，不度量系统性偏向（所有人都少标同一类时 Kappa 可以很高）。因此配套约束：
- 归因确认人不得是该条知识的 Owner；Business Understanding Failure 的归因由 Steward 或第三方团队复核。
- 每季度抽样 N%（待实测）的归因结论做盲评（标注者不知晓原结论），一致率低于门槛则触发归因指南修订。门槛见 §2.7.2「归因盲评一致率门槛」。
性质：本条整段为工程推导，无外部量化依据（与蓝图 §10.2 同口径） | 置信度：中
确认即提交：原则 2 的自动转化草稿，必须由该域业务成员（而非平台组）在自己的分支上确认后以自己名义提 MR。草稿由机器生成，但 MR 的作者身份必须是业务成员——这是「主动提交」能被观测到的唯一路径。配套建设项：草稿确认入口（IDE 插件或 MR 模板一键确认），见 §3.2 P1。

2.5 多租户隔离层次

蓝图 §10.2 定义多 BU 共用一套实例时的隔离要求：

维度	隔离要求	理由
索引	每租户独立 collection / index，不靠 metadata 过滤	metadata 过滤一旦漏写即跨租户泄露；与 05 §9.1 的"检索前过滤"是同一原则的租户版
受控术语表	租户内受控；全局术语表只放真正共用的术语	同一术语在不同 BU 可能语义相反，全局共享会污染 05 §6 的查询改写
评测集	金标集不得跨租户共享	金标集含真实业务 query 与答案（07 §3.1）
审计与配额	按租户归集，成本分租户核算	§2.6.6 成本模型需要租户维度才能定价与限流
平台组 / Steward	平台组共享，Steward 每租户各一套	平台是技术设施可复用，目录与术语是业务语义不可复用

2.6 非功能性设计

2.6.1 容量与规模量级

蓝图 §10.3 给出三档规模，具体数值必须由本团队按实际语料测算后填入：

规模档位	知识条目数	向量数（含切分放大）	典型部署形态
小型	千级	万级	单机 pgvector。可与业务库同实例，但须满足下述两项隔离前提
中型	万级	十万级	独立向量库单集群 + ES 混合检索
大型	十万级以上	百万级以上	向量库分片集群 + 独立 Embedding 服务

小型档「与业务库同实例」有两项前提，缺一即须独立实例：① 索引重建必须能限流并可暂停（§2.6.3 约束 1）——同实例时重建的 CPU/IO 会直接与业务查询争抢，而千级条目的重建窗口往往被安排在业务时段；② 审计日志不得与该实例同库（§2.6.3 约束 3、05 §9.3 纪律 1）。原文只写「与业务库同实例」，读者会连带把元数据库与审计日志也放进去，而审计日志一旦与业务库同实例，业务库的容量增长与备份策略就会决定审计日志的保留期——这违反「保留期由合规确定」（§2.7.2）。
性质：本条为工程推导，无外部依据 | 置信度：中

切分放大系数必须实测：一条知识条目按 04 §5.1 切分后产生的 chunk 数不是常数，它取决于文档长度分布。若按"1 条 = 3 chunk"估算而实际是 8，向量存储与 Embedding 成本会偏差数倍，且这个偏差在 P0 阶段就会暴露。

容量测算第一步：对现有语料做一次完整切分，统计 chunk 数分布（均值 / P90 / 最大值），再乘以上下文前缀带来的长度增量（04 §5.2）。

2.6.2 QPS 与并发

调用来源	流量特征	设计影响
开发者交互式提问	低频、突发、延迟敏感	决定低并发下的 P95 基线（05 §10.1）
Agent 自动检索（编码中）	高频、批量、每任务多次、同步阻塞故同样延迟敏感	决定容量上限与高并发下的 P95，是主要负载来源
CI / Hook 校验	与 MR 量正相关、可排队	可异步，不进延迟预算
索引构建与重建	周期性、CPU/GPU 密集	必须与在线检索资源隔离

关键判断：Agent 自动检索的量级通常远高于人的提问量级——一次编码任务可能触发数十次知识检索（「数十次」是定性量级判断，非实测值；该因子必须在 P0 按 §2.6.2 的测算方法实测后回填，性质为阈值待实测）。若按"团队人数 × 人均提问数"估算容量，会严重低估。容量必须按"并发 Agent 数 × 每任务检索次数"估算。

Agent 检索同样延迟敏感：Agent 在编码过程中检索是同步阻塞的——拿不到结果就无法继续生成。一次任务数十次检索，每次多等 300ms 就累积成数秒任务延迟。因此不能只把人的交互式提问纳入 P95 目标，否则会出现「容量按 Agent 负载设计（吞吐优先）、延迟按人的负载设计（P95 ≤ 500ms）」的分裂，两者在压测时必然冲突（高并发 P95 与低并发 P95 完全不同）。

两个因子的可执行测算方法（原公式正确但无采集途径，等于口号）：

因子	测算方式	前置条件
并发 Agent 数	峰值时段内 `SessionStart` 事件数 / 平均会话时长（`SessionStart`/`SessionEnd` 配对，08 §2.2 已确认 CLI 与 IDE 两形态均支持这两个事件）	审计日志新增 `session_id`
每任务检索次数	同一 `session_id`（或同一 `trace_id`）内 MCP `search_knowledge` 的调用次数（05 §10.1）	同上

注意：05 §9.3 的 actor 字段刻意只记录发起人身份（人，不是 Agent 服务账号），因此无法从 actor 统计 Agent 并发数。要执行上述测算，审计日志必须新增 session_id 与 client_type（human / agent / ci）两个字段——已列入 §3.1 P0「全链路审计」建设项。

2.6.2.1 流量优先级与限流

§2.6.4 的降级表只覆盖组件故障，未覆盖过载（检索服务被打满）。人的交互式提问与 Agent 批量检索竞争同一资源时必须有明确优先级：

优先级	流量类型	过载时处置
P1	人的交互式提问	永不拒绝，最多排队
P2	Agent 编码中检索	限流（按租户/会话配额），超限返回「暂不可用」而非空结果，使 Agent 知道自己没有知识（Fail-Closed）
P3	CI / Hook 校验、索引构建与重建	先排队、后暂停；重建可限流可暂停（§2.6.3 约束 1）

配额按租户归集（§2.5），这也是「审计与配额按租户核算」的用途之一。限流阈值待实测。

2.6.3 部署架构

三条架构约束：

摄入层与服务层资源隔离。索引重建是 CPU/GPU 密集操作，与在线检索争抢资源会直接击穿 P95。重建应能限流、可暂停。
Embedding 服务是单点依赖，必须配熔断与降级（§2.6.4）。
审计日志独立存储，不与业务元数据同库（05 §9.3 纪律 1）。

2.6.4 高可用与降级策略

核心原则：知识库不可用时，Agent 必须知道自己"没有知识"，而不是继续凭记忆生成。这是 Fail-Closed 在系统层的体现（05 §9.2 OWASP 第 14 类威胁）。

故障	降级行为	用户可见结果
向量库不可用	降级为 BM25 + Exact 双通道	提示"语义检索暂不可用，结果可能不完整"
全文索引不可用	降级为向量单通道，精确标识符查询直接拒答	提示；标识符类问题不猜
Rerank 服务不可用	跳过 rerank，用融合分数（05 §5 的超时处置一致）	对用户无提示（质量下降但不误导），但必须写入审计：`degradation_flags: [rerank_skipped]`（04 §3.7.2）。原文只写「无提示」，等于该次交互的质量下降在审计中不可见——07 §2.1 的四层归因会把它误判为 Retrieval Failure，进而把改进预算投向错误的方向
Embedding 服务不可用	摄入侧：排队重试，索引延迟上升。在线侧：同样受影响——查询理解阶段需要把 query 向量化，Embedding 服务不可用则 Dense Vector 通道无法工作，降级为 BM25 + Exact 双通道（与「向量库不可用」同一处置）。原文写「在线侧不影响（用已有向量）」是错的：已有向量是索引侧的文档向量，query 向量必须实时生成，两者不是同一件事	摄入侧：索引延迟上升，触发 04 §7 告警。在线侧：提示「语义检索暂不可用」，并写入 `degradation_flags: [vector_channel_down]`（04 §3.7.2）
权限服务不可用	全量拒答，不降级为无过滤	提示"权限校验失败，暂停知识检索"
元数据库不可用	拒答（无法校验 status 与 effective 区间）	提示
审计本地缓冲写入失败（磁盘满 / inode 耗尽 / 权限错误）	拒绝服务（05 §9.3 审计完整率 = 100% 是机制保证）	提示
审计异地同步不可用	不拒绝服务：写入本地 append-only 缓冲 + 重试	提示"审计异地同步延迟"
检索服务过载（非组件故障）	按 §2.6.2.1 的三级优先级：先排队 P3 → 再限流 P2 → P1 永不拒绝	Agent 侧收到「暂不可用」，不得静默返回空结果

关键取舍：权限与审计本地缓冲失败时继续服务，等于在无管控状态下输出高密级内容且无法追溯。可用性与合规冲突时，本方案选择合规。这个取舍必须写入方案并在评审时明确确认，不能留到故障时临时决定。

但「拒绝服务」不能直接挂在异地同步上：§2.6.5 要求审计日志 RPO 趋近 0（异地同步），而 05 §9.1 的检索延迟预算是 P95 ≤ 500ms。若异地同步是同步阻塞的，每次检索都要含一次跨地域写入，物理上很难满足 500ms；若是异步的，RPO 就不趋近 0。二者不可兼得，必须显式取舍：

本方案选择「本地 append-only 缓冲 + 异步异地上传 + 缓冲耗尽才拒绝服务」。这样既把「审计存储短时抖动」与「知识库不可用」解耦，又保持 RPO≈0（缓冲不丢，只是延迟落地）。判定口径随之明确：

情形	是否算「写入失败」	处置
本地缓冲写入成功、异地同步失败	否	重试；缓冲剩余容量 < 阈值（建议 20%，待实测）时告警
本地缓冲写入失败	是	立即拒绝服务
缓冲耗尽（异地同步长时间不可用）	是	拒绝服务

审计存储自身的高可用设计（原方案只给了「拒绝服务」，等于承认单点，且单点故障 = 全系统不可用，同时 §2.6.3 约束 3 又要求它独立存储、不能借元数据库的高可用）：

按天 + 按租户分区（append-only，天然可分区）
冷热分层：热数据本地/同区，冷数据异地归档（§2.6.5）
容量增长是无上界的（保留期由合规确定，通常数年不删），已单列入 §2.6.6 成本模型
保留期到期后的合规删除流程须与 §2.7.2「审计日志保留期」衔接

可用性 SLO 与 RTO 目标：本节原无任何可用性数值。既然明确「可用性与合规冲突时选择合规」，就必须量化牺牲了多少可用性，否则该取舍无法在评审中被确认。建议目标（全部待实测）：检索服务可用性 ≥ 99.5%；审计缓冲耗尽导致的拒绝服务年累计时长 = 缓冲容量 / 平均写入速率 × 年故障次数（须实测后回填，并作为缓冲容量的选型依据）。

2.6.5 备份、容灾与恢复目标

对象	备份方式	恢复手段	说明
知识原文（Git）	Git 自身即多副本 + 远端仓库	`git clone`	这是唯一不可再生资产，优先级最高
元数据库	定期快照 + WAL/日志	快照恢复 + 重放	部分可重建：`frontmatter` 派生字段（`content_hash`、chunk 元数据、`owner_group` 派生结果）可从 Git 全量重建；治理过程状态（`flags`、`flagged_at`、复核/审核/冲突计时、评测 run 历史）不可重建，故必须保留快照 + WAL。04 §2 的派生索引原则只覆盖 L4 层（向量/全文索引），套用到 L2 治理控制面是超出适用范围的误用
向量索引	不备份	从 Git 全量重建	备份成本高且易过期，重建更可靠
全文索引	不备份	从 Git 全量重建	同上
审计日志	异地归档，仅追加	归档恢复	不可重建，丢失即永久丢失
评测集与金标标注	纳入 Git 版本管理	`git clone`	人工标注成本极高，必须版本化。评测结果 run 历史不在 Git，随元数据库快照保留
上下文前缀	随 Git 版本管理（sidecar 文件或元数据快照）	`git clone`	前缀是 chunk 的确定性函数；持久化后全量重建的 LLM 调用量 = 变更 chunk 数而非全部 chunk 数。这是重建时长目标成立的前提，见 §2.6.6 与 04 §3.6 S1.6

RPO / RTO 设定依据是"可重建性"而非"重要性"：

向量与全文索引：RPO 无意义（可从 Git 完全重建），RTO = 04 §7 的索引重建时间。
审计日志：RPO 必须趋近 0（仅追加、异地同步），因为不可重建。
评测集：RPO = 0（Git 提交即备份）。
元数据库治理状态：RPO = 快照间隔（建议 ≤ 1 小时，待实测；与审计日志的 RPO≈0 区分开），RTO = 快照恢复 + WAL 重放时间。若 04 §3.6 S1.5 选择「flags 写回 Git frontmatter」，则 flags/flagged_at 部分转为 RPO = 0，快照间隔可放宽。

关键取舍："索引不备份、只重建"是本方案的核心容灾策略——它把容灾问题转化为"重建够不够快"，从而让 04 §7 的索引重建时间从一个性能指标升级为容灾指标。若重建时间不可接受，才需要引入索引备份——顺序不能反。

这个取舍在大型档下有两个成立前提，缺一不可：

上下文前缀必须持久化。§2.6.6 指出前缀生成是「全量重建时最大的单项 token 消耗」，需为每个 chunk 调 LLM 一次。百万级 chunk 要在 30 分钟内跑完，意味着 ≥ 555 次 LLM 调用/秒——远超任何企业 LLM 网关的限流阈值，成本也不可接受。而 Prompt Caching 解决不了这个问题：它只能省掉输入 token 的重复部分（文档级上下文），输出 token（每个 chunk 自己的前缀文本）无法缓存，调用次数也无法减少。唯一可行解是把前缀结果持久化（随 chunk_hash 写入 Git sidecar 或元数据库），使重建时只对 content_hash 变化的 chunk 重新调用 LLM，全量重建退化为「Embedding + 索引写入」。若前缀不持久化，则本取舍在大型档不成立，必须回退为索引备份。
重建时长目标必须按规模档位分级。§2.7.2 原写「≤ 30 分钟」是一个与规模无关的常数，而 §2.6.1 明确规模分三档：大型档 = 百万级以上向量，30 分钟 = 1800 秒，要求 ≥ 555 chunk/秒的持续 Embedding 吞吐（还不含解析、切分、写入、ES 索引构建）。对千级和百万级都适用的重建时长目标在物理上没有意义——§2.6.1 已经对切分放大系数要求「必须实测」，同样的谨慎必须用在重建时长上。分级目标见 §2.7.2。

重建时长的推导公式（不写裸数字）：

重建时长 ≈ chunk 总数 / min(Embedding 吞吐, 索引写入吞吐)
         + 变更 chunk 数 × LLM 单次延迟 / LLM 并发度

各项均为待实测。

与 04 §8 的口径统一：04 §8「风险与依赖」把「必要时引入备份」当作可接受的兜底，本节原文把它当作必须避免的倒退，两处对同一风险处置不一致。统一为：引入索引备份是「受控回退」，触发条件 = 实测重建时长超过所属档位目标；回退后须重新评估存储成本。

2.6.6 成本模型

成本分三类，必须分别核算：

成本类别	构成	驱动因子	优化手段
一次性建设	人力（解析、索引、权限、评测集标注）	存量文档规模、来源种类数	分期建设（§2.1 成熟度、§2.2 冷启动）；先做核心域；§4 三项最易低估的人力
持续运行	Embedding 调用、Rerank 推理、LLM 判官、向量库存储、检索算力、审计日志存储与异地同步带宽、漂移语义过滤、激励看板聚合、反馈脱敏与聚类	chunk 总数 × 重建频率；在线 QPS；日均交互数 × 审计保留期（不可收敛）	Prompt Caching（04 §5.2）；增量索引而非全量重建；前缀持久化（§2.6.5）
治理人力	审核、漂移处理、冲突裁决、复核、激励看板运维、归因盲评复核	`active` 条目数 × 复核频率（04 §3.5）	06 §2.4 边际价值评估淘汰低价值条目

七个容易被漏算的成本项：

上下文前缀的 LLM 成本（04 §5.2）：每次索引构建都要为每个 chunk 调用 LLM 生成前缀。这是全量重建时最大的单项 token 消耗，必须用 Prompt Caching 缓存文档级上下文，否则重建成本会显著超出预算（「超出一个量级」是方向性判断，非实测值，性质为阈值待实测；且 Prompt Caching 只能省输入 token 的重复部分，输出 token 与调用次数无法靠缓存减少，见 §2.6.5 前提 1）。
LLM-as-Judge 的评测成本（07 §3.3）：判官调用量 = 评测集规模 × 每次评测的 claim 数 × 偏差控制的重评次数（位置偏差需交换顺序各评一次，即 ×2）。若回归集作为合并门禁（07 §2.5），这笔成本按 MR 频次发生。
双索引期间的成本翻倍（04 §5.6）：模型迁移期存储与写入同时翻倍，必须限定迁移窗口长度。
审计日志存储（无上界增长）：§2.6.5 规定审计日志异地归档、仅追加、不可重建，05 §9.3 的字段含 query_text（原始 + 扩展查询全文）、retrieved_chunks（列表 + 分数）、generated_claims（claim 全文 + evidenceIds）。这是每次交互都写入、含长文本、保留期通常数年不删的数据，增长曲线与向量库完全不同（向量库随知识量增长且可通过 06 §2.4 淘汰收敛，审计日志随交互量线性增长且不可收敛）。驱动因子：日均交互数 × 单条审计记录平均字节 × 保留期天数 × (1 + 异地副本数)，另加异地同步带宽。
漂移检测的语义过滤成本：06 §2.2 的 matches_semantic_filter(changed_hunks, entry.knowledge_type) 若用 LLM 实现，成本 = active 条目数 × 日均源变更命中率 × 单次过滤成本，每日发生。这可能超过判官成本（判官只在 MR 时发生）。06 未说明该过滤器是确定性规则还是 LLM——若为 LLM，须先做规则预筛再调模型。
激励回流看板的聚合成本（§2.4 原则 3）：从审计日志聚合「按作者/Owner 的命中与引用次数」需要持续扫描 retrieved_chunks 与 generated_claims，是审计日志的二次全量读取。驱动因子：审计日志扫描量 × 聚合频率。
反馈闭环的脱敏与聚类成本：07 §2.3 的「正则 + NER 识别敏感实体」与「向量相似度 + 主题聚类」，若 NER 与 Embedding 用模型实现，则成本 = 日均反馈数 × (NER 单次 + Embedding 单次)。07 §2.3 把这一步标为「全自动」，容易被误读为零成本。

成本约束应反向影响设计：若治理人力成本不可承受，说明 04 §3.5 的复核周期过密或知识条目过多，应通过 06 §2.4 边际价值评估收敛规模，而不是降低复核标准。

2.6.7 自建与选型的取舍

路线	代表	优势	代价与风险
云托管 RAG 服务	AWS Bedrock Knowledge Bases、Google Vertex AI RAG、Azure AI Search	摄入/切分/索引/检索开箱即用，运维成本低	元数据 Schema 与权限模型受服务方约束；04 §3 治理字段、05 §9.1 Chunk 级 ACL 未必能完整表达
开源 RAG 平台	RAGFlow、Dify、FastGPT	部署快，含 UI	治理生命周期（审核、漂移、废弃、冲突裁决）通常缺失，需二次开发（截至本文撰写时的版本状态；三者均为高速迭代项目，须在选型时按实际版本验证）
框架自建	LlamaIndex、Haystack	完全可控，能精确实现本方案全部控制点	全部工程量自担；权限、审计、评测都需自建

判断依据不是"哪个更好"，而是"哪个能承载 04 §2 + 05 §9.1"：

本方案的核心价值在治理控制面（状态机、Owner、漂移、版本裁决）与可信输出（引用、拒答、权限），这两项恰好是通用 RAG 产品最弱的部分。
因此推荐路径：检索与索引能力优先用成熟组件（ES / 向量库 / 云检索服务），治理控制面与引用校验层自建。
「治理层是薄的」这个判断只在代码量意义上成立，在人力意义上不成立，必须分开说：治理层的代码确实薄（元数据 Schema + CI 脚本 + 审核流），但治理层的持续人力是 §2.6.6 三类成本中唯一不可收敛的一类（审核、漂移处理、冲突裁决、复核、激励看板运维、归因盲评），而 §4 更进一步指出「权限映射清洗在实践中经常超过整条摄入链路的开发量」——权限映射正是治理控制面的一部分。原文用「治理层是薄的」论证「自建成本可控」，与同一文档的 §4 和 §2.6.6 直接冲突。修正后的判断依据是：治理层自建的成本主要是持续人力而非一次性开发量，因此选型时真正要问的是「该产品能否承载这些治理动作」，而不是「自建要写多少代码」。
若选择云托管服务，必须在选型阶段验证三件事：能否写入自定义元数据字段、能否在检索前做权限过滤（pre-filtering）、能否返回稳定的 chunk 标识。任一项不满足，本方案的关键控制就无法落地。
若选择开源平台，须额外验证四项（比笼统的「治理生命周期缺失」可操作）：能否表达 status 四态状态机（06 §2.1）、能否存储并校验自定义 frontmatter、能否接入外部 CODEOWNERS 作为 Owner 来源、能否输出稳定的 chunk_ref。

性质：成本分类与"治理层自建、检索层复用"的取舍为工程推导；对具名产品（RAGFlow / Dify / FastGPT / Bedrock / Vertex / Azure AI Search）的能力判断是撰写时点的观察，非规范结论，产品能力边界须按选型时的实际版本验证 | 置信度：中高
待实测：云服务的元数据与权限能力验证结果、开源平台治理生命周期的实际覆盖度。

2.7 验收指标与校准参数

蓝图 §10.4 明确门禁分级是本节的核心：只有性质为"机制保证"的指标可以在 P0 直接作为硬门禁；"阈值待实测"的指标在校准完成前只能观测，不得阻断。

2.7.1 硬门禁（机制保证，P0 可直接阻断）

10 项指标由设计机制强制成立、可被脚本直接判定、不依赖模型或人的行为假设。

「接入 CI 门禁」不等于「全部塞进 MR 流水线」：10 项的判定位置实际分四类——MR CI 同步（2 项）、索引 Pipeline 内断言（2 项）、定时对账（3 项）、运行时（3 项，含越权测试集属发布前）。把定时对账类与运行时类塞进 MR 流水线会产生持续误报（MR 上下文无法判定索引完整性）。下表已逐项标明判定位置、脚本与失败处置；标注「待新建」的 6 个脚本已列入 §3.1 P0 建设项。

阶段	指标	含义	目标	判定位置	判定脚本 / 机制	失败处置
验证	符号可解析率	符号级引用能在 source_revision 中解析的比例	100%	MR CI（同步）	02 §4.1 `knowledge-lint.py --check-symbol-resolvable`	Error，不可合并
存储	索引完整性	索引条目数 / `active` 条目数	100%	定时对账（非 MR）	索引对账脚本（待新建）	告警 + 自动补索引；连续 N 次失败才阻断发布
存储	前缀覆盖率	已生成上下文前缀的 chunk / 总 chunk	100%	索引 Pipeline 内断言	Pipeline 断言（待新建）	Pipeline 失败重试；重试耗尽告警
存储	模型版本一致率	索引中 `embedding_model_version` 唯一的比例（非迁移期）	100%	索引 Pipeline 内断言	Pipeline 断言（待新建）	Pipeline 失败；迁移期由 04 §5.6 蓝绿开关豁免
引用	幻觉引用率	输出的 `evidence_id` 不在本次检索结果集中的比例	= 0	运行时（每次响应）	05 §7.2 输出校验	丢弃该 claim，不进 MR 门禁
安全	越权拦截率	权限过滤拦截的越权请求 / 全部越权请求	100%	权限越权测试集（发布前）	越权用例集（待新建，含在 07 §2.2 评测集中）	测试集失败 = 阻断发布，不是阻断 MR
安全	缓存串味事件数	缓存返回超出调用者密级结果的次数	= 0	运行时异步复核	缓存键含权限集 + 复核脚本（待新建）。P0 阶段禁用检索结果缓存，故该指标恒为 0（无缓存即无串味）	告警 + 清空缓存
可观测	审计完整率	有完整 `trace_id` 链路的交互 / 总交互	100%	运行时 + 定时对账	05 §9.3 写入校验 + 对账脚本（待新建）	§2.6.4：本地缓冲写入失败即拒绝服务
维护	新增孤儿知识率	本次 MR 引入的 `owner_group` 无效条目比例	= 0	MR CI（同步）	03 §7 S3 `owner_group` 存在性校验（Error 级）	Error，不可合并
维护	删除残留率	源删除后仍能召回的比例	= 0	定时对账	06 §2.3 Tombstone + 索引对账	强制删除 + 告警

2.7.2 待校准指标与参数（阈值待实测，校准前仅观测）

阶段	指标/参数	目标 / 初始建议值	校准方法
生成	知识识别覆盖率	≥ 80%	按核心模块人工盘点覆盖度后校准
生成	解析成功率	≥ 95%	首轮实测脏数据比例后设定
验证	AI 审核通过率	≥ 85%	建基线后按误报率调整
审核	审核周期	≤ 2 工作日	按团队实际响应能力观测
存储	索引延迟	≤ 5 分钟	按 Pipeline 实测 P95
存储	Chunk 大小与重叠	300-500 tokens / 重叠 50（04 §5.1）	按文档类型分别测试 Recall@K
存储	上下文前缀长度与 Prompt	无（04 §5.2）	对比有无前缀的 Recall@K 差值
存储	chunk 切分放大系数	无（§2.6.1）	对现有语料做一次完整切分后统计分布
检索	Recall@K	≥ 90%	须先建金标集（07 §3.1）
检索	权限过滤后 Recall@K	折扣幅度待实测	实测带过滤与不带过滤的差值后设定
检索	BM25/Vector Top-N	无	使用 Recall@K 和延迟校准
检索	最终 Top-K	无	使用 Faithfulness 和 Token 成本校准
检索	RRF 的 k 与 rank_window_size	k = 60（有外部权威默认值）、window = 50–100（本方案自拟起点，非业界默认值）（05 §3.1）	在评测集上网格搜索。原文标注「业界默认值」对 window 不成立：Elasticsearch `rrf` retriever 的 `rank_window_size` 默认值等于请求的 `size` 参数而非固定 100；Azure AI Search 的语义重排默认只作用于 top 50 文档。只有 k = 60 有外部依据（Azure 建议取小值如 60、ES `rank_constant` 默认 60、Cormack et al. 2009）
检索	Reranker 候选窗口与阈值	Top 20-50（05 §4）	使用人工标注集校准，同时测延迟
检索	检索延迟预算分配	见 05 §5 的环节划分	按实测 P95 重新分配
引用	引用可解析率	≥ 95%	按 source_revision 更新频率观测
拒答	拒答准确率	≥ 95%	须先建拒答集（07 §2.2）
拒答	拒答阈值	无	按错误回答成本设置
安全	缓存策略与保留期	高密级默认不缓存（蓝图 §6.6.2）	命中率与串味风险权衡
安全	审计日志保留期	无（05 §9.3）	由合规要求确定，技术侧不得自拟
维护	相似重复阈值	无	使用已确认重复样本校准
维护	主张抽取准确率门槛	无（02 §4.4）	达标前冲突检测不得升级为 Error
维护	受控谓词集合	5 个初始谓词（02 §4.4）	按实际冲突类型扩充
维护	复核周期分级	30/60/90/180 天（04 §3.5）	按知识风险与实际变更频率校准
维护	过期知识率	≤ 10%	按知识风险分级观测
维护	漂移未处理天数	≤ 5 天	按 Owner 响应能力观测
维护	单次命中节省的人时	无（06 §2.4）	两组对照实测，季度复测
维护	边际价值观察期长度	无（06 §2.4）	按知识价值的滞后周期设定
反馈	同类问题复发率	≤ 5%	按归因准确率观测
约束	一次 CI 通过率	≥ 80%	先建基线（07 §2.4）
约束	返工率	≤ 15%	先定义口径（07 §2.4.1）
约束	标注一致性 Kappa 门槛	无（07 §3.2）	先修指南再重标，门槛按团队实际设定
约束	LLM 判官与人工一致性门槛	无（07 §3.3）	达标前判官指标只观测
约束	初始评测集规模	100-300 条（07 §2.2）	按核心业务覆盖程度决定
约束	回归集门禁范围	见 07 §2.5 分级	按变更影响面调整
约束	回归评测频率	无（07 §2.5、07 §4）	07 §4 只写「每次版本迭代后」，而"版本迭代"频率未定义；非门禁类变更的回归频率也未给出。按判官成本预算与 MR 频次联立设定（门禁类每次合并，非门禁类每日定时）——频率直接决定 §2.6.6 的判官成本总量。主文档 §8.2 已列为待实测，原 §2.7.2 漏收
约束	样例风险层级判据与阈值	无（07 §2.2 的 `risk_level`）	跨 04/06/07 三文档共用的基础参数：04 §3.5 复核周期分级（30/60/90/180 天）、06 §2.4「安全/合规/资金/权限类不参与边际价值评估」的豁免类别、07 §2.2 的 `risk_level` 都依赖同一套风险分级，却没有任何一处负责校准它。须由 Steward 统一定义后校准。主文档 §8.2 已列为待实测，原 §2.7.2 漏收
反馈	归因盲评一致率门槛	无（§2.4 原则 4）	首批盲评后设定；低于门槛则触发归因指南修订
成本	全量重建时长	按档位分级：小型 ≤ 10 分钟 / 中型 ≤ 30 分钟 / 大型 ≤ 2 小时（均为初始建议值）	容灾指标（§2.6.5）。原「≤ 30 分钟」是与规模无关的常数，对千级与百万级同时适用在物理上不成立（§2.6.5 已给出量级推导）。须先实测 chunk 总数与 Embedding 吞吐；大型档若不达标则触发 §2.6.5 的索引备份受控回退
成本	容量与 QPS 全部数值	无（§2.6.1）	按"并发 Agent 数 × 每任务检索次数"实测，两个因子的采集方式见 §2.6.2（需审计日志新增 `session_id` 与 `client_type`）
成本	收益目标	不预设（07 §2.4）	先建立基线，再做对照或分阶段试验

3. 实施优先级

蓝图附录给出 P0–P3 四期建设清单，本文按"阶段 → 建设项 → ROI 理由"整理。

3.1 P0：治理基座 + 可信输出（ROI 最高，不做则知识库不可信）

建设项	对应文档	ROI 理由
元数据 Schema（状态、权威源、Owner、分级、标题）	04 §3	所有后续治理的前提
权威事实源指定	蓝图 §2.1	没有事实源，知识库就是第二个谣言场
检索前密级过滤 + Chunk 级 ACL 继承	05 §9.1	`classification` 已在 P0 采集，05 §8 已承诺权限拒答；采集密级却不过滤等于声明了一个不存在的控制，且泄露不可撤销
引用系统生成 + 拒答	05 §7	没有溯源和拒答，答案不可信
全链路审计（append-only，含被过滤记录）	05 §9.3	合规刚需，事后追溯的唯一手段；也是 07 评测与 §2.6.6 成本模型的数据来源
知识条目模板 + `_index.yaml` Schema（CI 生成）	`_index.yaml` → 04 §4.1；条目模板 → 蓝图 §5.5.1（04 未收录，须在 04 补一节，见 §6.2 LD11）	无模板则第一条知识就格式漂移，02 §4.1 校验随之失效；无目录 Schema 则蓝图 §6.3 的 L0 层形同虚设。原文只标 `04 §3.1`（现 §4.1），但 04 的该小节只定义 `_index.yaml` 路由地图，条目模板（背景 / 方案 / 正反例 / 适用范围四段结构）在拆分文档集中无处可查
CI 校验四件套（必填字段 / 源文件存在 / 符号可解析 / 结构完整）	02 §4.1	格式与引用的机制保证，是 §2.7.1 中 10 项硬门禁的实现载体
Git 仓库 Markdown 摄入链路	01 §7.1	代码类知识是 AI Coding 场景的主体，先打通零转换来源
Chunk 切分 + Embedding + 索引写入 Pipeline	04 §5.1、04 §5	原 P0 清单缺此项，但 C0 目标是「只读检索上线」——没有索引 Pipeline 就没有可检索的东西，P0 承诺无法兑现
混合检索服务最小实现（Exact + BM25 + Vector）	05 §2	同上。Rerank 可延后到 P2，但三通道检索是 C0 的最小载体
MCP Server / HTTP API 最小实现	05 §10.1	`幻觉引用率` 与 `越权拦截率` 两项硬门禁的唯一出口。原方案把它排在 P1，但 P0 完成判据要求 10 项硬门禁全部可判定——载体在 P1 则 P0 判据不可达。（P1 保留的是「替代直接读文件」的全面接入，P0 只需最小可用）
CODEOWNERS 配置 + `owner_group` 存在性校验	03 §3.2、03 §7 S3/S4.1	`新增孤儿知识率` 硬门禁的载体。原方案把「角色定义与兼任约束」放 P0、把其唯一机制载体 CODEOWNERS 放 P1，是断裂的
6 个待新建的硬门禁判定脚本（索引完整性 / 前缀覆盖率 / 模型版本一致率 / 越权测试集 / 缓存串味复核 / 审计对账）	§2.7.1	§2.7.1 承诺「可被脚本直接判定」，但其中 6 项的脚本在任何文档中都不存在
阈值待实测指标的观测看板（覆盖 §2.7.2 全部行的采集与展示）	§2.7.2	§2.7.2 的整个门禁分级设计（阈值待实测 → 观测 → 校准 → 升级为门禁）以看板存在为前提。没有看板，「校准前仅观测」等于「不观测」，校准永远无法开始
上下文前缀生成 + 持久化	04 §5.2、04 §3.6 S1.6	`前缀覆盖率` 是 P0 硬门禁，其载体不能排在 P1；且持久化是 §2.6.5 重建时长目标成立的前提，属不可逆决策
工程基线采集	07 §2.4	基线数据不可回溯。§2.7.2「一次 CI 通过率 ≥ 80% → 先建基线」「收益目标不预设 → 先建立基线」，以及 07 §2.4 整段「不预设提升百分比」的方法论，全部以基线存在为前提；晚一天开始就少一天对照。其中 6 项可从 GitLab API 回溯，6 项必须新增埋点即刻开始（人工重写比例、人类介入时间、模型 token 成本、缺陷逃逸率、契约测试通过率、Review 缺陷数）
P0 人力小样本实测（三步法，见 §4）	§4	三项易低估点的规模完全取决于本团队存量状态，跳过实测的人日数字都不成立
10 项机制保证指标各有判定脚本、判定位置与失败处置	§2.7.1	只有机制保证类可作硬门禁；阈值待实测类进观测看板（看板本身也是 P0 建设项，见上）
冷启动 C0/C1（只读检索上线 + 拒答与低召回 query 统计）	§2.2	无 C1 的需求证据，后续所有选题都是拍脑袋；且 C0 不要求写作，是唯一能在冷启动期不产生负价值知识的做法
角色定义与兼任约束（Owner / Steward / 平台组 / 园艺）	§3.2	Owner 归属业务团队是 03 §3.1 责任制的前提；Steward 与审批人不得为同一人是 02 §4.1 的前提

P0 完成判据：

§2.7.1 表中 10 项"机制保证"指标各有判定脚本、判定位置与失败处置，并按其判定位置可输出结果——MR 门禁类可判定通过/失败，定时对账类可输出差异报告并触发处置，运行时类可产生告警与自动处置动作。（原文写"全部接入 CI 并可判定通过/失败"，但其中 5 项不属于 MR CI，见 §2.7.1 的四类判定位置）
classification 过滤在检索链路上生效并有越权拦截记录。
审计日志可按 trace_id 还原一次完整交互。
C0「只读检索上线」有实际载体：索引 Pipeline、混合检索服务、MCP Server 三项最小实现均已上线（原 P0 清单缺此三项，见上）。
P0 阶段禁用检索结果缓存（使 缓存串味事件数 恒为 0；缓存键含权限集在 P1 建成后再启用）。
工程基线中不可回溯的 6 项已开始采集。

3.2 P1：工程同步 + 规则执行（让知识库跟着代码走）

建设项	对应文档	ROI 理由
GitLab CODEOWNERS（含 `[Section][N]` 与 Steward 回写）	03 §3.2	责任到人，知识才有人维护
MCP Server / HTTP API 接入（替代直接读文件）	05 §10.1	直接读文件会绕过 05 §9.1 全部控制；接口形态决定权限、引用、审计能否强制生效
最小金标集（≥ 30 条，仅"固定金标集"一类）	07 §3.1	P1 的前置条件：07 §2.5 规定「切分策略变更 = 硬门禁，不通过不得合并」，而完整金标集与回归集在 P2 才建成。下一行的上下文前缀切分正是一次切分策略变更（改变 chunk 内容与 `chunk_hash`，进而使全部 `chunk_ref` 变更）。若 P1 严格执行门禁则该改造无法合并；若跳过门禁则全量 `chunk_ref` 变更未经任何验证就上线，且 P2 建立金标集时会基于一个未经验证的切分策略。最小金标集是 P2 完整金标集的子集，不是额外工作
上下文前缀切分 + BM25 同步增强	04 §5.2	Anthropic 公布检索失效下降 35%（上下文检索）/ 49%（+ Prompt Caching）/ 67%（+ reranking），是检索质量提升单项 ROI 最高的改造。须在 P1 内先建成上一行的最小金标集，否则本项不得合并。引用纪律：67% 是「上下文检索 + Prompt Caching + reranking」三者叠加的结果，而 reranking 排在 P2（§3.3），因此 P1 只能主张 35%/49% 这一档，不得把 67% 写成 P1 的预期收益——那会让 P1 的验收基线建立在一个尚未建成的组件上。另注：Anthropic 原文用的是 "rank fusion techniques" 与 "the Cohere reranker"，并未指名 RRF 或 Cross-Encoder，本文的具体算法选择属工程推导
Embedding 模型选型评测（自 P2 提前）	04 §5.6	原排在 P2，但 P0 的只读检索上线就要用 Embedding 模型，意味着 P0/P1 用的是未经评测的模型，P2 换模型时又要全量重建（叠加 §2.6.6 的双索引成本翻倍）。提前到 P1 与最小金标集同期，用同一套评测集完成选型
MR Impact Manifest	08 §2.4	变更影响可追溯
OpenAPI、DDL 和配置 Diff 触发知识检查	06 §3.2	自动发现漂移，不靠人记忆
漂移检测（语义过滤 + 告警聚合 + `flags` 字段）	06 §2.2	无语义过滤则告警洪水会让治理机制在数周内失效
Qoder Hooks + CI 门禁（先确认 CLI 还是 IDE 形态）	08 §2.2	约束 AI 生成行为；形态决定可用事件集
ArchUnit、Lint、契约测试	08 §2.3	机器规则比文档约束可靠
Worktree 隔离 + 读写集声明	08 §2.5	多 Agent 并发的唯一可靠隔离手段。原「仅 CLI 形态 / IDE 须降级为 CI 侧实现」不成立：隔离由 `git worktree` 裸命令提供，与 Hook 形态无关；CLI 独有的 `WorktreeCreate` / `WorktreeRemove` 事件只影响生命周期自动化，IDE 形态用编排脚本包一层即可（详见 08 §2.2）。CI 侧只能做事后冲突检测，不具备预防能力，把它当作隔离的替代方案是降级的错误方向
Confluence / Wiki / PDF / Office 解析链路	01 §7.2	存量知识主体；无此链路则知识库只覆盖新增部分
缓存键含权限集（高密级默认不缓存）	蓝图 §6.6.2	OWASP 第 11 类威胁，当前唯一完全空白项，且泄露路径具体
冷启动 C2：种子域补齐 + Owner 复核与漂移闭环跑通	§2.2	种子域判据见 §2.2；不跑通 Owner 闭环则 06 全部治理机制无执行主体
激励回流（命中/引用次数按作者与团队双维度可见）	§2.4 原则 3	数据源已在 05 §9.3 审计日志中（`retrieved_chunks` + `generated_claims`），无需新增埋点；但聚合管道与看板需单独建设，工作量不可忽略（原写"边际成本近零"低估了聚合与展示层，已计入 §2.6.6 治理人力）。不做则写作无收益，知识库必然衰败
草稿确认入口（IDE 插件或 MR 模板一键确认，使业务成员成为 MR 作者）	§2.4 原则 5	"确认即提交"是「主动提交信号」能被观测到的唯一路径。缺此入口则自动转化的草稿只能由平台组的 CI 提 MR，§2.3 的冷启动完成判据第 3 条永远不成立

P1 完成判据：

CODEOWNERS 生效，新增孤儿知识率 在 MR CI 上可判定并阻断（§2.7.1）。
最小金标集（≥ 30 条）已建成并纳入 Git，上下文前缀切分改造是在该金标集通过后才合并的（否则违反 07 §2.5 的硬门禁）。
Embedding 模型选型评测已完成并有书面结论，P0 上线时的「临时选型」状态已解除。
C0b 的外部来源解析链路可用，且 fail-closed 处置（01 §7.3）经测试验证。
激励看板上线，命中与引用次数按作者与团队双维度可见（§2.4 原则 3）。
草稿确认入口可用，且 §2.3 冷启动完成判据第 3 条开始有数据（不要求达标，只要求可观测）。

3.3 P2：检索质量 + 评测体系（让答案准确且可度量）

建设项	对应文档	ROI 理由
术语库	05 §6	解决内部术语检索不准的核心痛点
Exact + BM25 + Vector + RRF（k=60 起）+ Reranker（Top 20-50）	05 §2	混合检索是精度提升的主要手段；参数有业界默认起点
双索引蓝绿切换机制	04 §5.6	升级会使全量向量失效，必须先有切换机制。（选型评测已提前到 P1，见 §3.2）
金标集标注流程 + 一致性度量（Kappa）	07 §3.1	无标注流程则评测集退化为随手编写的 query，全部指标失去意义
LLM-as-Judge 偏差控制与人工一致性校准	07 §3.3	未校准的判官等于把评测建立在另一个不可信组件上
版本化回归集 + 分级门禁	07 §2.5	没有回归集，质量改进无法度量；全量硬门禁会被绕过
引用准确性和拒答评测	05 §7	验证可信度机制是否生效
冲突检测主张抽取（受控谓词，Warning 级）	02 §4.4	准确率达标前不得升级为 Error（02 §4.3）
反馈归因	07 §2.3	把用户痛苦转化为改进信号
带权限过滤的 Recall@K 评测	05 §9.1 + 07 §2.2	权限过滤会系统性拉低召回，折扣幅度必须量化

P2 完成判据：

完整金标集（100–300 条，八类齐备）建成，标注一致性达到 §2.7.2 的 Kappa/Alpha 门槛。
LLM 判官已通过人工一致性校准；未达标前其产出的指标只观测不作门禁（07 §3.3）。
回归集门禁按 07 §2.5 的分级生效，硬门禁类变更不通过不得合并。
Recall@K、Faithfulness、拒答准确率 三项已从「仅观测」转为有实测基线值。
权限过滤前后的 Recall@K 折扣幅度已量化（§3.3 最后一行）。

3.4 P3：关系图谱 + 自动治理 + 熵治理 + 非功能性完善（规模化后的持续运营）

建设项	对应文档	ROI 理由
服务、接口、表和文档关系图（原生 kind + 自定义 kind 注册）	06 §3.4（该小节标题是"影响分析：三源融合"，图谱建模本身——原生 kind 清单、自定义 kind 注册机制、边的受控谓词集合——在 06 中无独立小节，主文档对应 §7.5/§7.6。须在 06 补一节，见 §6.2 LD9）	多跳影响分析的基础。依赖链：图谱建模（P3）→ 影响分析（P3）→ 08 §3.3 Impact Manifest（P1 的 MR Impact Manifest 只覆盖单跳）
上下游影响分析	06 §3.4	变更风险评估自动化
周期性知识园艺 Agent	06 §3.5	规模化后人工治理不可持续
离职资产转移	03 §6	防止知识随人走
知识边际价值评估（人时/年统一量纲 + 三重防误删）	06 §2.4	识别并清理负价值知识；关键度作否决项而非公式因子
容量测算、QPS 压测与降级演练	§2.6	按"并发 Agent 数 × 每任务检索次数"估算，人数估算法会严重低估
索引全量重建时长达标（容灾指标）	§2.6.5	"索引不备份只重建"的取舍成立的前提
成本模型核算（建设 / 运行 / 治理人力三类分列）	§2.6.6	前缀 LLM 成本、判官成本、双索引成本是最易漏算的三项
自建 vs 选型验证（自定义元数据 / pre-filtering / 稳定 chunk 标识）	§2.6.7	任一项不满足则本方案关键控制无法落地
安全事件响应流程	05 §9.2	OWASP 第 12 类的未完成部分
向量空间异常检测、查询侧注入检测	05 §9.2	OWASP 第 2、8 类的未完成部分
多租户隔离（索引/术语表/评测集/配额分租户，Steward 每租户各一套）	§2.5	仅当多 BU 共用一套实例时需要；索引必须物理隔离，不得靠 metadata 过滤（§2.5）
Owner 上手闭环验收（新 Owner 无文档完成告警处理闭环）	§3.2	做不到说明模板或告警文案有问题，应改工具而非加培训

P3 完成判据：

关系图谱可支撑多跳影响分析，Impact Manifest 的 affected_consumers 由图谱派生而非人工填写（08 §2.4）。
知识园艺 Agent 周报稳定产出，覆盖全部 5 个 flags（06 §3.5），且无自动删除事件。
边际价值评估完成首轮，豁免类别（安全/合规/资金/权限）已确认未被纳入评估。
容量压测与降级演练完成，§2.6.4 表中每一类故障都有演练记录。
索引全量重建时长按 §2.7.2 的档位目标达标；未达标的档位已触发 §2.6.5 的受控回退并留档。
OWASP 14 类中原「部分覆盖 / 未覆盖」的项（05 §9.2 的第 1、11、12 类）已闭合或有书面风险接受。

P3 不是「可以不做」的期次。上表第 4、5 条是 §2.6.5「索引不备份只重建」这一核心容灾取舍的验证动作——不做就等于该取舍从未被验证过，而它已经在 P0 决定了存储架构。

优先级调整说明：原方案将"Chunk 级 ACL + 检索前权限过滤"（05 §9.1）与"全链路审计"（05 §9.3）分别置于 P3 与 P0，理由为"知识库内部使用，规模化后再收紧权限"。该理由不成立并已修正——classification 自 P0 起就在必填 frontmatter 中，05 §8 也已把"权限判断失败 → 拒答"列为承诺行为；两者缺一即构成对外声明了不存在的控制。P3 现仅保留 OWASP 映射表中"部分覆盖 / 未覆盖"的增量项（05 §9.2）。

4. P0 人力估算

蓝图 §10.2 明确本方案不给数字，只给最易低估的三项。任何具体人日数都必须先做小样本实测再外推，因为下面三项的规模完全取决于本团队存量状态。

实测方法（三步法）——原文写「按 §2.7.2 的方式」，但 §2.7.2 是「指标 → 目标值 → 校准方法」的参数校准表，不含任何人力估算方法（该引用错误继承自主文档 §10.2 的「按 §10.4 的方式」，两处一并修正）：

抽取 30–50 篇代表性存量文档做完整解析，统计实际人均耗时与脏数据比例，按形态分类（扫描版 PDF / 表格截图 / 失效内链 / 正常 Markdown）。
抽取 1–2 个 IAM 组做完整 acl_groups 映射，统计每组耗时与需人工裁决的授权冲突比例。
邀请 2–3 名业务专家标注 10 条金标样例，统计人均每条耗时与仲裁比例。

三项各乘存量规模并加风险系数（系数待实测）后外推。**任何跳过 ①②③ 的人日数字都不成立。**这三步已列入 §3.1 P0 建设项，与 C0 的形态调研同期。

存量文档的脏数据比例——§2.7.2 中"解析成功率 ≥ 95%"是目标值而非现状，首轮实测通常远低于此，返工量由脏数据形态（扫描版 PDF、表格截图、失效内链）决定。
权限映射清洗——把现有 IAM 组结构映射为 acl_groups（05 §9.1）的工作量，取决于历史授权是否已经混乱；这一项在实践中经常超过整条摄入链路的开发量。
金标集标注——需要业务专家时间，平台组无法自己完成（07 §3.2），且专家时间是全项目最稀缺的资源。

培训与上手：

不需要培训"怎么用知识库"。用户侧入口是 Agent，用户感知不到知识库存在——这正是 05 §10.1 接口设计的意图。若需要培训用户，说明接口设计失败了。
需要培训的是 Owner 侧：frontmatter 必填字段、复核触发条件、漂移告警的处理动作。
上手成本判据：一个新 Owner 能在不查文档的情况下完成"收到漂移告警 → 确认 → 更新条目 → 合并"的闭环。做不到说明模板或告警文案有问题，应改工具而不是加培训。

注意：本节刻意不给出任何人日数字或激励系数。P0 人力必须实测；三项易低估点是定性提示，不是可直接引用的估算系数。（此条限定来自主文档 §10.2，此前在拆分时丢失。缺了它，上面三项很容易被当成估算系数使用——例如把"权限映射经常超过摄入链路开发量"直接引用为"权限 = 摄入 × 1.5"。）

5. 度量指标

指标	计算方式	目标	性质
种子域覆盖率	审计日志中该域去重 query（按 05 §9.3 的 `query_text` 原始查询，用 07 §2.3 的聚类去重，聚类阈值待实测）里，Top-K 检索结果中至少含一条该域 `active` 条目的比例	阈值待实测（初始建议值：C3 阶段 ≥ 70%，须按种子域实测设定）	阈值待实测。原口径「已有条目的核心问题数 / 去重 query 数」不可计算：P0 的 7 字段 frontmatter 与 01 §6.1 条目结构都没有「核心问题」字段，分子无从取数；若改用「条目数」近似则量纲不一致（一条目可覆盖多 query，比值可能 > 100%）。新口径完全可从现有审计字段计算，无需新增字段。使用时机：C2 阶段只采集不设目标（与 §2.2 C2「不追求覆盖率指标」一致），C3 起作为验收指标
拒答率	`refusal` 交互数 / 总交互数，按 05 §9.3 的 `refusal.原因分类` 分组统计	只观测，不设目标形态	趋势指标。原「先降后稳」不可判定：附录定义趋势指标为「只看环比方向」，而「先降后稳」同时含方向与终态——拒答率从 15% 升到 18% 时，按「先降后稳」无法判定，按趋势指标应判为恶化。联立硬约束见下方注
主动提交率	非平台团队成员提交的知识 MR / 全部知识 MR	趋势上升	趋势指标（冷启动完成的唯一硬信号，§2.2）
Owner 响应时长	漂移告警到 Owner 处理的平均时长	≤ 5 天（与 §2.7.2"漂移未处理天数"同口径）	阈值待实测
知识复用度	单条目年检索命中次数的分布	只观测分布，无绝对目标	趋势指标（06 §2.4 边际价值模型的输入）
新增孤儿知识率	见 §2.7.1	= 0	机制保证
孤儿检出率	每日扫描检出的孤儿数 / 实际孤儿数	100%	机制保证
存量孤儿收敛速度	存量孤儿条目数随时间变化	趋势下降	趋势指标（消除依赖人工认领，机制只保证「必被检出」）

拒答率与拒答准确率的联立硬约束：§2.7.2 要求拒答准确率 ≥ 95%，本表要求拒答率下降，两者存在直接张力——降低拒答率最简单的办法是放宽拒答阈值（§2.7.2「拒答阈值」），而这会同时降低准确率（不该答的答了 = 幻觉风险上升）。因此：

拒答率的任何下降不得伴随拒答准确率下降；若两者同时下降，判定为阈值放宽导致，须回滚拒答阈值并重新校准。
其中「没有可靠证据」与「权限判断失败」两类拒答不参与下降目标：前者是知识缺口的正确信号（05 §8 的安全底线），后者是安全底线。
「拒答率按原因分类的分布」是 C1 阶段的核心产出——§2.2 的 C1 目标就是「统计 refusal 与低召回 query，形成种子知识清单」，按原因分类正是形成该清单的方法。

6. 决策点清单

6.1 已确认决策

编号	决策点	选定方案	依据
LD1.1	成熟度是否分级	是，L0–L5 六级	蓝图 §10.1
LD1.2	安全是否属于 L0	是，密级过滤在 L0 必须就位	蓝图 §10.1
LD2.1	冷启动是否先读后写	是，C0 不要求写作	蓝图 §10.1
LD2.2	冷启动是否分四期	是，C0–C3	蓝图 §10.1
LD2.3	迁移顺序是否按目录树	否，按 C1 的 query 命中缺口	蓝图 §10.1
LD3.1	角色是否分四类	是，Owner / Steward / 平台组 / 园艺	蓝图 §10.2
LD3.2	Owner 是否不得为平台组	是，平台组不了解业务语义	蓝图 §10.2
LD3.3	Steward 是否不得同时为审批人	是，避免自审自批	蓝图 §10.2
LD3.4	园艺 Agent 是否不得有自动删除权	是，06 §2.4 三重防误删	蓝图 §10.2
LD2.5	激励是否与阅读收益解耦	是，写作激励不靠派发	蓝图 §10.2
LD4.1	多租户索引是否物理隔离	是，不靠 metadata 过滤	蓝图 §10.2
LD5.1	容量是否按 Agent 并发估算	是，人数估算法会严重低估	蓝图 §10.3
LD5.2	摄入层与服务层是否资源隔离	是，避免重建击穿 P95	蓝图 §10.3
LD5.3	权限与审计失败时是否拒绝服务	是，可用性让位于合规	蓝图 §10.3
LD5.4	索引是否备份	否，从 Git 全量重建	蓝图 §10.3
LD5.5	审计日志是否异地归档	是，不可重建	蓝图 §10.3
LD6.1	成本是否分三类核算	是，建设 / 运行 / 治理	蓝图 §10.3
LD6.2	自建与选型是否以"能否承载 04 §2 + 05 §9.1"为判断依据	是	蓝图 §10.3
LD7.1	验收指标是否分级	是，硬门禁 vs 待校准	蓝图 §10.4
LD7.2	硬门禁是否可在 P0 直接阻断	是，10 项机制保证指标	蓝图 §10.4

6.2 待确认决策

编号前缀说明：本文决策编号统一使用 LD 前缀（Landing Decision）。原用 L1–L11 与 §2.1 的成熟度层级 L0–L5、以及 04 §2 的存储分层 L0（Git 层）/ L4（索引层）三重占用同一字母——「L4」在本文可能指成熟度「变更驱动」、存储层「向量/全文索引」或决策项「上下文前缀是否持久化」，跨文档引用时无法判定所指。与 05 §14 把 R 改为 RT 属同一类问题。

原表 7 行中有 6 行在正文已作为定论给出（LD2.4 见 §2.2「迁移顺序不按目录树」且 §6.1 LD2.3 已记录同一条为已确认；LD2.6 见 §2.3 三条并列判据；LD3.5 见 §2.4 与 §2.5「每租户各一套」；LD4.2 见 §2.5「金标集不得跨租户共享」；LD6.3 见 §2.6.7「任一项不满足则无法落地」即 D；LD7.3 见 §3.1 P0 完成判据）。把这 6 行留在"待确认"会导致评审重议已定案内容，或更糟——评审者改了而正文没同步，产生两套并存结论。 已删除，改列真正未决且高影响的项：

编号	决策点	候选方案	建议	必须何时前决策	决策人
LD1	审计异地同步失败是否拒绝服务	A. 直接拒绝（原方案） / B. 本地缓冲 + 异步上传，缓冲耗尽才拒绝	B（见 §2.6.4：A 与 P95 ≤ 500ms 物理上不可兼得）	P0 启动前，不可逆（决定审计存储架构）	架构评审 + 合规
LD2	是否引入本地审计缓冲	A. 引入 / B. 不引入	A，同 LD1	P0 启动前	架构评审
LD3	P0 阶段是否禁用检索结果缓存	A. 禁用 / B. 启用并要求缓存键含权限集	A（B 的载体在 P1，见 §3.2；禁用则 `缓存串味事件数` 恒为 0）	P0 启动前	平台组
LD4	上下文前缀是否持久化到 Git	A. 持久化（sidecar 或元数据库） / B. 每次重建重算	A（见 §2.6.5：不持久化则"索引不备份只重建"在大型档不成立）	P0 启动前，不可逆	架构评审
LD5	`flags` 字段是否写回 Git frontmatter	A. 写回（04 §3.6 S1.5 选 A） / B. 只存元数据库	A（B 则元数据库治理状态不可重建，见 §2.6.5）	P0 启动前	架构评审
LD6	Embedding 模型选型评测是否提前到 P1	A. 提前到 P1 / B. 保持 P2	A（见 §3.2：B 意味着 P0/P1 用未评测模型，P2 换模型触发全量重建）	P0 启动前（决定 P0 上线时是否声明"临时选型"）	平台组
LD7	是否新增 frontmatter `author` 字段	A. 纳入 P0 的 8 字段 / B. 只做团队级（`owner_group`）	A（见 §2.4 原则 3：B 无法解决作者个人的激励不对称）	P0 启动前，不可逆（Schema 变更成本随存量单调上升）	Steward + 架构评审
LD8	多租户是否为 P0 前置判断	A. P0 前确认租户数并按租户分 collection / B. 保持 P3 再决定	A。§3.4 把多租户隔离排在 P3 并注明"仅当多 BU 共用时需要"，但 §2.5 要求索引物理隔离（每租户独立 collection）。若团队确实是多 BU，P0 建索引时就必须按租户分 collection——P3 才决定多租户、P0 就要承担后果，是不可逆的架构决策	P0 启动前，不可逆	架构评审
LD9	关系图谱建模归属	A. 在 06 新增"资产关系图建模"一节（原生 kind 清单 / 自定义 kind 注册 / 边谓词集合） / B. 保持在主文档 §7.5–§7.6 不下沉	A（§3.4 与 §2.2 C3 都引用 06 §3.4，但该小节只讲影响分析，图谱建模在拆分文档集中无处可查）。附带须澄清：§2.7.2「受控谓词集合（5 个初始谓词，02 §4.4）」指的是冲突检测的主张谓词，与图谱的边谓词是否同一套，现无说明	P3 启动前	Steward
LD10	全量重建时长的分级目标	A. 统一 ≤ 30 分钟 / B. 小型 ≤ 10 分 / 中型 ≤ 30 分 / 大型 ≤ 2 小时	B（见 §2.6.5 量级推导），且须先实测 chunk 总数与 Embedding 吞吐	P0 启动前（初始值）→ 实测后校准	平台组
LD11	知识条目模板归属	A. 在 04 新增「知识条目模板」一节（承接蓝图 §5.5.1 的四段结构） / B. 保持在主文档不下沉	A。09 §3.1 把「知识条目模板」列为 P0 建设项，但拆分文档集中没有任何一节定义它——04 §4.1 只有 `_index.yaml` 路由地图。P0 建设项在落地文档里找不到规格，执行时必然各自发挥，而「无模板则第一条知识就格式漂移」正是该行自己写的 ROI 理由	P0 启动前	Steward

7. 待实测项与校准计划

原清单只有 9 条，逐字对应主文档 §10.3 的"待实测"行，完全没有汇总 §2.7.2 的 40+ 行与 01–08 各章的待实测项。 后果很具体：§2.7.2 的整个门禁分级设计（阈值待实测 → 观测 → 校准 → 升级为门禁）需要一份校准计划作为落地载体，而本节是全文档唯一可能被当作校准计划的地方。它只覆盖约 1/5，意味着其余参数会永久停留在"仅观测"状态，校准永远不开始。

校准计划的要求：§2.7.2 中标为「无」或「阈值待实测」的每一行都必须在此登记，字段为：

参数	校准所需数据	校准方法（引 §2.7.2）	最早可校准的成熟度阶段	前置依赖	责任角色	目标完成期

当前已登记的 9 条（其余待按上表逐行补齐，属 §6.2 之外的执行动作，不需决策）：

全部容量数值（知识条目数、向量数、QPS 峰值）——采集方式见 §2.6.2
chunk 切分放大系数——§2.6.1 已给出方法（对现有语料做一次完整切分后统计分布）
重建时间——按档位分级，推导公式见 §2.6.5
三类成本的实际金额（建设 / 运行 / 治理人力）——驱动因子公式见 §2.6.6
云服务与开源平台的能力验证结果——验证清单见 §2.6.7
种子域覆盖率阈值——新口径见 §5，C3 起作为验收指标
Owner 响应时长：验证 §5 的 ≤ 5 天初始建议值是否可达（原文写"阈值待实测"与 §5 已给出的 5 天自相矛盾，现统一为"验证初始建议值"）
单次命中节省的人时（两组对照实测，季度复测）
边际价值观察期长度

本轮新增登记（本次审计发现此前无处登记）：归因盲评一致率门槛（§2.4 原则 4）、样例风险层级判据与阈值（跨 04/06/07 共用）、回归评测频率、审计缓冲告警阈值（建议 20%）、限流配额（§2.6.2.1）、可用性 SLO 与审计缓冲耗尽年累计时长（§2.6.4）、主动提交信号的周期 N 与人数 M（§2.3）、P0 人力三步法的风险系数（§4）。

8. 与其他文档的接口

接口方	接口内容	方向
01 知识生成	摄入链路作为 P0 建设项	01 ← 本文
02 知识验证	CI 校验四件套作为 P0 建设项	02 ← 本文
03 知识审核	CODEOWNERS + `owner_group` 存在性校验提前到 P0（它是"新增孤儿知识率"硬门禁的唯一载体，也是"角色定义"的机制承接；把定义放 P0、载体放 P1 是断裂的）；离职资产转移仍为 P3	03 ← 本文
04 知识存储	元数据 Schema 作为 P0 建设项；Chunk 切分 + Embedding + 索引写入 Pipeline、上下文前缀生成与持久化作为 P0 建设项；索引重建时长作为容灾指标（按档位分级）	04 ← 本文
05 检索与引用	检索前密级过滤作为 P0 建设项；MCP Server 最小实现提前到 P0（幻觉引用率与越权拦截率两项硬门禁的唯一出口），P1 保留"替代直接读文件"的全面接入	05 ← 本文
06 知识维护	漂移检测作为 P1 建设项；边际价值评估作为 P3 建设项	06 ← 本文
07 评测与反馈	工程基线采集作为 P0 建设项（不可回溯，见 §3.1）；最小金标集（≥30 条）与 Embedding 选型评测作为 P1 建设项；完整金标集标注与回归集门禁作为 P2 建设项	07 ← 本文
08 约束执行	Qoder Hooks 作为 P1 建设项（须先确认 CLI / IDE 形态，形态只影响事件集与生命周期自动化，不影响隔离能力）；Worktree 隔离作为 P1 建设项；AI 输出快照 Hook 是 07 §2.4.1「人工重写比例」的唯一数据源，须与之同期建成	08 ↔ 本文