132 lines
12 KiB
Markdown
132 lines
12 KiB
Markdown
# 质量与复利领域 SoT
|
||
|
||
> 数据权威已改订为 PostgreSQL：正式内容（Canonical）都在库里，待审候选（Shadow）也在库里，raw 进库可看全文，只读看板只查库渲染绝不写。本文档不再描述任何“作品内文件目录”作为质量证据的家。落库的横切合同见索引 §3，本文只引用、不重复定义。
|
||
|
||
## 1. 唯一职责
|
||
|
||
质量与复利领域拥有候选检查、语义审核、评分策略、失败终态合同和经验升格规则。它回答“候选有什么问题、是否可以交给用户裁决、某种写法是否稳定有效、哪些经验值得进入范式、Agent、Skill 或工具”。
|
||
|
||
本领域产出检查、审核、实验和升格结论，并把结论落库；它不拥有正文、实体事实、范式正文、模型运行底座，也不拥有用户的接受动作。一切检查输入与质量产出都必须落库可见，没落库的等于系统视角里不存在。
|
||
|
||
## 2. 四层质量链
|
||
|
||
```text
|
||
机械正确性
|
||
-> 语义正确性
|
||
-> 创作质量
|
||
-> 长期效果与复利
|
||
```
|
||
|
||
1. 机械检查：schema、字数合同、hash、引用、状态机、预算账本、确定性规则。
|
||
2. 语义检测：实体、关系、细纲硬约束、知情范围、时间线和来源支持。
|
||
3. 创作评审：通用底层指标 + 场景类型评分；指出具体可修问题。
|
||
4. 长期验证：跨章、跨场景或跨作品复核，结合用户决策和合法外部反馈判断方法是否有效。
|
||
|
||
机械失败不可被 Agent 主观覆判：机械层不过就是不过，语义和创作评审再高也不能把它盖过去。语义和创作评审也不能替代机械检查。
|
||
|
||
## 3. 评分结构
|
||
|
||
评分采用两层结构：
|
||
|
||
- 通用底层指标（四个通用维度）：设定与实体保真、规划忠实、文风一致、可读性。这些跨章节可比较。
|
||
- 场景类型策略（五类场景）：战斗、人物对话、转折、信息揭示、老角色回归，各有自己的重点、权重和锚点。
|
||
|
||
每章不能自创完全不同的量表，否则失去跨章比较；也不能用一套固定权重覆盖所有场景。量表、场景策略和阈值必须版本化——改了评分口径，要能读出“这次用的是哪一版量表”。
|
||
|
||
现有实现承认（各一句，不展开）：六类混淆项报告与新角色比例分层裁决由 [`adjudicate-quality-gate`](../../lifecycle/quality/skills/mechanical/adjudicate-quality-gate/SKILL.md) 承载；评分后的单变量归因建议由 [`optimize-content-quality`](../../lifecycle/quality/skills/judge/optimize-content-quality/SKILL.md) 承载；卡三角色审核与金标准校准由 [`review-knowledge-cards`](../../content/entity/skills/review/review-knowledge-cards/SKILL.md) 承载；AI 味案例的来源哈希、Shadow 捕获与来源重验证由 [`capture-ai-flavor-cases`](../../lifecycle/quality/humanization/skills/capture-ai-flavor-cases/SKILL.md) 承载，规则升格链由 [`promote-ai-flavor-rule`](../../lifecycle/quality/humanization/skills/promote-ai-flavor-rule/SKILL.md) 承载；父仓专题-09 五技能（定基线 `establish-voice-baseline`、前置预防 `prevent-ai-flavor`、诊断 `diagnose-ai-flavor`、修订 `revise-ai-flavor`、采集 `capture-ai-flavor-cases` + 升格 `promote-ai-flavor-rule`）的先行验证链由本领域承载，共享资产层在 [`humanization/`](../../lifecycle/quality/humanization)，接力铁律与链路登记见 [`muse/lifecycle/flow/chains/`](../../lifecycle/flow/chains/README.md)。v2 进一步把 Canonical 正文画像、载体 scope/mask、regex/handler/density 分层、模态/时间锚点硬门、前置合同的 WriterContext 冻结、案例生命周期和 holdout 激活门落到 agent-example；独立研究到实现的追踪矩阵见 [`muse/lifecycle/quality/humanization/research/20-project-skill-coverage.yaml`](../../lifecycle/quality/humanization/research/20-project-skill-coverage.yaml)。
|
||
|
||
## 4. 失败分类
|
||
|
||
安全报告至少区分五类（这是合同）：
|
||
|
||
- `execution_invalid`：调用、schema、hash、raw、预算、运行状态或适配器失败，无法形成质量结论。
|
||
- `quality_failed`：执行有效，但候选存在明确质量问题或硬约束残留。
|
||
- `insufficient_evidence`：样本或场景不足，不能形成方向结论。
|
||
- `no_gain`：执行有效且质量合格，但新策略没有证明增益。
|
||
- `passed`：满足对应质量或实验合同。
|
||
|
||
> 实现现状标注（诚实保留，不强改）：当前以四类终态承载——`passed` / `failed` / `insufficient_evidence` / `no_gain`，失败原因靠原因码表达。合同里的 `execution_invalid` 与 `quality_failed` 在实现中合并落 `failed`，靠原因码区分；这两类从合同五类到实现四类的精确映射待对齐。
|
||
|
||
运行器失败可以使 Gate 失败关闭，但报告必须保留失败类别与原因码，不能让用户把基础设施故障误解为正文不合格。
|
||
|
||
## 5. 库内证据
|
||
|
||
审核、实验、运行证据一律落库，并绑定它所评价的正文或候选哈希：
|
||
|
||
- 审核记录（reviews）：候选与章节的质量摘要、问题、修复与复验结论，落库并绑候选哈希。
|
||
- 实验记录（experiments）：baseline、假设、干预、预期、到期与结论，落库并绑被验证的正文或候选哈希。
|
||
- 运行回执（runs）：安全执行回执、预算账本与 raw 指针，落库；完整 Prompt/Response、供应商原始响应等 raw 进单独表、可看全文（访问控制见索引 §8）。
|
||
- 用户决策与正式状态：接受、合并、丢弃及其依据，落库。
|
||
|
||
正文发生变化后，旧审核不能继续作为接受依据——哈希一变，挂在旧哈希上的审核自动失效。
|
||
|
||
> 实现现状标注（诚实保留）：生产链审核证据已落库并绑候选哈希——机械门与语义检测结果随 `persist_writer_execution` 落 `example_quality_result`（`candidate_sha256` 绑定），语义状态另固化到候选行作为接受通道的 DB 兜底。回放评测链的审核报告仍散在 `docs/` 的带日期报告里、不绑哈希，迁库待建。
|
||
|
||
## 6. 经验升格
|
||
|
||
经验升格的规则由本领域独家拥有。范式领域和 Agent 与 Skill 领域只描述各自在这条链上的那一段，并链接回这里。
|
||
|
||
```text
|
||
单次观察
|
||
-> 作品 review/experiment（落库证据）
|
||
-> 重复出现的 lesson/win
|
||
-> 范式 draft/evaluating
|
||
-> active 范式
|
||
-> 稳定 Skill / Tool / Agent 规则
|
||
```
|
||
|
||
这是本领域的设计目标合同。现状：承接物骨架已建——`example_lesson` 登记表（`lesson_registry`）承载 lesson/win 证据（绑 run_id 与候选哈希），状态机 `proposed → reviewing → promoted/rejected` 由 DB 触发器强制：跳过评审的自动升格被拒，`promoted` 必须指明目标类型（pattern/skill/tool）与落点，终态不可再流转。仍未建：证据的自动收集（当前靠人/agent 登记）、升格到范式卡与 Skill 合同的具体变更动作（promoted 之后的落地由各 owner 领域承接）。
|
||
|
||
AI 味案例是“单次观察”的一种证据载体：既有作品反向扫描和创作反馈都先自动落库为 `shadow`，不直接进入范式或生产规则。确认、样例投影和规则消费前必须重验来源哈希与位置锚点；哈希变化、来源不可得或锚点不一致时保留历史证据但 fail-closed。`shadow` 只在本卡/本作品作用域内作为待复核提示；只有跨作品重复、同时有“应修”和“不应修/边界/回归”证据，并完成回放与独立评审，才允许生成规则候选；规则候选仍不是 `active`。`canonical` 也不等于规则生效，`rejected`/`archived` 只保留审计。
|
||
|
||
> 与 02 的同名区分：本节“升格”指经验沿上面这条链从一次观察长成可复用的范式/Skill/Tool。[02-实体领域](02-实体领域.md) 里的“作品面实体入库（也叫升格）”指拆书抽出的实体进入某部作品的正式事实库。两者只是都叫“升格”，对象、链路与 owner 都不同，引用时注意区分。
|
||
|
||
升格原则：
|
||
|
||
- 同类问题第 3 次复发，停止逐次修补，评估是否固化为检查项或 Skill。
|
||
- 单作品证据默认只能产生作品级范式。
|
||
- 跨作品规则变更必须做影响复核。
|
||
- 每项优化必须写明可证伪假设、观察窗口和替代解释。
|
||
- 可机械判断的经验优先固化为工具，不长期堆进 Prompt。
|
||
- 已被 Skill/Tool 完整拥有的执行步骤，范式和 lessons 只保留原理、证据与链接。
|
||
|
||
## 7. Gate A/B 边界
|
||
|
||
- Gate A 只验证离线评测链可运行，不能宣布正文层通过。
|
||
- Gate B 才对跨作品样本做正文能力和策略增益裁决。
|
||
- Gate A/B 是开发验收，不是正常用户写一章的线上质量流程。
|
||
- 离线 raw、标准答案和候选进库（单独表 + 访问控制），不要求留仓外。
|
||
- **COMPLETED 判据（轮次封存）**：一轮评测完成，必须核对“本轮声明要产出的 raw 集合”与“实际落库集合”一致才置完成；“有行落库了”不是判据——一道不可能失败的门不是门。
|
||
- **代价明账**：评测证据与生产共享同一数据库信任根，是单用户场景的刻意取舍——换可观测性与防篡改，放弃证据底座独立性 / 外部可审计性。这是明账，不是纯收益。
|
||
- **常设不变量**（从预防迁到发现）：没有评测质量结果出现在任何生产视图、没有正式正文来源能追溯到评测候选——持续跑、违反即报警。（harness 改造原则，见 [docs/2026-08-01-评测harness改造设计](../../../docs/2026-08-01-评测harness改造设计.md)）
|
||
|
||
现有实现承认（各一句，不展开）：预算账本合同与运行探针锁定由 [`access-database`](../../authority/evidence/skills/access-database/SKILL.md) 与 `record-run-evidence` 承载，Gate B 通过回执的哈希链由 [`decide-candidate`](../../content/work/skills/sovereignty/decide-candidate/SKILL.md) 承载。
|
||
|
||
> 实现现状标注（诚实保留）：当前只有一个作品且评测样本已预注册，Gate B 因此恒判 `insufficient_evidence`（跨作品样本不足）——这是目标态下的正确行为，不是 bug。
|
||
|
||
## 8. 可恢复性
|
||
|
||
可恢复性不在本领域定义，见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)：质量证据与运行回执既然全部落库，可恢复性就跟随数据库备份、快照或可重建脚本，加上 Git 里的代码与 DDL 从零重建库结构。本领域不再单独主张“本地完备”。
|
||
|
||
## 9. 待建
|
||
|
||
- 经验升格链后半段：`example_lesson` 登记与状态机已建（见 §6），promoted 之后到范式卡/Skill 合同的具体变更动作、证据自动收集未建。
|
||
- 评测链审核证据落库绑哈希：生产链审核证据（机械门 + 语义报告）已随 `example_quality_result` 绑候选哈希落库；回放评测的审核报告仍在 `docs/` 日期报告里，迁库绑哈希待建。
|
||
- eval 收敛环脚本：把评分、失败分类与升格触发串成可机械复跑的闭环。
|
||
|
||
## 10. 验收条件
|
||
|
||
1. 机械失败、运行失败和内容质量失败可以由原因码明确区分，脚本能从报告里读出类别。
|
||
2. 修改后的候选一定重新检查并绑定新 hash；旧 hash 上的审核对当前正文不再有效。AI 味案例在确认、样例投影或规则消费前必须有 `verified` 重验证回执。
|
||
3. 每个 active 范式或稳定规则都有可追溯到库内记录（含哈希）的证据。
|
||
4. 同一章用两套不同场景策略打分时，通用底层指标的分差能被脚本读出并比较；场景策略只改场景权重，不改四个通用维度的定义。
|
||
5. 任一审核、实验或运行回执，都能用库内一条记录定位到它所评价的正文或候选哈希。
|
||
|
||
## 11. 关联 SoT
|
||
|
||
- 数据权威、落库合同、raw 边界与可恢复性：[索引](./_index.md) §2/§3/§4/§8，细则见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)
|
||
- 范式生命周期：[03-范式领域](03-范式领域.md)
|
||
- 实体入库“升格”（与本文经验升格不同义）：[02-实体领域](02-实体领域.md)
|
||
- Agent/Skill 升格：[07-Agent与Skill领域](07-Agent与Skill领域.md)
|
||
- 离线 Gate 上级合同：[专题-04](../../../../design-docs/专题-04-生成质量门控与创作健康度设计方案.md)
|