写作系统刚开始运行时，规则文件往往很短。每次模型写错一个词，就加一条禁令；每次漏掉一个步骤，就再补一句提醒；每次人工改完一段，又把改法复制到提示词末尾。几个月后，系统变得很“完善”，模型却开始在互相冲突的规则之间来回摇摆：该详细时过度简短，该继续时频繁询问，该保留引用时又强行替换。
问题不在于规则会增加，而在于没有治理。一次局部修改不一定值得成为永久约束；一条曾经有效的规则也可能随着文体、模型和任务变化而过期。本文给出从修改记录到规则候选、审核、发布、回归和删除的循环，让写作专家系统能够变化，却不至于失去方向。
一、每次改稿都不应直接变成规则
人工修改可以分成三类：偶然选择、文章级决定和可复用问题。
偶然选择是为了这篇文章的语境，例如某段故意保留一个长句、某个标题使用双关、某个引用不能改写。它不应进入全局规则。文章级决定只影响当前文章或当前文体，例如本篇采用时间线、只使用公开资料、结尾不提供操作步骤。可复用问题才有资格成为候选规则：它反复出现、影响读者理解或事实安全，并且下次仍然能检测和修复。
一个简单的准入标准是三个问题：
三项都没有达到时，把修改留在文章记录里，不要急着改系统。规则越少越容易理解，真正需要约束的地方反而更容易被模型执行。
二、保存原句、修改句和原因
没有原因的规则很难维护。每次人工修改都保存原句、修改句、修改原因、文章类型、问题标签和样本位置：
before 和 after 让审查者看到真实差异，why 才是未来决定保留或删除的依据。repeat_count 不是越高越好，它只是提示问题是否稳定；impact 帮助优先处理事实和身份问题；scope 防止观点文的规则污染教程；test_case 确保规则不是凭感觉发布。
不要只保存“模型写得不像我”。这类描述不能指导下次修改。把它拆成可观察的原因，例如“连续三段都用总结句，且没有新增信息”“把来源转述改成第一人称”“结尾重复开头的判断”。规则的可维护性来自具体触发条件，而不是强烈的情绪。
三、候选规则的审核和发布
候选规则先进入待审区，不要直接写入共享提示词。审核人需要检查：问题是否真实；证据是否来自实际修改；作用域是否够窄；是否会误伤引用、术语或其他文体；有没有正向和反向测试；规则失败时如何回滚。
通过审核后，给规则分配 ID、版本和负责人，并更新变更日志。发布信息至少包含：
规则版本与文章版本分开管理。文章使用的规则版本写在草稿元数据中，便于复现；不要把某篇文章的临时修改直接覆盖到主规则文件。发布后一段时间观察命中率、接受率、误杀和人工返工，再决定是否保留。
四、规则合并、替换和删除
规则只增不减，最终一定会出现冲突。定期整理时，把表达相近、触发条件相同的规则合并成一条，保留最清楚的原因和测试；把同一问题在不同文体下表现不同的规则拆开；把新规则已经完全覆盖的旧规则标记为替换，而不是两条都留着。
删除规则需要理由。可以删除的情况包括：它只修复过一次偶然问题；对应模型或工作流已经不存在；长期没有命中且反向样本证明它会误杀；另一条更高层规则已经覆盖它；作者明确改变了文体偏好。删除前先运行依赖它的回归样本，把结果记录在变更日志里。
规则状态可以简单分成：candidate、active、deprecated、replaced、removed。deprecated 仍保留在历史版本中，但不再加载；replaced 指向新规则；removed 只代表从当前系统移除，不代表历史上没有存在过。状态比删除文件更有审计价值。
五、回归样本怎样跟着规则走
每条重要规则至少绑定三类样本：应该拦截的正向样本、应该放行的反向样本、规则边界附近的相邻样本。比如“观点文不能把单次案例外推成普遍结论”，正向样本是过度确定句，反向样本是带有清楚范围的条件化判断，相邻样本是来自官方统计的确定数字。
规则版本变更后，三类样本一起运行，并记录：任务是否完成、事实是否保留、是否误杀、作者是否接受建议、输出长度和人工修改时间。只有“命中更多”没有意义；如果命中率上升但有效判断也被删掉，规则就是回归失败。
把历史失败样本与新任务样本分开看。历史样本用于防止旧问题复发，新任务样本用于发现系统没有覆盖的新边界。样本长期不变会让团队误以为规则稳定，实际只是测试集已经被模型熟悉。每隔一段时间抽取新的脱敏案例，并由作者确认能否加入。
六、规则冲突和版本回滚
冲突通常不是模型突然变笨，而是规则职责重叠。例如一条规则要求“结论必须直接”，另一条要求“所有不确定性都要展开”，第三条又要求“回答保持简短”。解决办法不是再加一句“自行平衡”，而是明确优先级、作用域和输出合同：保留支持结论所需的限定，删掉重复背景，必要时把详细证据移到下一段。
发布新版本前，用冲突样本测试。若事实边界、隐私或引用完整性受到影响，即使表达看起来更自然，也不能发布。回滚时恢复规则文件、提示词组合、文体路由和评测器版本，不能只删掉最后一行。恢复后重跑一组旧样本和一组实时脱敏样本，确认问题真的回到已知状态。
当两次规则修复都没有解决同一问题时，先检查是不是架构问题：事实资料是否缺失，文章类型是否路由错误，模型是否被暴露了无关工具，审稿职责是否混在一起。不要把系统层的缺陷继续伪装成一句更强的写作指令。
七、定期清理和作者最终判断
可以每月或每个内容周期做一次规则清理。统计命中次数、接受率、误杀次数、最后确认时间和依赖样本；先处理互相冲突的规则，再处理长期未命中和高误杀规则。清理结果写入变更日志，保留删除理由和恢复路径。
规则系统只负责保存可复用经验，不负责代替作者决定事实、价值和最终发布。模型可以发现模式、提出候选规则、生成回归样本，但作者要确认这次修改是否真的代表长期偏好。作者改变观点时，应该发布一个新的规则版本，而不是让模型通过隐含语气猜测变化。
可以给规则系统做一张轻量仪表盘，按版本显示活跃规则数量、最近新增和删除、命中最多的规则、误杀最多的规则、未解决的冲突、回归样本通过率以及仍需作者决定的 finding。仪表盘不是为了追求更多指标，而是帮助作者发现“规则很多但没有减少问题”或“某条规则几乎每次都需要人工例外”的位置。每个内容周期结束时，只挑最有影响的几项处理，并把决定写进变更日志。
规则评审也可以分成两个门：内容门确认这条规则代表作者真实判断，工程门确认它有明确作用域、测试和回滚。任何一扇门没有通过，都留在候选区。这样作者不用在写作时临时争论系统设计，系统也不会因为一次情绪化修改就改变所有后续文章。
八、适用边界与结论
持续迭代适合已经有多篇文章、稳定审稿流程和可保存修改记录的团队。刚开始写作时，不必建立复杂版本系统；先保存少量高影响问题和测试样本即可。规则治理也不能保证每篇文章都像作者，只能让系统不重复犯已经确认过的错误。
真正有价值的规则，不是最长、最严格或最能列出禁词，而是能说明问题为什么出现、适用于哪里、如何验证、什么时候应该删除。把每次改稿当作候选经验，经过重复性、影响和复用性审核，再发布、回归和定期清理，写作专家系统才会随着作者变化，而不是越用越乱。
