前沿科技洞见 · 2026-07-26

把绊马索拆了：Claude Code 删除 80% 系统提示词，和一场正在收敛的行业共识

正在发生的事很多，这件帮你看过了

2026-07-26

触发新闻：2026年7月24日，Claude Opus 5 上线当天，Anthropic 技术团队成员 Thariq Shihipar 在 X 上和 claude.com/blog 官方文章中披露，团队为 Claude 5 世代模型删除了 Claude Code 中约 80% 的系统提示词，且在编码评测上"没有可测量的性能损失"。

一句话定义

Anthropic 用一个具体数字——80%——证实了一个原本还停留在直觉层面的判断：当模型的推理能力跨过某个门槛，那些当初为了防止它"犯最坏错误"而堆进系统提示词里的规则，本身会变成新的负资产，模型的表现不是被规则撑起来的，而是被规则拖累的。

这不是一次孤立的产品优化。把时间线拉开看，它是"提示词工程"这门手艺从 2021 年诞生到 2026 年的一次阶段性终局——而且几乎在同一个月，OpenAI、GitHub、Replit 分别用各自的方式说出了同一句话。

纵向分析：从一个内部工具，到"给模型松绑"

起点：安全研究团队里长出来的一个玩具

Claude Code 的故事不是从"我们要做一个编程助手"开始的。它的雏形是 2021 年前后 Anthropic 内部 AI 安全对齐研究项目里的一个副产品，工程师 Eli Tran-Johnson 写了个粗糙的命令行工具，内部叫"clide"，让同事可以用对话的方式改代码——它诞生的初衷根本不是效率工具，而是安全团队用来观察模型行为的手边道具。

真正把它推向"agentic programming"方向的是 Boris Cherny。2024年1月 Anthropic 成立 Labs 团队，同年9月 Cherny 加入，带着一句后来被反复引用的信条：不要为今天的模型构建，要为六个月后的模型构建。他后来在 X 上回忆自己第一次用 clide 粘贴一个 issue 描述、工具直接吐出一个完整 Pull Request 时的反应："我从未见过这样的东西……感觉像是未来。"这句话本身值得玩味——它说明团队从第一天起就默认模型能力会持续跃升，工具设计要为"还没到来的能力"预留空间，而不是死死钉在当前模型的短板上打补丁。这个假设后来直接决定了 2026年那次 80% 的删减：既然团队一直相信模型会变强，那当它真的变强了，就该兑现"少管一点"的承诺。

从研究预览到 GA：一条陡峭得反常的曲线

Claude Code 以"研究预览"形式正式面世是 2025年2月24日，跟 Claude 3.7 Sonnet 同时发布，当时功能很朴素——聊天、编辑文件、跑 bash 命令。三个月后，2025年5月22日，随 Claude 4 一起转为正式可用（GA）。

真正让人意外的是采用速度。GA 后约六个月，2025年11月，Claude Code 的年化运行率收入（ARR）突破 10 亿美元。作为参照，ChatGPT 达到类似量级用了约 11 个月，Slack 花了四年以上。到 2026年2月，这个数字翻倍到超过 25 亿美元；再到 2026年5月，攀升至约 80 亿美元。第三方分析估算，Claude Code 已经写下了全球公开 GitHub 提交量的约 4%——这不是一个小众开发者工具的体量，是一个已经嵌入行业日常工作流的基础设施。

这条曲线之所以重要，是因为它解释了 Anthropic 为什么"敢"在 2026年7月做这次激进的精简：当一个产品还在小范围试验阶段，工程团队天然倾向于用详尽规则兜底，因为出错的代价看起来更大；但当它已经是数十亿美元 ARR、被数百万开发者依赖的基础设施，团队反而有底气把决策权交还给模型——因为这时候"规则冲突拖累表现"造成的损失，已经比"模型偶尔犯错"更值得担心。

两个平行长出来的骨架：MCP 和"上下文工程"话语

