在一个成熟的AI Agent项目里，.claude/rules/目录往往会堆积大量为旧版模型编写的指令。当新的前沿模型发布时，它们本身就能正确处理大部分默认行为，但这些旧规则依然存在。它们不仅会占用每次消息的上下文（tokens），有时还会与模型改进后的默认行为产生冲突。
更糟糕的是，很少有人会去审计这些规则，因为目前业界对于“审计Prompt”究竟意味着什么，并没有一个普遍共识。
针对这一难题，本文提出了一种解决方案：为每条持久化规则附带两个强制性标签：
- WHY（为何存在）：明确该规则旨在纠正何种默认行为，以及是在哪个模型版本上观察到的。
- Retire when（何时退役）：定义该规则不再需要的可观测条件。
当有新的前沿模型发布时，开发者可以根据这些规则的“退役条件”进行一次快速审计，并归档那些不再适用的规则。这并非一个革命性的想法，而是在每条规则上付出的小而有意的成本，确保您的Prompt能“干净”地衰退，而不是无声无息地积累债务。
作者已在其GitHub项目 github.com/aman-bhandari/claude-code-agent-skills-framework 中实践了这一模式。目前，该框架中有四条规则已采用这种标签化管理，其余规则正在逐步完善中。
无人提及的失败模式
缺乏这种规范管理会导致以下问题：
设想一个项目进行了六个月，你的.claude/rules/目录已经有机地膨胀起来——每当Claude Code出现一些令人不悦的行为时，你就会添加一条规则来阻止它。例如：“提交前总是运行测试”、“文档中不要使用‘无缝’一词”、“优先使用显式类型提示而非推断类型”、“当被提问时，在调用工具前先说明将要执行的操作”等等，从第1条到第30条规则，内容大同小异。
某天，一个新的Claude模型发布了，例如Sonnet 4.7。它在Python方面表现更出色，无需指令便已倾向于使用显式类型提示，能够主动叙述其操作，甚至自行避免使用营销术语。然而，你的规则文件依然存在，并在每次消息中尽职地加载，告诉模型去做它本就会做的事情。这不仅偶尔会与模型新改进的默认行为发生冲突，还会浪费每次请求中数百个上下文Token。
你可能根本不会注意到这些问题。这些规则可能自Sonnet 4.5时代就已经存在，它们已经变成了“家具”——常驻、不起眼。没有人会进行审计，每个新的会话都会继承这份累积的“债务”。这就是所谓的“脚手架债务”（Scaffolding Debt）：为旧模型编写的规则，如今却扮演着承重结构的角色。它是提示工程领域中的“遗留代码”，每个人都害怕删除，因为没人记得它们当初为何被写入。
解决方案的形态
为了实现有效的提示治理，建议为每条新添加的规则附带两个强制性标签：
- WHY（为何存在）：
明确该规则旨在纠正何种默认模型行为，以及是在哪个模型版本上观察到的。
- Retire when（何时退役）：
定义该规则不再需要的可观测条件。
缺乏这两个标签的规则，将无法被证伪也无法被“退役”。这正是关键所在。一条没有明确指出它纠正了何种不良行为的规则，就无法测试在更新的模型版本中它是否依然有效或是否已被取代。