先说结论：值得删的是重复和过期内容，不是责任边界

这篇官方文章最有价值的地方，不是给出一个可以复制的“删 80%”指标，而是承认上下文会随着模型能力变化而变成技术债。系统提示词、项目说明、Skills、记忆和工具描述可能同时讲一件事，甚至互相冲突。模型越需要在这些规则之间做仲裁，留给任务本身的注意力就越少。Anthropic 给出的方向是：让通用模型判断匹配周围代码风格，用参数和枚举设计工具接口，把代码审查、验证等专项知识放进按需调用的 Skill，并让高保真参考物承担一部分说明工作。

中文创作者也会遇到同样的问题。长期提示词里常常混着账号定位、语气、平台规格、禁用词、历史案例、每日步骤和临时活动信息。更好的整理方式不是一次性把它压成一句“写得好一点”，而是把稳定身份留在短入口，把平台格式放进模板，把来源核验和发布检查做成清单，把活动资料按任务加载。这样减少的是无关上下文，而不是验收标准。

做一次能被复现的“上下文减重”

先挑十个真实任务，覆盖选题、资料整理、初稿、事实核查、标题改写和发布前检查。保存当前配置作为基线，记录提示词 token、首轮通过率、引用错误、人工返工分钟数和是否触发危险动作。然后只删三类内容：在工具定义里已经出现的重复说明、模型从仓库直接可见的显然信息、已经过期或互相冲突的例子。不要同时换模型，否则无法判断改进来自哪里。

第二轮把“如何做”改成“交付物怎样算合格”。例如，与其列出二十条写作动作，不如提供一张已通过审校的参考卡、一份来源字段 schema 和一组失败示例。对模型可自由判断的部分给出品味和目标，对安全关键部分仍使用明确的允许范围、审批点和禁止动作。官方文章自己也强调，Skills 不应过度约束，“高度重要领域”除外。

最后比较结果，而不是只看上下文长度。如果 token 下降但漏引来源、错发内容或返工上升，这次精简就是失败；如果准确率稳定、加载更快且规则冲突减少，才值得推广。真正可传播的内容应是一份带前后配置和任务数据的实验报告，而不是把厂商内部的 80% 变成新的提示词玄学。