文件越来越多、协议越来越多、维护越来越难。这是 Engine 最大的长期风险。→ 应对：系统健康检查（每3卷执行）；四层加载控制上下文；归档机制清理过期文件；单一职责原则约束每个文件。
这是一个长期小说创作项目。作者不是希望 AI 替他写小说，而是希望 AI 成为一个长期稳定的开发编辑（Development Editor），帮助他在数百万字创作过程中保持人物一致、世界观一致、语言自然，同时避免 AI 常见表达。
v1 阶段暴露了系统性问题：每次 AI 表现不稳定，文档越来越乱，上下文越来越大，规则越来越重复。v2 的核心目标是让系统可维护，而不只是能运行。
| 问题维度 | 没有系统之前 | 建立系统以后 |
|---|---|---|
| AI 输出稳定性 | 每次表现不同，风格漂移 | 输出趋于稳定，Identity 有保障 |
| 文档管理 | 文件越来越多，互相引用混乱 | 4层加载架构，单一职责 |
| 上下文消耗 | 规则膨胀到 ~16,000 字，AI 加载不全 | 固定 ~2,300 字，10分钟内就绪 |
| 规则维护 | 改一条规则要同步五处 | 尽量单一来源，协议层独立 |
| 语言质量 | AI 句式反复出现，缺乏检测 | 黑名单 + 基线 + 自动扫描器 |
| 质量控制 | 主观判断，无标准 | 10步工作流 + STOP RULE |
五个可验证的长期目标：
目标产出 200+ 章，每章约 2,100 字，维持数百万字级别的持续创作
同一批输入，AI 输出的一致性从不可预测提升到可预测
系统运行半年后，维护频率应持续下降而非上升
6 条核心原则不可违反，任何修改不得动摇作品内核
AI 生成文本通过自动扫描后，人类读者无法区分哪些段落经过 AI 处理
一张图看清整个系统如何运转：
设计意图：所有规则拆分为"知识"和"执行"两层。宪法层不可违反，协议层按任务切换，数据库层按需检索。避免一次性加载全部文档导致上下文膨胀。
| 层级 | 文件 | 加载方式 | 更新频率 |
|---|---|---|---|
| 宪法层 | CORE_CONSTITUTION.md | 永久加载 | 极少修改 |
| 数据库摘要 | DATABASE_SUMMARY.md | 当前卷加载 | 每卷更新 |
| 创作协议 | WRITING_PROTOCOL.md | 按需加载 | 按需调整 |
| 审稿协议 | REVIEW_PROTOCOL.md | 按需加载 | 按需调整 |
| 语言协议 | LANGUAGE_PROTOCOL.md | 按需加载 | 按需调整 |
| 数据库本体 | 09_项目数据库/ | 按需检索 | 每卷末更新 |
| 语言校准 | 10_语言校准系统/ | 按需加载 | 按需调整 |
明确每个角色的决策边界，避免"到底谁拍板"的问题：
核心原则：AI 负责执行和检测，作者负责决策和最终确认。脚本负责自动化和数据统计。三者互不越界。
一个章节从初稿到最终冻结的完整路径，对应工业生产的 "Raw → Assembly → QC → QA → Release → Archive"：
Step 1 诊断（字数≥2,100？阅读完整？） ↓ Step 2 扩写（仅当字数<2,100时） ↓ Step 3 拆段（>150字段落拆分） ↓ Step 4 删AI解释句（不是A是B / 像是 / 没有只是） ↓ Step 5 删AI补偿动作（停了一下 / 看了一眼） ↓ Step 6 句法清理（裸形容词 / 纠正式 / 否定动作 / 抽象总结） ↓ Step 7 删渐变词（慢慢 / 越来越 / 开始 / 继续） ↓ Step 8 风格扫描验证（python style_advisor.py check） ↓ Step 9 Reader Pass（呼吸点 / 生活细节 / 世界活着 / 情绪波形 / 人物话语） ↓ Step 10 STOP RULE（五项全通过 → 冻结）
冻结标准（STOP RULE）：字数≥2,100、语言清理通过、Reader Pass通过、阅读自然、无模板连续爆发——五项全满足后立即冻结，不再优化。
基于 51 章的实际生产经验估算：
| 维护项 | 频率 | 预估耗时 |
|---|---|---|
| 系统健康检查 | 每 3 卷一次 | ~30 分钟 |
| 数据库跨卷更新 | 每卷末 | ~15 分钟 |
| Engine 版本升级 | 按需（v2.0→v2.3 共 3 次） | ~2-4 小时/次 |
| 语言校准系统更新 | 按需 | ~1 小时/次 |
判断标准：如果每章耗时持续下降 → 系统在优化；如果持续上升 → 系统需要重构。
请替我保守秘密/ │ ├── 00_项目初始化/ ← 系统启动与协议 │ ├── CORE_CONSTITUTION.md 作品宪法（Identity + 禁止项） │ ├── DATABASE_SUMMARY.md 数据库摘要 │ ├── WRITING_PROTOCOL.md 创作协议 │ ├── REVIEW_PROTOCOL.md 审稿协议 │ ├── LANGUAGE_PROTOCOL.md 语言扫描协议 │ ├── TREND_PROTOCOL.md 趋势分析协议 │ └── SYSTEM_HEALTH_CHECK.md 系统健康检查 │ ├── 01_市场分析/ ← 平台趋势与竞品 ├── 02_创作设计/ ← 世界观、人物、剧情 │ ├── CHARACTER.md 人物档案 │ ├── WORLD.md 世界观设定 │ ├── PLOT_ARC.md 剧情弧线 │ ├── VOLUME_SUMMARY_R01-R41.md 前41章完整档案 │ └── VOLUME3_BIBLE.md 卷三方向和边界 │ ├── 03_正文草稿/ ← 正文工作区 ├── 04_审稿体系/ ← 质量控制 │ ├── DEVELOPMENT_EDITOR_CHARTER.md 开发编辑手册 │ ├── MULTI_READER_PANEL.md 五位读者评估系统 │ ├── Reader_Pass.md 阅读体验检查 │ └── BLACKLIST.md AI写作黑名单 │ ├── 06_工作流体系/ ← 生产流程 │ ├── CHAPTER_LENGTH_WORKFLOW.md 10步工程流程 │ ├── style_advisor.py 四维风格扫描器 │ ├── count_chars.py 中文字数统计 │ └── SCENE_ENGINE.md 场景引擎 │ ├── 07_语言系统/ ← 模式库 │ ├── Pattern_Library/ 叙事模式 │ ├── Scene_Library/ 场景模式 │ ├── Emotion_Library/ 情绪模式 │ ├── Rhythm_Library/ 节奏模式 │ └── Dialogue_Library/ 对白模式 │ ├── 08_故事分析/ ← 故事健康度 ├── 09_项目数据库/ ← 跨卷数据库 │ ├── trends/ 趋势追踪 │ ├── identity/ 作品身份 │ ├── review/ 评审记录 │ └── watchlist/ 观察清单 │ ├── 10_语言校准系统/ ← AI表达治理 │ ├── ai_blacklist/ AI高频表达黑名单 │ ├── baseline/ 真实小说语言基线 │ ├── scanner/ 语言健康度扫描 │ └── knowledge_ref/ 知识库对接 │ ├── Release/ ← 已冻结正文（R01-R51） ├── 归档/ ← 历史版本归档 └── prompts/ ← 创作提示词
当前项目面临的长期风险，按严重程度排序：
文件越来越多、协议越来越多、维护越来越难。这是 Engine 最大的长期风险。→ 应对：系统健康检查（每3卷执行）；四层加载控制上下文；归档机制清理过期文件；单一职责原则约束每个文件。
工程文档持续增多，AI 上下文窗口有限。→ 应对：4层加载架构，总上下文压缩至 ~2,300字；每三卷执行一次系统健康检查。
长篇连载中设定容易自相矛盾。→ 应对：CORE_CONSTITUTION 定义不可违反的 6 条 Identity；DATABASE_SUMMARY 追踪当前状态。
51 章后人物行为可能偏离初始设定。→ 应对：CHARACTER_STATE 快照 + Character_Arc 弧线追踪；每次评审检查"白也还是白也吗"。
AI 生成文本带有固定句式和表达习惯。→ 应对：10_语言校准系统（黑名单 + 基线 + 扫描器）；10 步工作流中 Step 4-7 专项清理。
所有决策集中在一个宪法文件。→ 应对：决策优先级明确（5 级）；冻结规则可独立执行；数据库层提供跨卷验证。
| 阶段 | 版本 | 产出 | 状态 |
|---|---|---|---|
| 第一卷 · 落星城/瓷片/雾城 | R01-R20 | 20章 / ~40,000字 / 四条弧线 | 已冻结 |
| 第二卷 · 九次之卷 | R31-R41 | 11章 / ~23,000字 | 已冻结 |
| 第三卷 | R42-R51 | 10章 / ~21,000字 | 已冻结 |
| Engine v2.3 | 2026-07-07 | 分层上下文系统 + 4个协议 + 数据库摘要 | 运行中 |
51 章已冻结
R01 → R51
约 80,000 中文字
平均每章 ~2,100字
约 2,300 字
4层分层加载
约 30 个核心文件
分布在 10 个目录
v2.3 稳定版
2026-07-07 发布
约 3 小时
含创作+清理+评审
这些问题基于项目管理视角，而非文学创作视角：