前段时间，一位程序员跟我说起他最近的困扰。

现在产品经理在用 AI 写需求、画原型，他也在用 AI 写代码。照理说，两个人都变快了，项目应该推进得更顺才对。可实际情况恰恰相反。

产品经理把 AI 生成的方案交过来，他用自己的 AI 拆解和实现。讨论到一半，两个人才发现，产品经理未必完全理解那份方案，他也未必完全理解 AI 生成的代码。两个人围绕两个 AI 的产物来回争论，最后甚至说不清，分歧究竟出在需求、实现，还是各自一开始就带错了上下文。

他说了一句很有意思的话：真想让产品经理的 AI 和我的 AI 直接对接。

既然很多内容都是 AI 生成的，与其让两个人分别转述，再在误解上继续讨论，不如让两个 AI 自己把问题说清楚。

这听起来像一句程序员式的吐槽，却可能指出了 AI 进入团队之后最早暴露的问题：我们更新了个人工具，却还在沿用上一代的协作方式。

过去两年，市场上的 AI 提效工具越来越多。写文档、做调研、画原型、写代码、做数据分析，每个环节都有人在做 Copilot 和 Agent。管理者也开始关心，公司买了多少账号、多少员工在使用、单项任务节省了多少时间。

但生产力变化之后，生产关系不会停在原地。

如果产品经理、程序员、运营和销售都拥有自己的 AI，如果一个人不再只是一个执行者，而是在同时调度多个 Agent，那么团队合作还会是今天的样子吗？

这可能是每一个管理者现在都应该开始思考的问题。

个人越快，团队为什么可能越慢？

传统协作里存在一个很少被说出来的前提：一份工作成果，大体代表着交付者本人的理解。

产品经理写出一份需求文档，意味着他至少能够解释需求的背景、边界和取舍；程序员提交一段代码，意味着他大体知道代码为什么这样实现；运营给出一份方案，也应该知道数据从哪里来、判断依据是什么。

成果当然也可能有错，但“谁产出，谁理解，谁负责”通常连在一起。

生成式 AI 正在拆开这三件事。

一个人现在可以在十分钟内得到一份结构完整的竞品分析、一套看起来专业的产品方案，或者一段能够运行的代码。但输出质量的提高，并不意味着人的理解同步提高。很多时候，AI 已经写到了第五层，使用者的判断还停留在第二层。

于是，团队里开始出现一种新型交付物：它看起来已经完成，实际却没有被任何人真正吃透。

这类交付物进入下一个环节后，问题会被继续放大。接收者通常不会看到它背后的对话，不知道 AI 使用了哪些事实、补充了哪些假设，也不知道哪些结论是明确要求，哪些只是模型为了完成答案而作出的合理猜测。

一旦发生分歧，双方很难再回到同一个问题上。

过去的争论可能是“这个需求该不该做”；现在的争论可能变成“你的 AI 为什么这样理解”“我的 AI 明明给了另一个答案”。表面上是人在讨论，实际上每个人身后都站着一个上下文不同、资料不同、推理路径也不同的 AI。

AI 降低了生成成本，却提高了另外三种成本：判断什么是真的，确认大家使用的是不是同一个版本，以及在结果出错时找到责任落点。

所以，个人效率不等于组织效率。

当输出增长得比团队的理解、验证和决策能力更快，更多产出甚至会变成新的拥堵。文档更多了，方案更多了，代码更多了，需要审查和返工的东西也更多了。

AI 时代最危险的团队，不一定是不用 AI 的团队，也可能是每个人都在高效地产出，但没有人负责让这些产出收敛到同一个现实里的团队。

一边让每个人带 Agent，一边要求所有事情写进文档

我在寻找 AI-native 团队案例时，看到句子互动创始人李佳芮提出了一种组织设想：未来组织的基本单元，会从一个人变成“一个人加一支 Agent 队伍”

在她分享的客户案例里，一名普通销售过去要亲手处理两百多条客户消息，再手工整理跟进记录；现在，多个 Agent 可以并行处理对话，人只接手低置信度的问题，并在一天结束前检查交付报告。

这时人的工作不再是逐条回复，而变成三件事：分活、定义、验收。

这组变化很重要。

我们过去习惯把“管理”理解为管理别人，所以只有主管、总监和 CEO 才是管理者。但当一个员工开始同时调度多个 Agent，他也在做资源分配、任务拆解、过程干预和结果验收。从这个意义上说，AI 正在把管理权下放给每一个普通员工。

可是，句子互动同时强调另一件看起来更传统的事情：文档。

李佳芮在谈团队必读书时写道，句子互动把文档视为正式的沟通协议；没有进入文档的事情，就不能被视为真正发生。原因不是公司喜欢写材料，而是他们天天在客户现场交付，如果思考和表达的底子不统一，交付质量就无法统一。

一边鼓励每个人带着 Agent 并行工作，一边要求工作进入正式文档，这两件事并不矛盾。

