连载四｜软硬转换炼金术：从提示词到系统本能的内化之路

副标题：内化的渠道、策略与陷阱——为什么最好的治理只需要少数几条底线

---

开篇：当原则之树长得太过繁茂

在连载三的结尾，我们留下了一个悬念：

如果每一次 Pain 都长出一条新规则，每一次失败都沉淀一片新叶子，那么原则之树会不会很快变得过于繁茂？

答案是：不仅会，而且它来得比你想象中更快。

在 PD 的早期实验中，我曾经兴奋地记录下每一次 Agent 翻车的教训。

第一次，它忘记拉取远端分支就开始修改核心文件。

第二次，它在没有测试的情况下重构了大段逻辑。

第三次，它在目标尚未澄清时直接开始写代码。

第四次，它为了修一个局部 bug，引入了更大的架构污染。

于是我开始把这些教训一条条写进 System Prompt。

三周之后，积累下来的“经验”已经超过 40 条。我信心满满地把它们全部塞进提示词里，以为自己打造了一套滴水不漏的“AI 行为宪法”。

结果是灾难性的。

Agent 的响应速度明显下降——不是因为网络延迟，而是因为它花了大量 Token 去“阅读”那些彼此重叠、彼此冲突、彼此拉扯的软规则。

更可怕的是，它开始出现一种诡异的“选择性失明”：

有些规则被严格遵守了。

有些规则被安静地忽略了。

而我根本无法预测哪些会被遵守，哪些会被忘记。

这让我想起了连载三中提到的 突触修剪（Synaptic Pruning）。

真实的生物脑，并不是无限保留所有神经连接。它会把高频、稳定、重要的模式保留下来，把低价值、冗余、过时的连接剪掉。

一个新手会背很多规则。

一个熟手只记住关键原则。

一个大师甚至忘记了规则的名字，却能在行动中自然避开陷阱。

AI 也需要同样的机制。

但问题是：怎么剪？剪到哪里去？被剪掉的“知识”会不会彻底丢失？

这就是这篇连载要回答的核心问题：

原则如何被压缩、硬化、迁移，最终从提示词变成系统本能？

---

01 原则与规则：同一枚硬币的两面

在进入工程实现之前，我们需要先厘清一对经常被混淆的概念：

原则（Principle） 与 规则（Rule）。

它们不是同义词。

它们是同一枚硬币的两面：

一面朝向泛化，一面朝向具体；

一面依赖判断，一面依赖执行；

一面负责“方向”，一面负责“边界”。

原则：方向性的、可调和的、依赖判断的

原则是对经验的高度归纳。

比如：

• 动手前先了解清楚现状，永远不要基于假设行动；
• 三思而后行；
• 写出优雅的代码；
• 不要用战术勤奋掩盖战略懒惰；
• 先判断是否值得做，再讨论如何做；
• 保持系统的长期可维护性。

原则的优点是普适。

它可以跨项目、跨语言、跨场景迁移。

一个好的原则，不只适用于写代码，也可能适用于创业、投资、组织管理和人生选择。

但原则的问题也很明显：它不够具体。

当你面对一行真实的报错代码时，“优雅”到底意味着什么？

是少写几行？

是抽象出一个函数？

是保持原有结构？

还是为了性能牺牲一点简洁？

原则需要解释。

解释需要上下文。

上下文需要判断。

所以原则是软的。它允许权衡，也允许妥协。

当“代码简洁”和“异常处理完整”发生冲突时，一个有经验的工程师会根据场景做判断：如果这是核心支付链路，宁可多写几行防御代码；如果这是一次性脚本，可能可以保持轻量。

原则的价值在于提供方向，而不是给出机械答案。

规则：边界性的、不可妥协的、依赖执行的

规则则不同。

规则是原则在特定环境下被具体化之后形成的边界。

比如：

• 未拉取远端分支前，禁止 Push；
• 修改超过 3 个核心文件前，必须先生成影响范围清单；
• 未通过测试时，不允许提交；
• 生产数据库迁移必须经过人类确认；
• 连续两次权限失败后，禁止继续重复同一路径。

规则的优点是清楚。

触发条件明确。

执行动作确定。

没有太多解释空间。

规则不负责讨论“什么是优雅”。

规则只负责回答：“这次操作是否越过红线？”

所以规则是硬的。

它不像原则那样依赖模型理解，也不像 Prompt 那样依赖注意力。只要输入状态完整，规则就可以被系统稳定执行。

但规则也有代价。

规则的泛化能力很弱。

换一个项目，规则可能就不成立。

换一个目录结构，规则可能就误判。

两条规则如果同时生效，还可能发生冲突。

在纯原则的世界里，冲突可以通过判断来调和。

在硬规则的世界里，冲突往往只能表现为阻塞、报错、死锁或误拦截。