在 Claude Code 自己往前走的同时，两条平行线在悄悄搭建后来支撑"删除系统提示词"这件事的骨架。

第一条是工程侧的：Model Context Protocol（MCP），由 Anthropic 工程师 David Soria Parra 与 Justin Spahr-Summers 于 2024年11月25日发布，是一套连接 AI 与外部工具/数据源的开放标准。它本身跟提示词精简没有直接关系，但它确立了一个后来变得至关重要的设计原则：模型需要的"上下文"不必全部写死在提示词里，可以做成按需调用的外部资源。这条思路在 2025年10月16日迎来了下一站——Anthropic 正式发布 Agent Skills，把"验证""复杂工作流"这类原本只能塞进系统提示词的内容，拆成可以按需激活的独立技能包。Simon Willison 当时的评价是"Claude Skills 可能比 MCP 更重要"，这句话现在回看有点像预言：2026年7月这次 80% 删减里，被移出主系统提示词、改造成独立 Skill 的，正是代码审查和验证类指令。

第二条是话语侧的："prompt engineering"这个词本身开始被质疑。2025年6月18日，Shopify CEO Tobi Lütke 在 X 上写下一句后来被广泛引用的话："我更喜欢'context engineering'这个术语，而不是 prompt engineering。它更准确地描述了核心技能：为任务提供所有能让 LLM 合理解决它的上下文的艺术。"大约一周后，Andrej Karpathy 转发支持，补了一句更技术流的解释："人们把 prompt 和日常使用中给 LLM 的简短任务描述联系起来。而在每一个工业级 LLM 应用里，context engineering 才是填充上下文窗口这门精妙的艺术与科学。"Simon Willison 紧接着在 6月27日发博客系统化了这个概念。几个月内，这个词被印上了一本 O'Reilly 图书的封面，被 LangChain 结构化成一套方法论，据说连 Gartner 的简报里都出现了"context engineering is in, prompt engineering is out"这种表述。

这两条线在 2025年9月29日汇合成 Anthropic 的官方立场——工程博客《Effective context engineering for AI agents》。这篇文章提出了一个后来反复被引用的概念："Context Rot"（上下文腐化）：LLM 和人类一样存在"注意力预算"，每多塞一个 token 都在消耗这个预算，且成对关系的计算复杂度是 n² 级别的。文章给出的工程目标是——找到能最大化期望结果的、最小的高信号 token 集合。系统提示词要保持"恰当的高度"：太具体会因为硬编码逻辑而变脆，太宽泛又缺乏有效信号。这篇文章当时更多是方法论宣讲，还没有落到一个具体产品的具体数字上。

一次失败的预演：4月的教训

如果只讲"精简"的成功故事，这个纵向叙事就会显得太顺理成章，容易忽略掉一个关键细节：Anthropic 自己也在这条路上摔过跟头。2026年4月16日，团队尝试往 Claude Code 系统提示词里加一条"降低啰嗦度"的指令，结果这条改动跟其他提示词叠加后损害了编码质量，影响了 Sonnet 4.6、Opus 4.6、Opus 4.7 三个版本，4天后（4月20日）被撤销并发布了官方 postmortem。

这次失败很重要，它说明"精简"从来不是无脑正确的教条，而是一件需要跟模型能力代际精确匹配的判断——加一条指令可能翻车，删一堆指令同样可能翻车，关键不在"多"或"少"本身，而在于这些指令跟当前模型的实际能力是否匹配。正是因为踩过这个坑，团队后来做80%删减时才格外强调"按模型维护不同的系统提示词"——前沿模型（Opus 5、Fable 5）适用精简版，旧模型仍然保留更完整的指令集。这不是一次教条式的"少即是多"运动，而是一次经过失败校准之后的、更审慎的动态判断。

铺垫：从"Steering Claude Code"到炉边谈话

