muse-agent-example/docs/2026-07-13-M3清洗拆书执行计划.md
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

5.4 KiB
Raw Blame History

M3 清洗+拆书执行计划(2026-07-13,待创始人批准后开工)

版本 v1 | 读者:创始人 | 边界:只覆盖「全语料清洗 + 试拆管线 M3 化」,不含 B2 放量拆书(已拍:先不批量拆)

一、拍板回执(本计划的前提)

拍板项 结论
清洗/拆书的内容生产 LLM 全部改为 New-API 的 MiniMax-M3 直调(已验通:模型在列、JSON 输出干净)
Fable5(主会话)角色 只做四件事:固化 agent/提示词、写 skill、发起调用、守卫验证与呈报——不亲自生产内容
密钥 New-API token 明文写入 skill 脚本(仓库政策允许)
清洗范围 所有书(8 本 ≈3,300 万字)
清洗结果 删除落库前必须创始人质检样张
拆书 先不批量拆;试拆改用 M3 重做,opus 已产的机动风暴第 1 章留作对比基准

二、分工模型

flowchart LR
    A[Fable5 主会话<br/>固化skill/提示词<br/>发起调用/呈报] -->|每窗一调| B[MiniMax-M3<br/>只当探测器/抽取器<br/>输出JSON]
    B --> C[脚本守卫<br/>精确匹配/长度界/20%顶<br/>泄漏检查/审计入库]
    C -->|样张| D[创始人<br/>质检确认门]
    D -->|放行| C
  • M3 永远不直接改库:清洗它只报「待删段逐字原文」,拆书它只报「脚手架/范式卡 JSON」;落库动作全部由带守卫的脚本执行,LLM 建议 ≠ 必删/必收。
  • 源 txt 永远不动,任何一步可整书重导回滚。

三、步骤(从最基础开始)

P0 — llm skill 固化 + 首窗真跑(我自行决策,无确认门)

  1. 新建 .claude/skills/call-content-model/:封装 New-API chat 调用(默认 MiniMax-M3)——超时/重试、<think> 剥离、JSON 提取容错、token 用量审计打印。所有后续调用走这一个入口,不裸调。
  2. clean/parse-book 两个 skill 的文档与参数改口:模型标注 haiku→MiniMax-M3,编排方式从「Workflow 派子代理」改为「skill 脚本直调 M3」。
  3. 首窗真跑:机破星河(最脏书)win-001(第 1–39 章,10.1 万字)探测一次 → 验证窗口不超限、JSON 可解析、exact 逐字命中率。
    • 若 10 万字窗超限或命中率差 → 我自行降窗(如 5 万字/窗,总调用数约 ×2,量级仍可接受),呈报时说明。

P1 — 清洗演示(★确认门①:创始人质检)

  1. 机破星河前 ~50 章:M3 探测 → clean_apply --dry-run 对账 → 呈报样张:删什么/理由/次数、守卫拒了什么、我抽查的误伤扫描结论。
  2. 等质检放行后该批真删落库,呈报前后对比(字数变化、审计行、quality_report 复扫)。

P2 — 清洗放量(所有书;门①过后我自行执行)

  1. 8 本 ≈340 窗 ≈350 次 M3 调用(输入 ~35M token;若降窗则 ~700 次)。断点续跑(manifest 标记已处理窗),书间顺序跑,每书收口报一行。
  2. 收口交全局清洗报告(每书删除段/字数/理由分布/拒绝率/抽查样张 + 垃圾残留复扫对比)→ 创始人复核。此为呈报非阻塞门:源 txt 可回滚,发现异常再处理。

P3 — 拆书管线 M3 化 + 试拆(★确认门②:创始人质检样张)

  1. 把 workflow 里的 scaffold/patterns 提示词(含 extractor 身份段、五型合同)移植固化为 parse-book skill 的 M3 直调脚本,状态仍全在库(example_parse_task),断点续跑。skill 固化可与 P2 放量并行(不花 M3 调用)。
  2. 试拆:5 本试拆书(机动风暴/超神机械师/机战无限/深空之影/星环使命)各前 3 章 = 15 章 ≈30 次 M3 调用。机动风暴第 1 章与 opus 基准并排呈报(细纲/实体/范式卡样张 + 泄漏检查)。
  3. 等质检。质检后呈报 B2 放量编排与成本量级,硬停等新指令(已拍:先不批量拆)。

四、确认门汇总

类型 事项
需创始人确认才继续 门① 清洗样张质检(P1→P2 真删与放量的前提);门② M3 试拆样张质检;B2 放量拆书(硬停,等新指令);单章删除超 20% 顶等守卫异常若成批出现(升级呈报)
我自行决策 skill 实现细节(重试/容错/断点续跑)、窗口大小调整、dry-run 与 1–2 次量级的试跑、演示书选择、框架文档同步与「框架:」提交推送
纪律不变 库内 LLM 产物一律不 commit;确认=commit 仅创始人指令触发

五、成本量级(全部 MiniMax-M3)

事项 调用数 输入量级
P0 首窗试跑 1 ~0.06M token(实测:10万字窗 in=5.9万 out=2k 耗时24s)
P1 清洗演示(机破前 50 章) 2 ~0.08M token(实测收口)
P2 清洗放量(8 本全语料) ~340 ~19M token(实测 M3 中文 0.58 token/字,比预估砍半;输出极小)
P3 试拆(5 本×3 章×两 pass) ~30 ~0.5M token

六、风险与回滚

  • 误删正文:三层防护——M3 只报逐字原文、守卫(4–500 字/不碰章题/单章≤20%)、门① 人工质检;全程审计入 example_clean_log,源 txt 不动可整书重导。
  • M3 长窗退化:P0 首窗真跑先验,退化即降窗,不带病放量。
  • M3 拆书质量不如 opus:试拆并排对比呈报,由创始人裁决质量是否可接受,不预设结论。