zizi-al/muse-agent-example
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
muse-agent-example/docs/2026-07-16-升格卡改造设计.md

26 KiB
Raw Blame History

升格卡改造设计（P0 补骨架记里程碑 · P1 串链语义判重）

  • 版本：v1（2026-07-16 设计稿，供创始人评审，未实现、未动数据、未提交）
  • 目标读者：创始人 + 后续实现的子代理
  • 边界：只改参考书作品面升格卡（source_type='upgrade_book'）的字段骨架、抽取提示词、判重方式、上下文裁剪标注；不碰范式卡、不碰主仓。概念定义对齐 ../design-docs/（专题-06、架构-02）与源方案 docs/2026-07-14-参考书作品面数据入库方案.md，本稿是对该方案 §五「实体卡生命周期」的一次修订，不自立门户。
  • 一句话结论：给机甲/武器/力量体系这些型补上一条"从登场到结局"的演变历程明细，用真实章号当索引（不用会变的运行时窗号），并把这条上万字的明细只给一致性检查看、不给续写看（续写只看当前态和一句话梗概）；再用语义判重把改了名、换了型的同一条成长线并回一起、串成前后链。

一、先说人话：这次要解决什么

升格卡 = 每本参考书里"会随剧情长大的实体卡"——人物、机甲、武器、力量体系都算。它的价值是：当 muse 学一本书时，能看清"这台生物机甲是怎么从 4 级一步步打到 7 级对决"的完整成长线。

现在这条线维护不出来。典型病例：一台生物机甲开头 4 级出场，中段 5 级 6 级，终局 7 级对决——卡里完全看不到这条演变线，只剩一个"最终态"，中间全被抹平了。

这次改造分两步走：

  • 第一步（先补骨架、记里程碑）：给机甲/武器/力量体系这些型补上"演变历程"字段，把每一次进化台阶记成一条条里程碑，不再被覆写抹平、不再塞错字段。
  • 第二步（再串链、上语义判重）：加"前身/后继"把散落的碎卡串成一条进化链；判重从"只比名字字符串"升级到"比语义"，治改名和跨型漏并。

两个硬要求贯穿全程：里程碑用真实章号索引（不用窗号）；卡片分两层给——续写只看当前态，一致性检查才看全历史。

二、病根复述（都有真实卡为证）

以下四条病根，均从库里真实升格卡（work_id=8）抽样核实，不是推断。

病根 1：只有"人物"型有成长字段，机甲/武器/力量体系型是"骨架残缺"

库里 23 型中，只有两个型有"记录演变"的数组字段：character（成长弧线）、character_relation（演变轨迹）。机甲/武器/战舰所属的 item 型、力量体系所属的 power_system 型，以及 faction/location/event，一个演变字段都没有。

  • 铁证：机甲卡「铁头机甲（一代）」（id=1154）出场横跨 64 章（第 10 章到第 548 章），字段却只有"品阶/类别/知情范围/能力与限制"，全是会被覆写的当前值。它的一句话摘要是"已退役，封存于暗龙会仓库"——这是最终态，把它 10 章出场时"崭新训练机"的样子彻底抹平了。一台陪跑全书的机甲，成长线为零。

病根 2：进阶要么被覆写抹平，要么塞进错字段成流水账

没有专门的演变字段，模型只能把"进化"硬塞进当前态字段，结果字段语义被污染：

  • 机甲卡「影杀者」（id=4935）：把"被重创 → 修复 → 配合突围"这条演变线，塞进了「流转计划」（本该写未来伏笔）和「能力与限制」（本该写当前能力），还带着"本窗/前窗"这种一旦脱离运行环境就没法读的相对指代。
  • 力量体系卡「生物机甲」（id=6223，正是病例本体）：把"第 420 章 V 代编队 → 477 章拦截 → 489 → 490-492 → 549-550 → 572 章"整条升级线，塞进了「戏剧作用」（本该一句话写规则）和「跨体系换算」（本该写强弱对照），写成一大段散文流水账。它的摘要同样是最终态（200% 同步率对决 VI 型领主），4 级出场的初始态被抹平。
  • 对照「机甲世代」（id=4995）的「境界阶梯」="一代 < 二代 < 三代 < 四代 < 伪 V 代"——这是静态的世界规则（一把标尺），不是某台机甲实际爬台阶的历程。说明现有字段能记"规则"，但记不了"某个实体自己怎么一步步长大"。

