| name | novel-editing-patterns |
| description | 网文章节修复与质量提升模式——爽点追回、弧线植入、节奏调整、字数补全 |
| category | novel |
网文编辑模式
来源:实战项目验证过的可复用模式。以下方法论不绑定特定书籍,案例部分标注为示例。
固定篇幅快节奏章节(优先规则)
当章节硬性要求约 2200 字,同时出现环境补字、动作碎片、重复确认、静态等待或爽点稀释时,必须先加载 references/2200-effective-content-standard.md。
核心纠偏: 不能以缩短章节解决节奏问题。应先保证剧情容量,再让 2200 字由冲突回合、人物决策、反方应对、结果兑现和反馈构成。该参考中的字数口径与内容密度双门槛,覆盖本技能后文所有宽松字数建议。
一、爽点沙漠诊断与追回
诊断
逐章检查 5 项(钱落地/震惊反应/打脸/收入对比/系统神秘化),零命中 = 荒漠章。连续 ≥3 章零爽点 = 沙漠段。
章节若硬性要求约 2200 字,还要检查内容密度:每 500 字是否发生局势、利益、关系或信息变化。不能因为“有转折”就给节奏高分;必须检查转折间隔、重复信息、静态动作和爽点兑现链。
追回策略(破坏性从小到大)
策略 1:系统被动数据对比(破坏最小,≈150 字)
章末系统面板后插入一次性数据对比。系统不说话,只报数。灰色小字。
示例(仅作参考):
码头日均收虾一百七。大城市水产公司日均收虾八百六。收购价差百分之十二。
策略 2:算牌内心独白(≈400 字)
主角过资源/牌面 + 对手的牌。必须算完→行动暗示,不能算了就完。
示例:码头底座 / 冷库合伙人 / 系统日结 →「对手看不到第三张牌」。
策略 3:外部视角验证(≈300 字)
旁观者/对手的眼睛看主角成长。从别人嘴里说出来比主角自己说有力。
示例:旁观者/对手的视角——「这个码头跟以前不一样了」「照实说」。
策略 4:章末强钩子(破坏较大,≈150 字)
新信息打破平衡:电话/短信/突然出现的人/系统数据跳变。仅在章末钩子虚弱时用。
执行规则
- 优先策略 1-3(不动主线)
- 每章 ≤2 注入点,每个 ≤300 字
- 追回后必须跑 review_scan
- 补字数必须合理不水;若作品明确要求约 2200 字,必须同时满足 2200—2400 字与有效内容密度,不能用“差一点可接受”绕过硬要求
二、弧线空洞修复:三节点植入法
适用场景
- 角色有功能但无独立生活(每次出场都帮主角)
- 角色无 Want/Need、无背景冲突、无独处场景
- MILESTONE 反复标记「弧线空洞」但未处理
方法
在角色早期出场的三个关键章中各植入一个 100-150 字的独立瞬间——不是帮主角,是她自己的生活:
| 节点 | 时机 | 内容方向 |
|---|
| 节点 1 | 首次出场后 | 她去哪?她有什么习惯?她有什么从来不去的? |
| 节点 2 | 决策/签约后 | 她停了一下的瞬间在想什么?在看什么? |
| 节点 3 | 独处场景 | 她一个人的时候做什么?什么东西她拿在手里没放下? |
示例(配角弧线植入)
- 首次出场后:骑电动车经过某人病房楼下——不停。
- 决策签约后:窗外病号服老人让她停了一秒——不是她亲人,但体型差不多。
- 独处场景:黑暗冷库里掏口袋里的纸条——在外打拼多年。冻虾拿在手里,没拆。
串联:不停→停一秒→一个人黑暗中握着冻虾。不是一场大戏,是背景噪音。读者回头看时会自己连起来。
三、B 线注入法:单线章转双线章
适用场景
- 章节是纯人情/支线章,拖节奏但核心情感又不能砍
- 读者审查反馈「想弃」
方法
保留 A 线(核心情感),注入一条平行 B 线(主线压力)。B 线视角从外部切入——对手/旁观者。
示例:A 线 = 人情/家庭线。B 线 = 主线压力(对手的视角)——他们看到主角地盘变了,报告「无异常」得到回复「继续盯着」。
效果:人情不砍、压迫感注入、章末双线收束。
四、章节质量修复全流程
自动扫描 → 诊断报告 → 文档修复(delegate_task) →
字数补全(Claude Code CLI sonnet) → 爽点注入(Claude Code CLI sonnet) →
读者审查(Claude Code CLI sonnet) → 验证扫描
分工铁律:
- 文档修复(伏笔表/系统状态/人物总表)→ delegate_task
- 文字创作(补字数/爽点注入/弧线植入)→ Claude Code CLI sonnet
- 读者审查 → Claude Code CLI sonnet
- 验证扫描 → 主 Agent 直接执行
五、MILESTONE 数字纪律
- 禁止自创进度百分比。分卷细纲说第一卷 1-60 章 = 25/60 (42%),不能说 25/30 (83%)。
- 禁止自创卷数划分。所有章段划分以
分卷细纲/ 为准。
- MILESTONE 报告的进度数字必须可追溯到分卷细纲。
- 不要用章节规划的行数当成卷总章数。
六、字数铁律
- 默认按番茄显示字数验收:去除标题、空格与换行,保留标点、数字和字母
- 章节要求约 2200 字时:目标 2250,合格区间 2200—2400
- 字数不足不得直接扩写环境、五感、动作、等待、回忆或重复确认
- 删除注水后不足 2200 字,必须补有效剧情回合,具体标准见
references/2200-effective-content-standard.md
- “差一点可接受”只适用于用户未设定硬字数要求的作品;用户明确要求 2200 字时不适用
删减纪律:只删字,不动句子
用户要求「控字数」「轻微删改」时,必须严格遵循以下规则:
- 只删个别冗余修饰词,不改变任何句子结构、不删对话、不改粤语台词
- 不删对白 — 对话是网文灵魂,删字从叙述语下手
- 不允许合并/重构句子 — 删字就像删柴,不能改房子的骨架
- 不影响叙述节奏 — 删完读一遍,不要破坏段落的气口
- 如需要删超过20字才能达标,优先考虑删一整句次要描写,比每句各删几个字更干净
- 绝不动用户未指定修改的章节 — 哪怕发现了明显的错字/设定不一致,只要用户没提到那章就不要碰
实战信号:用户说「为什么改那么多」「这样不行吧」= 已经越界。立即恢复原版重新来过,减少删减量。
番茄字数计算验证
番茄后台显示字数为纯正文无空格字符数(含标点、数字、字母,不含空格/换行):
import re
lines = open('第N章.md').read().strip().split('\n')
body = '\n'.join(lines[2:])
text = re.sub(r'\s', '', body)
print(f'番茄字数≈{len(text)}')
七、流程纪律:novel_step.sh 防跳步
问题
连续创作时,助理会跳过 novel-main 7 步流程中的步骤(跳 PLOT、缩 REVIEW、跳 TRACK)。纸面约束挡不住势头压力。
解决
~/.hermes/skills/novel/scripts/novel_step.sh — 状态锁。每步执行前 check,完成后 done。
novel_step.sh check DRAFT
novel_step.sh done DRAFT
详见 novel-writing → references/general/workflow-lock.md
跳步信号
- 连续两章之间的步骤越来越少
- REVIEW 只跑 review_scan 不做爽点/OOC/读者审查
- TRACK 被完全跳过
- 用户问「有按照流程来吗?」= 已经跳了
八、跨章一致性扫描流程
来源:实战项目中行政层级错误(虚构市/县/镇层级不一致)+ 同名实体地理位置冲突排查。
核心规则
发现一个错误 → 先全局搜索,再修复。
不要只改发现的那一处。用 search_files 以错误关键词在所有章节中搜索同类模式。只有确认「仅此一处」才能只改一处。
扫描维度与执行顺序
| 执行顺序 | 扫描维度 | 搜索策略 | 示例 |
|---|
| 1 | 错误关键词级联 | 用发现的错误词搜全部章节 | 发现层级用词错误→搜所有相关行政区名 |
| 2 | 同类模式 | 思考错误属于哪类模式,搜同类 | 行政层级错误→搜所有上级+下级行政区名 |
| 3 | 关联实体 | 与错误相关的其他实体是否也有问题 | 某区错→检查其他区/镇是否正确 |
真实案例
案例1:行政层级错误
发现:某个虚构行政区的层级使用不一致(如将「市」误写为「县」,或将「镇」误写为「县」)。
扫描:
- 搜索错误的层级用词 → 定位出错章节
- 搜索同类模式 → 检查全书是否还有类似错误
- 搜索关联实体 → 确认上下级行政区名称是否正确
案例2:地名位置逻辑
发现:不同章对同一地点的地理定位矛盾(同一实体在不同章节出现在不同位置)。
扫描:
- 搜索矛盾地点名 → 定位所有出现位置
- 核对每章场景的地理位置(角色在哪、能看见什么、能听见什么)
- 分类:在正确场景的→保留;在错误场景的→修正
结论:跨章同名实体存在位置冲突。
地理位置铁律
修改地点参照时,必须核验角色的当前位置:
- 角色在某地 → 不能「看」到远方城市的市场(间距数百公里)
- 角色在某地 → 不能「听到」远方城市的声音
- 角色在本地说话 → 不能拿远方城市举例(逻辑不通)
⚠️ 常见推理陷阱:
当发现某个地点参照错误时,不要只换地名,要重建场景的物理可行性。例如角色站在本地码头,距离大城市500km,不可能「看」到那边。正确做法是替换成本地可感知的参照物,同时更换视角动词。
核验方法:
- 先读章首,确认场景设定在哪
- 再读角色出现的段落,确认角色当前位置
- 再判断地点引用是否在合理距离内
跨章同名实体通则
一个命名实体(市场/机构/店面/大楼)在全书中只能有一个地理位置。如果它在不同章节出现在不同地方,处理方式:
- 场景位置与实体位置一致→保留
- 场景位置与实体位置不一致且角色在本地→改为本地实体或通用描述
- 场景位置与实体位置不一致但角色在远处→改为纯方向性描述(如「往大城市方向」而非指名具体地点),不能有看/听/去的具体动作
九、读者审查方法论(深度逐章版)
来源:2026-07-27 1-30章全量逐章深度审查实践。用户三个纠正信号:
- 「你不会找?」= 不要问文件路径,主动 find
- 「怎么都是好话?」= 诚实审查,不要心软,不能说假话
- 「有没有逻辑问题 有没有坑 有没有上下剧情对不上的问题」= 三线检查:时间线一致性/人物行为一致性/线索闭环
核心规则
诚实优先,具体优先,对抗心软。 用户花钱花时间,说假话就是浪费用户的钱。
每章三问必答:弃点?爽点?想看下一章?
四维审查框架
| 维度 | 检查内容 | 输出要求 |
|---|
| 开头吸引力 | 前300字能不能抓住人?第一句有没有信息量? | 评级+理由 |
| 弃书点排查 | 哪里想划走?具体到段落 | 评级+具体段落原因 |
| 爽点落实 | 至少1个实爽点,连续3章零爽点=沙漠段 | 评级+具体爽点描述 |
| 章尾钩子 | 看完想不想点下一章 | 评级+钩子类型 |
逻辑与连续性检查(用户特别要求)
每次全量审查必须额外检查:
- 时间线一致性:前后时间衔接是否合理
- 人物行为一致性:性格/能力/人设是否前后一致
- 线索闭环:前文伏笔有没有回收,挖坑有没有填
- 系统设定一致性:系统是否始终遵守初始规则
- 数字连续性:金钱/人口/系数/产量是否前后对齐
阅读型审查可疑信号
出现以下任意一条,立即停止,重新逐字阅读:
- 每章评价几乎一样(「节奏好」「爽点足」循环使用)
- 没有引用具体段落或具体台词
- 字数直接从机器读取,没有主观感受
- 无法回答「这章主角做了什么」
- 评语套话化(「张力够」「推进自然」循环)
完整参考文档
见 references/case-studies/读者审查标准.md——包含审查人设、四维框架、全量审查输出格式、评审纪律、对抗心软检查清单、分批审查策略。
十、深度审查→修复执行流水线
来源:2026-07-27 全量审查修复(14项,12章,约1800字增补)。
三阶段修复
深度审查报告产出后,按以下顺序分阶段执行:
| 阶段 | 内容 | 派发方式 | 典型件数 |
|---|
| S级(紧急) | 机械清洁(删残留/补标题/修格式)+ 关键爽点注入 | 机械→主Agent patch;创作→Claude Code (sonnet) | 3-5项 |
| A级(核心) | 结构性重写(拆PPT式独白/压缩科普/加爆点尾钩) | Claude Code (sonnet)(≥100字创作) | 2-4项 |
| A级(核心) | 结构性重写(拆PPT式独白/压缩科普/加爆点尾钩) | Claude Code (sonnet)(≥100字创作) | 2-4项 |
执行纪律:每项独立执行→验证→下一项。同阶段不可并行的项串行。
- 独立章节可并行:不同章之间的 B 级微调可批量读取+批量 patch。
- 每项有明确 success criteria:字数目标/具体行号/注入位置。
- opus 产出后必须验证:review_scan + 确认是完整章节(非摘要)。
- 引号格式统一检查:全书使用「」成对引号。修改后必须检查新增/修改的对话是否用了 "",统一改成「」。
- 人物情绪落点补全:B级微调中,给配角加一句话收尾(如「某人在此蹲了十五年,今天总算摆在明面上了」)是低破坏高回报的修复模式。优先在配角有高光时刻的章节末尾补一句——不是解释剧情,是让配角自己开口点一下自己的情绪。
模型摘要陷阱
问题:当 prompt 较长/复杂时,模型可能只输出变更摘要("三个修改完成"),而非完整章节。
症状:终端输出以描述性文字开头,如「三个修改已全部完成。修改1…修改2…」,没有以 ## 第X章 开头的完整正文。
防御:
- 检查终端输出第一行是否以章节标题开头(
## 第 或 # 第)。如果不是 → 摘要模式。
- 摘要模式下,检查输出中是否有完整章节代码块(```包裹),有则提取。
- 若 opus 声称「已将文件写入…」,用 read_file 验证文件确实被更新。
- 若以上均不成立 → 回退到主 Agent patch(适用于 ≤100 字的简单修改)或重新派发 Claude Code 并强化「直接输出完整章节。不要解释。」指令。
修改前置:备份
任何对 01-正文存稿/ 的修改必须先行备份:
python3 ~/.hermes/skills/novel/scripts/backup_chapter.py <path>
多章可批量:
for f in 第17章 第18章; do
python3 ~/.hermes/skills/novel/scripts/backup_chapter.py \
~/novels/books/<书名>/01-正文存稿/$f.md
done
验证清单(全阶段完成后)
十一、批量语言风格审计(方言标准化实战模式)
来源:实战项目中方言过量(每章15-22行→3-5处)系统性修正经验。适用于任何方言类型。
触发条件
审查清单中「方言检查」连续多章不通过,或用户指出「滥用方言」。
审计流程
扫描 → 分类 → 决定保留/替换 → 批量patch → 验证 → 更新书配置
第1步:扫描
canto_chars = ['嘅','唔','佢','咗','喺','哋','冇','咩','睇','啲','嘢','嚟','乜','係','俾','咁']
第2步:保留/替换决策框架
| 类型 | 保留条件 | 替换条件 |
|---|
| 该地域角色对话(有方言背景的角色) | 身份标识,1-2句/章 | 长段叙述或非角色特质对话 |
| 地域风味(当地老渔民/老居民) | 极简一两句地域风味 | 连续多句、信息性对话 |
| 情感动敌高潮 | 关键时刻1句 | 普通汇报/分析性对话 |
| 主角对话 永不保留 | — | 主角说方言破坏叙事视角一致性 |
| 叙述性文字 永不保留 | — | 叙述混方言不伦不类 |
第3步:批量执行
python3 ~/.hermes/skills/novel/scripts/backup_chapter.py 第20章.md
第4步:同步更新生成约束
修完正文后,必须更新opus prompt/书配置中的方言规则,防止新章节重复犯同样的错。具体做法:
- 在DRAFT prompt铁律中把模糊的「方言N处」替换为明确的禁止清单+字符数上限
- 在审查清单中增加量化检查项
- 更新书配置中的方言设置
纪律要点
- 先备份再改:多章可并行备份
- 每句单独决定:不批量替换,逐句评估是保留还是转普通话
- 保留的句子整句不动:不把方言句子改成「半方言半普通话」——要么整句保留,要么整句转普通话
- 主角/叙述零容忍:主角、叙述性文字中出现方言,直接转标准语
- 改完更新书配置:这是最重要的——只修正文不修配置,新章还会犯
十二、Markdown语法清理(番茄平台不渲染Markdown)
来源:2026-07-28 第10-30章全量扫描发现38处---分割线+1处反引号代码块,跨11个章节。
问题
opus在生成正文时倾向用---做场景分隔线。番茄小说平台不渲染Markdown,---会直接显示为三个减号,破坏阅读体验。同理**加粗**、`代码块`、> 引用也不应出现在正文中。
扫描与清理
grep -rn '^---$' ~/novels/books/<书名>/01-正文存稿/
grep -rn '\*\*' ~/novels/books/<书名>/01-正文存稿/
grep -rn '`' ~/novels/books/<书名>/01-正文存稿/
清理方式:直接删除---行(场景之间空行衔接即可),删除反引号(保留文字内容),删除**(保留文字内容)。
预防
DRAFT prompt铁律第3条已增加「禁止任何Markdown语法」明确禁止。REVIEW审查清单第6项已增加Markdown残留检查。新章节产出后扫描确认零残留。
十三、Claude Code 超时与主 Agent 接管策略
来源:2026-08-04 第34章创作。opus 连续两次超时(300s+180s)零输出,用户发出 frustrateion 信号「怎么这么久,很不正常」。
问题
单章 DRAFT 派发 claude -p --model sonnet 时,有时 模型会卡住完全无输出。background 重试不是解决方案——只是让用户多等一次。用户对等待时间极度敏感。
规则
- Claude Code 连续失败2次(超时/零产出)→ 停止重试,主 Agent 直接接管
- 不解释、不等——用户说「怎么这么久」时流程已经出问题,立刻切换
- 主 Agent 接管时:严格按骨架场景顺序填肉,每场景写够骨架标注字数
- 主 Agent 写初稿通常偏短(~2000-2100字 vs Claude Code 的 2300+)。必须在 POLISH 阶段补有效剧情到 2200+
- 补字数只加有效剧情回合(渔民群体反应、搬货细节、账目具体化、新角色与旧角色互动),不加环境描写
- DRAFT/POLISH 用
--model sonnet(deepseek-v4-pro),不用 opus(glm-5.2 长prompt卡死)
补字数技巧(有效剧情注入,约 150-200字)
- 群体反应:不只写「有人搬回来了」,写具体几个人的动作和表情
- 财务具体化:不只写「刘芳核账」,写她桌上多了什么具体数字
- 新角色落地:新角色学干活的具体动作细节(怎么码泡沫箱、怎么扛货)
- 对抗余波:花衬衫走后,被收走的渔民的具体反应——谁低头、谁走开
十四、review_scan.py 地点误报识别
每次扫描都产生 15-25 条 level1 误报,浪费审查时间。
模式
review_scan.py 把白名单内地名与相邻标点/引号拼在一起,整个字符串去白名单匹配,自然不中。如 「码头、,穗城、。码头、色,穗城 都报 level1。
快速过滤方法
hits = [h for h in scan_result['hits']
if h['type'] == '地名白名单外: 疑似地名']
false_positives = [h for h in hits
if h['word'].strip('「」。,;:!?、…— \n') in PLACE_WHITELIST]
real_issues = [h for h in hits if h not in false_positives]
判断规则
- 误报:命中词去掉标点后 = 白名单内地名 → 忽略
- 真报:命中词去掉标点后 仍不在白名单 → 必须修复
- 其他 level1(禁用词、字数不合格)→ 全部为真,必须处理
十五、claude_runner.py 产出回收与 POLISH 字数控制
来源:2026-08-07 第43章创作。两个独立问题连续出现。
问题 A:claude_runner.py --target-file 不落盘
现象:claude_runner.py 执行成功(exit_code=0),但 --target-file 指定的路径下没有文件。正文内容只在 JSON 的 result 字段中。
原因:claude_runner 的 --target-file 参数在 claude_code 未调用 Write 工具时(模型直接输出文本而非调用工具写文件)不会自动落盘。
防御:
- claude_runner 进程结束后,检查
--target-file 路径是否存在
- 若不存在,从
--output-file 的 JSON 中提取 result 字段,手动写入目标文件:
import json, os
with open(output_json_path) as f:
r = json.load(f)
content = r.get('result', '')
if content and not os.path.exists(target_path):
with open(target_path, 'w') as f:
f.write(content)
- 这不是错误——是 claude_runner 的已知行为。不要把缺少文件当成 claude_runner 崩溃去调试。
问题 B:POLISH 压缩过度
现象:DRAFT 产出 3200+ 字(超标),POLISH prompt 要求压缩到 2200-2400,结果压到 ~1800 字(低于下限)。
原因:Claude Code 在收到「压缩到 N 字」指令时倾向激进删减——删掉所有描写层、合并对话回合、砍过渡段。
防御:
- POLISH prompt 中不要只给「压缩到 2200-2400」,要同时给出保留清单:哪些对话回合不能删、哪些角色互动必须保留
- POLISH 完成后立即跑 review_scan 检查字数
- 若 POLISH 压过头(<2200),不要重新派发 Claude Code——直接用 patch 逐处补有效剧情(对话回合、配角反应、动作细节)。主 Agent patch 比 Claude Code 全文重写更可控
- 补字数的有效内容类型(已在 §13 补字数技巧中列出):
- 角色互动余波(陈伯问候家人、细虾多一层试探)
- 财务操作细节(签字、数钱、交接)
- 场景过渡中的信息增量
- 不要补环境描写或内心独白
通用教训:Claude Code 字数指令偏差模式
| 指令 | 实际产出 | 偏差方向 | 补救 |
|---|
| 「写 2200-2400 字」 | 2800-3300 字 | 偏长 20-40% | POLISH 压缩(可能压过头) |
| 「压缩到 2200-2400 字」 | 1700-1900 字 | 压过头 15-25% | 主 Agent patch 补有效剧情 |
| 「补字数到 2200」 | 2100-2200 字 | 略短 | 1-2 处 patch 微调 |
结论:Claude Code 对字数目标的控制不稳定。主 Agent 必须在 Claude Code 产出后跑 review_scan 验证,并准备好直接 patch 修正——不要反复派发 Claude Code 调字数。
字数振荡止损阶梯
出现“偏短→扩写过长→精简仍略超”的振荡时,按剩余偏差切换工具,禁止继续全文重写:
| 与合格区间的偏差 | 处理方式 |
|---|
| ≥300 字 | Claude Code 仅恢复/删除骨架中已列明的有效回合;prompt 同时给保留清单、禁增清单和目标窄区间 |
| 50—299 字 | 先备份,用段落级定点 Edit;每处指定原文、替换方向和不可动项 |
| <50 字 | 停止创作式 POLISH;只做 1—3 个精确替换,优先删重复解释或冗余修饰,不碰核心对白 |
每轮都必须:备份 → review_scan.py → 对话占比 → diff 对照授权范围。若目标文件已修改但 runner 非零退出,先读 result/events 和文件 diff;确认修改完整落盘时,不因退出码盲目重跑。
跨章时间窗口核验
涉及“满两周、连续若干月、N 天后”等结果型章节,PREP 前必须做锚点算术:
- 找到真正开始日(交付、上架、签约、首次发生),不能拿上一章日期代替。
- 计算最早兑现日,并核对中间章钩子;例如 D92 开始,满两周最早 D106。
- 对“已发生两天、再约若干天后”复算总时长,避免把 2+10 当 14。
- 若旧细纲或已归档钩子提前宣告结果,先修前章;同步 REVIEW、TRACK、章节规划、PREP/PLOT 和新归档版本,再开始下一章。
- 历史设计文档中的旧钩子也要同步,否则后续回读会再次污染时间线。
细节见 references/timeline-and-wordcount-repair.md。
十七、指标修复与条件性例外
对话占比修复:替换,不叠加
- 先独立统计有效字数与「」内对话占比,标出最长说明段。
- 优先把说明段改成能改变信息、利益或局势的交锋;不要在原稿上追加机械问答。
- 每轮前备份,轮后统计净字数变化与对话占比。若“比例提高但字数超限”,用备份 diff 定位新增冗余,下一轮执行“删叙述、换对话”,禁止继续叠加。
- 重复确认、逐项复述、无局势变化的问答属于注水,即使比例达标也不能通过。
- 达到 REVIEW↔POLISH 上限后停下,不为机械抬高少量百分点无限消耗 token。
用户条件性放行
当用户明确说「如果只有 X 问题,可以通过」时:
- 用最新正文排他核验字数、剧情逻辑、时间线、人物、设定、系统权限、授权数字、编码/格式、扫描命中、注水和读者体验;
- 扫描误报必须定位具体行并人工解释;后台退出码 0 不能替代正文和审查结果;
- 若有只读读者审查,必须读取结果正文,确认一级问题为 0、结论与 TRACK 放行状态;
- 仅当 X 确为唯一未达项时,按用户授权作为该章节、该数值的局部例外;不得外推到其他章节或指标;
- 在审查报告和进度状态中记录实测值、授权范围及例外原因,供 TRACK/MILESTONE 复核。
十八、Claude Code 产物、权限与模型审计
Claude Code 的退出码、status=success、target_file_modified=true、stdout 自述和 --allowed-tools 都不能单独证明任务合规完成。DRAFT/POLISH 后必须同时验收:目标文件、events JSONL、result JSON、正文指标和写入范围。
- 解析 events,列出实际模型与全部工具调用;出现 Agent/Bash/未授权模型或目标外写入,记录为执行过程越权。
- 过程越权但目标文件已修改时,先保护并独立验收现稿,不盲目重跑覆盖;产物合格可保留,但审查报告必须记录越权。
review_scan.py 零命中后仍须人工审计隐性数量/时长、系统数据来源和法律/资本结论来源。
backup_chapter.py 的时间戳文件仅是修改前保护副本;正式归档仍须生成 第N章_vK.md、设定快照、备份日志并校验哈希。
完整检查表与判断矩阵见 references/claude-code-artifact-audit.md。
十九、章节修复工具速查
| 工具 | 用途 |
|---|
review_scan.py | 零容忍扫描(地名/系统词/禁用词) |
novel_scan.py --book <名> --chapters N | 违禁词扫描 |
consistency_check.py --book <路径> | 7维跨文档一致性 |
backup_chapter.py <路径> | 修改前备份 |
novel_step.sh check <步骤> | 流程锁——进入步骤前校验 |
claude --model sonnet --max-turns N -p \"...\" | 创作派发 |
delegate_task | 文档维护(非创作) |