真正的"官宣"之前，其实有两次公开预热。2026年6月18日，官方博客《Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents》系统列出了七种"引导模型行为"的机制——CLAUDE.md、Rules、Skills、Subagents、Hooks、Output styles、临时追加系统提示词——并明确给出一个数字：CLAUDE.md 应控制在 200 行以内。这篇文章的核心比喻是，各种机制其实是在"用上下文成本换权威性"：像 output styles 这类方式对指令的遵循权重最高，但会永久占用 token；而 skills、subagents 只在需要时才加载，能在长会话里省下大量上下文空间。

一周后，2026年7月21日，在 AI Engineer World's Fair 上，Thariq Shihipar 和同事 Cat Wu 与 Simon Willison 做了一场炉边谈话，提前把核心结论说了出来："去掉示例（examples）非常有帮助，因为模型比我们给的示例更有创造力。"Cat Wu 补充了一条互补原则："无论何时给模型一个提示词，你都应该思考它可能被误解的方式。"——这句话很关键，它说明这次删减不是简单粗暴地"删",而是删的同时要重新审视剩下的每一条指令会不会被曲解，是一次带着质检的减法，而不是一次偷懒的减法。

值得一提的是，这套判断早在 2026年5月18日就已经在团队内部酝酿——Thariq 在 Lenny's Newsletter 的播客中提到过一个具体对照："用详尽的系统提示词过度约束通常会产生比简单、信任的指令更差的结果"，并举了自己在 plan mode 下用的极简提示词——"创建HTML文件制定计划。帮助我可视化。包括摘录、模型、代码，任何能给我最大上下文的内容"——关键就在结尾那句开放式的"任何需要的内容"，它传达的是信任，而不是控制。

2026年7月24日：数字落地

Claude Opus 5 正式发布的这一天，一切铺垫汇合成一个具体的、可以被写进新闻标题的数字：80%。Thariq 在 X 上写道："We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them."同日发布的官方博客《The new rules of context engineering for Claude 5 generation models》给出了最具体的一个反例：旧指令里一条说"酌情保留文档"，另一条同时说"禁止写注释"——两条相互矛盾的规则，迫使模型花费本该用于任务本身的注意力去调和冲突。替换后的新指令只有一句："写出与周围代码风格一致的代码：匹配其注释密度、命名、习惯用法。"这句替换本身就是整个范式转变的缩影——从"穷举所有情况的死规则"变成"给一个判断原则，剩下的交给模型"。

配套推出的还有一个叫 /doctor 的命令，帮开发者自动识别"对新模型已经不再需要的指令"，第三方总结其检测流程包含冲突检测、显而易见项检测、技能抽取、示例检测、评测检测五道关卡——这相当于把"精简"这件事本身也工具化了，不再依赖工程师凭感觉去删。

团队把这套方法论浓缩成一句口诀："thin prompts, thick artifacts + context, thin skills"（提示词要薄，产物与上下文要厚，技能要薄）。而 Thariq 用来描述这个过程的词是"unhobbling"——去掉绊马索。这个词本身有一个更早的源头：2024年6月，Leopold Aschenbrenner 在其长文系列《Situational Awareness: The Decade Ahead》里首次系统化这个概念，原意是"通过工具、记忆、更长上下文窗口与agent脚手架，释放模型已具备但尚未能表达出来的潜在能力"，并把它列为推动 LLM 能力进步的三大因素之一。Thariq 借用这个词时做了一次巧妙的翻转——Aschenbrenner 讲的是"给模型加能力"，Thariq讲的是"减少束缚模型的规则"，但逻辑内核完全一致：拿掉绊马索，让模型展现出它本来就有的能力。

更长的历史弧线：为什么恰好是这几年

如果把镜头再拉远一点，"提示词该多详尽"这件事本身也是一门随模型能力起伏的手艺，不是一条直线演化。2020年底 GPT-3 打开"少样本学习"的口子后，"prompt engineering"作为一个术语开始进入行业词汇表；2022到2023年是它的巅峰期，Riley Goodside 这样的从业者靠精巧的 few-shot 设计和显式思维链提示（Chain-of-Thought，学术上由 Wei et al. 和 Kojima et al. 在2022年系统化）成为这门手艺的代表人物。

