最近,一篇题为《Context is the new Moat》的文章在 AI 圈引发热议。
作者 Shubham Saboo 提出了一个看似简单却深刻的观点:当所有人都能用上 Claude、GPT、Gemini 这些最先进的模型时,真正的竞争优势不再是模型本身,而是语境。
这篇文章在 Twitter 上获得了广泛转发,其中 AI 领域的资深从业者 Andrea Volpini 评论道:" 语境不仅仅是静态的事实。如果你捕捉决策痕迹、时间信号,并在知识图谱中保存来源,你就能给 AI 一个丰富的、不断演化的世界模型。"

这个观点道出了 2026 年 AI 应用领域最核心的竞争逻辑:模型在商品化,语境在分化。
当价格下降、能力趋同、每个创业公司都能调用同样的 API 时,什么才能让你的 AI 产品与众不同?答案就藏在你的业务知识、用户洞察、踩过的坑和积累的经验里——这些无法下载的语境,才是真正的护城河。
以下是文章的完整编译。

原文链接:https://x.com/saboo_shubham_/status/2011278901939683676?s=46&t=rEzZcOBRsZFqalAwGXdDFw
今天,每个人都能用上同样的模型。
你用 Claude Opus 4.5,你的竞争对手也在用。你用 GPT-5.2,上周刚成立的那家创业公司也在用。你用 Gemini 3 Pro,所有做 AI 产品的人都在用。
模型正在商品化。价格在下降。能力在趋同。几个月前还是最先进的技术(SOTA),现在任何有 API 密钥的人都能用上。
那么,真正的竞争优势从哪里来?
语境(Context)。
能够将自己掌握的知识外部化,并以结构化的方式喂给 AI 代理的团队,能够构建出竞争对手无法仅仅通过使用同样模型就能复制的产品。
同样的模型,不同的结果
我看到两个开发者用同一个模型构建几乎完全相同的代理。
第一个开发者给 Claude 的提示是:" 构建一个多代理系统,用来处理客服工单并进行升级。"
第二个开发者给 Claude 喂了关于他们具体产品的语境:用户实际会问的问题、品牌使用的语气、获得五星好评和引发投诉的回复示例、需要人工介入的边缘情况、代理需要访问的内部工具、" 已解决 " 对他们的用户来说真正意味着什么。
同样的模型。同样的任务。完全不同的输出。
第一个开发者得到了一个通用的客服机器人,听起来和其他所有 AI 客服代理没什么两样。第二个开发者得到的东西,感觉像是专门为他们的产品训练了好几个月。
模型是相同的。语境才是护城河。
而且,与模型不同,语境无法下载。它必须被赚取。
什么才是真正的语境
语境不是 " 在提示词里多写点东西 "。它是结构化的知识,帮助模型理解你的具体情况。
用户语境—— 不是用户画像,而是真实的细节。
" 我们的用户是想快速搭建 AI 应用原型的开发者。他们在意的是能立刻运行的代码,而不是理论解释。任何需要配置超过 10 分钟的东西,他们都会放弃。"
领域语境—— 你所在领域的特定模式和约束。
" 在多代理系统中,协调代理永远不应该直接调用工具。它应该委派给专门的代理。这就是为什么这对可靠性很重要。"
历史语境—— 你之前尝试过什么,为什么没有成功。
" 我们在 2025 年第二季度用单一提示词的方法构建过类似的代理。它失败了,因为上下文窗口填充得太快。这是我们在分块和摘要方面学到的东西。"
质量语境—— 在你的具体情况下,好的表现是什么样子。不是抽象的原则,而是实际的例子。
" 这是用户觉得有帮助的代理回复。这是让他们困惑的回复。区别在这里。"
约束语境—— 塑造解决方案的真实限制。
" 我们需要这个功能在 API 的免费额度内运行。延迟必须保持在合理范围内以供交互使用。解决方案需要足够简单,让别人通过阅读代码就能理解。"
这些东西存在于你的脑海中。存在于你的 GitHub issues 里。存在于 Slack 对话里。存在于你收到的反馈里。存在于你通过实际交付产品而建立起来的直觉里。
为什么语境会复利增长
语境会随着时间积累。
你做的每一个项目、记录的每一次失败、捕捉到的每一个用户洞察、收集的每一个案例,都在为你的语境库添砖加瓦。
A 团队每次都从零开始。他们给模型下指令,得到通用输出,花几个小时修正和调整,然后继续下一个项目。学到的东西要么留在脑子里,要么完全消失。
B 团队维护语境文档。每个项目结束后,他们都会更新学到的东西:哪些有效,哪些无效,新的用户洞察,好的输出案例,需要注意的新边缘情况。
六个月后,A 团队还在得到通用输出,还在花几个小时做修正。
B 团队的代理在第一天产出的结果,就比 A 团队迭代一周后的还要好。
这就是飞轮:好的语境 → 更好的输出 → 学习哪些语境重要 → 改进语境文档 → 重复。