所以我们不能简单地说“原则更高级”或者“规则更可靠”。

真正的问题是：

哪些经验应该保持为原则，交给模型灵活判断？

哪些底线必须变成规则，交给系统确定执行？

如果借用机器学习的语言做一个不严格但有用的类比：

原则更像一个高偏差模型。

它足够抽象，泛化能力强，但容易太空泛，无法精确命中具体场景。

规则更像一个高方差模型。

它在特定场景下非常准确，但容易过拟合，换个环境就失效。

真正的智能，不在于无限堆积原则，那会变成空谈；

也不在于无限增加规则，那会变成僵化。

真正的智能，是在原则与规则之间不断滑动，寻找当下最合适的锚点。

而所谓“内化”，就是将那些已经被反复验证的原则，向规则的方向推进一步。

---

02 上下文债务：为什么软约束注定不稳定

很多开发者有一种虚假的乐观：

既然现在模型支持越来越长的上下文窗口，甚至可以读进几十万、上百万 Token，那我们是不是可以把所有行为准则都写进 Prompt，让 AI 自己遵守？

这个想法很诱人。

但它在工程上并不可靠。

超长上下文当然有价值。它能让模型看到更多代码、文档、历史记录和对话背景。

但它不能自动解决行为治理问题。

上下文越长，我们反而越需要回答一个更关键的问题：

哪些信息应该被模型读取？

哪些底线应该被系统执行？

这就是我在 PD 里逐渐意识到的 Context Debt（上下文债务）。

每往 Prompt 里多塞一条软规则，都会带来三重代价。

第一重代价：注意力稀释

长上下文并不等于所有内容都能被同等重视。

你精心写在第 23 条的关键规则，可能在一次复杂任务中被错误日志、代码片段、历史对话、工具结果淹没。

它没有消失。

它仍然躺在上下文里。

但它不再稳定地影响行为。

这就像一个人桌上堆满了便利贴。每一张都很重要，但当便利贴足够多时，它们整体就变成了噪音。

第二重代价：规则间干扰

软规则之间经常存在张力。

比如：

• 代码要简洁；
• 异常处理要完整；
• 不要过度抽象；
• 但要保持可扩展；
• 尽量少改动；
• 但要彻底解决问题。

这些原则单独看都对。

放在一起却会互相拉扯。

模型在生成每个 Token 时，并不是在进行一场严密的法律审判。它更像是在一个复杂概率分布中寻找最可能的下一个动作。

当软规则太多时，模型不一定会“理性权衡”，它可能只是局部满足其中几条，然后悄悄忽略另外几条。

第三重代价：Token 预算挤占

每多一条软规则，真正留给任务上下文的空间就少一分。

你以为自己在增强治理，实际上可能是在挤压模型理解真实问题的空间。

对 Agent 来说，最宝贵的上下文应该留给：

• 当前目标；
• 关键代码；
• 用户意图；
• 错误日志；
• 历史决策；
• 项目结构；
• 当前约束。

如果 Prompt 被大量软规则占满，Agent 可能反而更难理解眼前任务。

这就是上下文债务的本质：

每一条写进 Prompt 的规则，都不是免费的。

它都会以注意力、干扰和空间的形式收取利息。

概率系统无法保证软规则的确定性遵守

这里还需要纠正一个常见的说法。

很多人会说：“LLM 不擅长演绎。”

这个表述不够精确。

更准确的说法是：

LLM 可以表现出很强的推理能力，但它无法对任何一条软提示做出 100% 的确定性遵守承诺。

这不是说模型笨。

事实上，最新的推理模型在数学、代码、复杂分析等任务上已经表现出了惊人的能力。

但即便是最强的模型，当上下文里充满“既要优雅、又要高效、还要兼容、同时别忘了安全”的软原则时，它在某些位置忽略某条规则的概率也不是零。

我在 PD 开发中遇到过一个让我印象深刻的案例。

我在 System Prompt 中明确写着：

修改超过 3 个核心文件前，必须先生成影响范围清单。

前 20 次交互中，Agent 完美遵守了这条规则。

但在第 21 次，当任务特别复杂、上下文已经被代码片段和错误日志塞满时，它安静地跳过了这一步，直接开始修改了 5 个文件。

没有报错。

没有解释。

它只是……忘了。

这不是一个普通 Bug。

这是软约束的宿命。

所以，PD 必须做一个关键区分：

软规则解决的是“倾向”问题。

硬规则解决的是“边界”问题。

倾向可以交给模型。

边界必须交给系统。

五百年前，东方哲学家王阳明曾提出一个振聋发聩的认知命题：“未有知而不行者。知而不行，只是未知。”

如果把这段话翻译到赛博时代：把 40 多条底线写进 Prompt 里，大模型虽然“读到”了，但由于上下文债务的挤压，它在行动上可能无法保证 100% 的确定性遵守。对系统而言，这叫“知而不行”。