但几乎同时，另一股力量在把系统提示词越写越长——2023到2024年，随着模型被大规模部署，行业开始用越来越复杂的系统提示词去做越狱防御和行为约束（学术界如 arXiv 2305.13860 系统研究了78种越狱提示词），这是 Claude Code 之类产品的系统提示词越写越像"操作手册"的历史背景。换句话说，系统提示词的膨胀本身有个正当理由：早期模型确实需要被"圈住"。

转折点出现在推理模型登场之后。OpenAI 在2024年9月12日发布 o1-preview，官方很快给出一个反直觉的建议：不要再显式提示思维链，因为模型已经在内部自主推理，画蛇添足只会浪费算力。Anthropic 随后推出的 Extended Thinking 功能文档里也写得很直白：告诉模型"一步一步思考"在这个功能开启后是纯粹的浪费，因为"Claude的推理常常超出人类会规定的范围"。到2026年，OpenAI 在 GPT-5.5系列的官方 prompting guide 里进一步把这个判断固化下来，直言"如果你直接把老版提示词堆栈原样搬到新模型上，模型大概率还是能回答，但你可能在为已经不再有帮助的指令付费"。

Claude Code 这次的 80% 删减，因此并不是一次孤立的产品决定，而是这条"推理模型出现后应该精简提示词"的行业共识，第一次落到一个具体商业产品的具体数字、具体反例和具体工具上。它把一个原本停留在博客和播客里的判断，变成了可以被审计、被复现的工程实践。

横向分析：谁在做减法，谁还在加法

把镜头切到 2026年7月的同一个时间切面，会发现一件更有意思的事：Anthropic 不是一个人在战斗，但也远没有一统江湖。

与 Anthropic 同步：OpenAI 的镜像信号

几乎在同一个月，OpenAI 发布了 GPT-5.6 的官方 Prompting Guide，给出了近乎对称的结论——移除重复指令和示例、简化工具描述能同时提升任务表现和效率。内部编码 agent 测试显示，精简后的系统提示词能把评测分数提高 10%到15%，同时减少 41%到66% 的 token 消耗，成本降低 33%到67%。指南明确警告"always/never"这类绝对化规则和重复的"ask first"式约束会让模型过度请求确认，核心原则被总结成一句话：每条指令只说一次。更值得玩味的是，这份指南直接点名说这套结论逆转了 2025年8月 GPT-5 发布时官方还在推崇的做法——那时候的最佳实践是用详尽的 XML 持久化块、逐步收集上下文的模板、工具调用前的口述脚本。

也就是说，OpenAI 自己一年之内，对同一个问题给出了两个方向相反的官方答案。这不是 OpenAI 说错了话，而恰恰印证了 Anthropic "按模型维护不同系统提示词"这个判断——提示词该详尽还是精简，从来不是一个有普适真理的问题，而是一个跟当代模型能力代际强绑定的动态判断。GPT-5 时代该详尽，GPT-5.6 时代该精简，中间那条分界线就是模型推理能力本身的跃升。

但这里有一个内部张力值得单独拎出来：OpenAI 的 Codex CLI 官方 "starter system prompt" 本身其实相当详尽——覆盖自主性、代码实现约束、git 工作流、工具使用、错误处理多个板块，是"经过内部评测反复优化"出来的详尽版本，官方建议的做法是"系统提示词通用、项目专属信息放进仓库内的 AGENTS.md"，这是一种职责分离式设计，而不是单纯的做减法。换句话说，OpenAI 同时存在两套逻辑：公司层面的最新指南在鼓吹精简，但具体产品（Codex CLI）的默认配置还没跟上这个判断。这个错位本身就是个信号——理念转向往往比产品落地快半拍。

明确站队精简一边：GitHub 和 Replit

