从WorkBuddy企业版：到AI Native组织的关键问题

从WorkBuddy企业版出发，探讨AI如何重构企业协作的深层逻辑，揭示从个人效率到组织变革的必经之路。核心内容：1. AI时代下，个人效率提升与组织流程瓶颈的矛盾2. AI进入组织后需要解决的三个层次问题（L1-L3协作协议）3. 迈向AI Native组织的关键挑战与思考框架

前几天，我看到一篇文章。作者参加了 WorkBuddy 产品负责人的一场分享，回来后把现场的 PPT、问答和会后交流整理了出来。分享的题目是《从 0—1 打造 AI Native 产品背后的组织思考》。如果对这个产品不熟悉，可以先把 WorkBuddy 理解为腾讯云推出的一种 AI 工作台。我们过去使用的大多数 AI 产品，更像一个聊天顾问。人提出问题，AI 给出答案、建议或者一段生成内容。至于结果怎样进入实际工作，通常还需要人自己完成。WorkBuddy 想往前多走一步。它不只回答问题，也尝试调用工具、操作文件、处理更长的任务，并交付可以继续使用的结果。面向企业和团队的 WorkBuddy 企业版，又在个人工作台的基础上增加了知识、权限和协作能力。它试图连接腾讯文档、腾讯乐享以及会议产生的上下文，让内容生产、知识沉淀与能力复用发生在同一个工作空间里。但真正让我停下来的，并不是这些产品功能。是这场分享逐渐把问题从产品推向了组织。当 AI 大幅降低执行、试错和知识调用的成本以后，企业原来的分工与协作方式还成立吗？这个问题刚好碰到了我最近一直在想的一件事。过去一段时间，我们听到了很多关于“超级个体”的故事。一个人带着 AI，可以写代码、做设计、研究市场、制作销售材料，甚至独立搭起一个小产品。原来需要一个小团队完成的事情，现在可能由一个人指挥多个 Agent 完成。这些变化都是真的。但在企业里，我也看到另一种情况。某个岗位的产出变快了，整个流程却没有同步变快。销售方案生成得更快，但承诺与交付之间出现了更多返工。代码写得更快，测试、维护和架构一致性的压力却转移到了后面。客服回复速度提高了，一些原本由有经验的人识别的投诉升级信号，反而更容易被忽略。看起来是效率提升。实际只是把摩擦从一个环节移到了另一个环节。这让我意识到，AI 带来的变化可能不只是消除瓶颈。更多时候，它是在移动瓶颈。当执行变快以后，新的瓶颈可能出现在验证、协作、判断、信任和责任上。也正是在这里，WorkBuddy 负责人的分享提供了一个很有意思的观察框架。他把 AI 进入组织以后遇到的问题，分成了三个逐渐扩大的层次。第一个层次，是一个人怎样带着多个 Agent 工作。第二个层次，是多个被 AI 放大的个体怎样形成团队。第三个层次，是多个团队之间怎样交换能力、价值和资源。在分享中，这三个层次分别被称为 L1、L2 和 L3。这里不妨先把它们理解为三层协作协议：L1 是个人与 Agent 之间的协作。L2 是多个个体和 Agent 之间的团队协作。L3 是不同团队之间的能力流动和组织治理。它们不是 WorkBuddy 的三个产品版本，也不是可以一次性采购的三个功能模块。更像是 AI 逐渐进入真实工作以后，组织依次需要回答的三类问题。所谓 AI Native 组织，也不只是给现有组织增加一些 AI 工具。它意味着，当 AI 开始成为工作的实际参与者，我们需要重新设计任务怎样发生、信息怎样流动、结果由谁验证、经验如何沉淀，以及责任最终由谁承担。
一个人先快起来01
WorkBuddy 团队内部最早出现的“超级个体”，据文章转述，并不是来自一场自上而下的 AI 转型动员。团队里先有资深工程师做出了可用的 AI coding 客户端。后来，一个几个人组成的小团队在两个月左右发布了接近 80 个版本。数字本身不是最重要的。重要的是，这个工具并不只会生成一段代码。它开始接触真实的代码仓库、测试、扫描、命令、规则和 CI/CD，也开始保留任务上下文和执行状态。AI 进入了完整的工作流。工程师的工作位置随之发生变化。他不再亲自完成所有中间步骤，而是把更多注意力放在定义目标、拆解任务、审核结果和承担质量责任上。Agent 负责规划、执行、调用工具和自检。任务结束后，过程中形成的规则和经验，还可以被沉淀为 Skill 或 Memory，供下一次任务继续使用。Skill 可以简单理解为一套能够被 AI 重复调用的工作方法。Memory 则不只是一份知识文档。它还可能包含某项任务的历史、偏好、判断依据和执行状态，让下一次工作不必完全从头开始。分享中把这一层称为 L1，也就是个人与 Agent 之间的协作协议。它包含一个很重要的闭环：先规划，再执行，最后验证。分享中用 PEV 来概括，也就是 Plan、Execute、Verify。先把目标和完成标准想清楚。再让 Agent 承担中间执行。最后由测试、规则或者人的判断确认结果。如果验证没有通过，就修改计划或者重新执行，而不是把一个未经检查的结果直接交出去。这听起来像一个技术闭环，背后其实是一套责任安排。AI 可以承担越来越多的劳动，却没有自动获得定义目标的权力。它可以生成结果，也不能替人决定这个结果是否应该被接受。人仍然需要回答：什么值得做，怎样算完成，出了问题在哪里停止，以及这次任务留下了哪些可以复用的经验。所以，分享中对“超级个体”的理解，并不是一个人用了很多 AI 工具。更接近的表达是：一个人带着一组 Agent，在清晰的目标、工具和验证机制下，完成过去需要多人协作才能完成的工作。这也解释了为什么“一人公司”开始变得可能。过去一个人创业，常常不是某项能力不够强，而是整个商业链条太长。一个人可能懂产品，但不会设计；懂客户，但不会写代码；会做内容，却不懂财务测算。一个商业闭环里有很多环节。只要其中几个环节不及格，整件事就很难跑起来。AI 的价值，是把一部分原来不及格的环节补到了及格线。它没有让每个人都成为全才。但它让一个人的能力曲线不再那么容易断裂。
快起来以后02
事情到了这里，看起来很顺利。一个人可以完成更多任务，小团队可以做过去大团队才能做的项目，公司也可以用更少的资源获得更高的产出。但这只是第一层。WorkBuddy 分享里有一个很好的问题：如果一家公司已经有了十个超级个体，它就自然成为超级团队了吗？直觉上，我们容易回答“是”。每个人都变快了，团队当然也应该变快。但再想一步，就会发现事情可能恰好相反。以前，一个人一天形成一个方案，团队还有时间开会、讨论和修正。现在，几个人分别带着 Agent，一下午就可以形成十几个版本。每个版本都有自己的上下文、判断依据和实现路径。产出增加了，需要被理解和比较的内容也增加了。如果团队仍然依靠会议同步、手工汇总和层层拍板，个人节省下来的时间，很快又会被新的协调成本吃掉。被 AI 放大的不仅是能力，也包括分歧。每个人都可以迅速把自己的想法变成一个看起来已经成形的方案。原来还停留在讨论阶段的差异，现在都变成了需要评审、测试和维护的产物。瓶颈从执行移动到了协作。WorkBuddy 分享把这一层称为 L2，也就是团队协作协议。它要解决的，不再是一个人怎样给 Agent 分配任务，而是多个人、多个 Agent 和多个任务线程怎样形成共享状态。这里的“共享状态”和共享一份文档不太一样。一份最终文档通常只能告诉后来者：最后写了什么。但它很难完整保留：最初为什么提出这个目标，中间尝试过哪些方案，哪些路径被放弃，哪些结论已经验证，哪些冲突还没有解决，以及下一步可以从哪里继续。而 Agent 要继续完成任务，恰恰需要这些信息。如果一个人把任务交给另一个人，后者需要重新阅读、询问和理解。一个 Agent 把任务交给另一个 Agent，也会遇到同样的问题。缺少的不只是文件。缺少的是一段可以继续运行的认知状态。所以，L2 需要解决几类连接。一个新的目标出现后，相关的人和 Agent 怎样知道这件事。多个方案同时产生以后，怎样比较、合并，或者保留仍有价值的分歧。一个任务中形成的有效经验，怎样被其他人继续使用。一个失败方案留下的判断和数据，怎样避免在下一轮被重新踩一遍。这些问题过去也存在。AI 只是让它们出现得更快了。我在做 AI 调试时，经常遇到一个很小的版本。模型在某个场景里答错了。我们找到一个反例，补规则，改提示词，希望它下一次能够答对。但真正麻烦的是，改完以后，过去那些已经答对的样本还能不能继续答对。一个新规则可能修复一个问题，也可能破坏原来稳定的部分。所以，成熟一点的调试不能只看眼前这个错误有没有消失。还要做回归测试，检查边界，确认系统整体是否真的变得更可靠。企业引入 AI 也是一样。替换一个任务，就像给系统增加一条新规则。这个节点也许更快了，但上下游的节奏可能被改变，原来隐含的责任可能变得模糊，一些只有经验丰富的人才能识别的异常信号，也可能一起消失。这不是因为 AI 不够强。而是因为业务从来都不是单点运行的。
公司原本解决的是什么03
说到这里，我想起了经济学家罗纳德·科斯。科斯出生于英国，是 1991 年诺贝尔经济学奖得主。他最重要的贡献之一，是把“交易成本”带进了对企业和制度的分析。1937 年，他在《企业的性质》中提出了一个后来影响很大的问题：既然市场可以通过价格和交易组织分工，为什么世界上还需要公司？比如，一家企业需要设计、生产、销售和财务服务，理论上都可以临时到市场上寻找最合适的人。任务来了就合作，任务结束就解散，似乎比长期维持一个组织更灵活。但真实世界不是这样运行的。每一次临时合作，都需要寻找合适的人，比较不同方案，解释需求，谈判价格，签订合同，监督过程，并在出错后确认责任。这些动作本身也消耗时间和资源。科斯把这类成本称为交易成本。公司的意义之一，就是把那些需要反复发生的市场交易，变成相对稳定的内部协作，从而系统性降低交易成本。当组织内部协调的总成本低于每次重新到市场上交易的成本，公司就有了存在的理由。这也是科斯获得 1991 年诺贝尔经济学奖时被特别强调的贡献之一。这个解释帮助我重新理解企业。一家公司并不只是一群人待在同一个组织里。它也是一种降低协作成本的安排。很多岗位之所以长期存在，不只是因为它们完成了一项显性的任务。它们还保存了上下文，建立了信任，缩短了沟通路径，也承担了持续协作中的责任。那么，AI 对企业更深的价值，也许不只是让某个人更快完成某项任务。它还应该继续降低那些原本就促使公司存在的成本。降低信息寻找的成本。降低需求反复解释的成本。降低跨部门同步的成本。降低返工和异常升级的成本。也降低事情出了问题以后，重新确认责任的成本。这些成本很少被完整地写在财务报表里，却每天都在消耗一家公司。一个节点的产出提升，很容易被计算。但一次沟通少解释了多少背景，一个异常是否更早被发现，一个失败方案能不能被下一个团队复用，这些变化要慢得多，也不那么容易被看见。所以，AI 的 ROI 如果只用“替代了几个人”衡量，可能会错过更重要的部分。真正需要观察的，也许是交付周期有没有缩短，返工有没有减少，质量有没有提高，经验有没有被复用，以及同样规模的团队能不能承接过去无法承接的复杂度。人力、Agent 和 Token 都是成本。但最终要看的，仍然是整条业务链有没有变得更好。
当能力开始跨团队流动04
如果个人与 Agent 已经可以稳定协作，多个超级个体也开始形成共享状态，接下来才会出现第三层问题。一家公司通常不只有一个团队。产品、研发、销售、交付、财务、法务和供应链，各自积累着不同的经验和能力。一个团队可能沉淀了一套需求分析方法。另一个团队可能拥有熟悉特定行业的专家。还有一个团队可能建立了一套可靠的测试和合规检查流程。今天，这些能力通常存在于文档、代码仓库和少数员工的经验里。知道它们的人可以使用。不知道它们的人，往往只能从头再做一次。WorkBuddy 分享把不同团队之间的这层协作称为 L3，也就是组织层面的协议。它关心的是：一种能力能不能被组织里的其他团队发现、获得授权、实际调用，并在使用之后得到评价。比如，一套被验证过的需求分析方法，可以被封装成 Skill。一位资深员工的部分经验，可以形成专家 Agent。一套项目复盘，不再只是放进知识库，而是直接更新团队下一次任务会调用的检查规则。到了这一层，知识不再只是供人阅读的静态内容。它开始成为可以运行的组织能力。这幅图景很吸引人。但问题也会随之出现。调用次数多的能力，是否一定更有价值？那些长期重要、短期低频的能力，会不会被低估？一个由员工经验训练出来的专家 Agent，究竟属于谁？当它被跨部门调用，贡献、收益和责任又应该怎样分配？所以，能力可以像市场一样流动，却不能只有市场。它还需要治理。这也是企业知识沉淀里最容易被忽略的一部分。技术上，我们已经可以把一个人的文档、代码、方法和工作记录整理成知识库、Skill 或专家 Agent。但能够沉淀，不等于愿意沉淀。很多人的经验，本来就是他的职业价值。假如组织只是要求员工把经验交出来，却没有解释贡献如何被记录、能力怎样归属、调用产生的价值怎样反馈，知识管理就很容易被理解成一种单向索取。WorkBuddy 负责人在交流中给出的边界很克制：产品可以支持一个人分享专家能力和工作结果，但不能强迫他分享。技术可以负责封装知识。让知识真正流动起来，依靠的却是信任。
从一条工作流开始05
回头看，L1、L2 和 L3 并不是三个需要记住的专业概念。它们只是帮助我们看见，AI 进入企业以后，问题会怎样逐层变化。最初的问题是：一个人怎样带着 Agent 完成工作。接下来的问题是：多个被 AI 放大的个体怎样形成团队。最后的问题是：多个团队之间怎样交换能力和价值。第一层主要面对执行效率。第二层主要面对协作成本。第三层则开始碰到组织的信任和价值分配。三层之间有顺序。没有真实工作流里的个人实践，团队层的协议很容易变成一套空洞的制度。没有稳定的团队协作、验证和经验沉淀，组织也很难建立真正可复用的能力体系。所以，它们不是三个可以一次性采购的功能。它们更像是 AI 能力逐层长出来以后，组织必须依次回答的三个问题。当我们开始讨论超级个体、超级团队和超级组织，事情很容易变得宏大。但企业的 AI 转型，可能不需要从一张未来组织架构图开始。更现实的起点，仍然是一条具体的工作流。这项工作的输入是什么？中间需要哪些判断？要调用哪些系统？哪些步骤高度重复？哪些异常必须由有经验的人识别？谁来验收结果？如果出错，谁负责停止和重启？最后，这次任务形成的经验会被写回哪里？管理层可以给出方向、资源和红线，明确数据、安全、权限与责任边界。具体场景则应该从真实工作中长出来。最熟悉一项工作的人，更容易看见哪些地方只是重复劳动，哪些地方看似简单，背后却隐藏着判断、信任和风险。工具进入真实流程，才可能出现被 AI 放大的个体。这些人开始共享状态，才可能形成新的团队协作方式。团队的能力能够被安全地调用、评价和复用，才有机会沉淀为组织能力。
瓶颈会继续移动06
以前讨论 AI，我也很容易先问：这个岗位能不能被替代？现在我觉得，这个问题有些太粗了。它把公司理解成一堆岗位，又把岗位理解成一堆可以拆走的任务。但一家公司真正运转的地方，往往不在岗位说明书里。它在上下游的接口里，在异常出现的瞬间，在一次没有写进流程的判断里，也在一个人愿不愿意为结果负责的那条边界上。AI 可以让执行变得更快，也可以让一个人拥有过去一个小团队的行动半径。但速度提高以后，瓶颈不会就此消失。它可能从产出移动到验证，从验证移动到协同，从协同移动到信任，再从信任移动到责任。所以，我现在更愿意把问题换成：这个流程里，真正的瓶颈在哪里？如果瓶颈是产出，就提高产出。如果瓶颈是信息，就重新组织上下文。如果瓶颈是协同，就减少解释和交接。如果瓶颈是判断，就先保护并放大那些判断。如果瓶颈是信任，就不要用速度冒充信任。如果瓶颈是责任，就不要把责任悄悄藏进自动化里。AI Native 组织未必是人最少的组织。它可能只是更清楚：什么应该交给机器，什么必须留给人，以及两者之间应该怎样连接。AI 让执行变便宜以后，我们真正需要重新学习的，也许不是如何少用几个人。而是如何把更多分散的判断、行动和责任，重新连接起来。

登录查看剩余 70% 内容