病根 3：一条成长主线被拆成 30+ 张碎卡，跨多个型，彼此无链接

"机甲代际"这条主线，散落在：力量体系型的「生物机甲」「机甲世代」「旧联邦机甲代际」，加上 item 型的「铁头机甲」「铁卫」「枪骑士」「影杀者」等一堆具体机甲卡。它们之间没有任何链接，看不出"铁头（一代）→ 铁卫（二代）→ 枪骑士（三代）→ 影杀者（四代）→ 生物机甲（V 代）"是同一条进化链。

病根 4：判重只比名字字符串，语义判重是关着的

现在的判重（在 parse_upgrade.py 的判重步）只有三招：名字/别名精确匹配、模型自报的疑似别名、同型名字互为子串。没有接语义判重——代码里白纸黑字写着"嵌入延后：试跑期不调嵌入 API"。

后果：同一实体一旦改名（如"影杀者"→"IV 代纯机械机甲·影杀者"）或跨型指代，字符串对不上就漏并，进一步加剧病根 3 的碎卡。

补充：源方案 v6 本来就设计了"名字精确 → 嵌入近邻 → AI 终判"三级判重，只是试跑期把嵌入近邻这级关掉了。所以第二步的语义判重不是发明新东西，是把 v6 已设计好、暂时关着的那一级打开。

三、方案总览

flowchart TB
    subgraph P0["第一步 P0：补骨架 + 记里程碑（治病根 1、2）"]
        A1["给 item/power_system 等型<br/>加『演变历程』数组字段"]
        A2["加进追加白名单 APPEND_FIELDS<br/>（只往后加，永不覆写抹平）"]
        A3["改抽取提示词：<br/>每次进化记一条里程碑<br/>标生命周期（登场→高光→退场→结局）<br/>当前态字段保持干净、不塞历史"]
    end
    subgraph P1["第二步 P1：串链 + 语义判重（治病根 3、4）"]
        B1["加『前身/后继』链接字段<br/>把碎卡串成一条进化链"]
        B2["判重打开语义近邻（≥0.60·小样实测校准）<br/>+ M3 终判 → 治改名/跨型漏并"]
    end
    subgraph FIX["两点硬性细化（贯穿全程）"]
        C1["① 里程碑用真实章号索引<br/>绝不用运行时窗号 [窗N]"]
        C2["② 卡片分两层披露<br/>续写只看当前态+梗概<br/>一致性检查才看全历史<br/>（复用现成的 aiContext 按用途裁剪）"]
    end
    P0 --> P1
    C1 -.贯穿.-> P0
    C2 -.贯穿.-> P0

四、第一步 P0：补骨架 + 记里程碑

4.1 加什么字段

给缺演变字段的实体型补一个统一的「演变历程」数组字段。核心是 item（机甲/武器/战舰）和 power_system（力量体系/机甲代际）；faction/location/event 按需跟进（组织兴衰、地点易主、事件推进同样能用，建议同批补上，避免二次改）。

配套还要两个字段（详见第五节 schema 定义）：

  • 「演变概括」——一句话说清整条线的来龙去脉（现状层，续写可见）。
  • 「前身」「后继」——串链用（第二步 P1 用，schema 一次性加齐）。

4.2 抽取提示词怎么改（要点，不写代码）

改 parse_upgrade.py 里的两段提示词：

  • 实体观察提示词（observe）：新实体立卡时，如果这一窗就观察到它的登场/首个进化台阶，产出「演变历程」的第一条里程碑（带真实章号 + 生命周期标记）。
  • 卡更新提示词（update）：从现在的"记新信息"改为明确的"记进化台阶 + 生命周期"——每当实体发生境界/代际/形态/能力的跃迁，或到达登场、高光、退场、结局这些节点，就追加一条里程碑，绝不覆写、绝不抹平旧台阶。同时要求：当前态字段（品阶/能力与限制/摘要）只写"现在是什么样"的干净全量值，不许把历史流水塞进来（直接治病根 2 的"塞错字段"）。

提示词纪律要加两条硬约束：

  1. 每条里程碑必须带真实章号（正文里原样出现的"第 X 章"），禁止 [窗N] 窗号、禁止"本窗/近期/前段"这类相对指代——因为卡会脱离运行环境被单独阅读。
  2. 生命周期标记从固定枚举里选：登场 / 成长 / 高光 / 退场 / 结局。这一条直接治"铁头机甲摘要跳到已退役、中间态全丢"——有了登场和退场节点，一台机甲什么时候来的、什么时候谢幕，一目了然。