GitHub 官方在这件事上的表态比 OpenAI 更彻底。工程博客《How to build reliable AI workflows with agentic primitives and context engineering》里的原话是"只通过针对性的 .instructions.md 文件应用相关指令……这样能为实际工作保留上下文空间"，用的比喻是"建筑师不该去砌墙、工程师不该做规划"——每个角色只该拿到跟它相关的知识，而不是把所有信息一股脑塞给它。这跟 Anthropic 的措辞几乎是同构的："上下文应该被当作一种需要策略性管理的稀缺资源，而不是需要被详尽记录的对象"。

Replit Agent 走得更远，某种意义上比 Anthropic 更进了一步。他们的官方博客《Decision-Time Guidance》提出一个反直觉的观察：加约束会同时增加成本和优先级歧义，而且经常迫使模型去推理那些根本不相关的规则——verbose 规则堆到一定程度会自我瓦解，指令一旦冲突或堆积，模型反而会退回学到的默认行为，而不是遵循任何一条具体规则。他们的解法是"决策时刻引导"：维护一个稳定精简的核心提示词（保留 prompt caching 带来的90%成本下降），再用一个轻量级分类器实时判断 agent 当前所处的决策节点，只在需要时动态注入用完即焚的"微指令"，可以从几条静态提醒扩展到成百上千种情境化变体，而不用把它们都塞进固定提示词里。如果说 Anthropic 是"整体做减法"，Replit 做的是"核心精简+运行时精准投放"，概念上是把 Anthropic 的判断进一步工程化了。

明确的逆行者：Cognition/Devin

Cognition 是这批产品里立场最鲜明的反例。他们更关心的问题不是"提示词该多长"，而是"该用一个 agent 还是多个 agent"，并且专门写了篇博客反驳 Anthropic 早前那个"多 agent 系统成功率提升90.2%"的研究结论——核心论点是"多 agent 系统常常因为并行 agent 对代码风格、边界情况做出相互冲突的隐性判断而失败"，主张写操作必须保持单线程，额外的 agent 只该贡献建议和审查，不该直接碰代码。

落到提示词本身，泄露的 Devin CLI 系统提示词（约306行）也印证了这个立场：覆盖模式切换、沟通语气、工具批处理策略、任务管理、破坏性操作确认机制，是一份典型的详尽规则式文档，为"何时上报/升级"设置了具体触发条件，比如"遇到合并冲突时始终调用 smart friend"。这跟 Anthropic 那句"examples 会限制模型，因为模型比示例更有创造力"是正面冲突的判断——Cognition 相信详细规则能带来稳定性，Anthropic 相信详细规则会带来束缚。两家公司对"更多约束到底是保险还是拖累"这个问题给出了截然相反的答案，而且都拿出了各自的工程博客当证据，这是本次调研里唯一一处能看到公开、正面路线分歧的地方。

处在中间地带的产品

Cursor 的情况比较微妙。它内置的系统提示词（多份泄露版本流传于 GitHub 上的 jujumilk3/leaked-system-prompts 仓库）本身偏详尽规则式，写满了"never lie or make things up""生成的代码必须能够立即运行"这类具体禁令，社区讨论把它定性为"详尽的 prompt engineering 典范"。但规则文件架构层面，Cursor 已经从早期单体的 .cursorrules 演化到 .cursor/rules/ 目录下多个按 glob 和场景加载的 .mdc 文件——这本身是一种模块化、按需注入的设计。开发者社区甚至总结出了具体的经验上限：整个规则目录总行数控制在500行以内、全局生效的核心文件少于50行、按场景匹配的单个文件少于150行，并且明确提到"alwaysApply规则堆太多互相打架抵消"这个故障模式——这和 Anthropic 讲的"指令冲突消耗注意力"是同一个现象的两种表述。可以说 Cursor 的系统提示词本体还没跟上这一波精简，但它的规则架构已经在悄悄向精简方向改造。

