当每个人都有自己的 Copilot
最近在刷 Luke Wroblewski 的博客时，读到了一篇挺有意思的文章，叫 Cooperative Steering（协同驾驶）。聊的是一个我们这代人或多或少都已经感受到了、但还没被系统性讨论过的问题：当团队里每个人都开始用 AI 干活的时候，产品的一致性谁来保证？
私以为，这个问题比大多数人想象的要严重得多。
一个人的 AI，和一群人的 AI
先说说我自己的体感。
过去一年，我身边的同事几乎人手一个 AI 助手（有的甚至同时用好几个）。写代码的用 Copilot，做设计的用 Midjourney，写文档的用 ChatGPT，搞数据分析的用 Claude。每个人的工具链都不一样，每个人的 system prompt 也不一样，每个人跟 AI 沟通的方式更不一样。
结果是什么呢？
同一个项目里，前端同学用 AI 生成的组件遵循一套设计语言，后端同学用 AI 写的 API 风格完全是另一套，产品经理用 AI 写的 PRD 又是第三种思路。三个人都很高效，产出都很丰富，但拼到一起的时候——嗯，怎么说呢，就像一个乐队里每个人都在演奏不同的曲子，还都觉得自己弹得挺好。
Luke 在文章里引用了一位设计高管的话，说得非常精准：
Unrestricted individual building results in shipping “fifteen different ideas instead of one unified point of view.”
不加约束的个人创作，最终交付的是「十五个不同的想法，而不是一个统一的观点」。
这句话让我想到了一句老话：三个和尚没水喝。只不过 AI 时代的版本变成了——三个用 AI 的和尚，每人造了一座风格迥异的庙。
碎片化的根源：各自为战的上下文
问题的根源在哪？Luke 指出了一个很关键的技术细节：每个人管理 AI 上下文的方式是割裂的。
想想看，我们是怎么配置自己的 AI 助手的？有人用 .cursorrules，有人用 AGENTS.md，有人在 ChatGPT 的自定义指令里写了一大段，有人干脆每次对话前手动贴一段 prompt。这些配置文件散落在各自的电脑里，彼此不可见，也不可同步。
| 角色 | AI 配置方式 | 关注重点 | 输出风格 |
|---|---|---|---|
| 设计师 | 品牌一致性 prompt | 视觉规范、色彩体系 | 感性、视觉导向 |
| 工程师 | 代码规范 + 架构约束 | 性能、可维护性 | 严谨、结构化 |
| 产品经理 | 业务背景 + 用户画像 | 用户体验、商业价值 | 叙事性、场景化 |
这三种视角本身都是好的，甚至可以说都是必要的。但当它们各自独立地与 AI 交互，产出的东西就很难对齐。设计师让 AI 生成了一套圆润的 UI 风格，工程师让 AI 写了一套极简的 API 接口，产品经理让 AI 规划了一个大而全的功能列表——三者之间的 gap，最终还是要靠人来弥合。
讽刺的是，AI 本来是为了提升效率，结果却在团队层面制造了新的协调成本。
协同驾驶：一个可能的解法
Luke 提出的方向叫做 Cooperative Steering，直译就是「协同驾驶」。核心思路其实不复杂：与其让每个人各自驾驶自己的 AI，不如让团队共同掌舵一组共享的上下文。
具体来说，就是建立一个团队共享的 AI 指令框架。这个框架不是某一个人写的，而是团队中不同角色共同贡献的——设计师注入品牌规范，工程师注入架构约束，产品经理注入业务目标。所有人的「驾驶意图」被汇聚到一个统一的地方，AI 在这个共享上下文的约束下工作，产出自然就是对齐的。
Luke 在文中提到了一个叫 Intent 的平台，用于建立这种共享的项目参数。抛开具体的产品不谈，这个思路本身我觉得是非常值得关注的。
打个比方：传统团队协作就像一支交响乐团，指挥（项目负责人）拿着总谱，确保每个乐手（团队成员）在正确的时机演奏正确的段落。而 AI 时代的「各自驾驶」模式，相当于每个乐手都配了一个 AI 编曲器，各自编各自的，指挥根本管不过来。
协同驾驶的思路则相当于——大家共用一份总谱，每个人的 AI 都在这份总谱的框架下工作。你可以有自己的独奏段落，但和声、节奏、调性是统一的。
对工程团队的启示
聊到这儿，不妨再往深了想一层。
其实这个问题并不是 AI 带来的新问题，它本质上是一个古老的工程问题的新变种——配置管理与知识共享。我们早就知道代码要有统一的代码仓库，文档要有统一的知识库，CI/CD 要有统一的流水线。现在，AI 的上下文配置也需要「统一管理」了。
一些团队可能已经在做类似的事情了，比如：
- 在项目根目录维护
.cursorrules或AGENTS.md，作为团队共享的 AI 指令 - 在团队 wiki 中维护标准化的 prompt 模板
- 通过 MCP（Model Context Protocol）等服务化的方式，让 AI 助手共享项目上下文
但坦白说，大多数团队还停留在「各自为战」的阶段。Luke 的文章给了我一个启发：AI 上下文管理可能会成为未来工程团队的一个核心基础设施，就像代码仓库和 CI/CD 一样不可或缺。
一些冷思考
当然，我也不是完全乐观。协同驾驶的思路听起来很美，但落地还有不少现实问题：
第一，隐私与自主性的边界。 每个人的 AI 助手里可能包含个人的工作习惯、笔记、甚至敏感信息。让团队共享上下文，哪些该共享、哪些该隔离？这条线不太好画。
第二，版本管理与冲突解决。 当设计师想更新品牌规范，工程师觉得现有的架构约束需要调整，产品经理又有了新的业务方向——共享的 AI 上下文怎么管理版本？冲突了听谁的？这本质上是一个治理问题。
第三，工具链的碎片化。 现实是团队成员用的 AI 工具五花八门，让 Cursor、ChatGPT、Claude、Midjourney 都接入同一套共享上下文，技术上的挑战不小。
不过话说回来，哪个好的工程实践不是从一堆问题中趟出来的呢？当年 Git 刚出来的时候，大家也觉得「分布式版本控制」太复杂了，不如 SVN 直观。但时间证明了正确的方向。
最后
一言以蔽之：AI 让个人效率飞升，但团队协作的一致性正在被悄然侵蚀。这不会是某个工具能解决的问题，它需要新的协作范式、新的基础设施、以及新的团队文化。
Luke 的文章给了我一个很好的视角来审视这个问题。私以为，「协同驾驶」这个概念虽然还比较早期，但方向是对的。未来那些能率先建立起「团队级 AI 上下文管理」能力的团队，大概率会在 AI 时代的产品竞争中占据先机。
不多说了，我得去跟团队聊聊我们的 .cursorrules 是不是该从「我的个人配置」升级成「团队的共享资产」了 [抱拳]。
本文灵感来源于 Luke Wroblewski 的文章 Cooperative Steering，推荐阅读原文。