aude)
但在真正删减之前，还应该先建立评测。
因为 Anthropic 所说的是在其编程评测中没有观察到损失，不代表删除 80% 的规则适用于每个公司、每个 Agent 和每个业务场景。
客服、金融、医疗、生产运维和代码生成面对的风险完全不同。
更合理的方式是：
先建立一组真实任务和历史失败案例。
记录当前版本的完成率、错误率和人工干预率。
逐步删除重复和过度限制的规则。
比较修改前后的结果。
保留真正能降低风险的规则，删除只是在制造心理安全感的规则。
最后
这篇文章表面上讨论的是 Claude Code 的系统提示词，背后反映的其实是人类与模型协作关系的变化。
模型能力弱的时候，人类需要把每一步都写清楚。
模型能力增强以后，人类更重要的工作不再是替它决定每一步，而是：
定义目标。
提供真实环境。
设计工具。
划定边界。
建立反馈。
验证结果。
这和管理一个团队很像。
面对经验不足的人，需要给详细 SOP；面对能力强的人，继续事无巨细地规定每一个动作，反而会降低他的判断力和创造力。
因此，模型越强，上下文工程越不应该追求“把所有事情都写进去”。
真正优秀的上下文，不是信息最多、规则最细，而是：
该出现的信息，在正确的时候出现；该由模型判断的，留给模型判断；该由系统保证的，绝不只依赖模型自觉。
提示词工程没有消失。
它只是从“教模型说什么”，升级成了“设计模型如何工作”。
@aigc1024