Windsurf（现已并入 Cognition 旗下，2026年6月2日更名为 Devin Desktop）走的是类似路径——.windsurfrules 支持四种"激活模式"控制规则何时被载入上下文，官方文档也在强调"精准投喂而非堆砌规则"，但泄露的系统提示词本体依然详尽，且有"Tools Wave 11"这种持续加规则的版本号痕迹。用户口碑上，Trustpilot 多为差评，抱怨集中在自动补全滞后、处理大文件能力下降，这跟母公司 Cognition 在"详尽规则"这条路线上走得更坚决形成呼应——目前没有证据显示这种详尽路线在实际用户体验上占了便宜。

Sourcegraph 的 Amp 代表第三条路：既不完全认同做减法，也不认同堆规则，官方指南里的说法是"context engineering 是一个系统，不是一个字符串"，主张结构化、分层放置的详尽内容（根目录放宽泛指导、子目录放场景专属指令），但同时强调要在"死板的 if-else 规则"和"含糊的挥手带过"之间找一个"金发姑娘区间"。这更像是一种拒绝选边、追求精确胜过冗长的中间态度。

Manus 则完全站在另一个维度上讨论问题。他们那篇被广泛引用的《Context Engineering for AI Agents: Lessons from Building Manus》根本没有正面回答"系统提示词该多长"，而是在讨论更底层的工程基础设施：KV-cache 命中率是生产级 agent 最重要的单一指标（缓存命中的 token 成本是未命中的十分之一）、用 logit masking 代替动态增删工具列表以保护缓存、保留错误痕迹而不是清除以维持模型的错误恢复能力、用不断重写的 todo.md 对抗长上下文里的"lost-in-the-middle"问题。这篇文章的产品哲学是"押注 context engineering 而非模型微调"——因为 Manus 不掌握底层模型，如果模型进步是上涨的潮水，他们想做那条随之升起的船，而不是钉死在海床上的柱子。这跟 Anthropic 的处境形成了一个很有意思的对照：正因为 Manus 不拥有模型，他们没法像 Anthropic 一样"按模型代际调整系统提示词"，只能在工程基础设施层面下功夫，这是两种不同处境催生出的两种不同应对方式。

一个容易被忽略的分层现象

横向扫过这些产品后，能看出一个此前不太被讨论的分层：面向模型本身的系统提示词在普遍收敛变短，但面向项目/团队的规则文件层仍然倾向详尽。GitHub 的 .instructions.md、Cursor 的 .mdc、Windsurf 的 .windsurfrules、Amp 的 AGENT.md，这些"项目专属层"的内容量并没有随着"精简运动"同步缩水——反而因为要覆盖具体的项目约定、编码规范、技术栈信息，天然需要更多细节。真正在收缩的是"给模型的通用行为指令"这一层，而不是"关于这个项目本身的事实性信息"那一层。这个区分很重要，因为它说明 2026年这波"精简"运动的本质不是"少即是多"这种笼统口号，而是精确地针对"用规则约束模型判断力"这一类指令做减法，对"告诉模型项目里有什么"这类信息反而没有减少的压力。

横纵交汇：历史怎么塑造了今天的位置

Anthropic 的优势，能追溯到哪两个历史节点

把纵轴和横轴放在一起看，Anthropic 今天能做出这次 80% 删减、并且是这批公司里做得最彻底最有说服力的一个，能追溯到两个具体的历史决定。

第一个是它同时拥有模型和产品。Cursor、Windsurf 这些第三方工具厂商，本质上是"模型消费者"，它们没法像 Anthropic 一样根据自己模型的能力代际去精确调整提示词策略——它们要同时兼容 GPT、Claude、Gemini 等多个后端，天然倾向于用更详尽、更通用的规则去兜底所有可能的模型行为，这是横向对比里 Cursor、Windsurf 的系统提示词至今仍偏详尽的结构性原因。Anthropic 反过来，因为同时掌握 Claude 5 世代的具体能力边界，能做"按模型维护不同系统提示词"这种精细化操作——这是本次调研里唯一一家能把"模型能力提升"和"提示词精简"直接挂钩、并给出量化验证的公司。

