# 范式领域 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_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`。升格必须说明样本范围、场景选择偏差和替代解释。 现有实现锚点:公共范式卡由 `parse-book` 窗级聚类出卡,经 `review-cards` 三角色审核(番茄作家 / 起点作家 / 主编)判 pass / revise / reject 后写回卡里,再由用户确认落为正式内容。 ## 5. 消费合同 - 范式按意图、场景、适用范围选择,不能临场把整个范式库倾倒给 writer。 - 注入 writer 的是有尺寸上限的写法摘要(名称、一句话摘要、写法要点),不是库行全文。来源指针另留在冻结上下文里供审计回读。 - **尺寸上限(现有实现,合同侧失败关闭)**:`name ≤ 40` 字、`summary ≤ 120` 字、`writingPoints ≤ 6` 条且每条 `≤ 200` 字;召回每型取 top-2、单次总量 ≤ 12 张。超量内容在合同侧直接拒收,无论检索端将来怎么换,超量都进不了 writer 输入。 - 范式冲突时按作品明确绑定、适用范围、证据等级和版本顺序处理;无法确定时省略,不随机拼接。 - 范式只影响“怎么写”,不能覆盖作品和实体的正式事实。 > **消费方式待对齐**:设计目标是“规划期选定并绑定范式,写作期只消费已绑定范式”;现状是“写作期按本章意图实时有界召回”。两者尚未对齐,规划期绑定待建。 实验臂现状:Gate A 用 A/B/C 三臂,A 臂恒空(纯历史原文对照),B/C 臂拿候选范式卡;分臂规则收敛在 writer 合同一处,保证“有无范式卡”这个单变量不被破坏。 ## 6. 范式在经验升格中的位置 范式是经验升格的中转站:作品里反复出现的稳定观察,先进入范式验证,达到可复用标准后,再升格为 Skill、确定性工具或 Agent 规则。**完整升格规则和判据由质量与复利领域独家拥有**,见 [06-质量与复利领域 §6](06-质量与复利领域.md)。本节只说范式这一段: - 升格一旦发生,范式卡只保留原理、适用边界和证据,具体执行步骤链接到接手它的 Skill 或 Tool,不再自己留一份。 - 只适用于单书的经验留在作品级(非零 `work_id`),不得污染公共层(`work_id = 0`)。 > **两个“升格”不同义**:本节的“经验升格”指写法经验从范式提炼为 Skill / Tool / Agent 规则,对象是**方法**。02 实体领域里的“升格”指参考书或正文产生的实体草稿经用户确认成为作品正式事实,对象是**作品面实体入库**,见 [02-实体领域](02-实体领域.md)。两者对象不同,不要混用。 ## 7. 检索与召回 范式的选择靠库内检索:按型别、适用范围、场景和意图从库里过滤候选;库内检索加速(pgvector 向量索引)只负责提高召回速度,不是独立权威,可从库重建。任何命中都必须回读库行并校验内容哈希后才能采用。 - 检索加速失败只影响速度,不改变范式状态语义、不跳过审核。 - 只读看板查库渲染范式,绝不写库;接受、丢弃等写操作仍由 `confirm` skill 和主会话走。 - 可恢复性(库备份、快照、可重建脚本)见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)。 ## 8. 验收条件 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. 待建 - 五态生命周期(`evaluating` / `active` / `retired`)的机械判据。 - scope 的 category(品类)层:现状只有公共 / 作品两层,品类层为目标。 - 规划期绑定:现状是写作期实时有界召回,待与设计目标对齐。 ## 10. 关联 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) - 知识消费上级合同:[专题-07](../../../../../design-docs/专题-07-知识消费契约与质量闭环.md)