前者解决个人生产力，后者解决组织如何对齐。

每个人都可以拥有自己的提示词、工作流和 Agent，那是个人工作台；但一项工作的目标、关键事实、版本、决策和验收结果，必须进入团队共同认可的空间，那是公共记录。

没有这个公共层，个人越 AI-native，团队反而越容易碎片化。

Anthropic 对内部 132 名工程师和研究人员所做的调查，也显示了这种张力。受访者自述，Claude 已经参与其约 59% 的日常工作，并带来约 50%的生产力提升；但多数人认为，真正可以完全交给 Claude、不需要自己验证的工作仍然只有 0—20%。与此同时，一部分员工发现，以前会去问同事的问题，现在首先问 Claude，团队中的指导和交流机会也因此减少。

这意味着 AI 同时带来了两种结果：一个人能完成更多事情，但他也可能越来越多地在自己的上下文里工作。

如果组织只看到前一种结果，就会误以为给每个人配上 AI，AI-native 团队便自然出现了。实际上，工具的普及只是起点。真正困难的是，怎样让一群各自变强的人继续共享事实、传递判断并共同承担结果。

三、未来团队真正缺少的，是一个“公共控制面”

OpenAI 曾进行过一项很激进的内部实验：团队用 Codex 从零构建一个真实使用的软件产品，代码、测试、持续集成配置和开发工具都由 Agent 生成，人类不直接编写代码。

这项实验最值得注意的，不是“AI 写了一百万行代码”，而是团队很快发现，瓶颈并不在模型会不会写代码。

早期进展比预期慢，是因为环境的规范不够明确。Agent 不知道项目真正的目标，不清楚哪些信息可信，也缺少把结果验证到底的工具。模型有能力执行，但组织没有为它准备一个足够清晰的工作环境。

后来，这支团队把代码仓库改造成了记录系统：架构文档、产品规格、执行计划、进度、决策日志和技术债务都被集中存放并进行版本管理。简短的 AGENTS.md 只充当地图，引导 Agent 找到不同任务所需的真实资料，而不是把所有规则塞进一份不断膨胀的说明书。

他们还提出了一个很关键的判断：如果知识只存在于聊天记录、Google Docs 或某个人的脑中，而 Agent 在执行时无法访问，那么从 Agent 的视角看，这些知识就等于不存在。

这件事不只适用于软件开发。

今天很多团队的关键信息仍然散落在微信群、飞书消息、会议口头结论和不同人的本地文件里。人类过去可以依靠记忆、关系和反复询问勉强补齐上下文，AI 却不会自动知道上周会议上谁临时改变了决定，也无法判断群聊里的哪句话代表最终版本。

当 Agent 开始参与执行，组织中原本隐性的知识缺口会被迅速暴露。

因此，未来团队需要的可能不是一套让所有 AI 互相聊天的复杂协议，而是一个人和 AI 都能读取的“公共控制面”。

这个控制面至少要回答五个问题：

1. 我们究竟要解决什么问题？
2. 当前被认可的事实和版本是什么？
3. 哪些约束不能突破？
4. 谁对过程和最终结果负责？
5. 做到什么程度，才算真正完成？

私人工作台允许每个人自由选择模型、提示词和工作方式，公共控制面则确保这些不同的工作方式最终回到同一个目标上。

未来的团队协作，不是所有人必须使用同一个 AI，而是所有 AI 必须能够找到同一个现实。

四、协作的最小单位，将从“任务”变成“任务契约”

过去，管理者经常用一句话分配工作：“研究一下竞品”“把转化率提高一点”“做一个新用户引导”。

人接到这种任务后，可以通过会议、追问和经验逐渐补齐含义。但如果任务要交给 AI，模糊空间会迅速变成错误空间。

例如，“优化注册转化率”至少还缺少这些信息：当前基准是多少，主要问题发生在哪一步，面向哪类用户，哪些流程不能改，本轮实验持续多久，成功指标是什么，以及谁有权决定方案上线。

未来一项可以被人和 Agent 共同执行的任务，不应该只包含一句要求，而应该是一份最小任务契约：

– 目标：希望改变什么结果，而不是笼统地“做一个功能”；

– 上下文：使用哪些事实、数据和历史决定；

– 约束：哪些事情不能做，哪些风险必须避开；

– 交付物：最终要产生什么，而不是只描述过程；

– 验收标准：如何判断完成、正确和可上线；

– 责任人：谁有最终判断权，谁为结果负责。

这不是把所有工作都变成僵硬的流程，而是把过去藏在人脑里的协作前提显性化。

当任务契约足够清楚，产品经理的 AI 和程序员的 AI 不必先互相说服。它们可以围绕同一份目标、约束和验收标准分别工作，冲突也能落到具体条目上：是事实不同、方案不同，还是对完成标准的理解不同。

岗位也会因此发生变化。