第二个是它 4月那次失败的教训。如果没有那次"降低啰嗦度"翻车并回滚的经历，7月这次 80% 删减很可能不会做得这么彻底、这么有底气——正是因为吃过"精简不是无脑正确"的亏，团队才发展出"按模型动态调整"这套更审慎的方法论，而不是简单地把"少即是多"当成教条。这是一个"坏决策"（一次失败的改动）反而催生出更好方法论的例子。

对手们的纵向路径，如何决定了今天的立场

Cognition 今天在"详尽规则"这条路线上站得最坚决，能追溯到 Devin 从一开始就是以"全自主工程师"这个叙事起家的产品定位——一个号称能独立完成整个工程任务的 agent，天然需要比"辅助型编程助手"更强的可控性和可预测性，否则用户没法信任它去做无人监督的大范围代码修改。这个起点决定了 Cognition 后来在多 agent 协调、系统提示词设计上，始终倾向于用详尽的显式规则去兜底不确定性，而不是像 Anthropic 那样相信模型的自主判断。

Manus 今天完全避开"提示词该多长"这个维度去讨论问题，根源也在于它从创立起就不拥有底层模型——这个先天约束决定了它没法像 Anthropic 一样把"精简提示词"当成随模型能力升级而动态调整的杠杆，只能在自己能控制的层面（缓存策略、错误处理、上下文格式）上做文章。这不是 Manus 团队没想到，而是它的处境根本不允许它像 Anthropic 一样打这张牌。

优势的另一面：会不会变成明天的包袱

一个值得留意的隐忧是，"按模型维护不同系统提示词"这套做法本身依赖 Anthropic 持续保有对自己模型能力边界的精确认知——这在他们自己掌控训练和产品的前提下成立，但如果未来行业出现更多"模型层和应用层分离"的第三方开发情形（比如更多团队用 Claude 的 API 去做自己的 Agent 产品，而不经过 Anthropic 官方的 Claude Code），这些第三方就没法享受到"官方按模型精细调整"的红利，只能像 Cursor 一样退回详尽规则的兜底策略。换句话说，这次的"减法"红利目前只属于 Anthropic 自己的第一方产品，尚未证明能被行业其他玩家复制。

三个剧本

最可能的剧本：未来6到12个月，"面向模型的通用行为指令精简、面向项目的事实性信息详尽"这种分层会成为行业默认实践，OpenAI、Google 会陆续在自己的 agent 产品线上跟进类似的精简动作，第三方工具厂商（Cursor、Windsurf）会继续保留相对详尽的系统提示词本体，但在规则文件架构上加速向"按场景加载"的模块化方向改造。Cognition/Devin 会作为行业里少数公开坚持"详尽规则更可控"的声音继续存在，成为这场收敛运动里的对照组，而不是被淘汰。

最危险的剧本：某个团队盲目照搬"删除大部分系统提示词"这个结论，却没有配套"按模型能力动态判断"和"删除同时质检是否会被曲解"这两道工序，结果复现 Anthropic 自己4月那次翻车——精简本身不是万能药，如果脱离了具体模型的能力评估、单纯当成"降本增效"的捷径去执行，很可能造成大规模、难以追溯的行为退化，而且因为系统提示词精简后信息密度更低，出问题时反而更难定位是哪条被删掉的规则原本在兜底某个边界场景。

最乐观的剧本：/doctor 这类"自动识别过时指令"的工具被行业标准化，逐渐发展成一套通用的"提示词健康度审计"方法论，能同时适配不同厂商的模型，中小团队不再需要靠资深工程师的直觉去判断"这条规则还有没有用"，而是可以像做代码 lint 一样自动化地维护系统提示词的精简度——如果这一步真的发生，"提示词工程"作为一门手艺可能会经历它自己的"从手工作坊到工业化流水线"的转型，而 Anthropic 这次的披露，会被回看成这条工业化路径上的第一块奠基石。

信息来源

内容由AI辅助生成，请谨慎甄别。资讯分享仅供参考，相关观点不代表主观立场，不构成任何形式的投资建议。