实际应用中的样子
我维护着 Awesome LLM Apps 这个开源仓库,里面收集了 100 多个 AI 代理和 RAG 实现。当我构建新代理时,我从不从零开始。
这是我积累的一些语境示例:
目标用户:想要快速搭建 AI 代理原型的开发者
- 他们会克隆、运行,然后在 10 分钟内决定是否有用
- 他们不会读大段文字,只会扫一眼 README 找快速入门
- 他们会放弃任何需要超过 10 分钟设置的东西
设置要求:
- 最多 3 个环境变量(只有 API 密钥)
- 单个 requirements.txt,没有复杂的依赖链
- "pip install + 运行 " 在 5 分钟内完成
技术栈:
- 只用 Python
- 用 Streamlit 做 UI(快速构建,易于理解)
- 直接用 OpenAI/Anthropic/Google AI SDK,最少的抽象层
什么能获得 stars:
- 解决人们真正遇到的实际问题(不是玩具 demo)
- 代码可读,不需要大量注释
- 容易扩展或修改以适应他们自己的场景
- 好的 README,配有 GIF 或截图展示效果
什么不受欢迎:
- "Hello world" 级别的 demo(太基础)
- 简单问题用过于复杂的架构
- 需要 10 分钟以上配置才能首次运行的代理
要避免的常见失败模式:
- 长对话中的上下文窗口溢出
- 代理卡在工具调用循环中
- API 调用失败时错误信息不清晰
- 没有优雅地处理速率限制
有效的代理模式:
- 单一用途的代理,把一件事做好
- 角色分工明确的多代理系统
- 复杂工作流的协调器模式
- 高风险决策的人工参与循环
当我打开 Claude Code 或 Antigravity 来构建新代理时,这些语境会首先输入。代理已经知道这个仓库的 " 好 " 是什么样子,该用什么模式,要避免哪些错误。
第一次输出就能达到 90%,而不是 50%。
这就是护城河。不是模型本身,而是积累的语境,让模型更好地适应我的具体情况。
让它自动化
最好的语境系统是隐形的。语境就在那里,随时准备好,每次都在。

现在所有主要的 AI 编码工具都支持持久化的语境文件。你创建一次,放进项目里,它们就会自动加载到每次对话中。
文件名各不相同,但模式是一样的:
Antigravity / Gemini CLI: GEMINI.md
Cursor: .cursor/rules
Claude Code: CLAUDE.md
Windsurf: .windsurfrules
Codex: AGENTS.md
Claude Projects: 作为项目知识上传
我把代理模式、质量标准和失败模式都保存在这些文件里。每次会话开始时,代理就已经理解了我的世界。
把你知道的东西外部化到存放在仓库里的文件中。不要再重复解释你的技术栈。不要再重新描述你的模式。不要再纠正同样的错误。
设置一次,之后的每个提示都能受益。
如何开始
今天:开始写一个语境文档。你的用户到底是谁?什么是好的?你尝试过哪些失败了?不需要完美,直接开始。
每个项目结束后:你学到了什么?什么让你惊讶?你会做什么不同的事?把它加进去。
持续进行:强迫症般地收集案例。好的输出,坏的输出,边缘情况。案例是你能提供的最高杠杆的语境。
让它自动化:给你的项目添加 GEMINI.md 或 CLAUDE.md。它会自动加载。你再也不用想它。
就是这样。四个步骤。剩下的就是不断重复。
提示会变得更容易。模型会用更少的词更好地理解你。
但语境永远重要。
把语境当作一流工程问题来对待的人,会更快地构建出更好的东西。
不是因为他们有更好的模型,而是因为他们更擅长教学。
这才是真正的技能。
不是告诉代理该做什么,而是帮助它们理解为什么这很重要。