4.3 合并逻辑要跟着改

「演变历程」进 APPEND_FIELDS 追加白名单后，parse_upgrade.py 的合并/立卡/撤销逻辑（merge_card/new_card/undo_window）要从"处理带 [窗N] 前缀的字符串条目"适配为"处理带章号的里程碑条目"：去重按里程碑内容、排序按章号（不再按窗号）。现有那套针对脏数据的守卫（剥前缀、剥尾部残渣、拦垃圾、拆巨型粘连）要保留并改造，别丢。

顺带清理：APPEND_FIELDS 里的「大事记」「经历」两个名字在任何 schema 里都没有定义（是孤儿字段，模型就算输出也会被字段校验裁掉）。这次统一到「演变历程」，孤儿名可保留做向后兼容但不再新用。

五、「演变历程」字段的 schema 定义

5.1 字段清单（加在 item.yaml / power_system.yaml 等型的"特有字段")

字段名 类型 说明 属哪层
演变历程 里程碑对象数组 已发生的进化台阶明细，一条一台阶，永远追加不覆写 完整历史层
演变概括 一句话文本 整条线的来龙去脉梗概（如"4 级训练机出场 → V 代编队主力 → 300% 同步率对决 VI 型领主"） 现状层
前身 链接（卡号 + 名称） 这张卡的上一代/来源，指向同书另一张卡 现状层
后继 链接（卡号 + 名称） 这张卡的下一代/继承者，指向同书另一张卡 现状层

5.2 里程碑对象结构（每条演变历程条目长这样）

推荐用极简三字段结构化对象，既能按章号排序/定位，又不会因字段太多让模型抽崩：

{
  "章": 420,
  "台阶": "V代编队首战：暗星帝国出动十台生物机甲配合亡灵号，扭转多瑙星海战场局势",
  "周期": "高光"
}
  • 章：绝对章号，用于索引与排序。单章事件填整数（420）；跨多章的连续事件填区间字符串（"420-423"）。这是"用绝对章号索引"的落点。
  • 台阶：一句话讲清"进化到什么 + 靠什么事件"。刻意把"结果 + 经过"合成一句，不再往下拆细字段，避免模型输出格式崩。
  • 周期：生命周期枚举，取值 登场 / 成长 / 高光 / 退场 / 结局。

这个结构是有真实依据的：库里关系卡「苏铭×林初雨」早期就自发用过 {状态, 章区间: "Ch.21", 转折事件} 这种带章号的结构化格式，证明模型抽得出、章号索引可行。三字段是"结构化可查询"和"模型稳定"之间的最优平衡点。

备选（若评审认为对象改造风险太大）：退一步用带章号前缀的字符串条目，即把现在的 [窗2] xxx 换成 [第420章·高光] xxx。改动更小、迁移更平滑，但章号在文字前缀里，得靠正则抽取、不能直接用 SQL 过滤。推荐前者、备选后者，见第九节拍板点。

5.3 一条真实成长线改造后长什么样（以病例"生物机甲"示意）

现在（病根 2 的样子）：升级史一大段塞在「戏剧作用」字段里，散文流水，摘要只剩最终态。

改造后：

  • 演变概括（现状层，续写可见）："卡依斯生物反应驱动的奇袭兵器，从 4 级机体登场，历经 V 代编队、300% 同步率解放，终局对决近帝皇级 VI 型领主。"
  • 演变历程（完整历史层，只给一致性检查）：
    • {章: 332, 台阶: "生物机甲首次登场，作为突破哈姆斯要塞的核心奇袭兵器", 周期: 登场}
    • {章: 420, 台阶: "V代编队首战，配合亡灵号扭转多瑙星海战场", 周期: 成长}
    • {章: "490-492", 台阶: "苏铭精神链接同步率飙至300%，压制伪VI代、夺龙基之枪贯穿拜鲁特", 周期: 高光}
    • {章: "549-550", 台阶: "300%同步率独战近帝皇级VI型英雄级伊琳莉丝，龙基之枪刺穿其AT立场", 周期: 结局}

一条清清爽爽、按章号排序、能看出起承转合的成长线就立住了。