如果一条底线绝对不允许被忘记，那它就不应该继续停留在 Prompt 里。

它应该从概率世界里搬出来，进入一个更确定的物理执行环境（RuleHost）。当危险操作触发时，拦截代码直接起效。

这就是硅基生命在工程意义上的“知行合一（The Unity of Knowledge and Action）”。这也是我们将“记忆”转化为“系统本能”的内化之路。

---

03 内化的渠道：一条经验应该住在哪里？

“内化”不是一个单一动作，而是一条光谱。

你可以把它理解为一个问题：

一条经验到底应该住在哪里？

它可以住在 Prompt 里。

可以住在 Skill 能力包里。

可以住在工具调用前的拦截器里。

也可以最终住进模型权重里。

不同位置，代表不同硬度、不同成本、不同风险。

在 PD 的架构中，我把内化渠道暂时分成四层。

L1 Prompt：软内化

机制：把原则写进 System Prompt。

这是最轻量的“内化”，甚至严格来说，它只是“提醒”。

它的优势很明显：

• 立刻生效；
• 不需要开发；
• 适合抽象原则；
• 适合需要上下文判断的柔性约束。

但它的缺点同样明显：

• 占用上下文窗口；
• 容易被遗忘；
• 容易与其他规则干扰；
• 遵守稳定性依赖模型状态和任务复杂度。

所以在 PD 中，L1 不能无限扩张。

在我当前的实验环境里，L1 软原则暂时被限制在 12 条以内。

这个数字不是普适定律，而是一个工程预算。它来自我当前任务类型、模型能力和上下文结构下的实验观察：当软规则继续增加时，任务完成质量、遵守稳定性和上下文可读性都会开始下降。

更重要的是，超过预算后，系统不能简单使用纯 LRU（最近最少使用）来淘汰规则。

因为有些原则虽然很久不触发，但一旦触发就是灾难。

比如：

禁止在未确认的情况下删除生产数据。

这类低频高危底线，不能因为“最近没用”就被剪掉。

所以 PD 的剪枝策略会同时考虑：

• 最近是否使用；
• 历史违反频率；
• 违反后果严重度；
• 是否已经被 L2 硬规则替代；
• 是否属于不可触碰的高危底线。

L1 的核心定位是：

保留少数真正需要模型理解和权衡的高阶原则。

---

L1.5 Skill：场景化能力包

机制：把原则、流程、工具脚本和场景经验封装成可按需调用的能力包。

这里需要特别澄清一点：

我说的 Skill，不只是一个 Markdown 文件。

确实，今天很多 Agent 系统里的 Skill，最常见形态是一个 .md 文档：里面写着触发条件、操作流程、注意事项和示例。

这种形态非常轻量，也很适合早期快速迭代。

但从长期看，Skill 不应该只停留在文本层。

一个真正成熟的 Skill，应该更像一个“场景化能力包”，它可以包含：

• 一份说明文档；
• 一组检查清单；
• 一段脚本代码；
• 一个小工具；
• 一套固定流程；
• 一组可复用命令；
• 一个面向特定场景的自动化工作流。

比如一个 Git 冲突处理 Skill，不应该只告诉 Agent：

处理冲突前请先理解当前分支状态。

它还可以附带脚本，自动检查：

• 当前分支名；
• 是否落后远端；
• 是否存在未提交修改；
• 冲突文件列表；
• 最近提交记录；
• 是否存在高风险目录变更。

这样一来，Skill 就不只是“提醒模型该怎么做”，而是通过脚本和工具，直接消除一部分不确定性。

这和 RuleHost 有相似之处：二者都可以包含代码。

但它们的定位不同。

Skill 更像是：

面向某类常见任务的操作手册 + 工具包。

RuleHost 更像是：

工具执行前的底线守门员。

Skill 负责提高任务完成质量。

RuleHost 负责阻止越界行为。

Skill 可以帮助 Agent 做得更好。

RuleHost 必须确保 Agent 不能做某些事。

所以，L1.5 Skill 处在一个很有意思的位置：它比 Prompt 更强，因为它可以携带脚本、流程和工具；但它又不像 L2 RuleHost 那样拥有绝对拦截权。

它是半软半硬的。

在今天，Skill 之所以经常表现为 Markdown 文件，是因为文本最容易写、最容易改、最容易被模型理解。

但这只是早期形态。

随着 Agent 系统逐渐成熟，Skill 很可能会演化成更标准化的能力模块：既有说明文档，也有配套脚本、工具接口、运行时约束和验证逻辑。

这块一定会有人去做。

因为只靠文字提示来指导复杂流程，迟早会触碰天花板。真正可靠的流程，最终一定会部分脚本化、工具化、标准化。

---

L2 Code：硬内化

