Claude Code 为前沿模型大幅精简系统提示词，让我开始重新检查内容 Skill 里不断累积的规则，以及内容系统下一阶段应该把能力放在哪里。

TL;DR： Claude Code 为 Opus 5、Fable 5 这类前沿模型删掉了超过 80% 的系统提示词，编码评测没有测到能力损失。这让我开始重新检查自己的内容创作系统：Skill 要学会删除旧规则，更多职责应该交给上下文、工具、状态、验证和反馈。

§7 月 24 日的一个信号

7 月 24 日，Claude Code 工程师 Thariq Shihipar 发布文章，复盘团队怎样为新一代模型调整上下文。其中有个数字很扎眼：Claude Code 为 Opus 5、Fable 5 这类模型删掉了超过 80% 的系统提示词，编码评测没有观察到可测量的能力损失。

这项结果有清楚的边界。它来自 Claude Code，观察的是编码评测，只适用于能力更强的模型。旧模型仍然使用更完整的系统提示词。

团队发现，早期模型需要大量示例、重复提醒和绝对规则。新模型已经能从代码、工具和任务背景里推断很多判断。旧示例可能压窄探索范围，互相冲突的指令还会增加负担。

Anthropic 开始减少硬约束，让工具接口表达意图，把详细知识放进按需调用的 Skill，再让模型结合现场做判断。

我看到这里，马上想到了自己的内容创作系统。

§Skill 也会积累技术债

过去几个月，我把选题、简报、写作、标题、配图、检查、发布和归档拆成了不同 Skill。这套方法确实有效，原本依赖个人经验的内容生产，第一次变成 Agent 可以理解和执行的流程。这里的 Agent，指能调用工具完成多步任务的 AI。

开头不够好，我会补一条钩子规则。文字太像 AI，我会继续增加禁用句式。事实没有核验，再加一道强制检查。一次发布效果不好，又想塞进一套用户痛点分析。

每条规则单独看都有理由。时间一长，Skill 同时承担任务说明、写作方法、工具调用、质量检查、失败恢复和用户偏好。重复开始出现，例外越来越多，规则之间也会打架。

我原本以为，Skill 越完整，系统越成熟。

做下来有点不踏实。一个只能增加规则、不能删除规则的系统，迟早会被自己的历史经验拖住。

Claude Code 的变化给了我一个更具体的检查方法。以后遇到失败，我会先判断问题发生在哪里：

这样做以后，Prompt 不用替整个系统背责任。

隐私边界、发布确认、事实核验和品牌口吻仍然要留下。这些内容不能指望模型临场猜对。错误如果不会自动暴露，代价又很高，这类规则就是系统的承重墙。

其他内容可以移走。详细案例放进参考资料，需要时再读。检查方法做成独立 Skill，只在发布前调用。任务进度交给状态系统，历史反馈进入记忆和数据层。

删提示词的前提，是其他层已经能接住这些职责。

我把过去这套方法看成内容创作系统 1.0。它解决 Agent 会不会做，把经验写成 Prompt 和 Skill，让模型按流程完成内容。

下一阶段要解决能不能持续交付。内容从哪里来，哪些材料需要加载，事实怎样核验，任务怎样恢复，结果怎样验收，发布反馈怎样进入下一轮，这些问题靠一份更长的 Skill 很难解决。

它们需要一套更完整的 Harness，也就是围绕模型搭建的运行系统。Prompt 继续负责原则和必要边界，上下文、工具、记忆、状态、评测、权限和反馈各自回到合适的位置。

内容系统 1.0 更关注单次生成质量，2.0 还要守住长期交付的下限。

我不会照着 Claude Code 的数字，直接砍掉 80% 的 Skill。内容没有编译器，品牌口吻和事实偏差也不一定会立刻报错，盲删同样危险。下一步会从审计开始。

每条规则都要能回答三个问题：它解决过什么真实失败，模型能不能从现有材料自行判断，删掉以后用什么结果验证。

说不清来源的规则进入删除候选。只在特定任务里有用的内容改成按需加载。涉及隐私、发布、事实和权限的边界继续保留。

我现在还不知道最终能删掉多少，这需要拿真实任务反复测试。方向已经清楚了：模型升级以后，系统也要主动卸下旧脚手架。真正拉开差距的，会是怎样组织上下文、工具、验证和反馈，让模型能力稳定进入真实业务。