2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
任何成熟的 .claude/rules/ 目录都充斥着为旧版模型编写的指令。较新的前沿模型能够自行正确处理大多数此类默认行为——但旧规则依然存在，在每条消息中占用上下文空间，有时甚至与模型改进后的默认行为相冲突。没有人去审查这些规则，因为大家对于“审查提示词”究竟意味着什么并未达成共识。
本文提出了一种解决方案：每条持久化规则都应携带一个 原因（WHY） 标签（说明该规则旨在纠正何种默认行为）和一个 退役条件（Retire when） 标签（说明在该规则不再具备存在价值时可观察到的具体条件）。当新的前沿模型发布时，你可以根据规则的退役条件进行简短审查，并归档那些不再适用的规则。这并非革命性的理念。这是一种针对每条规则支付的微小且刻意的成本，目的是让你的提示词能够干净地迭代更新，而不是在无声无息中不断累积冗余。
我在 github.com/aman-bhandari/claude-code-agent-skills-framework 中实践了这一模式。目前其中有四条规则带有这些标签，其余规则正在逐步扩展补充。
无人指出的失效模式
以下是缺乏这种纪律性时会发生的情况。
项目进行到六个月时。你的 .claude/rules/ 目录已经自然增长——每当克劳德代码（Claude Code）做出令人恼火的举动，你就会编写一条规则来防止它再次发生。规则一：“提交前始终运行测试。”规则二：“不要在文档中使用‘无缝’一词。”规则三：“优先使用显式类型提示而非推断类型。”规则四：“当被问及问题时，在调用工具之前先说明你打算做什么。”规则五至规则三十：类似的内容。
某天，一个新的克劳德（Claude）模型发布了——比如索内特（Sonnet）4.7 版本。它在 Python 方面表现更佳。它无需告知便已倾向于使用显式类型提示。它已经会自动叙述其操作。它已经能自行避免使用营销辞令。但你的规则文件依然在那里，恪尽职守地在每条消息中被加载，指示模型去做它本来就会做的事情，同时偶尔还会与其新改进的默认行为发生冲突，并在每次请求中浪费你数百个 tokens 的上下文空间。
你并未察觉。这些规则自索内特（Sonnet）4.5 时代起就已存在。它们已变得如同家具一般习以为常。没有人执行审查。每个新会话都继承了这些累积的技术债务。
这就是脚手架债务——为旧版模型编写的规则在今天却表现得如同承重基础设施一般。这是提示词工程版本的遗留代码，每个人都因不记得当初为何编写而不敢删除。
修复方案的形式
你添加的每条规则都携带两个强制标签：
**原因：** <该规则纠正的默认模型行为，以及观察到该行为的模型版本>
**退役条件：** <不再需要该规则时可观察到的条件>
如果没有这两个标签，该规则就无法被证伪，也无法自然淘汰。那是 t
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
