一、技能重组(动作-对象命名) - 旧目录 clean/confirm/continuation/db/detect/embed/… 重组为 clean-book-text/decide-candidate/write-next-chapter/access-database/ check-content-consistency/embed-knowledge/…(git 识别为 rename,内容保持) - agents/*.md、AGENTS.md/CLAUDE.md 收编、example_skill 登记表同步新名 二、先审后入创作闭环(本次核心) 正文接受从"机械门一过就写正典"改为"机械门+语义审查双通过+用户批准+单事务原子提交", DB 级兜底,编排层跳步即被硬拒。 - candidate_cas.py + example_candidate_cas(109):持久化 CAS 状态链 - fact_delta.py + example_fact_delta/example_fact_ledger(106):结构化事实增量, 模型只提六型闭集增量+正文证据引文,仅用户批准的增量随正文同事务入账本 - projection_registry.py + example_projection_run(107):投影登记与恢复 - acceptance_state.py:接受前置实时状态重读 - lesson_registry.py + example_lesson(108):经验升格链,禁止自动升格 - DDL 105:example_candidate 增 semantic_status/semantic_report_sha256 - write_canonical.accept:语义兜底+同事务合并增量+登记投影; run_writer_pipeline/persist_writer_run/run_writer_semantic_detector/step2 接入全链 - claude_runtime:兼容新 CLI modelUsage 信息字段 三、审查修复(独立子代理四维审查后) - 事实增量 propose→approve 翻态正道,不撞唯一键 - 冻结配置探针重刷(CLI 2.1.211→2.1.231 漂移),profileSha256/adapterVersion 再登记 - 可视化合同悬空路径/五六空间矛盾、 SoT 旧技能名漂移、行尾空白清理 测试:离线 65 套 + 真实库集成 5 套(CAS/接受故障注入/事实增量/投影/经验升格)+ 回放 79 项全绿。 创作内容(docs/design、生成正文 artifacts)按"框架与创作分开"未入本提交。
146 lines
16 KiB
Markdown
146 lines
16 KiB
Markdown
# 范式领域 SoT
|
||
|
||
## 1. 唯一职责
|
||
|
||
范式领域拥有可复用的写作方法、适用条件、禁用条件、来源证据和验证状态。它回答“什么写法在什么场景下值得参考、证据是什么、是否已经达到可复用标准”。
|
||
|
||
范式不是作品事实。范式可以指导规划和写作,但不能证明某人物、事件或世界规则成立。
|
||
|
||
范式的正式内容(Canonical)权威在 PostgreSQL,不在 Git 文件。Git 只管代码、Skill、`meta/schemas` 和文档;范式卡作为正式内容存在库里,由只读看板查库渲染给人看。一切输入产出必须落库可见,这条硬纪律见 [领域索引 §3](_index.md),本文件不重复定义。
|
||
|
||
## 2. 数据合同
|
||
|
||
范式不再用“目标文件目录”定义,改用数据合同定义:字段权威 = `meta/schemas` 六个范式型 + 库表。
|
||
|
||
- **六个范式型**(由 `meta/schemas` 驱动):`scene_pattern`(通用桥段)、`trope`(套路)、`craft`(技法)、`pacing`(节奏)、`emotion`(情感)、`combat`(打斗)。每型的字段、边界判据和 aiContext 控制项由对应 schema 拥有,本文件不复制字段定义,见 [`meta/schemas/`](../../../../meta/schemas/README.md)。
|
||
- **库表**:范式卡是 `muse_knowledge_draft` 表里的行。公共范式 `work_id = 0`,作品级范式 `work_id = 8`(当前实验作品)。型别、名称、摘要、写法要点、适用条件、例证出处等放在 `draft_payload`(JSONB)里,结构对齐 `meta/schemas` 对应型。
|
||
- **scope(适用范围)用库内字段区分**,不再用目录层级:公共 / 作品两层靠 `work_id` + 目标库区分。`work_id = 0` 是公共范式,非零 `work_id` 是某部作品的作品级范式。
|
||
- 范式卡的演进历史靠库内 `revision` 和数据库自身的版本/备份承载,不在卡里另写一份不可校验的历史叙述。
|
||
|
||
## 3. 最小范式合同
|
||
|
||
一张范式卡至少由这些库内字段说清楚:
|
||
|
||
- `work_id`:0 为公共,非 0 为作品级,决定这张卡的适用范围。
|
||
- `draft_type`:范式型,取六个范式型之一。**现状**:库内活卡 `draft_type` 恒为 `entity`、无区分力;型在 `draft_payload` 中文键「型」(公共卡)/ 英文键 `type`(作品卡),见可视化合同 §7;目标合同待对齐。
|
||
- `draft_payload`(JSONB):至少含 `名称`、`一句话摘要`、`标签`、`来源`(手工 / 抽取@第N章 / 拆书@书名),以及该型在 `meta/schemas` 定义的特有字段(如通用桥段的场景类型、目标结构、推进机制、例证出处)。
|
||
- `status`:库内状态字段。现状取值是“待确认 → 确认 / 丢弃”,见第 4 节。
|
||
- `confidence`:可信度,供召回排序参考,不单独决定卡是否成立。
|
||
- `source_type` / `source_id`:来源回指,能追到拆书原文、抽取章节或作品证据。
|
||
|
||
`draft_payload` 的人可读部分必须至少说明:要解决的问题、适用条件、不适用或容易误用的条件、可操作写法、预期效果和可观察信号、来源与验证证据。例证出处只记书名 + 回目 + 一句话定位,严禁抄录原文;原书全文按 raw 规则进库,见 [领域索引 §8](_index.md)。
|
||
|
||
## 4. 生命周期
|
||
|
||
设计目标合同是五态:
|
||
|
||
```text
|
||
observation -> draft -> evaluating -> active -> retired
|
||
```
|
||
|
||
- `observation`:只留在作品审核、实验或经验记录中,不进入正式范式。
|
||
- `draft`:已形成可操作写法,但证据不足。
|
||
- `evaluating`:已进入预注册实验或跨样本复核。
|
||
- `active`:有可追溯证据,允许被正式上下文选择。
|
||
- `retired`:被证伪、被更高版本替代或适用边界已失效。
|
||
|
||
> **现状标注**:库里现在只有“草稿 / 待确认 → 确认 / 丢弃”这一档,五态生命周期尚未建成。`evaluating`、`active`、`retired` 的机械判据待建。
|
||
|
||
单章、单作品或一次高分不能直接产生公共 `active`。升格必须说明样本范围、场景选择偏差和替代解释。
|
||
|
||
现有实现锚点:公共范式卡由 `deconstruct-book` 窗级聚类出卡,经 `review-knowledge-cards` 三角色审核(番茄作家 / 起点作家 / 主编)判 pass / revise / reject 后写回卡里,再由用户确认落为正式内容。
|
||
|
||
## 5. 消费合同
|
||
|
||
- 范式按意图、场景、适用范围选择,不能临场把整个范式库倾倒给 writer。
|
||
- 注入 writer 的是有尺寸上限的写法摘要(名称、一句话摘要、写法要点),不是库行全文。来源指针另留在冻结上下文里供审计回读。
|
||
- **尺寸上限(现有实现,合同侧失败关闭)**:`name ≤ 40` 字、`summary ≤ 120` 字、`writingPoints ≤ 6` 条且每条 `≤ 200` 字;召回每型取 top-2、单次总量 ≤ 12 张。超量内容在合同侧直接拒收,无论检索端将来怎么换,超量都进不了 writer 输入。
|
||
- 范式冲突时按作品明确绑定、适用范围、证据等级和版本顺序处理;无法确定时省略,不随机拼接。
|
||
- 范式只影响“怎么写”,不能覆盖作品和实体的正式事实。
|
||
|
||
> **消费方式(已决策,见 §6)**:合同态是“规划期选定并绑定范式,写作期只消费已绑定范式”,决策与落库合同见 §6;现状“写作期按本章意图实时有界召回”在绑定合同生效后即为违规路径。范式注入 writer 的尺寸上限与冲突规则仍以本节为准,§6 只补“选哪几张、何时生效、谁来消费”的绑定语义。
|
||
|
||
实验臂现状:Gate A 用 A/B/C 三臂,A 臂恒空(纯历史原文对照),B/C 臂拿候选范式卡;分臂规则收敛在 writer 合同一处,保证“有无范式卡”这个单变量不被破坏。
|
||
|
||
## 6. 设计决策:规划期绑定
|
||
|
||
**背景**:范式的正路是“规划期决策、写作期引用”——规划产出显式挂所引范式的引用,写作期只按引用注入、不重新检索范式,上级合同见 [专题-07 §2](../../../../../design-docs/专题-07-知识消费契约与质量闭环.md)。本领域 §5 消费合同的目标态与此一致,但现状是写作期按本章意图实时有界召回,两者未对齐;同时 [01-作品领域 §3](01-作品领域.md) 已在作品行字段合同声明 `pattern_bindings`(绑定的范式范围或明确 ID),真实库表 `muse_content_work` 却无承载列。这两处缺口由本决策一并收口为明确合同。
|
||
|
||
**选项**:
|
||
|
||
| 选项 | 做法 | 取舍 |
|
||
|---|---|---|
|
||
| A 写作期实时召回(现状) | 每章按意图对公共范式库有界召回 | 选择不可追溯、不可复现,无法形成“规划决策→写作引用”链;与专题-07 验收 3 直接冲突 |
|
||
| B 规划期绑定 + 写作期只读引用 | `select_patterns` 规划期选定 → Shadow → 用户确认 → 写 `pattern_bindings` → 写作期只消费已绑定 | 选择由用户决策、落库可追溯、注入可复现;代价是绑定须有库表承载位与确认门禁 |
|
||
| C 写作期海选 + 事后登记 | 写作期向量海选,选中后再补登记 | 登记滞后于消费,单变量与可复现性同样被破坏,只是 B 的劣化版 |
|
||
|
||
**结论**:采用 B。合同如下。
|
||
|
||
1. **绑定对象与形态**:`pattern_bindings` 承载本作已确认绑定的范式引用集合,每条绑定 = 范式卡库内 `sourceId` + 选定时的版本 / 内容哈希快照。绑定可指公共范式卡(`work_id = 0`,已确认 / `active` 态),也可指作品级范式(非零 `work_id`)。哈希快照冻结绑定语义:范式卡后续被修订不静默改变已绑定内容,是否换绑由用户重新决策。
|
||
|
||
2. **SoT↔库不一致与补齐方向**:`pattern_bindings` 已是作品行 SoT 合同字段([01-作品领域 §3](01-作品领域.md)),但 `muse_content_work` 尚无承载列——这是 SoT 先于库的债。本领域只定范式侧语义;库表承载位与落库机制归 [01-作品领域](01-作品领域.md) 与 [08-数据权威与可视化领域](08-数据权威与可视化领域.md),不在此写 DDL。补齐方向:在作品行增结构化承载位,存已确认绑定的范式引用集合;承载位建成前,绑定事实必须有临时落库位,不得只活在内存或文件,否则违反“一切落库”横切合同([领域索引 §3](_index.md))。
|
||
- **实验仓落地承载**(遵循 `db/ddl` 「主仓表原样不改列、实验扩展进 example_*」口径):承载位 = 最新一条已确认 assembly 规划行(`example_planning_section`,`section_type=assembly`,`state=confirmed`)的 `patternReferences`;确认 assembly 即激活绑定,不另改 `muse_content_work`。消费侧由 assemble-context `load_confirmed_pattern_bindings` 只读该已确认绑定(写作期不临场召回)。作品行 `pattern_bindings` 列仍是主仓生产承载方向(归 01/08),届时实验仓承载收敛回作品行。
|
||
|
||
3. **生效时机(Shadow→confirmed)**:规划期 `select_patterns` 从公共范式卡选定本作范式,选择先落 Shadow(规划候选);经用户确认翻 confirmed 后才写入 `pattern_bindings`、才可进生成上下文(横切总闸见 [架构-02](../../../../../design-docs/架构-02-核心数据结构与双轨模型.md))。未经确认的 Shadow 选择不是绑定,不得被写作期消费。
|
||
|
||
4. **assembly 落点与 knowledgeBindings 填充**:assembly 装配本次写作上下文时,其范式绑定项(`knowledgeBindings` 的范式部分)只从该作品 confirmed 的 `pattern_bindings` 派生——按引用回读冻结范式卡、回读验哈希,再按 §5 尺寸上限裁成注入视图;不从全库临场召回。选择、冻结、裁剪、投影的机制归 [04-上下文领域](04-上下文领域.md),本领域只约束“范式这一路只认已绑定引用”。
|
||
|
||
5. **消费合同(写作期只读引用)**:assemble / writer 只消费 `pattern_bindings` 里 confirmed 绑定的范式;写作期对公共范式库做相似度临场海选的链路判违规(对齐 [专题-07 §7 验收 3](../../../../../design-docs/专题-07-知识消费契约与质量闭环.md))。范式冲突仍按 §5 既有规则(作品明确绑定优先、无法确定则省略,不随机拼接)。
|
||
|
||
6. **与评测 A/B/C 臂的关系**:生产绑定走作品行 `pattern_bindings`;评测 A/B/C 臂的分臂规则仍收敛在 writer 合同一处(开发评测边界见 [05-创作流程领域 §7](05-创作流程领域.md)),A 臂恒空、B/C 臂注入评测侧独立冻结的同一组范式卡。两条注入路径分立:评测臂不读作品行 `pattern_bindings`,生产绑定也不改写评测臂的冻结卡集——保证“有无范式卡 / 哪组范式卡”这个单变量不被生产绑定污染。
|
||
|
||
**后果**:
|
||
|
||
- 范式选择从“写作期黑盒召回”变为“规划期用户决策 + 落库可追溯”,规划产出携带引用链,写作任务可回指该绑定。
|
||
- 新增两条机械门禁:①写作期任一注入 writer 的范式必须能回指 `pattern_bindings` 一条 confirmed 绑定,无绑定来源失败关闭;②`select_patterns` 的 Shadow 选择在用户确认前不出现在 `pattern_bindings`、不进生成上下文。
|
||
- 产生一项对作品领域的依赖:`muse_content_work` 需补 `pattern_bindings` 承载位(见结论 2);承载位建成前绑定只能走临时落库位,属过渡通道,不是合同形态。
|
||
- 现状写作期实时有界召回在绑定合同生效后即为违规路径,须收敛为“只读已绑定”。
|
||
|
||
## 7. 范式在经验升格中的位置
|
||
|
||
范式是经验升格的中转站:作品里反复出现的稳定观察,先进入范式验证,达到可复用标准后,再升格为 Skill、确定性工具或 Agent 规则。**完整升格规则和判据由质量与复利领域独家拥有**,见 [06-质量与复利领域 §6](06-质量与复利领域.md)。本节只说范式这一段:
|
||
|
||
- 升格一旦发生,范式卡只保留原理、适用边界和证据,具体执行步骤链接到接手它的 Skill 或 Tool,不再自己留一份。
|
||
- 只适用于单书的经验留在作品级(非零 `work_id`),不得污染公共层(`work_id = 0`)。
|
||
|
||
> **两个“升格”不同义**:本节的“经验升格”指写法经验从范式提炼为 Skill / Tool / Agent 规则,对象是**方法**。02 实体领域里的“升格”指参考书或正文产生的实体草稿经用户确认成为作品正式事实,对象是**作品面实体入库**,见 [02-实体领域](02-实体领域.md)。两者对象不同,不要混用。
|
||
|
||
## 8. 检索与召回
|
||
|
||
范式的选择靠库内检索:按型别、适用范围、场景和意图从库里过滤候选;库内检索加速(pgvector 向量索引)只负责提高召回速度,不是独立权威,可从库重建。任何命中都必须回读库行并校验内容哈希后才能采用。
|
||
|
||
- 检索加速失败只影响速度,不改变范式状态语义、不跳过审核。
|
||
- 只读看板查库渲染范式,绝不写库;接受、丢弃等写操作仍由 `decide-candidate` Skill 和主会话走。
|
||
- 可恢复性(库备份、快照、可重建脚本)见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)。
|
||
|
||
## 9. 验收条件
|
||
|
||
1. 每张 `active`(或现状下已确认)范式卡都能从 `draft_payload` 回到来源(拆书书名 + 回目,或作品证据)。
|
||
2. 公共范式行的 `work_id = 0`,作品级范式行的 `work_id` 非 0;单作品观察不会被写成 `work_id = 0`。
|
||
3. 任一注入 writer 的范式摘要可机械校验:`name ≤ 40` 字、`summary ≤ 120` 字、`writingPoints ≤ 6` 条且每条 `≤ 200` 字;超量在合同侧失败关闭。
|
||
4. 单次召回每型 ≤ 2 张、总量 ≤ 12 张,可机械读出。
|
||
5. 检索加速命中后必回读库行并验哈希;哈希不符的命中不被采用。
|
||
6. 范式卡只影响“怎么写”,上下文里的作品事实和实体事实不被范式覆盖。
|
||
7. 范式升格为 Skill/Tool 后,卡里不存在第二份执行步骤,只有链接。
|
||
8. 只读看板对范式只查不写。
|
||
9. 规划期绑定(§6)可机械校验:写作期任一注入 writer 的范式都能回指作品行 `pattern_bindings` 一条 confirmed 绑定,无绑定来源失败关闭;`select_patterns` 的 Shadow 选择在用户确认前不出现在 `pattern_bindings`、不进生成上下文。
|
||
|
||
## 10. 待建
|
||
|
||
- 五态生命周期(`evaluating` / `active` / `retired`)的机械判据。
|
||
- scope 的 category(品类)层:现状只有公共 / 作品两层,品类层为目标。
|
||
- 规划期绑定的合同已定(见 §6);消费侧取数端(assemble-context `load_confirmed_pattern_bindings`)与生产编排接线已建(实验仓以已确认 assembly 行承载)。剩余待建只是落地:`muse_content_work` 的 `pattern_bindings` 承载列(库表承载归 [01-作品领域](01-作品领域.md),届时实验仓承载收敛回作品行)、绑定确认门禁、写作期范式须可回指 confirmed 绑定的机械门禁(尚未强制)。
|
||
|
||
## 11. 关联 SoT
|
||
|
||
- 数据权威与落库硬纪律:[领域索引](_index.md)
|
||
- 质量与经验升格规则:[06-质量与复利领域](06-质量与复利领域.md)
|
||
- 实体入库(另一种“升格”):[02-实体领域](02-实体领域.md)
|
||
- Skill 边界:[07-Agent与Skill领域](07-Agent与Skill领域.md)
|
||
- 数据权威与可恢复性:[08-数据权威与可视化领域](08-数据权威与可视化领域.md)
|
||
- 类型结构:[`meta/schemas/`](../../../../meta/schemas/README.md)
|
||
- 作品行 `pattern_bindings` 字段合同与库表承载:[01-作品领域](01-作品领域.md)
|
||
- 装配的选择 / 冻结 / 裁剪 / 投影机制:[04-上下文领域](04-上下文领域.md)
|
||
- 开发评测边界与 A/B/C 臂:[05-创作流程领域](05-创作流程领域.md)
|
||
- 知识消费上级合同(规划期决策、写作期引用):[专题-07](../../../../../design-docs/专题-07-知识消费契约与质量闭环.md)
|