六、两点硬性细化的落地

6.1 细化①：真实章号索引 + 现有 [窗N] 卡的迁移办法

为什么不能用窗号：窗号（[窗N]）是抽取时"切正文窗"的运行产物——切窗规则是"每窗 12 章或 3.5 万字"，规则一改窗号全变。它是运行时定义、会变、不该当卡的稳定属性。真实章号（第 420 章）才是永远不变的锚。

存量卡怎么迁移（一次性迁移脚本，本稿只给办法、不实现）：遍历所有 upgrade_book 卡的演变类字段（成长弧线/演变轨迹等）里每一条带 [窗N] 的条目，按下面优先级把 [窗N] 换成真实章号：

  1. 优先——抽条目文字里已有的真实章号：很多条目正文里模型自己就写了"第 420 章""163 章""Ch.21"，正则抽出来直接当「章」。这是最准的。
  2. 兜底——用窗到章的映射表：条目里没有内嵌章号的，查 example_upgrade_window 表（窗号 → from_chapter~to_chapter），把 [窗N] 映射成该窗的章区间（如 [窗2] → "13-24"），并打一个"章区间近似"标记，表明这是窗级近似、不是精确到章。
  3. 顺手清脏：迁移时一并清掉已知垃圾——[窗17] ['窗23 这类残片、重复条目、尾部 JSON 拼接残渣。复用 parse_upgrade.py 里现成的剥前缀/剥尾残/拦垃圾逻辑。

诚实边界：上万字的历史里，兜底那批（无内嵌章号、只能靠窗映射）会损失精度——只能定位到 12 章宽的区间。这是存量迁移的固有局限，新抽取的卡因为提示词强制带真实章号不受影响。

6.2 细化②：渐进式披露 = 现状层 + 完整历史层，接现有 aiContext 按用途裁剪

这不是新机制。本仓早就有"字段按用途可见性裁剪"的机制：每个 schema 字段有个 aiContext 标注——true 任何场景可见、false 一律不给、[用途…] 只有列出的场景可见。用途有四种：generation（续写）、detection（一致性检查）、planning（规划）、extraction（抽取判重）。read-context（组装上下文）、search（检索）、detect（一致性检查）三个 skill 都已经按这个标注干活。渐进披露就是给演变字段填对 aiContext，一行标注的事。

分两层：

  • 现状层——写作 agent 续写时默认只读这层。包括实体当前态（品阶/能力与限制/当前持有者/一句话摘要）+ 演变概括 + 前身后继。让续写者知道"这台机甲现在几级、一路怎么来的梗概、前身是谁"，但不被上万字明细淹没。
  • 完整历史层——只有一致性检查（detector）读全。就是「演变历程」那个可能上万字的里程碑数组。续写用不上这么细，一致性检查却必须有它才能查出"上一章还 4 级、这一章怎么突然 7 级"这种跳级穿帮。

用途可见性分层表（这张表就是要填进各型 schema 的 aiContext 标注）：

层 字段 aiContext 标注 续写
generation		 一致性检查
detection		 规划
planning		 判重
extraction
现状层 当前态（品阶/能力与限制/当前持有者） true ✓ ✓ ✓ ✓
现状层 一句话摘要 true ✓ ✓ ✓ ✓
现状层 演变概括 true ✓ ✓ ✓ ✓
现状层 前身 / 后继 true ✓ ✓ ✓ ✓
完整历史层 演变历程（全里程碑） [detection, extraction] ✗ ✓ (可选) ✓

关键就是最后一行：把「演变历程」标成 [detection, extraction]——续写（generation）自动看不到，一致性检查（detection）和判重（extraction）才看得到。填完这一行，三件事自动发生、不用再写别的代码：

  1. detect skill 会自动把「演变历程」纳入检查项（它的规则就是"凡 aiContext 含 detection 的字段，自动成为一个检查项"）——一致性检查从此多一道"演变连续性/跳级穿帮"关卡。
  2. read-context 组装续写上下文时，自动把「演变历程」裁掉——写作 agent 的上下文不会被上万字历史撑爆。
  3. search --purpose generation 检索时也自动裁掉它。

一个要讲清的区别：character 现有的「成长弧线」标的是 [planning, detection]，它的语义是"计划中的变化，防抢进度剧透"——防的是"未来"。而「演变历程」是"已发生的历史"，它对续写不可见的原因不是防剧透（都发生过了），而是怕上万字撑爆上下文。两者都对续写关闭，但一个防未来、一个防过载，别混为一谈。也因此，关系卡的「演变轨迹」保持 true（续写可见）是合理的——俩人现在什么关系、怎么走到这一步，对续写笔触很重要，且量不大；而机甲的上万字升级史续写用不上，只需当前几级。

七、改动清单（涉及哪些文件 / schema / prompt / skill）

全部是设计稿层面的改动点，本稿不实现、不执行、不重跑种子、不提交。

文件 改什么 属
meta/schemas/item.yaml 加「演变历程」[detection,extraction]、「演变概括」true、「前身」「后继」true 四字段 schema
meta/schemas/power_system.yaml 同上 schema
meta/schemas/faction.yaml location.yaml event.yaml 同上（建议同批补，避免二次改；见拍板点） schema
meta/schemas/character.yaml 语义对齐：明确「成长弧线」=未来计划，已发生台阶归「演变历程」（是否给 character 也加演变历程见拍板点） schema
meta/schemas/character_relation.yaml 「演变轨迹」说明里"章区间"沿用真实章号（本就如此），确认 aiContext 保持 true schema
.claude/skills/parse-book/scripts/parse_upgrade.py ①APPEND_FIELDS 加「演变历程」②observe/update 提示词改为记台阶+生命周期+真实章号、禁窗号相对指代、当前态字段保持干净 ③合并/立卡/撤销逻辑适配里程碑对象（去重按内容、排序按章号）④判重步接语义近邻+M3 终判（P1） prompt + 逻辑
.claude/skills/db/scripts/seed_schemas.py 不改脚本；schema YAML 改完后需重跑一次把新字段和 aiContext 灌进库（本稿不跑，实施时跑） 种子
.claude/skills/read-context/SKILL.md Layer 2 知识卡裁剪说明里，点名"演变历程完整层仅一致性检查可见、续写不给"（机制已支持，补一句说明） skill 文档
.claude/skills/detect/SKILL.md 检查项示例表补一行"演变历程 → 演变连续性/跳级穿帮"（实际自动生成，文档补例） skill 文档
新增一次性迁移脚本（如 docs/ 或 skill scripts 下） 存量卡 [窗N] → 真实章号 + 字符串条目 → 里程碑对象 + 清脏（见 6.1） 迁移

不需要改的：数据库表结构（演变历程/前身/后继都是知识卡 JSON 里的字段，不需要 DDL 建表/改表）；语义判重复用现成的 example_knowledge_embedding 向量表和 embed/search skill，不新建表。

八、第二步 P1：串链 + 语义判重（细化）

8.1 串链：前身/后继

用第五节已定义的「前身」「后继」链接字段（指向同书另一张卡的卡号 + 名称），把"铁头（一代）→ 铁卫（二代）→ 枪骑士（三代）→ 影杀者（四代）→ 生物机甲（V 代）"这条链串起来。链接机制照抄现成的做法——关系卡早就用"甲方卡号/乙方卡号"指向人物卡，一样的路子。标 aiContext: true，续写要知道"这台机甲的前身是谁"。

8.2 语义判重：打开嵌入近邻 + M3 终判

在判重步，除现有的名字精确匹配/子串外，新增（就是打开 v6 已设计、暂时关着的那级）：

  1. 对候选新实体算向量（走 embed skill），用 search 召回同书同型相似度 ≥ 0.60 的近邻卡（原定 0.78，2026-07-18 零落库小样实测校准：同实体改名对余弦 0.63-0.66、不同体系对 ≤0.58，0.78 永不触发语义层；依据详见 parse_upgrade.py 阈值注释）。
  2. 召回的近邻交给 M3 终判（走 parse_llm.py 的 m3_json 入口，构造"这两张卡是不是同一实体 / 是不是前身后继关系"的判断），判定三选一：同一实体（并卡）/ 前身后继（不并卡但串链）/ 无关（各自立卡）。

这样"影杀者"和"IV 代纯机械机甲·影杀者"这种改名、以及跨型指代同一条线的，都能被语义召回并正确处理。

跨型判重要收着点：item（具体某台机甲）和 power_system（一整套体系）很容易被向量拉近却其实不是一回事（如"生物机甲体系"vs 具体机甲"伊琳娅丝"）。所以跨型只做"提示 + 串链候选"，不自动并卡；同型才允许自动并。

九、风险与验证办法

风险

  1. 条目从字符串变对象，合并逻辑改动面不小。parse_upgrade.py 现有一大套针对字符串条目的守卫（剥前缀、剥尾残、拦垃圾、拆粘连、窗序归位），全要跟着改造成处理里程碑对象；存量卡还是字符串，迁移要兼容。→ 缓解：分两步落，先补字段和提示词（新卡受益），再做存量迁移；对象结构压到三字段降低崩坏面。
  2. 模型抽结构化对象比抽字符串更容易格式崩。→ 缓解：三字段极简；保留降级——抽不出完整对象就退化成"章号 + 一句话"最小对象，别整条丢。
  3. 语义判重增加调用量和跨型误并风险。→ 缓解：0.60 阈值（实测校准） + 同型才自动并 + 跨型仅提示；判重近邻可像 v6 说的那样批量做、不逐条烧。
  4. 存量迁移精度损失：无内嵌章号的条目只能靠窗映射到 12 章宽区间。→ 接受为存量固有局限，新卡不受影响。
  5. 改 schema 后必须重跑种子，否则库里字段合同和 YAML 不一致，抽取会按旧合同把新字段裁掉。→ 实施清单里钉死"改 YAML 后重跑 seed_schemas.py"这一步。

验证办法（实施后怎么确认真治好了）

  • 成长线立得住：挑病例"生物机甲"这条线（work_id=8）跑改造后的抽取，看能不能维护出"4 级登场 → V 代 → 300% 高光 → 结局对决"这条按章号排序、带生命周期的清晰台阶，以及"铁头 →…→ 生物机甲"的前身后继链。
  • 分层裁剪真生效：search --purpose generation 查一张机甲卡，确认「演变历程」被裁掉、只回现状层；--purpose detection 确认「演变历程」保留。
  • 一致性检查自动加项：对一章跑 detect，确认检查清单里自动多了"演变连续性"这一项。
  • 语义判重召回：造一个改名样例（影杀者 / IV 代纯机械机甲·影杀者），确认语义判重能召回并由 M3 判为同一实体或前身后继。
  • 章号无窗号残留：迁移后全库扫一遍，确认演变类字段里不再有 [窗N] 前缀。

十、需要创始人拍板的点

✅ 已拍板（2026-07-17，创始人 4 项 + 主代理定 #4）——实现以此为准，下方原始理由留档：

  1. 里程碑格式 = 结构化对象（章 / 台阶 / 周期），配降级（抽不出完整对象退成"章号 + 一句话"，不整条丢）。
  2. 补齐范围 = 五型全补：item / power_system / faction / location / event。
  3. character = 一起改：给人物也加「演变历程」、「成长弧线」回归"未来计划"本义，连带迁移 200+ 张存量人物卡。
  4. 演变概括 = 独立字段（主代理定：摘要管当前态、概括管轨迹，职责清晰）。
  5. 存量迁移 = 人工精确化：不接受 12 章宽近似——无内嵌章号的老条目靠再抽原文 / 人工核对精确到真实章号。
  1. 里程碑用"结构化对象"还是"带章号前缀的字符串"？ 本稿推荐三字段对象（章/台阶/周期，可 SQL 按章排序、结构清晰），备选字符串前缀 [第420章·高光] …（改动最小、迁移最平滑）。取舍是"规整可查询"对上"改动小、模型稳"。
  2. 演变字段是否给全部实体型补齐？ 核心必补 item/power_system。faction/location/event 建议同批补（组织兴衰、地点易主、事件推进同样用得上），避免将来二次改 schema。请拍板范围。
  3. character 型怎么处理？ 现在它把"已发生历程"记在名为「成长弧线（未来计划）」的字段里，语义拧巴。是否给 character 也加「演变历程」、让「成长弧线」回归"未来计划"本义？这会牵动 200+ 张存量 character 卡的迁移，请拍板做还是暂缓。
  4. 「演变概括」是独立字段还是并进「一句话摘要」？ 本稿推荐独立字段（摘要管当前态、概括管轨迹，职责清晰）；也可并进摘要写法要求省一个字段（更省、但摘要职责变重）。
  5. 存量迁移的精度损失可接受吗？ 无内嵌章号的老条目只能定位到 12 章宽区间。确认接受，还是要投入人工/再抽一遍把这批精确化。