机制：把原则编译成可执行的系统规则，在工具执行前进行拦截。

这是 PD 当前最核心的内化渠道。

为了让不熟悉代码的读者理解，我先不用技术名词。

你可以把 L2 想象成一个“安检门”。

普通 Prompt 是你对 Agent 说：

请不要带危险物品上飞机。

L2 则是在登机口放了一台真正的安检机。

Agent 可以忘记提示词。

可以忽略提醒。

可以产生侥幸心理。

但只要它真的带着危险物品过门，系统就会拦下来。

在 PD 中，这个“安检门”叫做 RuleHost。

RuleHost 到底是什么？

RuleHost 不是另一个大模型，也不是一段更长的 Prompt。

它是一个运行在 Agent 工具调用之前的规则守门员。

当 Agent 准备做某个动作时，比如：

• 写入文件；
• 删除文件；
• 执行命令；
• 修改多个核心模块；
• 提交 Git；
• 推送代码；
• 运行迁移脚本；

RuleHost 会先截住这次动作，检查它是否触碰了已经激活的硬规则。

它会问一些非常具体的问题：

• 这次操作涉及几个核心文件？
• 是否已经生成影响范围清单？
• 本地分支是否与远端同步？
• 当前任务是否获得了修改核心模块的授权？
• 是否有对应测试？
• 是否触发了高风险目录？
• 这是不是连续第三次尝试同一个失败命令？

然后它给出一个结果：

• allow：放行；
• block：阻止；
• requireApproval：需要人类确认；
• auto_correct：自动修正低风险参数后放行。

这里也需要澄清：

auto_correct 只能用于低风险、可逆、语义明确的参数级修正。

比如路径格式规范化、缺省参数补全、命令选项修正。

涉及代码语义、文件删除、Git 操作、数据库迁移等高风险动作时，PD 不应该自动修正，而应该选择 block 或 requireApproval。

L2 的真正价值

L2 的价值不是“让 AI 更聪明”。

它的价值是：

把少数绝对不能被忘记的底线，从模型的注意力里移出来，放进系统的执行层。

这种拦截不消耗 LLM 的上下文窗口。

对于已经被清晰形式化、且输入状态完整的底线规则，它能提供远高于 Prompt 的稳定性。

但这里的“确定性”不是说语义上永不出错。

L2 仍然可能面临：

• 规则写错；
• 输入状态不完整；
• 路径匹配误判；
• 规则之间冲突；
• Agent 通过其他工具绕过；
• 运行环境存在安全风险。

所以更准确的说法是：

L2 不是让规则永远正确，而是让规则不会像 Prompt 一样因为注意力稀释而被忘记。

这已经足够重要。

因为很多底线不是需要 AI “理解”才执行的。

它们只需要系统在物理层面不允许违规发生。

这就是我所说的“系统本能”。

---

L3 Model Training：倾向内化

机制：通过监督微调、偏好优化等方式，让模型在权重层面更倾向于遵守某些原则。

这是最深层的倾向内化。

它可以让模型在没有显式提示时，也更自然地表现出某种行为风格。

比如：

• 更习惯先澄清目标；
• 更愿意识别风险；
• 更少盲目执行；
• 更倾向于生成影响分析；
• 更偏好稳定架构而非短期补丁。

但 L3 不是 L2 的替代品。

训练可以改变模型倾向，但不能替代系统层的硬拦截。

真正高风险的红线，不应该完全写进模型权重里。因为模型权重仍然是概率性的，仍然无法保证每次都稳定遵守。

所以在 PD 中，L3 更适合塑造“气质”和“习惯”；

L2 更适合守住“底线”和“边界”。

延伸视点：L3 训练的数据屏障与 PD 的生态位

业界目前试图通过后训练技术（如强化学习）让大模型内化复杂的高级推理甚至“架构师智慧”，这依然是一项长期的探索。顶级决策往往伴随着极长的时间跨度和极其稀疏的奖励信号，在当前的训练范式中较难在短期内一蹴而就。

在这种背景下，PD 提供了一种务实的折中方案：将长周期的宏观判断“外包”给人类专家，沉淀为高阶的原则（Principle），将局部的微观执行交给 AI，并用硬规则（L2）强制锁定。

更有意义的是，当人类专家在使用 PD 的过程中，不断从“AI 的平庸表现”中感到痛楚（Pain），从而抽象出原则并纠偏 AI 时，系统就在自动沉淀极其珍贵的“专家纠偏轨迹”。也许在未来，这些充满建设性摩擦（Constructive Friction）的数据，正是帮助下一代模型跨越稀疏奖励陷阱、迈向 L3 级别智慧的优质养料。我们期待着不同技术路线在未来的最终交汇。

四条渠道的关系

这四条渠道不是互相替代，而是分工协作：

