prose-mechanics

散文机制

针对接近定稿的草稿，进行句子层面的散文质量诊断审查。每次审查都聚焦于一个方面，并生成一份标出问题的报告；作者审阅并应用修正后，再进行下一次审查。适用于小说或非虚构作品。

会话连续性

审查工作会跨多个会话迭代进行。Claude 不会在会话之间保留记忆，因此审查跟踪文件是你的持久状态记录。

• 会话开始时： 阅读项目目录中的 audit-tracker.md（如果该文件不存在，请从 assets/audit-tracker-template.md 复制一份）。检查哪些章节已经进行了哪些审查，以及还有哪些工作尚未完成。
• 会话结束时： 更新跟踪文件，记录审查了哪些内容、标出了哪些问题，以及解决了哪些问题。记下停止的位置。
• 指出尚未解决的问题： 如果之前的审查标出的问题作者尚未处理，请在会话开始时列出，以便用户决定接下来处理哪些问题。

核心概念

审查是诊断，而非编辑。每次审查都只扫描一种特定的问题，并生成一份标出问题段落的清单，然后停止。每个标出的问题是否属实，以及如何修正，由作者而非审查来决定。

适用场景

此技能适用于：

• ✅ 对已完成或接近完成的草稿进行句子层面的审查（小说或非虚构作品）
• ✅ 投稿、询稿或出版前的最后润色
• ✅ 发现经开发性编辑后仍然存在的机械性问题
• ✅ 在结构编辑完成后，配合使用 fiction-workshop 或 narrative-nonfiction

不适用场景

此技能不适用于：

• ❌ 早期起草阶段——审查用于修改，而非生成
• ❌ 开发性编辑任务——请改用 fiction-workshop 或 narrative-nonfiction
• ❌ 结构尚未稳定的手稿（你可能会审查即将被删掉的散文）
• ❌ 单个场景或较短的段落，因为人工快速浏览比执行一轮审查更快
• ❌ 风格偏离常规较大的作品（例如实验性散文），因为审查所依据的假设并不适用

审校项目

每次只运行一项审校，并按顺序执行。顺序很重要，因为前面的审校会影响后续审校标记的问题。建议顺序：先运行频率类审校（它们会为赘词配置提供参考），再运行机械类审校，最后运行语义类审校（判断成本高；不要对即将重写的文本运行）。

#	审校	类别	调用方式	检查内容
1	主动／被动语态	混合	"Run active/passive audit on..."	缺乏理由的被动语态、隐藏的施事者
2	平行结构	语义	"Run parallel-structure audit on..."	语法结构不平行
3	句长变化（文件：sentence-length-variance.md）	确定性	"Run sentence-variance audit on..."	节奏平淡、句长范围狭窄
4	可读性（文件：accessibility-audit.md）	确定性	"Run readability audit on..."	阅读年级骤升、段落臃肿
5	词语回响	确定性	"Run echoes audit on..."	100 个词以内重复出现的词
6	频率	确定性	"Run frequency audit on..."	全手稿中使用过多的词
7	赘词	确定性	"Run crutch-words audit on..."	作者个人过度使用的词
8	过滤词	确定性	"Run filter-words audit on..."	felt/saw/heard/realized/noticed/watched
9	副词审校	确定性	"Run adverb audit on..."	-ly 的使用密度、对话与叙述的区别
10	对话标签	混合	"Run dialogue-tags audit on..."	花哨的说话动词、由副词修饰的标签
11	黏滞句	确定性	"Run sticky-sentences audit on..."	胶水词密度
12	句子开头	确定性	"Run sentence-starters audit on..."	重复的开头模式
13	时态一致性	混合	"Run tense-consistency audit on..."	无意的时态切换
14	自创术语一致性	确定性	"Run invented-term-consistency audit on..."	大小写／拼写不一致
15	陈词滥调	混合	"Run cliches audit on..."	陈腐的表达
16	代词清晰度	语义	"Run pronoun-clarity audit on..."	指代不明
17	展示与告知	语义	"Run show-vs-tell audit on..."	直接点明与戏剧化呈现情绪
18	视角一致性	语义	"Run pov-consistency audit on..."	视角跳转、违反角色认知范围
19	AI 写作特征	混合	"Run ai-isms audit on..."	与 avoid-ai-writing 交叉对照

只加载与当前调用的审校对应的参考文件。不要在会话开始时预加载所有参考文件——这会浪费上下文预算。如果在会话中途切换审校，请加载新的参考文件，并将此前的参考文件视为不在当前范围内。

问题格式

每项审校都应输出符合 ../../references/finding-schema.json 的问题： audit、technique、severity（note/suggestion/warning）、location （file/line/quote）、issue、exemplar（可选）、confidence （deterministic/judgment）。按严重程度分组呈现问题，并根据 references/exemplars/<ref>.md 解析所有 exemplar 引用。

引擎钩子

运行任何审校前，检查 command -v scriptorium。如果命令成功：

• **确定性审校：**运行 scriptorium prose audit <name> <chapter> 并将其 JSON 结果视为权威结果——不要手动重新推导问题。
• **混合审校：**运行 scriptorium prose prepare <name> <chapter> 获取代码检测到的候选项，根据该审校的参考文件逐项判断，然后运行 scriptorium prose submit-findings <state> --findings-file <file>。
• **语义审校：**运行 scriptorium prose prepare <name> <chapter> （没有候选项——仅根据原始章节内容进行判断），按照内嵌说明作出判断，然后运行 submit-findings。

如果无法使用 scriptorium，请直接根据参考文件中的检测规则以对话方式执行审校——该参考文件就是完整规范，并非简略的备用方案。

