Thariq Shihipar：Anthropic 把 Claude Code 系统提示词砍了 80%，因为 Fable 5 比你给的例子更聪明

"模型越聪明，需要的指导就越少——例子反而在限制它，因为你给它例子，它就想'哦，你想要这样的东西'。把例子拿掉，它反而更自由。"

Anthropic Claude Code 团队成员 Thariq Shihipar（@trq212）在 Peter Yang 的播客中抛出了一个反直觉的判断：随着 Fable 5 的发布，Anthropic 把 Claude Code 系统提示词砍掉了 80%。理由很简单——新一代模型不再需要那么多 handholding，过度的指令和示例正在拖累它的表现。

从一条推文聊起

7 月 19 日，AI 创作者 Peter Yang（@petergyang，24.3 万关注者）发布了与 Shihipar 的最新播客对谈，其中"系统提示词砍掉 80%"这个数字瞬间引爆了讨论。推文发布后仅数小时就获得了 7.4 万次浏览、159 次点赞和 136 次收藏，11 条引用推文进一步放大了传播。

而 Shihipar 本人前一天发布的推文透露，这次系统提示词的削减是 Anthropic 团队"昼夜奋战"的成果——"当时能不能按时完成还不清楚，为每一位参与其中的人感到骄傲。Enjoy Fable。"这条推文获得了超过 98 万次浏览和 7766 次点赞。

Shihipar 在 Claude Code 团队工作，此前在 YC W20 创业，拥有 31.5 万关注者，是 Anthropic 对外最活跃的技术布道者之一。他在 7 月初的 AI Engineer World's Fair 上发表了主题演讲"A Field Guide to Fable"，此次播客对谈可以看作那次演讲的延续和深化。

"例子越多，模型越受限"

Shihipar 在播客中给出的核心洞察直指一个被很多人忽略的事实：提示词工程有一条 U 型曲线。

"早期的模型需要短提示词加大量例子和限制性指令。然后随着模型变聪明，提示词越来越长。现在它又变短了。"Shihipar 解释道，"最近我们发现，这类新模型想要更短的系统提示词。你给它例子，它就想'哦，你想要这样的东西'。把例子拿掉，它反而更自由。"

关键转折在于，当 Fable 5 级别的模型能力足够强时，示例不再是辅助，而成了约束。Shihipar 举了一个具体场景：如果你在 system prompt 里写"不要做 X"，旧模型会老老实实遵守；但 Fable 5 反而可能因为这条禁令被"锚定"在 X 附近——它理解了你在意什么，于是围绕着它打转，而不是自由发挥最好的方案。硬规则在新模型上变成了心理暗示，效果完全反了。

这和很多人直觉相反。通常人们以为，模型越强，越应该给它更多上下文、更多示例来说明边界。但 Shihipar 的结论是："新模型发布后，你要做的第一件事就是审计你的 CLAUDE.md 和 skills，删掉那些确定性的指令。给模型更多空间去跑。"

Peter Yang 在播客后发布的笔记中印证了这一点："当更好的 AI 模型发布时，你首先要尝试的是删掉指令，而不是增加指令。"

不过，并非所有人都有同样的体验。独立开发者 Danny Hatcher（Product Manager @hirekai_ai，4135 关注者）在引用推文中表达了不同的看法："我用 Claude（Fable 5 和 Opus 4.8）的体验和这个说法不符。减少约束之后，我遇到了重复按钮、日历崩溃、设计不一致等问题。"这恰恰说明 Shihipar 自己强调的一点——不同的任务场景需要不同的指令密度，不存在一刀切的最优解。"当你听到人们这样谈论 AI 时，我会很兴奋，然后失望，"Hatcher 补充道。

"薄提示、厚产物、薄技能"：Claude Code 团队的三字经

7 月 15 日，Shihipar 在推文中总结了他心目中的理想提示框架，仅用六个英文单词——"thin prompts, thick artifacts + context, thin skills"。这条推文获得了 5100 次点赞和 2751 次收藏，被广泛转发。

三者的分工很清晰：

薄提示（thin prompts）：指令本身要极简。不要长篇大论地告诉模型该怎么做，把空间留给模型自己推理。Shihipar 的核心理由是：Fable 5 的推理能力已经远超大多数人的 prompt 设计能力——你写下的每一条"指导"都可能是在画蛇添足。
厚产物 + 厚上下文（thick artifacts + context）：把真正有价值的东西放进模型能读到的文件中——HTML 规格文档、代码库、API 文档、项目历史。这些是模型推理的原材料，不是束缚它的笼子。Shihipar 在播客中展示了如何用 HTML artifact 做项目规划——不写文字 spec，而是直接让模型生成一个可交互的 HTML 原型，然后把这个原型作为后续开发的"对齐基准"。这个方法和 Anthropic CPO Mike Krieger 此前描述的 Fable 5 工作流完全一致：先花大量时间与模型进行架构对话，产出 artifacts，再让模型去执行。
薄技能（thin skills）：skill 文件的寿命比大多数人想象的要短。它们本质上是"当前模型短板的补丁"，而下一代模型往往在训练和后训练中已经修复了这些短板。只有无法进入模型权重的东西——你的偏好、公司的私有知识、你的工具和数据——才值得保留。Shihipar 特别指出，这次 80% 的系统提示词削减，本质上就是把那些不再是"短板"的东西清理掉。"原来需要告诉模型怎么用 Git——现在它还不会用 Git 吗？删掉。"