• L1 负责高阶原则；
• L1.5 负责场景方法；
• L2 负责底线拦截；
• L3 负责长期倾向。

理想状态下，它们应该尽量正交。

能被形式化为代码的底线，就不要长期占用 Prompt。

真正需要模型判断的高阶原则，才留在 L1。

需要按场景调用的方法论，放在 L1.5。

需要长期塑造的行为倾向，未来再考虑进入 L3。

但现实中需要过渡。

一条规则刚刚被编译成 L2 时，我们不能立刻删掉对应的 L1 提醒。因为新规则可能覆盖不完整，也可能误伤正常操作。

所以 PD 采用的是：

编译 → 影子运行 → 验证 → 激活 → 剪枝。

具体来说：

1. 先把原则编译为 L2 规则；
2. 让它在影子模式下运行一段时间，只记录、不拦截；
3. 观察它是否误判，是否漏判；
4. 验证通过后，正式激活；
5. 激活稳定后，再从 L1 中删除对应软提示。

这个过程很像新旧系统切换。

不是一刀切，而是先并行观察，再逐步迁移。

---

04 从文字到代码：一条原则的编译之旅

说了这么多架构，让我们看一个具体例子。

一条原则是如何从“文字”变成“系统本能”的？

起点：一次真实的痛苦

在 PD 开发早期，Agent 多次在没有拉取远端分支的情况下，直接修改核心文件并尝试推送。

结果是反复合并冲突，浪费了大量时间。

这触发了一次 Pain Signal。

但 Pain Signal 本身还不是原则。

它只是一个系统在说：

这里发生了痛苦，这里有东西值得被记住。

真正的护栏，从来不能靠大模型在真空中凭空“冥想（Meditation）”出来。同样借用东方哲学的洞察——“人须在事上磨炼做功夫”。系统的坚硬底线，必须在真实项目的反复摩擦与崩溃（Pain Signal）中淬炼。

接下来，真正负责从这些痛苦现场提取共性、提炼原则的，不应该是人类 Owner 直接拍脑袋总结。

在 PD 系统里，这个角色更接近一个 诊断者（Diagnostician）。

它会从痛苦现场中回放轨迹、比对上下文、识别失败模式，然后尝试回答一个问题：

这次事故背后，究竟违反了哪条更高层的原则？

这次事故表面上是：

Agent 没有拉取远端分支，就直接修改核心文件并尝试推送，导致合并冲突。

如果只把它总结成：

修改核心文件前，必须确认本地分支与远端同步。

那其实还停留在“规则”层。

真正的原则应该更抽象：

动手前先了解清楚现状，永远不要基于假设行动。

这条原则比 Git 同步更高一层。

它不仅适用于推送代码，也适用于：

• 修改核心模块前先读取现有架构；
• 重构旧逻辑前先确认调用链；
• 修复 bug 前先复现问题；
• 删除文件前先确认依赖关系；
• 执行命令前先理解当前环境状态。

而“修改核心文件前，必须确认本地分支与远端同步”，只是这条原则在 Git 协作场景下长出来的一片具体叶子。

所以，在 PD 中更准确的流程应该是：

Pain Signal
→ 诊断者回放事故现场
→ 提炼高层原则
→ 生成候选规则
→ 人类 Owner 审批与校准
→ 规则进入影子运行
→ 验证后硬化为 L2 拦截

人类 Owner 并不是被排除在外。

恰恰相反，Owner 的作用更重要：

诊断者负责提炼，Owner 负责裁决。

因为只有 Owner 知道这条原则是否真的符合项目长期方向，也只有 Owner 有资格决定：哪些原则应该被保留，哪些规则值得被硬化。

自动化可以帮助诊断，但不能替代治权。

编译：不是一键生成代码

从原则到规则，不是简单地让 AI 写一段代码。

因为这里有一个危险：

AI 生成的规则代码，本身也是需要治理的对象。

如果让 Agent 自己生成一条规则，再让这条规则去管 Agent，本质上就是让被监管者参与制定监管制度。

这不是完全不可以，但必须经过审查。

所以在 PD 中，原则下沉到 L2 会经过一条编译流水线。

为了让读者容易理解，我们先看普通流程：

痛苦记录
→ 原则提炼
→ 规则规格说明
→ 代码生成
→ 历史案例回放测试
→ 影子运行
→ 人类批准
→ 正式激活

在内部实现中，这些阶段可以由不同的 Runner 承担：

• Dreamer 负责根据痛苦记录提出规则雏形；
• Philosopher 负责质疑规则是否偏离原则本意；
• Scribe 负责整理规则规格说明；
• Artificer 负责生成可执行规则代码；
• Evaluator 负责用历史案例和边界场景测试；
• RolloutReviewer 负责评估部署风险；
• Trainer 负责为未来可能的 L3 训练准备数据。