工作流

对于每次审查：

1. 范围： 确认要审查的章节或段落。除非用户要求扩大范围，否则一次审查一章。

2. 执行审查： 阅读正文，查找相关参考文件中列出的特定模式。不要查找其他类别的问题——保持审查范围聚焦。

3. 生成问题报告： 对每处标记的问题，输出：

   • 文件和大致位置
   • 被标记的文本（简短摘录）
   • 标记原因（匹配了哪种检测模式）
   • 一两个建议的修改方案——仅供参考，不是必须遵照的要求

4. 停止，等待作者审阅。 不要自动应用修改。由作者决定哪些标记确实是问题，哪些是风格选择。

5. 应用已批准的修改： 使用 str_replace 对作者确认的问题进行精准编辑。其余问题跳过，不作评论。

6. 更新跟踪记录： 记下运行了哪项审查、审查了哪一章、标记了哪些问题，以及解决了哪些问题。

7. 进行下一项审查。 重复以上步骤。

常见错误

错误	发生原因	修正方法
同时运行所有审查	想一次审查得更全面	每项审查的视角各不相同。叠加起来会产生大量噪声，让作者无从下手。一次只做一项。
机械地应用修改	把标记当成指令，而不是诊断结果	每个标记都需要判断。被标记的被动语态可能恰到好处。指出问题，让作者选择。
把审查当作逐行编辑	混淆诊断与修改	审查用于找出可能的问题；逐行编辑则是解决问题的技艺。先做审查，再逐行编辑——不要同时进行。
审查尚不稳定的草稿	“边写边润色”的惯性	如果章节仍在删改或调整顺序，审查过的正文就会白费。等结构稳定后再审查。
跳过报告步骤	想直接修改以提高效率	报告就是交付成果。它能教会作者自行识别这些模式，这才是审查的长期价值。
不按顺序运行审查	为了方便或应用户要求	每项审查都会影响下一项将标记的问题。如果用户坚持采用不同顺序，请注明后续审查可能需要重新运行。
在开发阶段进行审查	把逐行层面的问题误认为结构问题	正文的机制问题应在结构稳定后处理。如果章节的目的不明确，问题就不在正文。应先使用开发阶段的技能。

自检：这样做有效吗？

使用以下检查点，确认审查执行正确。

开始审查前：

• 手稿的结构是否稳定（没有待处理的大幅删改或顺序调整）？
• 先前的开发阶段审查和角色塑造审查是否已完成？
• 审查范围是否明确（审查哪一章、哪些段落）？

审查期间：

• 是否只使用相关参考文件中的模式？
• 是否生成了问题报告，而不是直接应用修改？
• 是否忽略了审查范围之外的问题，即使已经注意到它们？

生成报告后：

• 作者能否在不重新阅读审查参考文件的情况下处理每个标记？
• 是否为每个标记附上了简短摘录和建议修改方案？
• 是否停止并等待审阅，而不是继续进行下一项审查？

应用修改后：

• 是否仅使用 str_replace 进行精准修改？
• 是否跳过了作者未确认的问题，且没有再次提及？
• 结束会话前是否更新了跟踪记录？

进行下一项审查前：

• 当前审查标记的问题是否都已处理完毕（已修改、已驳回，或已注明推迟处理）？
• 是否确认作者希望继续？

如果任何检查点的答案是“否”，请先停止并解决问题，再继续。

停止点

每项审查都有明确的终点。到达终点后就停止。不要自动进入下一项审查，不要悄然扩大审查范围，也不要在作者明确确认前应用修复。

工具 / 阶段	在……时停止	然后
主动/被动语态审查	已交付请求范围内的问题报告	等待作者审核。不要应用修复。不要开始下一项审查。
平行结构审查	已交付问题报告	同上。不要继续进行句式变化审查。
句长变化审查	已交付问题报告（包含标准差数值和标记出的句子组）	等待。句长变化修复会产生连带影响，因此确认很重要。
可读性审查	已交付问题报告（包含 FK 年级、段落长度和术语标记）	等待。如果发现结构问题，不要转入发展性编辑——指出问题并停止。
已批准修复处理	已通过 str_replace 解决所有经作者确认的问题	更新跟踪表。未经确认，不要开始下一项审查。
审查序列	作者选择暂缓，或后续审查发现手稿需要结构性处理	停止。在跟踪表中注明。建议作者切换到 fiction-workshop 或 narrative-nonfiction 进行结构性处理。
会话	到达停止点或上下文窗口即将填满	更新 audit-tracker.md；在 sessions/ 中撰写记录；停止。

如果作者明确要求你越过停止点继续操作（例如“只应用明显的修复”），可以照做——但要说明你将处理哪些问题、跳过哪些问题，以便清楚呈现范围变化。

快速参考命令

需求	命令
开始审查序列	"Run the prose-mechanics audits on [chapter]"
仅审查主动/被动语态	"Run active/passive audit on [chapter]"
仅审查平行结构	"Run parallel-structure audit on [chapter]"
仅审查句长变化	"Run sentence-variance audit on [chapter]"
仅审查可读性	"Run readability audit on [chapter]"
查看审查状态	"What audits have run on [chapter]?"

---

文件

• references/active-passive-audit.md - 句子层面的语态与施事关系
• references/parallel-structure-audit.md - 列表、比较和系列中的语法平行结构
• references/sentence-length-variance.md - 段落节奏诊断
• references/accessibility-audit.md - 可读性评分与结构可访问性
• assets/audit-tracker-template.md - 各项目审查运行情况和发现的跟踪表