"写得像某种风格"是一个模糊需求。如果直接把这句话塞进 Prompt，效果不稳定——有时模型听，有时回到八股腔。问题不在于模型，而在于没有把文风"编译"成机器能执行的指令。
写法引擎的核心思路就是把这个环节工程化：文风分析 → 结构化规则 → 规则编译 → Prompt 注入 → 输出检测 → 修正重写，形成一条稳定的流水线。
为什么文风不能直接写进 Prompt
问题出在两个地方。
一是粒度过粗。"这本书读起来要冷一点、现实一点"，听起来很清楚，但模型理解"冷"有十种方式——删除心理描写、压低情绪、用短句、用第三人称、减少对话。到底要哪几种的什么强度组合，模型不知道。
二是可复用性差。每次生成都要用自然语言重新描述一遍文风，费时，还容易描述不一致。A 次说"口语化""有脏话"，B 次说"粗糙""不文艺"，两个描述指的是同一个东西，但模型当成两套规则执行，结果就漂移。
解决方案是把文风从描述层和执行层分开：用户面对的是自然语言的描述（"我想要底层循环现实流的感觉"），系统底层处理的是结构化规则（register: colloquial, allow_self_reflection: false, emotion_expression: behavior_only），两者通过编译器连接。
流水线的六个环节
环节一：写法资产化
输入：拆书分析、参考文本、手工描述、内置模板。
输出：一份写法资产，包含叙事规则、人物表达规则、语言规则、节奏规则。
这一环的职责是"发现写法"。可以从已有拆书的"文风与技法"章节一键生成，也可以粘贴喜欢的文本让系统反推，或者直接从模板（底层循环现实流、悬疑压迫递增流、冷峻专业流）起步。
关键是让结果都进入同一套数据结构，而不是让每种来源产生格式各异的描述。
环节二：规则标准化
输入：来自上一环的原始规则描述。
输出：统一格式的字段集，每个字段有明确的取值范围。
这一环要解决的是去歧义。拆书可能写"语言兼具哲理与口语"，用户手工写的可能是"别太文青"，这两句指的可能是同一个规则，也可能指三个不同的规则。标准化器负责把这些模糊描述转成内部字段：
language.register = mixedallow_philosophy = truephilosophy_embedding = dialogue_or_action_only
规则标准化也负责补全缺失项。如果用户没说对话风格，系统给一个默认值而不是留空，保证后续编译环节永远有完整输入。
环节三：规则编译
输入：标准化后的规则字段 + 任务类型 + 绑定权重。
输出：分块的 Prompt 片段（context_block, style_rule_block, anti_ai_block, output_block, self_check_block）。
这是流水线的核心。编译器不是直接把 JSON 塞给模型，而是把每一块规则翻译成模型最容易执行的自然语言形式。
例如，对于禁止型规则（forbid_explicit_psychology: true），编译器生成：
禁止直接解释人物心理，不得使用"他感到""他意识到"等句式。人物状态必须通过动作、对话、环境反应体现。
对于软规则（allow_useless_details: true），编译器用不同的措辞：
优先加入无意义但真实的小动作，以增强生活感。
一个关键的设计选择是分层。不是把所有规则平铺在一个 Prompt 里，而是按层次组织：基础上下文层（说清现象）→ 写法规则层（怎么写）→ 角色校正层（角色怎么说话）→ 反 AI 约束层（不要这样写）→ 输出格式层（生成什么样的结果）→ 自检指令层（写完了检查一遍）。
这样做的好处是，不同任务可以选择性使用这些块。大纲生成阶段可能只要轻量提示，章节正文生成需要完整约束，修正任务需要强化反 AI 块——同一套规则，根据任务自适应编译。
环节四：生成执行
输入：编译后的 Prompt 块 + 用户输入 + 任务参数。
输出：模型生成的文本。
这个环节看起来最简单（就是调用 API），但涉及一个工程决策：单轮还是双轮？
单轮模式就是直接生成。快，成本低，适合尝试性写作。
双轮模式是先生成、再检测、若违规则进入修正生成。慢一点，成本高一倍，但稳定性显著更好，适合关键章节或风格敏感任务。
大多数情况下的选择是：正文生成默认单轮（靠 Prompt 约束压住），AI 味明显的情况再自动进入双轮修正。
环节五：输出检测
输入：模型生成的文本 + 当前绑定的反 AI 规则。
输出：检测报告，标记出每条违规规则、违规位置、建议修正。
检测的难点不在于关键词匹配——检测"他感到"很简单。难的是全局维度的检测：段落长度是否过于整齐、句式重复率是否过高、连续几段是否都是解释没有动作、对话是否纯功能性。这些需要统计分析，不是正则。
更难的是准度与召回的平衡。严太了，文章被误报，用户体验差；松了，真正的 AI 味漏过去。实践中的做法是用风险评分代替二值判决：risk_score = 76，超过阈值才自动触发修正建议。
环节六：修正重写
输入：原文 + 检测报告 + 当前写法规则。
输出：修正后的文本。
这一环的目标是"只修违规点，不伤原文信息"。所以 Prompt 需要精确指定问题位置，而不是丢给模型一个"去掉 AI 味"的模糊指令。
检测报告会说：第三段的"他感到一阵烦躁"属于直接心理解释，建议改为行为化表达。修正 Prompt 就根据这个报告逐条生成修正指令，而不是重新生成整段。
核心难点：一致性与失败处理
写法引擎最容易翻车的地方有两个。
一致性问题：写法可以绑定在多个层级——整本书、某一卷、某一章、某一角色视角、当前任务。这些绑定叠加时怎么合并？哪个优先级更高？
例如，书级绑定说"口语化"，章节绑定说"压抑、慢节奏"，角色绑定说"主角嘴硬、不做自省"。三套规则进入编译器时，应该是累加还是覆盖？如果都累加，会不会互相抵消？
实践中的答案是有明确的优先级：本次任务 > 角色视角 > 章节 > 卷 > 全书模板。同一类型的规则冲突时，高优先级覆盖低优先级；不冲突的规则进行累加。反 AI 规则通常只增不减。
但这个规则本身就是一个精细的平衡——优先级太严格会压死灵活性，太松散会导致混乱。这个值需要在实战中反复调整。
失败处理问题：检测不准、修正过度。
检测报告说第三段存在"段尾升华"，建议删除。但什么是升华？"生活终究教会了他……"显然是。"他停顿了一下"就不是。模型看到检测报告后，有时会删过头——把所有总结性的句子都删掉，反而破坏了叙事完整性。
对策是限制修正幅度。修正 Prompt 里明确写："不改变事件事实，不新增核心剧情，仅修正表达方式"。并且在修正后做差异对比——如果删除幅度超过某个阈值（比如删了 20% 的内容），就警告用户而不是直接替换。
边界设计：哪些参数化有效，哪些反而失控
能参数化的，不是所有纬度都值得。
有效的参数：语言风格（口语化程度、粗粝度）、情绪表达方式（行为化还是直说）、对话风格、节奏密度。这些参数改变后，Prompt 的改变直接对应输出的改变。
失控的参数：故事推进单元、视角制度、收尾方式。看起来文风相关，但改了这些参数，实际上是在改故事结构。参数化它只会导致写法引擎越界，跟故事规划模块打架。
更微妙的是中间地带：POV 距离（文字层的叙事距离，比如第三人称与第一人称的心理距离）值得参数化，但 POV 制度（这本书是单视角还是多视角）不应该。语言节奏密度（段落长、句子长短）值得参数化，但故事节奏（高潮应该在哪一章）不应该。
这条线的判断标准是：这个参数改了，是改表达形式，还是改故事结构？ 前者属于写法引擎，后者属于规划模块。
实际执行中，写法引擎确实有不少字段越界了——例如 narrativeRules.progressionMode，这明显是结构职责，不是表达职责。长期的做法是把这些字段降权或迁出，但短期为了兼容旧资产，可能还要保留。这时就需要在编译阶段明确标记：这个字段的权重很低，主要用于兼容，不作为新增规则源。
小结
写法引擎把文风从"模糊描述"转成"可执行约束"的关键，不是更多的规则字段，而是一条完整的、有检测反馈的流水线。
每个环节都有明确的输入输出合同：资产化产生结构化规则，标准化统一字段，编译器生成 Prompt 块，执行生成文本，检测标记问题，修正针对性重写。
核心难点不是单点的生成质量，而是一致性（多层规则怎么协调）与失败处理（检测与修正的准度边界）。边界设计的平衡点在于：不是所有看起来相关的维度都值得参数化——参数化要为了改表达，不是用来绕过结构约束。
■