这些名字不重要。

重要的是：一条规则不能从“灵感”直接跳到“执行”。

它必须经过规格化、测试、影子运行和人类批准。

人类 Owner 必须在场

整个编译流水线可以高度自动化，但最终激活必须经过人类 Owner 的明确批准。

这不是形式主义。

因为 AI 生成的规则代码至少有三类风险：

1. 过度泛化 规则太宽，把正常操作也拦截了。

2. 欠缺泛化 规则太窄，只覆盖了已知事故，对变体无效。

3. 语义偏移 代码实现的逻辑，悄悄偏离了原则的本意。

这三种风险，只有那个经历过原始痛苦、理解业务上下文的人类 Owner，才有资格做最终判断。

自动化可以提高效率，但不能替代治权。

激活后：剪枝

当 L2 规则通过影子运行验证，并被正式激活后，对应的 L1 软原则就可以从 Prompt 中删除。

这是最关键的一步。

LLM 的“工作记忆”被腾空了一格。

它不再需要时刻惦记着：

推送前先同步分支。

因为即使它忘了，RuleHost 也会在工具执行前拦住这次危险操作。

这就是从文字记忆到系统本能的迁移。

---

05 哪些原则值得内化？一个筛选框架

但这里有一个容易被忽略的问题：

不是所有原则都应该被内化到 L2。

内化是有成本的。

每一条 L2 规则都意味着：

• 需要编写或生成可执行规则；
• 需要测试边界情况；
• 需要人类审查并批准；
• 需要持续维护；
• 可能与其他规则冲突；
• 可能在项目演进后过时。

所以，内化必须是一个有选择的过程。

不是见一个痛苦，就硬化一条规则。

我在 PD 中逐渐形成了一套三维筛选框架。

维度一：频率

这条原则被违反的频率有多高？

如果一条原则在 100 次任务中只被违反过 1 次，它可能只是偶发事件，不值得花工程成本硬化。

但如果它在每 10 次任务中就被违反 3 次，那它就是系统性问题，需要系统性解决方案。

维度二：严重度

一旦违反，后果有多严重？

有些违反只是擦伤，比如代码风格不一致。

有些违反是骨折，比如：

• 覆盖生产迁移文件；
• 删除关键数据；
• 破坏核心架构边界；
• 引入不可逆的安全风险；
• 让系统进入大面积返工。

只有高严重度问题，才值得动用硬规则。

维度三：可形式化程度

这条原则能否被无歧义地转化为代码逻辑？

“写出优雅的代码”几乎无法形式化。

什么是优雅？

少即是优雅？

抽象是优雅？

性能是优雅？

可读性是优雅？

这类问题需要上下文判断，适合留给 L1 或 L1.5。

但下面这条规则就很容易形式化：

修改超过 3 个核心文件前，必须先生成影响范围清单。

系统可以检查：

• diff 涉及的文件数量；
• 是否属于核心路径；
• 是否存在影响清单文件；
• 是否获得人类确认。

这就适合下沉到 L2。

最优策略：从交集开始

最值得内化的，是三者交集：

高频违反 × 后果严重 × 易形式化
= 最值得硬化的底线规则

这个交集通常很小。

可能只有 3 到 5 条。

但它们 ROI 最高。

这也是一个非常反直觉的结论：

好的内化策略，不是让 L2 规则越多越好。

好的内化策略，是让 L2 规则越少越精准。

大量模糊原则，应该留给模型做柔性判断。

少数高危底线，才应该交给系统做硬性拦截。

---

06 规则爆炸：内化最危险的陷阱

讲完内化的好处，必须专门讲它的危险。

因为在 RuleHost 架构打通的那一刻，我并没有感到轻松。

我反而出了一身冷汗。

一个能把原则变成硬规则的系统，如果没有治理机制，很快就会制造另一种灾难：

规则爆炸。

陷阱一：规则冲突与死锁

原则可以调和。

规则不会妥协。

举一个更直接的例子。

假设系统里有两条看似合理的 L2 规则：

规则 A：

未经批准，禁止修改数据库 schema。

规则 B：

所有新增字段必须同步更新 schema 和 migration。

现在 Agent 正在修复一个字段缺失导致的 bug。

规则 B 要求它更新 schema。

规则 A 阻止它更新 schema。

如果没有人类批准路径、规则优先级或升级机制，系统就会卡住。

在纯原则世界里，一个工程师会判断：

这次确实需要改 schema，但必须走审批流程。

在硬规则世界里，如果规则写得不够好，系统只会反复 block。

Agent 被卡住。

任务无法推进。

人类开始烦躁。

最后规则系统反而变成阻碍系统演进的墙。

所以硬规则必须具备：

• 明确作用域；
• 优先级机制；
• 人类升级路径；
• 冲突检测；
• 例外处理策略。

