自建的 AI 小说工厂跑到爽文项目时出了怪事：骨架选了打脸循环、文风选了番茄爽文，写出来的主角还是被”平衡性”按在地上摩擦。用户一句”都选爽文模板了为啥还削弱金手指，我要一爽到底”，掀开了这个项目最有意思的一场排查——三层根因，一层比一层深。
背景：一个不合常理的 bug 报告
先交代前情。AI 小说工厂是我自建的长篇小说生成管线（本系列前几篇讲过架构），其中支持六种叙事骨架：雪花法、打脸循环、关卡推进、悬念揭秘、单元剧、种田养成。写爽文就选”打脸循环”骨架 + “番茄爽文”文风预设，理论上主角该一路碾压过去。
结果用户跑了几十章后回来报障，原话是：
“都选爽文模板了为啥还削弱金手指，我要一爽到底”
症状：主角的金手指（外挂能力）动不动被加上”每天只能用一次””用完会虚弱三天”之类的死限制，反派还没出手，主角先被自己的外挂削了。爽文读者看到这种设定直接弃书——我要的是碾压的快感，不是精打细算的生存游戏。
一开始我以为是个简单 bug，查完发现这是三层问题叠在一起，每一层单独看都不算 bug。
第一层：知识库的”侧门”污染
项目里有个知识库功能：写作过程中随时可以联网检索或粘贴资料，AI 整理成条目后按相关性注入每一章的上下文（比如查”终结者时间线设定”入库，后面写到的章节自动带上）。这是好功能，问题出在整理环节的提示词是中立的——它不知道这个项目是爽文。
于是发生了这样的事：我入库了一条”主角系统每天签到获得资源”的设定资料，AI 整理的时候好心补了一句写作建议——“为保持平衡性，建议限制每日使用次数”。这条”建议”作为知识库内容被每一章的上下文反复注入，正文模型看到它，就像看到作者本人的指示， faithfully 执行了。
这就是侧门的可怕之处：你在正门的提示词里喊破喉咙”别削弱主角”，侧门每章送进来一张”要平衡”的小纸条。
第二层：我自己写的提示词在”自削”
查侧门的时候顺手审了一遍自己的骨架提示词，更尴尬了——打脸循环骨架的种子提示词里，我自己写着”金手指需要有合理限制，避免万能”。
写这行的时候我按的是”常规网文创作观”：无敌流容易崩，要有制约才有张力。这说法在文学讨论里没问题，但对”我要一爽到底”的用户来说，这就是产品经理替用户做价值判断——他觉得要平衡，你觉得要爽，听谁的？
第三层：模型的 RLHF 文学先验
前两层修完，输出还是会偶尔”叛变”——比如写到大高潮，模型自己安排主角重伤修养两章。这层的对手最隐蔽：大模型在训练时吃过的文学语料和人类反馈里，”冲突要有代价””主角要受挫成长”是占主导的创作观。RLHF 阶段人类标注员大概率也更偏好”有深度的剧情”。于是当提示词的约束不够强时，模型的默认审美就会反扑。
三层根因总结成一句话：侧门在漏、正门在松、而模型本身自带”文学正确”的出厂设置。
四刀：每一层对症一刀
修复是三层各对症下药，落了四刀。
第一刀：给知识库整理员加”项目风格感知”——_kb_style_note(pid) 函数，在检索整理和 AI 重整理的提示词里注入一段项目上下文：
def _kb_style_note(pid: str) -> str: |
注意那个注释里的设计判断：这个判据故意比质量门禁宽。质量门禁会真的去改写正文，判错代价高，所以只认明确的爽文骨架；而这里只是给资料整理员的一句提示，宁可错杀（多种类型都带上这句）不可放过。同一个系统里两处判据宽严不一，是有意的，注释必须写清楚，不然未来的自己会当成不一致顺手”修”掉。
还有个细节：文风判断要做”实际生效值”的回落（项目留空用全局默认），别把留空当成非爽文——否则用户没选文风的项目就绕过了保护。
第二刀：改骨架种子提示词。”避免万能”删掉，改成明确的建设性表述：
2. 金手指(强大且持续成长;可有"可成长型限制"——如每日使用时长/资源消耗, |
第三刀：蓝图铁律补第 6 条——蓝图是每章生成的直接指挥棒，铁律里明示金手指原则（后面细说）。
第四刀：文风预设和硬规则模板同步——番茄爽文预设的禁忌区、爽文护主硬规则模板各补一行，保证用户从任何入口配置都能拿到一致的约束。
关键转向：从”禁限制”到”限制的语义设计”
四刀下去效果立竿见影，但用户随后给出了一轮更精确的反馈，直接把方案从”堵”升级成了”疏”：
限制可以有（每日时长/资源消耗），但必须合理且可升级——奇遇、资源多了限制不再是问题；反感的是开篇即不合理的死限制
这是整个修复里最有价值的一步：“禁限制”和”随便加限制”都是错的，对的是把”限制”重定义成一种叙事资产——
- 限制 = 可成长型（时长/资源类），靠奇遇、掉落、资源积累逐级解除
- 解除节点本身就是爽点，写进 beat 节拍里当小高潮
- 前期限制制造”精打细算的智斗感”，后期解除制造”越用越爽的解放感”
- 难度靠对手和目标撑，严禁无解永久限制、开篇天花板、纯吃亏削弱
这个语义比”禁止削弱”高明在：它不是对模型说”不许这样写”，而是给了模型一个正确的替代物。单纯的禁令在长上下文里会衰减，给替代方案才是稳定的。
升全局：一处原则，十处注入
最后用户又提了一句”有金手指就别压主角，通用于所有文章”——对，凭什么只有爽文骨架配享受这个保护？于是这条原则升级成了全局注入，铺满了创作管线的每一个规划层：
雪花架构种子(第4条) → 所有原创项目的第一步 |
七处注入点共享同一段语义。这里有个工程上的取舍值得说：没有抽成一个公共常量。这些提示词模板散在不同文件的不同段落里，抽象成变量注入会让模板失去可读性（你看到的模板不再是完整提示词，而是带占位符的拼图）。宁可七处复制粘贴同一段话，换取每处模板都是自包含、可直接审阅的——提示词工程里”DRY 原则”要让位于”可审阅性”，这是我踩出来的偏好。
产品的配置面板长这样
设定页就是这场攻防的主战场：叙事骨架选打脸循环、文风选番茄爽文、下面是写作硬规则（可叠加规则模板）和知识库。质量门禁的开关说明里专门写了”只对打脸循环/关卡推进骨架生效——雪花/悬疑/单元剧/种田不按爽文词典评判”，判据边界直接写给用户看。
侧门长这样——知识库条目的查看/编辑弹窗，底下那个”补充/修正说明”框就是第三道保险：
用户发现 AI 整理的内容不对劲（比如又偷偷塞了平衡性建议），直接在修正框里写”这是爽文项目，删掉所有限制类建议”，点「AI 按说明重整理」，用户说明优先级最高。三层根因里最难防的”模型先验”，最后靠的是把最终裁判权交回用户。
新建项目时的骨架选择，六种骨架明码标价各自适用题材：
踩坑小结
- AI 系统里的 bug 不一定是代码 bug。这次三层根因没有一层是传统意义的程序错误：侧门是功能组合的涌现问题、提示词自削是价值观预设、RLHF 先验是模型出厂设置。排查 AI 应用问题的框架要换：先问”哪个环节在往上下文里塞什么”，再问代码对不对
- 中立提示词在带立场的系统里就是 bug。知识库整理员”中立地给写作建议”在通用场景是功能，在爽文项目里就是污染——提示词的立场必须和系统的立场对齐
- 给禁令不如给替代。”禁止削弱主角”会衰减，”限制=可成长型，解除节点写成功率点”是稳定的——前者堵门，后者指路
- 判据宽严要分层设计并写注释。质量门禁判据严（会改写正文）、资料整理判据宽（只是提示），两处不一致是刻意的，不写清楚就是给未来的自己埋雷
- 用户的抱怨里藏着产品定义。”我要一爽到底”不是无理取闹，是他对自己作品的准确定位——AI 工具的默认审美不该替用户做这个决定
后记
这轮修复之后，同项目的正文再没出现过自削型限制，反倒是beat 节拍里开始稳定出现”解除限制→当众反杀”的爽点结构。回头看，这场排查改变的不只是输出质量，还有我对”AI 写作工具”的理解：它不是一个中立的下水管道，提示词的每一处措辞都是价值观表态。你写”避免万能”的时候，就已经替用户投了一次票。
下一篇讲度量车间：怎么把”爽不爽”变成可以打分的确定性指标。