Nicolas Bustamante（Microsoft AI 产品经理，2.5 万关注者）在引用中给出了一个精炼的补充："大多数 system prompt 和 skill 的寿命都很短。它们是对当前模型短板的补丁。但那些短板恰恰是下一代模型在训练中被修复的。今天有帮助的指令，明天可能就变成了拖累——甚至更糟，限制一个更强大的模型。最好的做法是，每次新模型发布时，重新评估整个系统提示词和技能库。"

这个观点在社区中迅速获得了认同。一位开发者评论道："我的 AGENTS.md 也是一样，我感觉它不是指导模型，而是在拖它的后腿。不到一年，变化就这么大——在 LLM 的世界里，一年就是永恒。"

"先消除未知，再动手构建"

Shihipar 在播客中分享的另一条重要方法论是：在让 Claude Code 动手写代码之前，先用它来发现未知。这个理念贯穿了他在 Anthropic 的日常开发实践。

他的工作流是这样的：在动手做一个视频编辑项目之前，他先问 Claude "像 Whisper 这样的语音转文字工具可能在哪些地方出错？"——让模型自己列举潜在的失败模式。然后他逐条阅读这个分析，手动判断哪些风险真实存在、哪些可以忽略。这个"消除未知"的步骤完成之后，才进入真正的构建阶段。

"最重要的收获可能是：他真的在手动阅读计划，而不是盲目信任 AI。"Peter Yang 在收听笔记中写道。这个细节值得留意——即便在最依赖 AI 的团队内部，最有效的用法也不是把一切都交给模型，而是用模型来扩展自己的判断力。模型负责枚举可能性，人负责做决策。

Shihipar 还透露了一个具体技巧：使用 /goal 命令时，必须设定一个可验证的终态。他举了一个对比强烈的例子——"你说'给我做一个好游戏'——结果不会好。但你说'给我一个渲染好的视频'——OK，这个是可以验证的。"前者的"好"无法被 Claude 自己验证，模型会无限循环；后者的"渲染好的视频"是一个二进制状态——文件要么存在且能播放，要么不存在。Peter Yang 在播客中坦言自己踩过这个坑，他让 Claude "做一个好游戏"，结果模型在没有任何终态约束的情况下跑出了大量的"创意发散"，最终产出一团乱码。

此外，Shihipar 还演示了如何在 Slack 中运行并行的 Claude 任务——他称其为"跑一支 AI 特工队"。核心思路是把大任务拆成多个独立子任务，分别丢给不同的 Claude session，然后由人类（或另一个 Claude）做最后的整合。这个模式很像 Mike Krieger 描述的"三路并发"工作流，区别在于 Shihipar 更强调并行任务之间的独立性——"不要让一个 agent 等另一个 agent 的输出，那就失去了并行的意义。"

一个正在收窄的窗口

Shihipar 在播客结束后发推表示，他正在撰写一篇更详细的文章，专门讲这次 80% 削减中学到的经验，以及开发者如何把这些原则应用到自己的 system prompt 和 skill 中——这篇推文已获得 450 次点赞和 286 次收藏，说明社区对"怎么做"的需求甚至比对"做了什么"更大。

但即便在当前的信息范围内，一个判断已经清晰：Anthropic 这次系统提示词的"大瘦身"不是一次简单的代码清理，而是一个信号——AI 编程工具的进化方向，不是堆更多指令，而是给模型更多空间。那些还在把 prompt 越写越长的人，可能需要停下来反向思考。

值得注意的是，并非所有人都赞同这个方向。除了 Hatcher 的负面体验外，Y Combinator 出身的 Kyle Mistele（@0xblacklight，CTO @humanlayer_dev，6763 关注者）在引用推文中将此事与 Pi Dot Dev 去年 11 月的类似做法对比，略带调侃地写道："Claude Code 团队终于赶上了。"他的引用推文在数小时内获得了 1.5 万次浏览和 38 次点赞。这两种声音——质疑效果的和质疑原创性的——恰好印证了 Shihipar 自己的核心论点：不同模型、不同任务需要不同的指令密度，不存在一刀切的答案。

但大方向是明确的：模型越强，提示词越薄。 Shihipar 在 AIE 演讲中给出的最后一句话或许是最好的总结——"给模型空间。它会让你惊喜的。"这不是偷懒，而是对模型能力增长的诚实回应。在 LLM 每年跨越一个世代的速度下，学会"少写"可能比学会"多写"更难，但也更重要。

参考链接：

Peter Yang 播客推文：
Thariq Shihipar "Enjoy Fable" 推文：
Thariq Shihipar "thin prompts" 推文：
The Decoder 报道：
Peter Yang 播客全文笔记：
Thariq Shihipar "A Field Guide to Fable" Keynote：
Nicolas Bustamante 引用评论：

本文由 AREX Agent 基于公开信息和一手社交平台内容整理撰写。如有不准确之处，请联系我们更正。