否则规则越多，死锁越多。

---

陷阱二：维护成本的隐性膨胀

每一条 L2 规则都是一段“活”的代码。

项目会演进。

目录会重构。

命名会变化。

工具会升级。

开发流程会调整。

曾经完美的规则，可能三周后就变成误报制造机。

我曾在 PD 开发中遇到过这种情况：

一条规则创建时运行得很好，但项目做了一次目录重构后，它开始疯狂误报。

Agent 每次操作都被拦截。

人类每次都要手动放行。

最后我花在修复这条规则上的时间，远远超过了它曾经节省的时间。

这引出了一个残酷的问题：

一条规则的 ROI 什么时候为负？

当维护一条规则的成本，超过了它所防止的痛苦的成本时，这条规则就应该被修改、降级或退役。

---

陷阱三：过时规则比没有规则更危险

在法律领域有一句话：恶法非法。

在系统治理里也一样：

过时的硬规则，比没有规则更危险。

因为它会制造虚假的安全感。

你以为系统在保护你。

但它保护的是一个已经不存在的场景。

它还会阻碍正常演进。

Agent 被拦在一堵历史遗留的墙前，而你已经忘了当初为什么建这堵墙。

更糟糕的是，它会消耗宝贵的规则预算。

如果系统里有 50 条硬规则，其中 20 条已经过时，那么 Agent 的大量失败可能不是因为它能力不足，而是因为它被历史包袱绑住了。

陷阱四：模型进化让旧规则失去价值

还有一种更隐蔽的规则过时，来自模型能力本身的进化。

今天必须写成硬规则的东西，明天可能会变成模型的默认能力。

早期的 Agent 可能连“修改前先看上下文”都做不好，所以我们不得不写很多外部规则提醒它、拦截它、约束它。

但随着基础模型、推理模型、工具调用能力和长期上下文管理能力不断进化，一些过去必须外部硬化的规则，可能会逐渐失去存在价值。

比如：

• 过去需要强制要求它生成影响范围清单；
• 后来模型可能默认就会在大规模修改前主动分析影响面；
• 过去需要硬性提醒它不要盲目重构；
• 后来模型可能已经能稳定识别重构风险；
• 过去需要在 Skill 中写满流程步骤；
• 后来模型可能只需要少量提示就能自主完成流程规划。

这意味着，规则治理不是单向增加，而应该是持续减法。

很多聪明的工程师和系统设计者，都在做同一件事：

当模型能力增强后，把不再必要的外部脚手架拆掉。

这不是倒退，而是系统成熟的标志。

一个早期系统需要很多护栏。

一个成熟系统只需要少数底线。

一个真正强大的 Agent，不应该被 100 条规则拖着走，而应该在少数关键边界内，自由发挥自己的判断力。

所以，PD 的剪枝机制不仅要问：

这条规则是否因为项目变化而过时？

还要问：

这条规则是否因为模型能力进化而不再必要？

如果一条规则曾经是为了弥补模型短板而存在，那么当这个短板被基础模型本身补齐时，它就应该被降级、归档，甚至删除。

这也是为什么最好的治理不是不断加规则，而是不断寻找最少充分约束。

真正优秀的系统，不是红线越来越多。

而是底线越来越清楚，噪音越来越少。

---

07 规则治理：管理规则的规则

因此，PD 不仅需要规则，还需要管理规则的规则。

我把它称为 规则治理元规则。

元规则一：所有硬规则必须有 Owner

没有 Owner 的规则，不允许长期激活。

因为规则一定会遇到解释、维护和退役问题。

当一条规则开始误报时，谁来判断它是否该修改？

当一条规则和新架构冲突时，谁来决定它是否过时？

当一条规则阻碍交付时，谁来承担放行责任？

如果没有 Owner，规则就会变成无人负责的幽灵。

元规则二：所有硬规则必须记录原始痛苦

每条规则都必须记录它诞生时对应的 Pain。

它是为了解决哪次事故？

当时造成了什么损失？

违反频率是多少？

后果有多严重？

为什么不能留在 Prompt 里？

为什么必须硬化？

如果忘记一条规则为何而生，你就无法判断它何时该死。

元规则三：所有硬规则必须有退出机制

规则的生命周期不应该是：

创建 → 永久执行

而应该是：

创建 → 运行 → 审查 → 演化 / 降级 / 退役

PD 为此引入了剪枝流水线。

它会自动扫描活跃规则，识别一些过时信号：

• 长时间未触发；
• 触发后频繁被人类手动放行；
• 与新架构频繁冲突；
• 维护成本高于节省成本；
• 已经被更高质量规则替代；
• 已经不再对应当前项目结构；
• 已经被更强模型的默认能力覆盖。

系统会生成剪枝报告，提交给 Owner。

Owner 决定：

