63a65ae9ff
- 新增 docs/2026-07-30 落库与看板设计稿：97-102 表设计(含 102 智能体/技能登记表 A 方案)、写路径、raw 合同、实施顺序 - 可视化合同 §10 重写为领域布局菜单树(五空间+作品工作区+章工作区+跨空间互联+数据来源标注+分阶段点亮) - 清理'不启用 96'残留：合同§9、02/04/08 领域、落库稿统一改为不启用/以 reference_work 为准 - 03 范式补 draft_type 现状标注；_index §4 零依赖口径对齐合同；08 §9/§10 状态收敛
8.8 KiB
范式领域 SoT
1. 唯一职责
范式领域拥有可复用的写作方法、适用条件、禁用条件、来源证据和验证状态。它回答“什么写法在什么场景下值得参考、证据是什么、是否已经达到可复用标准”。
范式不是作品事实。范式可以指导规划和写作，但不能证明某人物、事件或世界规则成立。
范式的正式内容（Canonical）权威在 PostgreSQL，不在 Git 文件。Git 只管代码、Skill、meta/schemas 和文档；范式卡作为正式内容存在库里，由只读看板查库渲染给人看。一切输入产出必须落库可见，这条硬纪律见 领域索引 §3，本文件不重复定义。
2. 数据合同
范式不再用“目标文件目录”定义，改用数据合同定义：字段权威 = meta/schemas 六个范式型 + 库表。
- 六个范式型（由
meta/schemas驱动）：scene_pattern（通用桥段）、trope（套路）、craft（技法）、pacing（节奏）、emotion（情感）、combat（打斗）。每型的字段、边界判据和 aiContext 控制项由对应 schema 拥有，本文件不复制字段定义，见meta/schemas/。 - 库表：范式卡是
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。
4. 生命周期
设计目标合同是五态：
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。本节只说范式这一段：
- 升格一旦发生，范式卡只保留原理、适用边界和证据，具体执行步骤链接到接手它的 Skill 或 Tool，不再自己留一份。
- 只适用于单书的经验留在作品级（非零
work_id），不得污染公共层（work_id = 0）。
两个“升格”不同义：本节的“经验升格”指写法经验从范式提炼为 Skill / Tool / Agent 规则，对象是方法。02 实体领域里的“升格”指参考书或正文产生的实体草稿经用户确认成为作品正式事实，对象是作品面实体入库，见 02-实体领域。两者对象不同，不要混用。
7. 检索与召回
范式的选择靠库内检索：按型别、适用范围、场景和意图从库里过滤候选；库内检索加速（pgvector 向量索引）只负责提高召回速度，不是独立权威，可从库重建。任何命中都必须回读库行并校验内容哈希后才能采用。
- 检索加速失败只影响速度，不改变范式状态语义、不跳过审核。
- 只读看板查库渲染范式，绝不写库；接受、丢弃等写操作仍由
confirmskill 和主会话走。 - 可恢复性（库备份、快照、可重建脚本）见 08-数据权威与可视化领域。
8. 验收条件
- 每张
active（或现状下已确认）范式卡都能从draft_payload回到来源（拆书书名 + 回目，或作品证据）。 - 公共范式行的
work_id = 0，作品级范式行的work_id非 0；单作品观察不会被写成work_id = 0。 - 任一注入 writer 的范式摘要可机械校验：
name ≤ 40字、summary ≤ 120字、writingPoints ≤ 6条且每条≤ 200字；超量在合同侧失败关闭。 - 单次召回每型 ≤ 2 张、总量 ≤ 12 张，可机械读出。
- 检索加速命中后必回读库行并验哈希；哈希不符的命中不被采用。
- 范式卡只影响“怎么写”，上下文里的作品事实和实体事实不被范式覆盖。
- 范式升格为 Skill/Tool 后，卡里不存在第二份执行步骤，只有链接。
- 只读看板对范式只查不写。
9. 待建
- 五态生命周期（
evaluating/active/retired）的机械判据。 - scope 的 category（品类）层：现状只有公共 / 作品两层，品类层为目标。
- 规划期绑定：现状是写作期实时有界召回，待与设计目标对齐。
10. 关联 SoT
- 数据权威与落库硬纪律：领域索引
- 质量与经验升格规则：06-质量与复利领域
- 实体入库（另一种“升格”）：02-实体领域
- Skill 边界：07-Agent与Skill领域
- 数据权威与可恢复性：08-数据权威与可视化领域
- 类型结构：
meta/schemas/ - 知识消费上级合同：专题-07