产品经理不再只是需求文档的生产者，而要成为问题和验收标准的设计者；程序员不再只对代码数量负责，而要判断技术路径、建立可验证的环境，并让关键假设可以追溯；管理者也不能只追进度，而要维护团队的公共上下文，处理目标冲突，保证组织不会在高速产出中失去方向。

岗位边界可能会变薄，但责任边界必须变清。

Anthropic 的调查里，很多工程师已经把自己描述为 AI Agent 的管理者。但他们仍然把战略判断、需要组织上下文的设计决策和“品味”留给自己。原因很简单：AI 可以扩大一个人的行动范围，却不能替他承担组织责任。

AI 写的方案署的是你的名字，Agent 发出的结果影响的是你的客户，最终负责的人仍然不能说：“这是 AI 做的。”

五、你的团队只是“人人在用 AI”，还是已经开始 AI-native？

怎样判断一个团队是否真正进入了新的协作方式？

第一，团队是否拥有唯一可信的信息源？

当需求、数据和决策发生冲突时，所有人是否知道去哪里找最终版本？还是每个人都从自己的聊天记录里寻找证据？

第二，任务是否可以被人和 AI 同时理解？

目标、上下文、约束、交付物和验收标准是否明确？还是只有一句“你先做一下看看”？

第三，AI 产出是否能够追溯？

接收者是否能知道一份结果依据了什么事实、作出了哪些假设、经过谁的确认？这不意味着保存所有提示词，而是保留影响决策的关键信息。

第四，验收是否发生在执行之前？

团队是在开始工作前就定义“什么叫完成”，还是等 AI 生成一大堆内容后，再凭感觉挑选？

第五，成功和失败能否沉淀为组织能力？

一个人摸索出的好方法，能否变成模板、Skill、规则或评估集，让下一个人直接复用？一次 AI 事故，是否只是返工结束，还是会进入下一轮的检查机制？

如果以上部分满足，团队大概率仍处在“个人工具化”阶段：大家都在使用 AI，但组织没有变。

如果以上大部分都满足，说明团队开始建立 AI 协作机制，不过许多关键上下文仍然依赖个别人。

若是全部都满足，那已经接近真正的 AI-native 团队：个人可以高度并行，组织又能让不同产出快速收敛，并持续把经验沉淀下来。

所以，AI-native 不是全员购买某个工具，也不是公司里部署了多少个 Agent。真正的标准是：当个人产出速度突然提高几倍，团队还能不能保持事实一致、责任明确、质量可控。

六、管理者应该提前布局，还是等待答案被验证？

面对这样一场变化，管理者很容易走向两个极端。

一种是立刻重构组织、引入一整套复杂系统，试图一步到位；另一种是继续观望，等头部公司把最佳实践全部验证之后再复制。

我认为两种选择都不必要。

今天没有人真正知道 AI-native 组织的终局。OpenAI 在公开经验中也承认，他们仍然不知道完全由 Agent 生成的系统，长期会怎样保持架构一致性。句子互动同样把产品、测试、运维和 AI 管培生的工作方式列为“还没有解完的题”。

但管理者不需要等到终局出现，才开始学习。

最现实的做法，是选择一个低风险、跨角色、验收结果相对明确的项目，做一次短期的协作实验：

1. 建立一份所有参与者和 AI 都可以读取的项目主页，只保留目标、事实、决策、任务和结果；
2. 允许每个人使用自己的 AI，但交付时必须说明关键依据、假设和未确认项；
3. 每项工作开始前先写验收标准，避免完成之后再争论什么叫完成；
4. 每周只复盘一个最典型的 AI 协作失败，并把教训写成下一次可执行的规则；
5. 涉及客户数据、商业秘密和高风险操作时，提前划定权限，保留人工确认和审计记录。

一次实验不一定能让团队变成 AI-native，却能让管理者看清真正的摩擦发生在哪里：是任务定义不清，信息分散，验证能力不足，还是责任一直没有落到人。

所谓提前布局，也不是提前购买一个还不存在的“AI 组织操作系统”。

更重要的是，从现在开始积累机器可读、人员可用的组织记忆；训练员工定义任务和验收结果的能力；把每一次成功和失败变成下一次可以复用的机制。

这些东西即使模型继续变化，也不会过时。

结语

再回到那位程序员最初的问题：要不要让产品经理的 AI 和程序员的 AI 直接对接？

方向或许没有错，但顺序需要调整。

不是先让两个 AI 自由聊天，而是先让它们读取同一份目标、事实、约束和验收标准；不是让 AI 替人决定谁是对的，而是让分歧变得可定位、可验证，最后由明确的人承担判断和结果。

未来的团队，很可能是这样的：每个人都带着自己的 Agent 队伍并行工作，组织通过一个公共控制面让所有工作收敛，人则负责定义问题、作出选择、验收结果并承担责任。

当生成越来越便宜，真正昂贵的将是判断、共识与负责。

这才是 AI 提效工具满天飞之后，管理者更应该提前建设的生产关系。