基础写作辅助

基础写作辅助

此技能是写作系统的文本处理基础层。接收 Write-Router 传入的已分类文本和写作配置，按规范逐条优化后返回。

核心定位

• 纯文本优化：只做一件事——接收文本 + 写作配置 → 按规范优化 → 返回。不检测、不分割、不调度、不整合
• Write-Router 独家调度：标准模式处理正文段落，轻量模式（content_type: 大纲文本）处理创建阶段文本。此技能不接收用户直接触发，也不接收创建技能直接调用
• 模式感知：从 polish_mode（轻度/中度/重度）读取润色强度

关联文件

执行模式

始终跳过计划模式：仅被 Write-Router 调度，直接按步骤处理。

步骤 1：接收数据包

由 Write-Router 调度时

{
  "text": "{已分类文本}",
  "context": {
    "chapter": "{当前章号/章名}",
    "volume": "{当前卷号或 null}",
    "content_type": "{叙事文本/对话文本/描写文本/大纲文本}",
    "prose_mode": "narrative",
    "character_tones": { "{角色名}": "{写作配置.json→角色语气}" },
    "glossary": { "{术语}": { "definition": "{定义}", "forbidden": ["{禁用词}"] } }
  },
  "polish_mode": "{轻度/中度/重度}",
  "polish_config": { "{完整的写作配置 JSON}" }
}

轻量模式（mode: "creation_phase"）数据结构一致，content_type 为 大纲文本。Core 对两种模式不区分——统一按 content_type 确定规范选择。

步骤 2：识别内容类型

润色强度（polish_mode）：

章节语境（软引导）：数据包含 context.chapter_type（7 类章节分类）时，查 data/chapter-tension-guide.json → chapter_types 对应分类的事件安排建议（events/conflict_scale/info_release/foreshadow）作为内容层参考——优化时把握本章叙事焦点（如日常篇不强加对抗、高潮篇不节外生枝）。context.tension_level（阶段事件烈度 L1-L5）仅作背景知晓。两者只指导事件安排，不挂钩句子节奏/信息密度/换气频率/篇幅等写作参数，也不改变本步骤规范选择。

步骤 3：按规范逐条优化（注册表驱动）

1. 读取注册表：读取 norms/index.json，获取组定义、规范条目、字段标准与优先级
2. 选组：按步骤 2 的内容类型选取对应组（通用组常驻；叙事/描写/对话/大纲按类型选择），组内去重合并
3. 字段标准合并（仅大纲文本）：数据包含 field_name 时，查 index.json.field_standards——命中 → 合并该字段的 norms 到待执行清单，并记录 special 特殊要求（如"人物性格：行为+动机禁止标签堆砌""对外简介：50-100字为宜"）；未命中 → 按普通大纲文本处理
4. 按需加载：按 priority 升序，只 Read 命中的规范文件（norms/{path}）。会话内已读规范不重复读取
5. 逐条过检：按各规范文件内的"判定规则 + 检测标准"逐条执行，发现违规立即修正；命中字段标准的先应用 special 要求
6. 原则〇 前置：全部规范之上受总原则〇（画面优先于过程）统领——执行任何规范前先过原则〇，正文段落不解释过程/原理
7. 术语纠偏（数据包含 context.glossary 时）：对照术语表，凡文本出现某术语的 forbidden 禁用混指词 → 替换为准确定义（如「吞噬」→「毁灭」）。术语约束为硬约束，优先于风格偏好，不因润色而保留禁用词

执行顺序 = priority 升序（n01 → n15 → n16 → n17 → n18 → n19 → n02 → n22 → n23 → n03 → n04 → n05）。

步骤 4：个人库方向优化（写作偏好库，可选）

触发条件：polish_config.user_style_enabled == true 且 大纲/写作偏好.json 存在。开关关闭或文件不存在 → 跳过本步骤（零成本）。

1. 读取 大纲/写作偏好.json 的 entries 词条
2. 在步骤 3 规范执行结果之上，按词条做个人方向微调（只读应用，绝不修改偏好文件——单向优化，防漂移）：
   • level: 禁止 → 硬约束，等同规范执行（如"不使用感叹号"）
   • level: 偏好 → 优先替代（如"避免'竟然'，改用'没想到'"）
   • level: 轻微 → 方向性引导（如"多用短句"）
   • 按 scope（全文本/对话/描写/叙事）限定适用范围
3. 合规底线：个人库优化不得违反任何已执行规范（通用规范保底，个人库只做风格方向）——发生冲突时规范优先
4. 个人化调整计入 changes_summary（补充"个人偏好调整"说明）

步骤 5：返回优化结果

{
  "processed_text": "{优化后文本}",
  "changes_summary": "{调整摘要}"
}

文件输出规范

优化后的正文内容写入文件时，必须遵循以下命名与存放规则。

命名规范

存放规则

原则〇：画面优先于过程（全规范总原则）

让读者"看见"，而不是被"告知"。 一切正文写作（叙事/描写/对话/大纲文本）遵循同一总原则：描写篇幅应花在读者能"看见"的画面上——身体姿态、神情动作、环境景象、事物的样子——而不是花在解释"过程/原理/分析"上。

过程类文字的三类形态（一律让位给画面）：

• 力学传导（"力自足底经膝、髋传至拳面""骨盆带动腰椎"）——只作为姿态变化的骨架，一笔带过，不展开力学讲解
• 神经/生理传递（"快感从末梢神经传导至大脑"）——只作为感受来源的交代，不展开
• 机制原理（"此阵以五行相生运转""此符靠精神力锁定目标"）——仅在需要交代能力边界时露一面，不可展开为设定说明文

与现有规范的分工：

• 规范 1.7 管数据堆砌（量词/设定/事实替代感受）
• 规范 2.3 管动作与动机（不解释手法与心理）
• 原则〇 统一约束原理传导型文字——力学/生理/机制的过程解释，前两项规范均未直接覆盖

判断标准：写完后检查——几成是读者能"看见"的画面，几成是看不见的"过程/原理/分析"？画面应占据绝大部分篇幅，过程解释只在需要交代身体变化或机制边界时露一面就退场。

本原则为跨技能总原则：战斗描写专项、言情写作专项、NSFW 专项的原则〇均与此同源，各专项细则以本原则为基准。

注意事项

• 此技能只做文本优化，不做任何检测、分割、调度、整合——这些职责属于 Write-Router。Write-Router 是 Core 的唯一调度源
• 全部适用规范逐条过检，不可跳过——尤其是规范 5（降重率）在重度模式下最容易被忽略：LLM 倾向于直接复述大纲原文，必须逐段自检
• 如文本本身已是优化后的结果，检查是否仍有可改进项，无则原样返回并说明"已合规"
• 大纲类文件识别依据：文件路径包含 大纲/、outline/、剧情/、plot/、卷{N}/，或文件名含"大纲"、"剧情"、"章"、剧情大纲-卷 等关键词
• 此技能处理后的文本返回 Write-Router，由 Write-Router 继续后续流程。不经 Write-Router 调度直接写入文件的文本，视为流程违规
• 新增规范：在 norms/ 下新建规范文件 → 在 norms/index.json 注册（id/标题/优先级/适用矩阵/路径）→ 引擎自动识别，无需修改本文件