| 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 执行修改 |