关于AIGC人工智能、思维方式、知识拓展，能力提升等。投稿/合作： @inside1024_bot
AIGC 领域的最新工具、开源项目以及行业大事件
AIGC 领域的最新工具、开源项目以及行业大事件
aude)
但在真正删减之前，还应该先建立评测。
因为 Anthropic 所说的是在其编程评测中没有观察到损失，不代表删除 80% 的规则适用于每个公司、每个 Agent 和每个业务场景。
客服、金融、医疗、生产运维和代码生成面对的风险完全不同。
更合理的方式是：
先建立一组真实任务和历史失败案例。
记录当前版本的完成率、错误率和人工干预率。
逐步删除重复和过度限制的规则。
比较修改前后的结果。
保留真正能降低风险的规则，删除只是在制造心理安全感的规则。
最后
这篇文章表面上讨论的是 Claude Code 的系统提示词，背后反映的其实是人类与模型协作关系的变化。
模型能力弱的时候，人类需要把每一步都写清楚。
模型能力增强以后，人类更重要的工作不再是替它决定每一步，而是：
定义目标。
提供真实环境。
设计工具。
划定边界。
建立反馈。
验证结果。
这和管理一个团队很像。
面对经验不足的人，需要给详细 SOP；面对能力强的人，继续事无巨细地规定每一个动作，反而会降低他的判断力和创造力。
因此，模型越强，上下文工程越不应该追求“把所有事情都写进去”。
真正优秀的上下文，不是信息最多、规则最细，而是：
该出现的信息，在正确的时候出现；该由模型判断的，留给模型判断；该由系统保证的，绝不只依赖模型自觉。
提示词工程没有消失。
它只是从“教模型说什么”，升级成了“设计模型如何工作”。
@aigc1024
但在真正删减之前，还应该先建立评测。
因为 Anthropic 所说的是在其编程评测中没有观察到损失，不代表删除 80% 的规则适用于每个公司、每个 Agent 和每个业务场景。
客服、金融、医疗、生产运维和代码生成面对的风险完全不同。
更合理的方式是：
先建立一组真实任务和历史失败案例。
记录当前版本的完成率、错误率和人工干预率。
逐步删除重复和过度限制的规则。
比较修改前后的结果。
保留真正能降低风险的规则，删除只是在制造心理安全感的规则。
最后
这篇文章表面上讨论的是 Claude Code 的系统提示词，背后反映的其实是人类与模型协作关系的变化。
模型能力弱的时候，人类需要把每一步都写清楚。
模型能力增强以后，人类更重要的工作不再是替它决定每一步，而是：
定义目标。
提供真实环境。
设计工具。
划定边界。
建立反馈。
验证结果。
这和管理一个团队很像。
面对经验不足的人，需要给详细 SOP；面对能力强的人，继续事无巨细地规定每一个动作，反而会降低他的判断力和创造力。
因此，模型越强，上下文工程越不应该追求“把所有事情都写进去”。
真正优秀的上下文，不是信息最多、规则最细，而是：
该出现的信息，在正确的时候出现；该由模型判断的，留给模型判断；该由系统保证的，绝不只依赖模型自觉。
提示词工程没有消失。
它只是从“教模型说什么”，升级成了“设计模型如何工作”。
@aigc1024
模型越聪明，越不能把它当成流程机器人
Anthropic 最近发布了一篇关于上下文工程的文章。
随着 Claude Fable 5 和 Opus 5 发布，他们删除了 Claude Code 超过 80% 的系统提示词，但在内部编程评测中没有观察到明显损失。过去那些用来“保护模型”的详细规则，随着模型能力提升，开始变成限制模型能力的枷锁。(Claude)
很多人看到这里，可能会得出一个结论：
提示词工程已经不重要了。
但我认为，更准确的说法是：
提示词工程正在从“写更多指令”，转向“设计更好的上下文结构”。
一、为什么模型越强，规则反而要越少？
早期模型判断力较弱，经常会出现过度注释、擅自修改文件、遗漏验证步骤、错误调用工具等问。
为了弥补模型能力的不足，人们只能不断增加规则：
不要写太多注释。
不要修改无关文件。
修改前必须先阅读代码。
完成后必须运行测试。
不要创建额外文档。
不要执行危险命令。
这些规则在当时是有价值的，因为它们相当于模型的“外置判断系统”。
但随着模型能力提升，模型已经能够从代码风格、目录结构、用户意图和任务目标中推断出很多事情。此时继续保留过去的详细约束，就可能产生三个问。
第一是规则冲突。
系统提示词说“不要写注释”，Skill 说“为复杂逻辑增加注释”，用户又说“保持和原项目一致”。模型需要先花费推理能力判断到底听谁的。
第二是注意力稀释。
上下文窗口虽然越来越长，但模型真正需要解决的是：哪些信息与当前任务最相关。大量通用规则会挤占模型对代码、需求和异常信息的关注。
第三是能力折损。
一些规则原本是为了防止旧模型犯错，但新模型已经能够处理例外。继续强制执行规则，就相当于要求一个高级工程师严格按照新员工操作手册工作。
Anthropic 过去要求 Claude 默认不写注释，新版则只保留一句更高层的原则：
写出与周围代码一致的代码，匹配它的注释密度、命名和惯用方式。
前者是在规定动作，后者是在定义判断标准。(Claude)
这背后其实是一种管理方式的变化：
过去是给模型 SOP，现在是给模型目标、边界和判断依据。
二、规则不是越少越好，而是要放在正确的位置
“精简系统提示词”不等于“不要规则”。
真正应该删除的，是模型可以从环境中自行推断出来的规则，以及在不同上下文层里被重复描述的规则。
而以下几类内容仍然需要明确保留：
不可逆操作的边界。
安全、隐私与合规要求。
明确的业务目标和角色定位。
模型无法从代码中发现的特殊约定。
容易踩坑但没有显性提示的历史问。
例如，“保持代码风格一致”可以交给模型判断；但“未经确认不得删除生产数据库”就不能只依赖模型的判断力，而应该通过权限、审批、沙箱和工具限制来保证。
所以未来的 Agent 不是没有约束，而是把约束分成两种：
软约束交给模型理解，硬约束交给系统执行。
能通过权限控制的，不要只写在提示词里。
能通过参数类型保证的，不要依靠自然语言提醒。
能通过测试验证的，不要要求模型“务必认真检查”。
能通过状态机限制的，不要让模型在无限的行动空间里自由选择。
三、从“给示例”到“设计接口”
过去教模型使用工具，最常见的方法是给它几个调用示例。
但示例存在一个问：它不仅告诉模型怎么做，也在无形中限制模型只能在示例附近探索。
更好的方法，是把工具本身设计得足够清晰。
例如，一个任务工具的状态参数只允许：
pending
in_progress
completed
这三个枚举值本身就在向模型表达任务的生命周期。
再规定同一时间只能有一个任务处于 in_progress，模型自然就能理解任务切换和进度管理，而不需要再写十几个调用示例。Anthropic 将这种变化总结为：从提供示例，转向设计具有表达力的接口。(Claude)
这件事对 Agent 产品特别重要。
很多 Agent 不稳定，并不一定是模型能力不够，而是工具设计得太模糊：
参数含义不清楚。
多个工具能力重叠。
返回结果没有固定结构。
失败原因无法被模型识别。
工具名称无法表达真实用途。
权限和使用条件只藏在提示词里。
于是开发者只能继续增加提示词，试图用自然语言弥补糟糕的接口设计。
但真正优秀的 Agent 架构，应该让工具的名称、参数、返回结构和权限边界本身就构成上下文。
最好的提示词，有时不是一段文字，而是一个设计良好的接口。
四、上下文窗口不是仓库，而是工作台
过去构建 Agent 时，大家很容易产生一种冲动：
把所有可能有用的信息都提前塞进上下文。
业务规则、操作手册、历史案例、代码规范、工具说明、异常处理、测试流程，全部放进系统提示词或者 CLAUDE.md。
这样看起来信息非常完整，但结果往往是模型每次处理一个小任务，都要背着一整套知识库上路。
Anthropic 现在强调的是“渐进式披露”：
系统提示词只放长期、通用、必须始终存在的信息。
CLAUDE.md只描述仓库用途、核心约定和真正难以发现的坑。
代码审查、发布、验证、数据迁移等独立流程拆成 Skills。
具体任务需要的设计稿、代码、测试和资料，通过引用或搜索按需加载。
工具的完整定义，也可以在真正调用时再载入。
Claude Code 的 Skills 正是采用这种方式：Skill 的主体只有在相关任务触发时才加载，因此长流程和参考资料不会在每次会开始时持续占用上下文。(Claude)
这其实说明，上下文管理正在越来越像计算机的存储层级：
系统提示词类似操作系统内核。
CLAUDE.md类似项目配置。
Skills 类似按需加载的程序模块。
Memory 类似跨会的长期记忆。
当前对类似工作内存。
引用文件和检索结果类似临时调入的外部数据。
问不再是“模型知道多少”，而是：
它能否在正确的时间，获取正确的信息。
所以长上下文并不能自动解决上下文问。
一个 Agent 即使拥有数百万 Token 的窗口，如果把过期规则、重复规则和互相冲突的规则全部装进去，仍然会表现得很差。
上下文工程的核心不是扩容，而是调度。
五、从简单文档到“可执行的上下文”
Anthropic 还提到一个很重要的变化：
过去人们主要给模型 Markdown 需求文档，现在可以直接给它 HTML、代码、测试文件、函数实现和评分标准。
这意味着“上下文”不再只是文字说明，而可以是能够被执行、比较和验证的对象。(Claude)
例如要实现一个页面，与其写几百字描述：
顶部有导航栏，左侧有菜单，卡片之间保持一定间距，按钮使用圆角……
不如直接提供一个 HTML 原型。
要迁移一个函数，与其解释它应该如何工作，不如直接引用另一个项目中的正确实现。
要告诉模型什么叫“好的 API”，与其写一些抽象原则，不如给它：
现有优秀 API。
反面案例。
测试用例。
验收标准。
评分 Rubric。
这代表需求表达正在从“自然语言描述”走向“多模态、结构化、可验证的参考环境”。
未来最有效的上下文，往往不是一句“请认真完成”，而是：
这里是目标。
这里是参考实现。
这里是禁止修改的边界。
这里是测试方法。
这里是验收标准。
模型拥有判断空间，但结果可以被外部系统验证。
六、从提示词工程，走向环境工程
把这些变化继续往前推一步，会发现 Agent 开发正在经历三个阶段。
第一阶段是提示词工程。
重点是研究一句怎么写，角色怎么设定，示例怎么组织，怎样才能让模型输出理想结果。
第二阶段是上下文工程。
重点变成如何组织系统提示词、Memory、Skills、知识库、工具说明、任务历史和引用文件。
第三阶段可能是环境工程。
不再主要通过语言要求模型怎么做，而是设计一个让模型自然做对事情的环境：
工具职责清晰。
权限边界明确。
信息可以按需检索。
关键状态能够持续保存。
错误可以被观察。
结果可以被测试。
失败后可以自动修正。
高风险操作需要审批。
也就是说，未来 Agent 的质量，越来越不只取决于模型和提示词，还取决于模型所处的“数字工作环境”。
同一个模型，放在一个工具混乱、规则冲突、信息过载的环境里，可能表现得像一个能力一般的助手。
放在一个接口清晰、权限合理、反馈及时、资料可检索的环境里，它才可能表现得像一个成熟员工。
七、自动记忆并不代表可以放弃知识管理
Anthropic 从手动写入 CLAUDE.md，逐渐转向自动记忆，这确实可以降低维护成本。
但自动记忆也会带来新的问：
模型可能记住错误结论。
临时偏好可能被误认为长期规则。
旧项目经验可能污染新项目。
过期信息可能长期保留。
个人偏好和团队规范可能混在一起。
所以 Memory 不能只是“能写进去”，还需要有完整的治理机制：
记忆从哪里来？
适用于个人、项目还是组织？
有效期多长？
是否有证据和来源？
什么时候应该更新？
谁可以查看和删除？
发生冲突时谁优先？
未来真正复杂的 Agent 系统，需要的不只是 Memory，而是记忆的生命周期管理。
八、如何重新整理自己的上下文系统？
可以先把现有上下文里的每一条信息重新分类。
始终有效、与产品角色有关的内容，放在系统提示词。
整个项目长期有效、模型又无法自行发现的约定，放在 CLAUDE.md或 AGENT.md。
代码审查、部署、测试、调研等可复用流程，拆成 Skills。
本次任务才需要的需求、代码和设计稿，通过引用按需加载。
用户习惯、长期偏好和历史经验，放进 Memory。
安全、权限、审批和不可逆操作，交给代码和系统机制控制。
然后重点检查三件事：
有没有同一条规则在多个地方重复出现？
有没有两条规则在某些场景下互相冲突？
有没有模型通过阅读代码和目录就能理解、却仍然被写进规则的废？
Claude Code 现在的 /doctor 会检查未使用但持续消耗上下文的 Skills、MCP 和插件，识别重复的 CLAUDE.md内容，并建议删除模型可以直接从代码库推断的信息。(Cl
Anthropic 最近发布了一篇关于上下文工程的文章。
随着 Claude Fable 5 和 Opus 5 发布，他们删除了 Claude Code 超过 80% 的系统提示词，但在内部编程评测中没有观察到明显损失。过去那些用来“保护模型”的详细规则，随着模型能力提升，开始变成限制模型能力的枷锁。(Claude)
很多人看到这里，可能会得出一个结论：
提示词工程已经不重要了。
但我认为，更准确的说法是：
提示词工程正在从“写更多指令”，转向“设计更好的上下文结构”。
一、为什么模型越强，规则反而要越少？
早期模型判断力较弱，经常会出现过度注释、擅自修改文件、遗漏验证步骤、错误调用工具等问。
为了弥补模型能力的不足，人们只能不断增加规则：
不要写太多注释。
不要修改无关文件。
修改前必须先阅读代码。
完成后必须运行测试。
不要创建额外文档。
不要执行危险命令。
这些规则在当时是有价值的，因为它们相当于模型的“外置判断系统”。
但随着模型能力提升，模型已经能够从代码风格、目录结构、用户意图和任务目标中推断出很多事情。此时继续保留过去的详细约束，就可能产生三个问。
第一是规则冲突。
系统提示词说“不要写注释”，Skill 说“为复杂逻辑增加注释”，用户又说“保持和原项目一致”。模型需要先花费推理能力判断到底听谁的。
第二是注意力稀释。
上下文窗口虽然越来越长，但模型真正需要解决的是：哪些信息与当前任务最相关。大量通用规则会挤占模型对代码、需求和异常信息的关注。
第三是能力折损。
一些规则原本是为了防止旧模型犯错，但新模型已经能够处理例外。继续强制执行规则，就相当于要求一个高级工程师严格按照新员工操作手册工作。
Anthropic 过去要求 Claude 默认不写注释，新版则只保留一句更高层的原则：
写出与周围代码一致的代码，匹配它的注释密度、命名和惯用方式。
前者是在规定动作，后者是在定义判断标准。(Claude)
这背后其实是一种管理方式的变化：
过去是给模型 SOP，现在是给模型目标、边界和判断依据。
二、规则不是越少越好，而是要放在正确的位置
“精简系统提示词”不等于“不要规则”。
真正应该删除的，是模型可以从环境中自行推断出来的规则，以及在不同上下文层里被重复描述的规则。
而以下几类内容仍然需要明确保留：
不可逆操作的边界。
安全、隐私与合规要求。
明确的业务目标和角色定位。
模型无法从代码中发现的特殊约定。
容易踩坑但没有显性提示的历史问。
例如，“保持代码风格一致”可以交给模型判断；但“未经确认不得删除生产数据库”就不能只依赖模型的判断力，而应该通过权限、审批、沙箱和工具限制来保证。
所以未来的 Agent 不是没有约束，而是把约束分成两种：
软约束交给模型理解，硬约束交给系统执行。
能通过权限控制的，不要只写在提示词里。
能通过参数类型保证的，不要依靠自然语言提醒。
能通过测试验证的，不要要求模型“务必认真检查”。
能通过状态机限制的，不要让模型在无限的行动空间里自由选择。
三、从“给示例”到“设计接口”
过去教模型使用工具，最常见的方法是给它几个调用示例。
但示例存在一个问：它不仅告诉模型怎么做，也在无形中限制模型只能在示例附近探索。
更好的方法，是把工具本身设计得足够清晰。
例如，一个任务工具的状态参数只允许：
pending
in_progress
completed
这三个枚举值本身就在向模型表达任务的生命周期。
再规定同一时间只能有一个任务处于 in_progress，模型自然就能理解任务切换和进度管理，而不需要再写十几个调用示例。Anthropic 将这种变化总结为：从提供示例，转向设计具有表达力的接口。(Claude)
这件事对 Agent 产品特别重要。
很多 Agent 不稳定，并不一定是模型能力不够，而是工具设计得太模糊：
参数含义不清楚。
多个工具能力重叠。
返回结果没有固定结构。
失败原因无法被模型识别。
工具名称无法表达真实用途。
权限和使用条件只藏在提示词里。
于是开发者只能继续增加提示词，试图用自然语言弥补糟糕的接口设计。
但真正优秀的 Agent 架构，应该让工具的名称、参数、返回结构和权限边界本身就构成上下文。
最好的提示词，有时不是一段文字，而是一个设计良好的接口。
四、上下文窗口不是仓库，而是工作台
过去构建 Agent 时，大家很容易产生一种冲动：
把所有可能有用的信息都提前塞进上下文。
业务规则、操作手册、历史案例、代码规范、工具说明、异常处理、测试流程，全部放进系统提示词或者 CLAUDE.md。
这样看起来信息非常完整，但结果往往是模型每次处理一个小任务，都要背着一整套知识库上路。
Anthropic 现在强调的是“渐进式披露”：
系统提示词只放长期、通用、必须始终存在的信息。
CLAUDE.md只描述仓库用途、核心约定和真正难以发现的坑。
代码审查、发布、验证、数据迁移等独立流程拆成 Skills。
具体任务需要的设计稿、代码、测试和资料，通过引用或搜索按需加载。
工具的完整定义，也可以在真正调用时再载入。
Claude Code 的 Skills 正是采用这种方式：Skill 的主体只有在相关任务触发时才加载，因此长流程和参考资料不会在每次会开始时持续占用上下文。(Claude)
这其实说明，上下文管理正在越来越像计算机的存储层级：
系统提示词类似操作系统内核。
CLAUDE.md类似项目配置。
Skills 类似按需加载的程序模块。
Memory 类似跨会的长期记忆。
当前对类似工作内存。
引用文件和检索结果类似临时调入的外部数据。
问不再是“模型知道多少”，而是：
它能否在正确的时间，获取正确的信息。
所以长上下文并不能自动解决上下文问。
一个 Agent 即使拥有数百万 Token 的窗口，如果把过期规则、重复规则和互相冲突的规则全部装进去，仍然会表现得很差。
上下文工程的核心不是扩容，而是调度。
五、从简单文档到“可执行的上下文”
Anthropic 还提到一个很重要的变化：
过去人们主要给模型 Markdown 需求文档，现在可以直接给它 HTML、代码、测试文件、函数实现和评分标准。
这意味着“上下文”不再只是文字说明，而可以是能够被执行、比较和验证的对象。(Claude)
例如要实现一个页面，与其写几百字描述：
顶部有导航栏，左侧有菜单，卡片之间保持一定间距，按钮使用圆角……
不如直接提供一个 HTML 原型。
要迁移一个函数，与其解释它应该如何工作，不如直接引用另一个项目中的正确实现。
要告诉模型什么叫“好的 API”，与其写一些抽象原则，不如给它：
现有优秀 API。
反面案例。
测试用例。
验收标准。
评分 Rubric。
这代表需求表达正在从“自然语言描述”走向“多模态、结构化、可验证的参考环境”。
未来最有效的上下文，往往不是一句“请认真完成”，而是：
这里是目标。
这里是参考实现。
这里是禁止修改的边界。
这里是测试方法。
这里是验收标准。
模型拥有判断空间，但结果可以被外部系统验证。
六、从提示词工程，走向环境工程
把这些变化继续往前推一步，会发现 Agent 开发正在经历三个阶段。
第一阶段是提示词工程。
重点是研究一句怎么写，角色怎么设定，示例怎么组织，怎样才能让模型输出理想结果。
第二阶段是上下文工程。
重点变成如何组织系统提示词、Memory、Skills、知识库、工具说明、任务历史和引用文件。
第三阶段可能是环境工程。
不再主要通过语言要求模型怎么做，而是设计一个让模型自然做对事情的环境：
工具职责清晰。
权限边界明确。
信息可以按需检索。
关键状态能够持续保存。
错误可以被观察。
结果可以被测试。
失败后可以自动修正。
高风险操作需要审批。
也就是说，未来 Agent 的质量，越来越不只取决于模型和提示词，还取决于模型所处的“数字工作环境”。
同一个模型，放在一个工具混乱、规则冲突、信息过载的环境里，可能表现得像一个能力一般的助手。
放在一个接口清晰、权限合理、反馈及时、资料可检索的环境里，它才可能表现得像一个成熟员工。
七、自动记忆并不代表可以放弃知识管理
Anthropic 从手动写入 CLAUDE.md，逐渐转向自动记忆，这确实可以降低维护成本。
但自动记忆也会带来新的问：
模型可能记住错误结论。
临时偏好可能被误认为长期规则。
旧项目经验可能污染新项目。
过期信息可能长期保留。
个人偏好和团队规范可能混在一起。
所以 Memory 不能只是“能写进去”，还需要有完整的治理机制：
记忆从哪里来？
适用于个人、项目还是组织？
有效期多长？
是否有证据和来源？
什么时候应该更新？
谁可以查看和删除？
发生冲突时谁优先？
未来真正复杂的 Agent 系统，需要的不只是 Memory，而是记忆的生命周期管理。
八、如何重新整理自己的上下文系统？
可以先把现有上下文里的每一条信息重新分类。
始终有效、与产品角色有关的内容，放在系统提示词。
整个项目长期有效、模型又无法自行发现的约定，放在 CLAUDE.md或 AGENT.md。
代码审查、部署、测试、调研等可复用流程，拆成 Skills。
本次任务才需要的需求、代码和设计稿，通过引用按需加载。
用户习惯、长期偏好和历史经验，放进 Memory。
安全、权限、审批和不可逆操作，交给代码和系统机制控制。
然后重点检查三件事：
有没有同一条规则在多个地方重复出现？
有没有两条规则在某些场景下互相冲突？
有没有模型通过阅读代码和目录就能理解、却仍然被写进规则的废？
Claude Code 现在的 /doctor 会检查未使用但持续消耗上下文的 Skills、MCP 和插件，识别重复的 CLAUDE.md内容，并建议删除模型可以直接从代码库推断的信息。(Cl
