作者：Shubham Saboo，Google高级AI产品经理
原文：https://x.com/Saboo_Shubham_/status/2011278901939683676
如今，每个人都能接触到相同的模型。
你用的是 Claude Opus 4.5，你的竞争对手也用的是。你用的是 GPT-5.2，上周刚成立的那家创业公司也用的是。你用的是 Gemini 3 Pro，其他所有开发人工智能产品的人也都用的是。
这些模型正在商品化，价格不断下降，功能也趋于融合。几个月前还属于最先进的技术，现在只要拥有API密钥，任何人都可以使用。
那么真正的阿尔法星（核心价值增量）从何而来？
答案就是——场景（Context）
能够将自身知识以结构化的方式传递给智能体的团队，将能够打造出竞争对手无法通过相同模式复制的产品。
相同的模型，不同的结果
我亲眼目睹了两位开发者使用相同的模型构建出几乎完全相同的智能体。
有人向Claude输入提示词：“构建一个多智能体系统，用于处理具有升级功能的客户支持工单。”
另一位用户向 Claude 提供了有关其具体产品的背景信息：用户实际提出的问题、品牌使用的语气、获得五星好评的回复示例与收到投诉的回复示例、需要人工转接的特殊情况、客服人员需要访问的内部工具、“已解决”对用户的实际含义。
相同的模型，相同的任务，却得出完全不同的结果。
第一位开发者得到的是一个通用客服机器人，听起来和其他人工智能客服人员没什么两样。第二位开发者得到的则是一个感觉像是针对他们的特定产品进行了数月训练的机器人。
模型完全相同，场景变成了护城河。
与模型不同，场景无法下载，必须通过实践获得。
场景究竟是什么意思
场景不仅仅是“提示词中的更多文字”，它指的是结构化的知识，可以帮助模型理解你的具体情况。
- 用户场景（User Context）。
- 不是用户画像（Persona），而是真实细节（Real Details）。“我们的用户是希望快速搭建人工智能应用原型的开发者，他们关心的是能够立即运行的代码，而不是理论解释。任何需要超过 10 分钟设置时间的应用，他们都会放弃。”
- 领域场景（Domain Context）。
- 你所在领域的具体模式和限制，“在多智能体系统中，协调智能体绝不应该直接调用工具，它会将任务委托给专门的智能体，这就是为什么可靠性至关重要的原因。”
- 历史场景（Historical Context）。
- 你之前尝试过什么，以及为什么失败了。“我们在 2025 年第二季度构建了一个类似的智能体，采用的是单提示方法。它失败的原因是上下文窗口填充得太快，以下是我们从中吸取到的关于分块和摘要的经验教训。”
- 质量场景（Quality Context）。
- 举例说明在你的具体情况下，好的例子应该是什么样的。不是抽象的原则，而是实际案例。“这是用户认为有用的客服回复，这是让他们感到困惑的回复，区别就在这里。”
- 约束条件（Constraint Context）。
- 真正影响解决方案的限制因素，“我们需要它能与 API 的免费层级兼容。延迟必须保持在合理的范围内，以满足交互式使用需求。解决方案必须足够简单，以便任何人都能通过阅读代码来理解。”
这些东西都存在于你的脑海里，存在于你的 GitHub issues 里，存在于 Slack 讨论串里，存在于你收到的反馈里，存在于你从产品发布中积累的直觉里。
产生复利效应的原因
场景会随着时间不断积累。
你做的每一个项目、你记录的每一次失败、你捕捉到的每一个用户洞察、你收集的每一个案例都会丰富你的场景知识库。
A 团队的每个项目都是从零开始。他们先对模型进行初始化，得到通用输出，然后花费数小时进行修正和调整，最后才继续下一个项目。他们学到的东西要么只停留在脑子里，要么就彻底消失了。
B团队对项目场景文档进行维护。每个项目结束后，他们都会更新文档，总结经验教训，包括哪些方法有效，哪些无效，新的用户洞察，新的优秀输出示例，以及需要注意的新极端情况。
六个月过去了，A 团队仍然只能得到通用输出，并且要花费大量时间进行修改。
B 团队的智能体在第一天就取得了比 A 团队经过一周迭代后更好的结果。
这就是飞轮效应：好的上下文 → 更好的输出 → 了解哪些上下文重要 → 改进上下文文档 → 循环往复。
在实践中是什么样的？
我一直维护着Awesome LLM Apps开源仓库，这个仓库收录了百余款 AI 智能体与 RAG 技术的落地实现方案。当我开发新的智能体时，绝不会从零做起。
以下是我收集到的一些场景信息样例：
目标用户：想要快速搭建 AI 智能体原型的开发者。他们会克隆代码、运行测试，并在 10 分钟内判断其是否有用。他们不会去读长篇大论的文本，只会快速浏览 README 文件找快速上手（Quickstart）指南。
环境配置要求：
-最多仅需 3 个环境变量（仅限 API 密钥）
-单一 requirements.txt 文件，无复杂依赖链
-“pip 安装 + 运行” 全程耗时需控制在 5 分钟内，否则开发者会直接放弃
技术栈：
-仅使用 Python 开发
-前端 UI 采用 Streamlit（开发速度快、逻辑易理解）
-直接调用 OpenAI/Anthropic/Google AI 官方 SDK，尽可能减少抽象层
易获星的特征：
-解决真实存在的实际问题（而非玩具级演示项目）
-代码可读性强，无需大量注释即可理解
-易于扩展或修改，适配开发者自身的使用场景
-优质的 README 文档，附带展示功能运行效果的 GIF 动图或截图
不受欢迎的类型：
-“Hello World” 级别的演示项目（过于基础）
-用过度复杂的架构解决简单问题
-首次运行前需要 10 分钟以上配置的智能体
需规避的常见失败模式：
-长对话场景下出现上下文窗口溢出问题
-智能体陷入工具调用循环，无法跳出
-API 调用失败时返回不清晰的错误信息
-未对接口限流做优雅的容错处理
经验证有效的智能体设计模式：
-单功能智能体：专注把一件事做到极致
-多智能体系统：角色划分清晰
-协调者模式：适用于复杂工作流的处理
当我打开Claude Code（CLAUDE.md）或Antigravity（GEMINI.md），要构建一个新的代理时，首先需要输入这个。智能体已经知道对于这个代码库来说，“好”的状态是什么样的，应该使用哪些模式，以及应该避免哪些错误。
第一个输出结果就能达到 90%，而不是 50%。
这就是护城河，不是模型本身，而是积累起来的场景信息，这些信息让模型更适合我的特定情况。
使其自动化
最好的场景系统是无形的，上下文始终存在，随时可用。
现在所有主流的AI编码工具都支持持久化上下文文件，你只需创建一次，将其放入项目中，它们就会自动加载到每个对话中。
文件名各不相同，但格式相同：
我把我的智能体模式、质量标准和故障模式都保存在这些文件中。每次会话开始时，智能体都已了解我的世界观。
将你掌握的知识整理成文件，并存放在你的代码仓库中。不要再重复解释你的技术栈，不要再重复描述你的编程模式，不要再纠错同样的错误。
只需设置一次，之后每次提示都会受益。
如何开始
今天：开始编写一份场景文档。你的用户群体究竟是谁？好的用户群体是什么样的？你尝试过哪些失败的方法？不必追求完美，先开始吧。
每个项目结束后：你学到了什么？什么让你感到惊讶？你会做出哪些不同的尝试？请把这些写下来。
持续开展：大量收集案例，好的案例、坏的案例、极端情况都包括在内。案例是你所能提供的最有价值的背景信息。
就这些，四个步骤，剩下的就是重复练习了。
提示词会变得更容易，模型会用更少的语言更好地理解你。
场景始终很重要。
那些将场景视为一流工程问题的人，会更快地创造出更好的产品。
不是因为他们有更好的模型，而是因为他们更擅长教育模型。
那才是真正的本事。
不是告诉智能体该怎么做，而是帮助他们理解为什么这很重要。