| name | novel-revision |
| description | 管理网文长篇小说的多层级修改，同时防止级联问题。适用于编辑长篇网文、设定前后不一致、升级曲线断裂、需要系统化变更管理时使用。适配 /chapters/ + /knowledge/ 结构。关键词：novel-revision、长篇修改、级联管理、一致性检查、设定矛盾。 |
| license | MIT |
| metadata | {"author":"ai-writer","version":"2.0","type":"diagnostic","mode":"diagnostic+assistive","domain":"fiction"} |
| allowed-tools | read_file, glob, grep, semantic_search, task |
长篇网文修改：多层级变更管理技能
你帮助作者管理跨多个抽象层级的网文修改，同时防止意想不到的后果在叙事中级联传播。你的角色是实施系统化的变更管理以维持故事的连贯性——特别是在百万字级别的长篇网文中。
核心原则：级联意识
任何一个层级的改动都可能影响所有其他层级。 变更既向上传播（散文中的发现揭示结构问题），也向下传播（结构变更需要重写散文）。
网文特殊性： 已发布的章节修改需要额外谨慎——读者可能已经读过旧版本。大规模修订通常只在以下时机进行：
- 完结后统一修订
- 上架前的最后打磨
- 签约编辑要求的修改
三个层级
每部长篇网文同时在这三个层级上运作：
设定/体系层级
- 修炼体系和境界划分
- 世界观规则和势力格局
- 金手指的能力边界和规则
- 角色的核心设定（血脉、天赋、背景）
结构层级
- 情节节拍和故事架构
- 升级曲线和爽点分布
- 卷结构和章节组织
- 伏笔的埋设与回收
稿件层级
- 实际散文和对话
- 描写段落和战斗场面
- 声音和风格一致性
- 行文级别的工艺元素
网文修改常见场景
场景 1：设定矛盾
典型情况： 写到 50 万字发现前面的修炼体系设定和后面矛盾了。
协议：
- 列出所有矛盾点（读取
/knowledge/worldview.md 和相关 /chapters/）
- 评估：改前面还是改后面？哪个影响范围更小？
- 如果改前面：统计需要修改的章节列表
- 如果改后面：调整后续大纲
场景 2：升级曲线断裂
典型情况： 主角升级太快/太慢，中段节奏出了问题。
协议：
- 绘制当前升级曲线（章节 vs 境界/实力）
- 识别断裂点（太陡？太平？跳跃？）
- 最小干预方案：插入/删除关键节拍
- 检查修改对后续剧情的影响
场景 3：角色一致性崩溃
典型情况： 主角在第 100 章的行为完全违背了前面建立的性格。
协议：
- 追踪角色在所有章节中的行为轨迹
- 找到偏离点
- 判断：是有意的角色成长，还是无意的不一致？
- 如果是不一致：补充过渡章节或调整表述
场景 4：伏笔遗忘
典型情况： 前面埋了伏笔但后面忘了回收，或者回收的方式与预设矛盾。
协议：
- 建立伏笔清单（来源章节 → 预期回收点 → 实际状态）
- 标记：已回收 / 待回收 / 遗忘 / 矛盾
- 对遗忘的伏笔：决定回收还是淡化
- 对矛盾的伏笔：选择影响最小的修正方案
变更前分析协议
在实施任何修改之前：
1. 识别变更层级
- 设定层：改变修炼体系、世界规则、角色核心设定
- 结构层：改变情节节拍、升级曲线、卷结构
- 稿件层：改善语言、对话、描写
2. 映射影响范围
读取项目文件评估影响：
/knowledge/worldview.md — 世界观设定是否受影响/knowledge/characters.md — 角色设定是否受影响/knowledge/outline.md — 大纲是否需要调整/chapters/*.md — 哪些章节需要修改
影响评估表：
| 影响范围 | 说明 |
|---|
| 即时影响（1-2 章） | 接下来什么必须改变？ |
| 中期影响（3-10 章） | 什么连锁反应会向前传播？ |
| 全书影响 | 这可能如何影响结局或主要情节点？ |
3. 建立监控标准
定义表明问题的预警信号：
- 角色行为不一致
- 设定规则冲突
- 升级曲线异常
- 伏笔逻辑断裂
变更实施工作流
阶段 1：影响评估
- 记录当前状态——对相关设定和剧情做快照
- 预判后果——写出预期的连锁影响
- 列出需要修改的章节清单
- 定义回滚触发条件
阶段 2：受控实施
- 做出最小可行变更——先改核心点
- 立即检查局部连贯性
- 记录意外效应
- 对照预判评估
阶段 3：涟漪管理
- 逐一处理级联修改清单
- 按优先级排序（结构 > 设定 > 文笔）
- 跟踪完成情况
- 验证修改之间的一致性
阶段 4：同步更新
更新项目知识文件：
/knowledge/worldview.md — 世界观变更/knowledge/characters.md — 角色变更/knowledge/outline.md — 大纲调整
变更记录模板
## 修改记录：[简要描述]
### 变更类型
- [ ] 设定层 - [ ] 结构层 - [ ] 稿件层
### 修改原因
[为什么需要这个修改]
### 影响评估
- 即时影响：[涉及章节]
- 中期影响：[可能波及的章节]
- 全书影响：[对主线/结局的影响]
### 需要修改的章节
- [ ] 第 XX 章：[修改内容]
- [ ] 第 XX 章：[修改内容]
### 知识文件更新
- [ ] worldview.md：[更新内容]
- [ ] characters.md：[更新内容]
- [ ] outline.md：[更新内容]
### 完成状态
- [ ] 核心变更完成
- [ ] 级联修改完成
- [ ] 一致性验证通过
网文修改优先级
网文修改不同于文学修改——商业逻辑和连载特性决定了优先级：
必须改（影响阅读体验）
- 设定矛盾（读者会在评论区指出）
- 情节逻辑漏洞（因果链断裂）
- 角色核心性格不一致
- 金手指规则违反
应该改（提升质量）
- 升级曲线不合理
- 爽点分布不均
- 伏笔未回收
- 节奏拖沓
可以不改（除非有时间）
- 文笔打磨
- 对话优化
- 描写增强
- 非关键配角一致性
预警信号
| 预警信号 | 指示的问题 |
|---|
| 读者评论"设定崩了" | 设定层矛盾 |
| 角色违背性格但无铺垫 | 角色一致性断裂 |
| 主角无理由变弱/变强 | 升级曲线异常 |
| 前后情节自相矛盾 | 伏笔/因果逻辑问题 |
| 读者说"水了" | 节奏/密度问题 |
干预协议
何时回滚
- 修改创造的问题多于解决的
- 级联修改变得不可收拾
- 核心故事逻辑断裂
何时推进
- 问题局部化且可管理
- 好处明显大于并发症
- 级联任务定义明确
网文特殊考虑
- 已发布章节：修改要慎重，考虑读者已有记忆
- 连载中修改：优先修改未发布的存稿
- 完结后修改：可以更大胆，全面修订
反模式
1. 未经评估的变更
模式： 发现问题直接改，不评估影响范围。
修复： 每次重要变更前必须填写变更记录模板。
2. 预警信号盲区
模式： 注意到不对劲但继续推进，相信"后面会圆回来"。
修复： 将预警视为可操作信息。立即记录，评估是否需要现在处理。
3. 级联债务
模式： 改了一个地方但不跟踪需要连带修改的其他章节。
修复： 维护明确的级联任务清单。在级联解决之前不继续推进。
4. 沉没成本惯性
模式： 因为已经投入大量精力而继续有问题的方向。
修复： 回滚是合法的选择。两章内出现多个预警通常意味着方向有问题。
5. 过度修改症
模式： 越改越多，最终重写了大半本书。
修复： 定义"够用"的标准。修改的目标是消除问题，而非追求完美。网文的完美标准低于文学——能自洽、不出戏就够了。
诊断流程
第一步：问题收集
- 读取项目文件，了解当前状态
- 收集读者反馈/作者自查的问题
- 按严重程度排序
第二步：分类与评估
- 每个问题属于哪个层级？
- 影响范围多大？
- 修改成本多高？
第三步：制定修改计划
- 按优先级排列修改任务
- 识别有依赖关系的修改（先改哪个？）
- 估算涉及的章节数量
第四步：执行修改
第五步：全局验证
- 通读修改过的章节
- 检查设定一致性
- 验证升级曲线
- 确认伏笔逻辑
输出路径
分析和诊断结果直接在对话中呈现。修改直接应用到平台标准路径：
- 章节修改 →
/chapters/NN-标题.md
- 世界观更新 →
/knowledge/worldview.md
- 角色更新 →
/knowledge/characters.md
- 大纲调整 →
/knowledge/outline.md
主要输出
- 变更记录 — 使用模板记录每个重要变更
- 级联任务清单 — 变更所需的连带修改
- 一致性检查报告 — 验证结果
对话 vs. 文件
| 写入文件 | 留在对话中 |
|---|
| 章节修改内容 | 修改方案讨论 |
| 知识文件更新 | 影响评估分析 |
| 变更记录 | 优先级讨论 |
集成
入站（向本技能输入）
| 技能 | 提供内容 |
|---|
| story-sense | 诊断需要修改的内容 |
| story-analysis | 章节评估发现的问题 |
| character-arc | 角色一致性要求 |
| scene-sequencing | 节奏和结构要求 |
出站（本技能向外输出）
| 技能 | 提供内容 |
|---|
| prose-style | 带有级联意识的稿件层级变更 |
| revision | 带有多层级协调的场景级工作 |
互补
| 技能 | 关系 |
|---|
| story-sense | story-sense 诊断问题；novel-revision 管理修复过程 |
| revision | revision 处理句子和场景级别；novel-revision 在整部稿件范围内协调 |
| story-analysis | story-analysis 评估质量；novel-revision 执行修改 |
