zizi b0bc7a8745 框架: 技能按动作-对象重组 + 先审后入创作闭环
一、技能重组(动作-对象命名)
- 旧目录 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)按"框架与创作分开"未入本提交。
2026-08-14 10:24:08 +08:00

10 KiB
Raw Blame History

name, description
name description
design-story-foundation 在正式规划前固化作品根设定,并按前三章、前十章、前五十章的追读节奏生成可比较的前期设计候选。用户仍在单文档前期设计阶段时使用;不写正文、不落库、不替用户定稿。

作品设定初始化

唯一目的

本 Skill 服务主会话,负责作品正式规划前的候选设计。它把零散对话收束成一份根设定和若干独立候选,让用户先比较故事吸引力、阶段节奏和设定兑现方式,再决定哪一案进入 plan-story。

本 Skill 不负责完整设定包、卷纲、逐章细纲或正文。用户没有选定方案时,不得抢跑到正式规划,也不得把任何候选写进 PostgreSQL。

元数据驱动:输入与权威顺序

每次执行先冻结一份 design-story-foundation/v1 任务包,至少包含:

  1. 作品名、前期设计 SoT 路径和本轮候选数量。
  2. 根设定全文,以及尚未解决的冲突和问题。
  3. 与本书有关的完整用户对话记录及决策状态。
  4. 前三章、前十章、前五十章和全书阶段的节奏要求。
  5. 参考书证据、禁止照搬项、候选目录、编号号段和篇幅门槛。
  6. 每个候选的唯一编号与输出路径;除此之外,各子代理输入完全相同。

冲突时按“用户最新明确要求 > 根设定中的已定事实 > 用户已接受方案 > 待定建议”处理。AI 自己说过但用户未接受的方案不能升格为根设定。

任务包的字段、状态和示例见 候选生成合同。冻结后再派发;执行期间收到的新要求先更新任务包,旧候选随即失效,不允许边生成边暗改口径。

本阶段产物不属于 23 型正式作品结构,字段权威就是 design-story-foundation/v1 候选合同。用户选定方案后,plan-story 才按 meta/schemas/ 把内容转换成正式 Shadow 规划。

根设定合同

前期设计 SoT 的第一章固定为“根设定”。这里只放作品自身的稳定事实和叙事硬约束,包括标题承诺、主角前提、能力边界、成长台阶、披露节奏、正文表达要求和不能触碰的内容。

  • 不写设计过程、代理分工、提示词、工具、候选比较或方案来源。
  • 每个点只写一句完整话,连同标签控制在 30—60 个可见字符。
  • 根设定内部最多两级结构;能用一组平铺条目说清时不继续拆章。
  • 用户原话含歧义时保留到“待决问题”,不能擅自补成作品事实。
  • 每次用户修正先更新根设定,再判断哪些候选必须作废重做。

根设定只回答“这部作品必须是什么样”。候选如何产生、谁来产生、生成几份,属于本 Skill,不得回写根设定。

先定节奏,再铺设定

设定必须从追读节奏反推。先回答各阶段读者为什么翻下一章,再设计能支撑这些事件的能力、资源、人物和世界规则。

阶段 必须完成 允许披露
前三章 立住处境、近期目标、首个可验证优势和连续钩子 只给当前行动所需规则;终局答案与最终敌方不得提前明牌
前十章 完成一次局部闭环,验证能力边界、代价和主要关系 展开当前舞台规则,留下能自然抬高舞台的问题
前五十章 完成初期主冲突与阶段高潮,让主角获得下一阶段资格 回收早期承诺,引入中期入口;不能把全书核心一次讲尽
全书阶段 逐级扩大个人、组织、战争与文明尺度 每次只揭开下一阶段必需的一层真相,并保留后续问题

每项关键设定都要同时写清“作者掌握的总设定”和“读者在各阶段看到什么”。终局真相可以在作者侧完整存在,正文披露点必须服从根设定,不能因为候选写得完整就在前三章泄底。

参考书证据

用户指定参考作品时,先读该书当前库内全部 example_parse_outline 窗级大纲,再用前五十章正文校验开局落地。报告必须分开标注:

  • 大纲明确写出的全书阶段线。
  • 前五十章正文能够直接支持的开局结论。
  • 可借鉴的结构方法、节奏方法和信息披露方法。
  • 不得照搬的专名、人物关系、能力、组织和剧情阶梯。

未读完窗级大纲时,不得把前五十章印象写成全书核心。参考书只提供方法证据,不替用户决定本书设定。

冻结候选合同

派发前由主会话一次性冻结候选结构,所有候选使用完全相同的二级标题、顺序和编号号段。结构冻结后,子代理不得自行增删章节或改号段。

  • 每章按内容写 10—50 项设定,不固定写 10 项,也不为凑上限拆碎同一规则。
  • 每份候选不少于 100 项设定;当前任务另有字数要求时同时执行,未明说时不得私自降低已冻结门槛。
  • 当前长篇设定候选的默认有效字符下限为 50000;用户明确修改时以任务包为准。
  • 每项使用唯一 S 编号,编号必须落在本章预留号段内,且在全文中递增、不重复。
  • 候选只能用被冻结的两级目录;具体机制、例子和剧情用途写在设定项正文里。

