语境才是真正的护城河

最近，一篇题为《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代理的团队，能够构建出竞争对手无法仅仅通过使用同样模型就能复制的产品。

1

同样的模型，不同的结果

我看到两个开发者用同一个模型构建几乎完全相同的代理。

第一个开发者给Claude的提示是：“构建一个多代理系统，用来处理客服工单并进行升级。”

第二个开发者给Claude喂了关于他们具体产品的语境：用户实际会问的问题、品牌使用的语气、获得五星好评和引发投诉的回复示例、需要人工介入的边缘情况、代理需要访问的内部工具、"已解决"对他们的用户来说真正意味着什么。

同样的模型。同样的任务。完全不同的输出。

第一个开发者得到了一个通用的客服机器人，听起来和其他所有AI客服代理没什么两样。第二个开发者得到的东西，感觉像是专门为他们的产品训练了好几个月。

模型是相同的。语境才是护城河。

而且，与模型不同，语境无法下载。它必须被赚取。

1

什么才是真正的语境

语境不是"在提示词里多写点东西"。它是结构化的知识，帮助模型理解你的具体情况。

用户语境 —— 不是用户画像，而是真实的细节。

“我们的用户是想快速搭建AI应用原型的开发者。他们在意的是能立刻运行的代码，而不是理论解释。任何需要配置超过10分钟的东西，他们都会放弃。”

领域语境 —— 你所在领域的特定模式和约束。

“在多代理系统中，协调代理永远不应该直接调用工具。它应该委派给专门的代理。这就是为什么这对可靠性很重要。”

历史语境 —— 你之前尝试过什么，为什么没有成功。

“我们在2025年第二季度用单一提示词的方法构建过类似的代理。它失败了，因为上下文窗口填充得太快。这是我们在分块和摘要方面学到的东西。”

质量语境 —— 在你的具体情况下，好的表现是什么样子。不是抽象的原则，而是实际的例子。

“这是用户觉得有帮助的代理回复。这是让他们困惑的回复。区别在这里。”

约束语境 —— 塑造解决方案的真实限制。

“我们需要这个功能在API的免费额度内运行。延迟必须保持在合理范围内以供交互使用。解决方案需要足够简单，让别人通过阅读代码就能理解。”

这些东西存在于你的脑海中。存在于你的GitHub issues里。存在于Slack对话里。存在于你收到的反馈里。存在于你通过实际交付产品而建立起来的直觉里。

1

为什么语境会复利增长

语境会随着时间积累。

你做的每一个项目、记录的每一次失败、捕捉到的每一个用户洞察、收集的每一个案例，都在为你的语境库添砖加瓦。

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%。

这就是护城河。不是模型本身，而是积累的语境，让模型更好地适应我的具体情况。

1

让它自动化

最好的语境系统是隐形的。语境就在那里，随时准备好，每次都在。

现在所有主要的AI编码工具都支持持久化的语境文件。你创建一次，放进项目里，它们就会自动加载到每次对话中。

文件名各不相同，但模式是一样的：

Antigravity / Gemini CLI: GEMINI.md

Cursor: .cursor/rules

Claude Code: CLAUDE.md

Windsurf: .windsurfrules

Codex: AGENTS.md

Claude Projects: 作为项目知识上传

我把代理模式、质量标准和失败模式都保存在这些文件里。每次会话开始时，代理就已经理解了我的世界。

把你知道的东西外部化到存放在仓库里的文件中。 不要再重复解释你的技术栈。不要再重新描述你的模式。不要再纠正同样的错误。

设置一次，之后的每个提示都能受益。

1

如何开始

今天： 开始写一个语境文档。你的用户到底是谁？什么是好的？你尝试过哪些失败了？不需要完美，直接开始。

每个项目结束后： 你学到了什么？什么让你惊讶？你会做什么不同的事？把它加进去。

持续进行： 强迫症般地收集案例。好的输出，坏的输出，边缘情况。案例是你能提供的最高杠杆的语境。

让它自动化： 给你的项目添加GEMINI.md或CLAUDE.md。它会自动加载。你再也不用想它。

就是这样。四个步骤。剩下的就是不断重复。

提示会变得更容易。模型会用更少的词更好地理解你。

但语境永远重要。

把语境当作一流工程问题来对待的人，会更快地构建出更好的东西。

不是因为他们有更好的模型，而是因为他们更擅长教学。

这才是真正的技能。

不是告诉代理该做什么，而是帮助它们理解为什么这很重要。

点个“爱心”，再走 吧