# 关于 AI 时代团队协作的思考 > 从 AI、Vibe Coding 与跨角色协作出发，讨论上下文、责任边界和团队效率如何在 AI 时代重新建立。 - 发布于：2026-07-18 - 更新于：2026-07-18 - 分类：AI - 标签：协作、AI、研发体验 - 原文：https://chanx.tech/blog/ai-era-team-collaboration # 关于 AI 时代团队协作的思考 > 当个人越来越快，团队为什么反而更难协作？ > > 最近一段时间，我经常遇到一种有些矛盾的协作体验。 一个需求还没有完全说清楚，页面已经可以运行；产品方案仍在讨论，代码已经提交；过去需要几个人共同推进的事情，现在一个人借助 AI，很快就能做出一个看起来不错的结果。 从个人视角看，这当然是一种进步。 过去需要查资料、请教同事、反复试错才能完成的工作，现在通过几轮对话就能得到一个可用结果。开发可以更快地补充文案和分析数据，产品、设计甚至运营也可以直接做出页面和交互原型。每个人都能跨出原来的职责边界，完成更多事情。 但从团队视角看，事情并没有因此变得更简单。 产出的代码、页面和方案变多了，真正推进起来却未必更顺畅。需求到了后期仍然需要重新解释，代码到了上线前仍然需要大量修改，一些原本可以提前暴露的问题，最后都堆到了开发和测试阶段。 看起来每个人都跑得更快了，但整个团队未必真的走得更远。 这让我开始意识到，AI 改变的不只是个人效率。它也在重新塑造团队内部的角色、沟通方式和协作关系，而我们的协作机制，还没有完全跟上这种变化。 ## 能运行，不等于完成交付 Vibe coding 很容易带来即时反馈。 输入一段描述，等待几分钟，一个页面、一个功能，甚至一条完整流程就出现了。过去需要排期、评审和开发的事情，现在似乎可以直接跳到结果。 问题在于，一个能够运行的结果，只代表实现已经开始，并不代表需求已经完成。 当这个结果进入真实协作时，团队仍然需要回答一系列问题： - 它究竟要解决什么问题； - 面向哪些用户和场景； - 当前方案做出了哪些取舍； - 哪些边界必须覆盖； - 哪些部分只是临时验证； - 谁对最终质量和上线结果负责。 这些问题不会因为代码已经生成而消失。 如果实现跑在理解前面，本应在前期完成的思考，最终会以返工、补文档、修复问题和反复解释的方式重新出现。 AI 确实缩短了“做出一个东西”的时间，但从“做出一个东西”到“完成一次交付”，中间仍然隔着需求理解、方案判断、质量保障和责任确认。 ## 被省略的沟通，只是被推迟了 传统协作流程经常显得笨重。 需求要讨论，方案要评审，技术要留下记录，提测还要整理说明。很多环节看起来像在重复信息，让人自然产生一种冲动：既然 AI 已经可以直接生成结果，为什么还要经过这些步骤？ 但这些流程真正保存的，未必是文档本身，而是共同上下文。 需求讨论让团队理解为什么要做，产品方案说明目标和边界，技术方案记录关键判断，提测信息帮助上下游确认完成范围。文档可以更短，会议也可以更少，但其中承载的信息不能完全消失。 否则，前面省下来的沟通成本，最后往往会转移给下游。 一个人独自和 AI 完成需求分析、界面设计和代码生成，过程可能非常顺畅。但当结果交给其他人时，对方看到的通常只有最终产物，看不到中间发生过什么。 接手者不知道方案基于哪些前提，不知道哪些风险已经考虑过，也不知道哪些问题只是暂时被忽略。为了继续推进，他只能重新理解需求、阅读代码、补全场景，再做一次完整判断。 对前一个人来说，效率提高了；对后一个人来说，工作却变得更重了。 这种成本转移很隐蔽，因为每个局部环节看起来都在提速。只有从完整链路回头看，才会发现工作并没有真正减少，只是从前期的显性沟通，变成了后期更昂贵的返工和兜底。 ## Vibe coding 没有问题，不理解自己做的东西才有问题 我并不反对 vibe coding。 它降低了实现门槛，也让很多想法可以更快得到验证。产品、设计甚至运营能够直接做出原型，本身就是一件有价值的事。 问题不在于谁写了代码，而在于做出结果的人，是否理解自己交付的东西。 如果只是把一句需求丢给 AI，等待它生成结果，再把结果抛给别人，自己却说不清整个流程如何运转、关键判断是什么、风险可能出现在哪里，那么这并不是能力边界的扩展，而是在把不确定性向下游转移。 需求推进方未必需要掌握所有技术细节，但至少应该能够说明： - 这个功能从哪里开始，到哪里结束； - 数据或消息在链路中如何流转； - 当前实现依赖了哪些前提； - 哪些部分已经确认，哪些部分仍然不确定； - 已知问题和风险有哪些。 AI 可以帮助一个人完成原本不熟悉的工作，却不能替代最基本的理解责任。 如果连自己交付的结果都无法解释，就很难期待其他人能够无成本接手。 ## 角色边界可以变宽，责任不能消失 AI 让跨角色协作变得更加容易。 开发可以理解更多产品和业务，产品可以更早验证技术可行性，设计也可以直接做出高保真原型。过去因为专业壁垒产生的等待，确实可以被缩短。 但能力边界变宽，不意味着主要角色可以消失。 产品可以参与代码实现，但仍然需要对问题定义、用户场景和方案完整性负责；开发可以参与产品讨论，但仍然需要对技术设计、实现质量和系统稳定性负责；设计可以通过 AI 完成交互原型，但仍然需要对体验逻辑和一致性负责。 跨角色参与的意义，是更好地理解上下游，减少信息损耗，并在必要时相互补位，而不是让责任变得模糊。 最危险的状态不是角色重叠，而是所有人都参与了，却没有人真正负责。 一旦需求边界不清、实现出现问题，事情往往会自然落到最接近生产环境的人身上。开发需要重新理解需求、修改实现、补充测试，最后还要承担上线后的维护。 这时所谓的“灵活协作”，实际上只是把责任和成本推到了链路后端。 ## AI 放大的，是人的能力结构 我更愿意把 AI 理解为一种能力放大器，而不是能力替代器。 如果一个人已经具备清晰的问题意识和专业判断，AI 可以帮助他更快地搜索、验证、补充和执行；但如果一个人对问题缺少理解，也没有明确方向，AI 同样会放大这种模糊。 生成式 AI 给出的，并不是唯一正确答案，而是在当前上下文中生成一个概率上合理的结果。 当你让它提供方案一、方案二、方案三时，这些方案都可能听起来完整，但未必真正指向你要解决的问题。如果使用者自己没有判断，就很难识别： - 哪个方案建立在错误前提上； - 哪个建议只是脱离场景的通用答案； - 哪个实现已经偏离真实需求； - 哪些细节看起来合理，实际并不可用。 因此，真正重要的并不只是会不会写 Prompt，也不只是能不能快速生成结果，而是一个人是否拥有足够的专业深度，以及对完整链路的基本理解。 在主要角色上，人仍然需要深度。 比如一个前端开发，仍然需要理解状态、性能、工程结构、交互和浏览器运行机制，而不能把所有判断都交给 AI。 与此同时，他也需要具备一定广度，知道产品为什么提出这个需求，后端如何处理数据，系统如何部署和运行，上线后如何监控和定位问题。 这些领域不一定都要达到专家水平，但至少应该知道有哪些关键环节、问题可能发生在哪里，以及什么时候需要找对应角色共同判断。 在具体业务中，这种广度还需要落到真实链路上。 例如开发一个 AI 应用，不一定要求每个开发者都深入研究模型训练，但至少应该知道一条消息如何从前端进入服务端，如何组装上下文，如何调用模型，结果如何流式返回，以及长上下文如何被压缩和管理。 深度帮助人判断结果是否可靠，广度帮助人理解结果能否进入完整系统。 AI 可以帮助我们更快拓展广度，也能辅助我们深入某些方向，但它无法替代使用者建立自己的知识结构。 ## 每个人都有答案，团队却未必形成答案 AI 让答案变得非常容易获得。 过去遇到一个陌生问题，我们可能先搜索资料，再和相关同事讨论。这个过程虽然慢，却会自然暴露彼此理解上的差异。 现在，每个人都可以先去问自己的 AI。 产品有一套答案，开发有一套答案，设计也有一套答案。每一套都听起来完整、合理，但它们可能建立在完全不同的前提上。 有人关注用户体验，有人关注实现成本，有人关注上线速度，还有人默认这个需求只是一次短期实验。 如果团队没有真正交换这些前提，就很容易产生一种错觉：每个人都已经理解了问题。直到开始执行，差异才逐渐显现。 AI 可以帮助每个人快速建立自己的上下文，却不会自动把这些上下文连接起来。一个人知道得更多，并不代表团队因此知道得更多。 只有当大家愿意把自己的判断、前提和不确定性拿出来讨论，个人获得的信息才有机会变成团队认知。 否则，每个人都可能越来越聪明，团队却越来越像一组彼此隔离的节点。 ## 不要把同事当成 Agent 和 AI 沟通时，我们很习惯只给出一个目标。 “帮我分析一下。” “把这个需求做出来。” “看看这个方案有没有问题。” 上下文不足时，AI 会继续追问；结果不满意时，我们可以重新生成。作为工具，这种交互方式没有问题。 但同事不是 Agent。 同事之间首先是人与人之间的关系，不是一方发出指令，另一方自动补齐上下文、理解意图并返回结果。 现实中的一些工作沟通，正在越来越像发送 Prompt： - 抛出一句模糊需求，默认对方会理解剩余部分； - 提出一个问题，却不提供必要背景； - 面对追问时，再临时向 AI 查询； - 转发一段 AI 输出，就认为沟通已经完成。 这类沟通最让人疲惫的地方，不一定是信息少，而是缺少真实判断。 对方可能带来了很多内容，却很难回答几个简单的问题：你自己怎么看？为什么倾向这个方案？哪些地方还没有想清楚？ 人与人之间真正有价值的交流，不只是交换结论。 我们会追问对方的前提，会指出彼此忽略的问题，也会在讨论中改变自己的判断。很多好的方案并不是某个人一开始就想出来的，而是在来回碰撞中逐渐形成的。 AI 往往会顺着你的问题给出答案，但同事可能会质疑这个问题本身。他可能会提醒你，这件事并不值得做，或者你忽略了一个更重要的约束。 这些质疑有时会让沟通变慢，甚至让人感到不舒服，但这恰恰是协作产生价值的地方。 如果大家只是转发各自 AI 的答案，沟通虽然没有停止，思考却可能已经停止了。表面上是人在交流，实际上只是不同模型输出之间的信息搬运。 ## 团队效率不能只看局部速度 AI 时代最容易被误判的指标，是速度。 原型生成得更快，代码提交得更多，方案输出得更及时，这些都是可见的变化。但团队效率并不是所有个人速度的简单相加。 一个需求即使一天内就有了可运行版本，也可能花费一周反复修正；一段代码即使很快完成，也可能因为缺少背景，导致后续每个人都要重新理解；一个问题即使被快速解决，也可能因为没有处理根因，在未来不断重复出现。 真正值得观察的，也许不是第一版完成用了多久，而是： - 从提出问题到形成共识用了多久； - 上线前经历了多少次返工； - 有多少信息在不同角色之间被重复确认； - 上线后还需要投入多少维护成本； - 团队是否越来越容易处理同类问题。 如果从这些角度看，一些看似快速的工作方式未必真的高效。 它们只是把时间从前面挪到了后面，把显性的讨论变成隐性的返工，把原本可以共同完成的思考，变成每个人各自重做一遍。 真正的团队效率，不是每个人都尽可能快地向前跑，而是整个链路能够稳定、清晰地向前移动。 ## 流程不必更重，但连接不能缺失 意识到这些问题，并不意味着要重新回到繁重的传统流程。 AI 已经改变了执行方式，协作流程也应该随之变轻。很多过去需要长文档和多轮会议完成的工作，现在完全可以被压缩。 但流程变轻，不应该等于上下文消失。 一项由 AI 辅助推进的需求，未必需要一份完整 PRD，但至少应该让相关人员知道： - 为什么要做； - 解决的是谁的问题； - 当前方案如何运转； - 有哪些已知边界； - 哪些地方仍然不确定； - 谁负责推动，谁负责质量，谁负责最终结果。 这些信息不一定需要写成长篇文档，也可以通过简短说明、需求群同步或关键节点记录完成。 重要的不是形式，而是团队中的人是否真正站在同一套上下文里。 当这一点成立时，AI 才能帮助团队减少重复劳动、加快验证，并扩大每个人的能力。否则，它只是让每个人更快完成自己的那一部分，同时让整个团队承担更多连接成本。 ## 结语 AI 让每个人都可以做更多事情，也让一个人完成完整任务变得越来越容易。 但团队的价值，本来就不在于把一群能够独立工作的人简单地放在一起。 团队真正有价值的地方，是让不同人的经验、判断和视角发生连接。一个人没有看到的问题，另一个人可以补充；一个角色默认的前提，可以被另一个角色重新检验；一个初步方案，也可以在讨论中不断变得完整。 AI 可以扩展我们的能力边界，也可以放大我们在专业领域中的判断。但前提是，我们仍然愿意理解自己做的事情，也愿意与他人建立真实的共同上下文。 当每个人都在和自己的 AI 深度交流时，我们也许更需要提醒自己：不要把同事当成 Agent，也不要把自己变成 Agent 的传声筒。 AI 可以帮助每个人更快获得答案，但一支团队真正需要的，可能从来都不只是更多答案，而是一起理解问题、形成判断并承担结果的过程。