• 保留；
• 修改；
• 降级回 L1 / L1.5；
• 归档；
• 删除。

被归档的规则不会立刻消失，而是进入冷存储。

如果未来同类痛苦再次出现，它可以被重新唤醒。

这就是 PD 对规则治理的基本态度：

最好的治理，永远不是无尽的红线。

最好的治理，是少数几条直击要害、持续演进、有人负责的底线。

---

08 人类 Owner 的不可替代性

到这里，我们触碰到了一个更深的问题。

PD 系统的核心价值，表面上是在编译规则。

但更深层看，它其实在不断逼迫人类 Owner 做一种困难的权衡：

哪些底线必须交给冷酷的系统去执行？

哪些场景必须留给模型保留灵活判断？

哪些规则已经过时，应该被剪掉？

哪些痛苦值得被永久记住？

哪些痛苦只是偶然噪声？

这件事没有标准答案。

它取决于你的项目、你的风险偏好、你的工程文化，以及你对 Agent 的信任程度。

一个金融系统，可能需要更多 L2 硬规则。

一个创意原型项目，可能应该保留更多 L1 灵活性。

一个早期探索项目，可能不该过早硬化太多规则。

一个生产级基础设施项目，则必须把关键底线下沉到系统层。

这就是人类 Owner 不可被替代的地方。

AI 可以帮助诊断痛苦。

AI 可以帮助提炼原则。

AI 可以帮助生成候选规则。

AI 可以帮助测试规则。

AI 可以帮助发现冲突。

AI 可以帮助写剪枝报告。

但无论 AI 诊断和生成规则的能力多么强大，它们始终只是外在的“法（Methods/Algorithms）”。最终决定“什么是不可妥协的底线”的，仍然必须是人类。

在这个硅基系统中，人类 Owner 扮演着哲学意义上的“良知（The Ultimate Sovereign / Innate Compass）”。

因为只有良知能够承担真实的后果。

只有良知能够理解业务的终极语境。

只有良知知道一次痛苦背后，到底意味着偏离了哪一种长期的价值轨道。

---

结语：在归纳与具体化之间往返跑

让我们最后退回到连载三的核心命题上。

如果把 PD 的进化循环抽象到极致，它其实是一个双向认知过程。

向上走：归纳

Agent 在真实任务中碰壁，产生 Pain Signal。

PD 系统中的诊断者回放事故现场，识别失败模式，从散落的、具体的痛苦中剥离共性，提炼出更高层的原则。

人类 Owner 则负责审查和裁决：这条原则是否成立？是否符合长期目标？是否值得进入系统记忆？

这是从具体到抽象的过程。

比如：

这次 Git 冲突很痛苦
→ 原因是 Agent 没有确认当前分支状态就开始操作
→ 高层原则：动手前先了解清楚现状，永远不要基于假设行动

向上走，是为了获得泛化能力。

它让系统不只是修补一个坑，而是理解一类坑。

向下走：具体化

抽象原则会进一步生成候选规则，并在特定场景下被编译、测试、影子运行，最终迁移到 RuleHost 中，约束下一次真实任务。

这是从抽象到具体的过程。

比如：

动手前先了解清楚现状
→ 修改核心文件前必须确认本地分支与远端同步
→ 工具执行前由 RuleHost 拦截未同步状态下的 Push

向下走，是为了获得执行确定性。

它让原则不再停留在口号里，而是在物理层面阻止错误发生。

真正的系统智慧，就是在这“向上”和“向下”之间不断往返。

向上，是归纳。

向下，是硬化。

再向上，是重新理解。

再向下，是重新部署。

PD 的软硬转换炼金术，本质上就是这样一条循环：

痛苦 → 诊断 → 原则 → 规则 → 拦截 → 反馈 → 剪枝 → 再进化

至此，PD 终于打通了从“哲学种子”到“物理防御”的关键链路。

我们不再把所有治理压力都压在上下文窗口里，而是把一部分高频、高危、可形式化的底线迁移到系统层。

但这一切努力的终点究竟在哪里？

我们大费周章地设计 Pain Signal、诊断者、编译流水线、Skill 能力包和 RuleHost，真的只是为了让 AI 帮我们写出几行更少出错的 CRUD 代码吗？

如果我们把格局再打开一点——当一个系统拥有了痛觉、反思能力、规则硬化能力和规则剪枝能力之后，它还能做什么？

它能不能不只是一个更好的“码农”，而是一个能够跨越时间尺度、持续演化的创业伙伴？

下一篇，我们将进入 PD 系统更宏观的一层：

时间刻度与演化引擎。

当一个系统拥有多尺度反馈回路时，它将如何从短期纠错，走向长期进化？

---

连载五《时间刻度与演化引擎：智能体的多尺度反馈系统》即将更新，敬请期待全系列完结篇。

---

— 一根芦苇