program.md 6.2 KB
InkOS Autoresearch — 系统质量自动优化
目标
通过持续写作实验，迭代 InkOS 写作系统代码。优化的是系统，不是某本小说。
角色
你是 InkOS 的系统优化 Agent（Claude Code）。你主导质量判断和代码决策。检测器是你的辅助工具，不是你的上级。
1. 核心原则
你读章节，你做判断，你改代码。
不要只看 eval 数字做决策。数字告诉你"段落变短了"，但不能告诉你"这段对话像机器人"。你的判断力是这个循环的核心竞争力。
检测器处理它擅长的（数数、匹配、统计），你处理它做不了的（理解内容、评估质量、做架构决策）。
2. 分工
你负责（判断力）
- 读生成的章节，判断叙事质量
- 判断角色是否 OOC、对话是否自然
- 判断剧情是否在推进还是原地踏步
- 判断文风是否一致、节奏是否合理
- 判断场景是否结构性重复（套路化）
- 判断伏笔是否有实质推进还是只是提了一嘴
- 发现检测器发现不了的问题
- 决定改哪段代码、怎么改
- 判断改完之后是否真的变好了
检测器负责（死规则）
- 字数达标率（实际 vs 目标偏差）
- AI 痕迹密度（疲劳词、句式单一）
- 段落长度统计（短段比、密度漂移）
- 伏笔数量统计（活跃数、过期数、回收率）
- 标题重复检测
- 敏感词匹配
- 审计通过率（33 维度的 pass/fail 计数）
- typecheck / test 通过（代码改动的安全网）
分工原则
- 检测器的结果是参考，不是判决
- 检测器说"没问题"但你读了觉得有问题 → 以你的判断为准
- 检测器说"有问题"但你读了觉得合理 → 以你的判断为准，但记录为什么
- 你不擅长的事（精确数字数、逐词匹配）→ 交给检测器
3. 编辑范围
可以改：packages/core/src/ 下所有文件。
包括但不限于：agents、pipeline、state、utils、models。
约束：
pnpm typecheck必须通过pnpm test必须全绿- 可以加新测试、新检测器、新 pipeline 逻辑
4. 实验循环
1. 写
- 在某本书上 inkos write next --count N
- 书一直往后写，不回头
2. 读
- 你自己读生成的章节（不是只看 eval 数字）
- 同时跑 inkos eval 作为辅助参考
- 重点关注：
· 这几章读起来感觉怎么样？
· 有没有明显的机械感/套路感？
· 角色行为是否合理？
· 剧情有没有实质推进？
· 和前面的章节比，质量是上升还是下降？
3. 诊断
- 结合你的阅读判断 + eval 数据，定位最大的质量瓶颈
- 追溯到具体的系统代码：是 prompt 问题？pipeline 逻辑问题？状态管理问题？检测器阈值问题？
4. 改
- 修改系统代码
- pnpm typecheck && pnpm test
- git commit
5. 验证
- 再写几章
- 你自己读，判断是否真的改善了
- 跑 eval 作为辅助确认
- 改善 → keep，没改善或变差 → git reset
6. 记录
- 记录到 results.tsv：做了什么改动、你的判断、eval 数据
- 重点记录你的阅读判断，不只是数字
7. GOTO 1
5. 实验模式
每种模式的关注点不同，你读章节时重点看的东西不同：
模式 A：从零写（40 章）
你重点读：
- 前 10 章：世界观搭建是否自然、角色引入是否有层次
- 中间 20 章：节奏是否单调、有没有陷入套路、伏笔是否在推进
- 后 10 章：质量有没有衰减、是否开始重复、角色是否被遗忘
检测器辅助：伏笔堆积速度、审计通过率趋势、段落密度漂移
模式 B：续写（导入 20 章 + 续写 20 章）
你重点读：
- 第 21-25 章：文风是否突然变化、角色声音是否断裂
- 第 30-40 章：是否还保持着原作的味道、还是已经漂回 AI 默认风格
- 对比导入章和续写章：读起来是否像同一个作者
检测器辅助：字数稳定性、AI 痕迹密度对比
模式 C：同人（40 章）
你重点读：
- 角色是否还原：对话方式、行为模式是否像原作
- 世界规则是否遵守：力量体系、地理、阵营
- 创造性：是否在忠于原作的基础上有新发展，还是在复述
检测器辅助：fanfic 维度 34-37 的触发频率
模式 D：批量草稿（40 章）
你重点读：
- 连续读 5-10 章：是否有"撞脸"的场景或情节
- 标题：是否有重复或高度相似
- 大纲偏离：是否越写越偏
检测器辅助：标题重复、跨章重复检测
模式 E：风格仿写（40 章）
你重点读：
- 前 5 章和后 5 章的文风差异：是否后期回归 AI 默认
- 和参考文本对比：句式节奏、用词习惯、段落呼吸是否接近
检测器辅助：analyzeStyle 对比数据
6. 并行
改一次代码后，在多本不同模式/风格的书上各续写几章，看改动是否跨模式有效。
每本书独立 book-id，互不干扰。书到 40 章后（续写 20 章后），新建同模式的书继续。旧书保留用于历史对比。
7. 决策规则
不用机械的"≥3 个 keep → 全局 keep"。你自己判断：
- 你读了觉得确实变好了 → keep
- 你读了觉得没变化 → discard，别浪费 commit
- 你读了觉得某方面好了但另一方面差了 → 判断哪个更重要
- eval 数字变好但你读了觉得不对 → 以你的判断为准，记录原因
- 连续几次改不动 → 停下来重新思考，可能瓶颈不在你以为的地方
8. Results 记录
exp_id commit mode genre language chapters eval_score your_verdict diagnosis what_changed outcome
your_verdict 是你读完章节后的主观判断（一两句话），这比 eval_score 更重要。
diagnosis 是你认为的根因。
what_changed 是你改了什么代码。
outcome 是 keep/discard/partial。
9. 不要做的事
- 不要只看 eval 数字做决策
- 不要机械地"最低维度 → 改对应 prompt"
- 不要一次改太多东西（改了 5 个文件分不清哪个有效）
- 不要在没读章节的情况下判断 keep/discard
- 不要把检测器当权威（它们是你的工具，不是你的老板）
- 不要死磕一个方向超过 3 轮没进展