同构只用于比较,不要求五份候选得出相同答案。每份方案必须有自己的故事发动机、阶段冲突、能力成本、关系推进和舞台扩张路径。

独立生成

每个候选交给一个独立 Claude Code 规划子代理。主会话将 planner 身份、本 Skill、冻结任务包和指定输出路径内联给它;模型遵守项目的 planner 配置,不静默换型。

  1. 每个子代理只负责一份候选,只能读取共同输入和自己的工作文件。
  2. 候选之间不共享草稿、提纲、评价和中间结论;文件隔离由工作目录或沙箱保证,不能只靠提示词提醒。
  3. 长文按冻结目录逐章续写,同一候选沿用自己的设计账本;续跑仍不能读取兄弟候选。
  4. 子代理先在内部检查设定咬合,再落完整条目;主会话不替它补创意,只做编排和机械验证。
  5. 任一候选未达到合同,不得先拿已完成候选做综合,避免后写方案被前案污染。

受控 Claude 调用遵守 execute-claude-task 的 fresh process、沙箱、期限和模型要求,并由 record-run-evidence 保存回执。模型超时或截断时保留该候选已完成的合法章节,从最后一个完整设定项继续;禁止用空话补足字数。

去 AI 味与语义复核

候选完成后单独做表达层复核。可用 humanizer-zh 时按其合同处理;没有该能力时,至少检查宣传腔、空泛升华、假对照、整齐三段式、连续同句型、模糊归因和高频套话。

去 AI 味只改表达,不得改根设定、数值、编号、章节、阶段披露点和因果。处理后必须重新跑机械门,并做一次语义复核:

  • 根设定是否全部兑现,是否暗加用户未授权的硬设定。
  • 前三章、前十章、前五十章是否各有目标、兑现、代价和新问题。
  • 作者总设定与读者阶段认知是否分开,是否提前泄露终局答案。
  • 能力、资源、等级、敌人和组织是否互相咬合,有无无成本万能解。
  • 设定能否通过事件、差异和后果呈现,是否只能靠旁白说明。
  • 参考作品是否只借了方法,是否换名照搬了专属骨架。

机械门

从 agent-example/ 运行:

.venv/bin/python .claude/skills/design-story-foundation/scripts/validate_candidates.py \
  --root-doc docs/design/<作品>-前期设计.md \
  --min-candidates 5 --min-chars 50000 \
  docs/design/candidates/*.md

校验器检查根设定句长和结构、候选目录一致性、号段、编号唯一性、每章 10—50 项、总项数、有效字符数和占位符。任一文件失败,整组状态为 SETTING_INIT_VALIDATION_FAILED,不得声称候选齐备。

用户选择与交接

全部候选通过后,向用户提交比较报告,不自动合并。每份方案说明开局吸引力、十章兑现、五十章高潮、长线扩张、主要代价和最可能失速的位置;选项必须说明会怎样改变后续故事。

只有用户明确选择或给出修改方向后,才开始收敛。用户可以直接指定主案,也可以要求把多份候选逐章统合;后一种方式必须遵守 串行统合合同,不能一次性把所有章节交给同一代理拼接。

逐章统合时,每一章使用一个 fresh 高推理代理。第一个代理只比较五份候选的第一章;主会话审定并写入统合候选后,第二个代理必须读取最新统合前文,再比较五份候选的第二章。此后依次推进,权威顺序固定为“最新根设定 > 已统合前文 > 当前五份来源章节”。后章不得推翻前章已经确定的因果、人物关系、数值、专名和披露节点。

统合代理负责筛选、识别冲突和提出当前章草案,主会话负责消歧、定名、补齐根设定和最终落文档。不能按票数机械取多数,也不能把五案互斥的发动机全部叠加。每章落盘后先检查结构与语义,再生成下一章任务包;失败时停在当前章,不得让后续代理基于未审定草案继续。

统合完成后仍是待选候选,不自动进入唯一前期设计 SoT。用户确认统合方向后,才把内容整理回 SoT;其余候选删除,由 Git 历史追溯。用户明确说“前期设计定稿”后,才把选定方案交给 plan-story,按正式 schema 生成 Shadow 规划。

数据与失败边界

  • 允许读取:用户点名的前期设计文档、对话记录、参考书窗级大纲与授权正文范围。
  • 允许写入:唯一前期设计 SoT 和其临时候选目录;不得修改正文、正式规划、知识卡或状态。
  • 数据库:不读不写任何表;这些文件是产品链之外的用户协作草稿,在系统视角中不是正式内容。
  • Git:不执行 add、commit 或删除候选,除非用户对相应动作另行明确授权。

缺根设定、对话冲突未标出、参考范围不完整、候选之间发生污染或机械门失败时,返回稳定失败码并停在候选阶段:SETTING_INIT_INPUT_INCOMPLETE、SETTING_INIT_CONTRACT_DRIFT、SETTING_INIT_CANDIDATE_CONTAMINATED 或 SETTING_INIT_VALIDATION_FAILED。不得用部分结果冒充完成。