知识管理

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

2026 年 7 月 17 日

从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 开始成为工作的实际参与者，我们需要重新设计任务怎样发生、信息怎样流动、结果由谁验证、经验如何沉淀，以及责任最终由谁承担。

一个人先快起来

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 的价值，是把一部分原来不及格的环节补到了及格线。

它没有让每个人都成为全才。

但它让一个人的能力曲线不再那么容易断裂。

快起来以后

事情到了这里，看起来很顺利。

一个人可以完成更多任务，小团队可以做过去大团队才能做的项目，公司也可以用更少的资源获得更高的产出。

但这只是第一层。

WorkBuddy 分享里有一个很好的问题：

如果一家公司已经有了十个超级个体，它就自然成为超级团队了吗？

直觉上，我们容易回答“是”。

每个人都变快了，团队当然也应该变快。

但再想一步，就会发现事情可能恰好相反。

以前，一个人一天形成一个方案，团队还有时间开会、讨论和修正。

现在，几个人分别带着 Agent，一下午就可以形成十几个版本。每个版本都有自己的上下文、判断依据和实现路径。

产出增加了，需要被理解和比较的内容也增加了。

如果团队仍然依靠会议同步、手工汇总和层层拍板，个人节省下来的时间，很快又会被新的协调成本吃掉。

被 AI 放大的不仅是能力，也包括分歧。

每个人都可以迅速把自己的想法变成一个看起来已经成形的方案。原来还停留在讨论阶段的差异，现在都变成了需要评审、测试和维护的产物。

瓶颈从执行移动到了协作。

WorkBuddy 分享把这一层称为 L2，也就是团队协作协议。

它要解决的，不再是一个人怎样给 Agent 分配任务，而是多个人、多个 Agent 和多个任务线程怎样形成共享状态。

这里的“共享状态”和共享一份文档不太一样。

一份最终文档通常只能告诉后来者：最后写了什么。

但它很难完整保留：最初为什么提出这个目标，中间尝试过哪些方案，哪些路径被放弃，哪些结论已经验证，哪些冲突还没有解决，以及下一步可以从哪里继续。

而 Agent 要继续完成任务，恰恰需要这些信息。

如果一个人把任务交给另一个人，后者需要重新阅读、询问和理解。

一个 Agent 把任务交给另一个 Agent，也会遇到同样的问题。

缺少的不只是文件。

缺少的是一段可以继续运行的认知状态。

所以，L2 需要解决几类连接。

一个新的目标出现后，相关的人和 Agent 怎样知道这件事。

多个方案同时产生以后，怎样比较、合并，或者保留仍有价值的分歧。

一个任务中形成的有效经验，怎样被其他人继续使用。

一个失败方案留下的判断和数据，怎样避免在下一轮被重新踩一遍。

这些问题过去也存在。

AI 只是让它们出现得更快了。

我在做 AI 调试时，经常遇到一个很小的版本。

模型在某个场景里答错了。我们找到一个反例，补规则，改提示词，希望它下一次能够答对。

但真正麻烦的是，改完以后，过去那些已经答对的样本还能不能继续答对。

一个新规则可能修复一个问题，也可能破坏原来稳定的部分。

所以，成熟一点的调试不能只看眼前这个错误有没有消失。还要做回归测试，检查边界，确认系统整体是否真的变得更可靠。

企业引入 AI 也是一样。

替换一个任务，就像给系统增加一条新规则。

这个节点也许更快了，但上下游的节奏可能被改变，原来隐含的责任可能变得模糊，一些只有经验丰富的人才能识别的异常信号，也可能一起消失。

这不是因为 AI 不够强。

而是因为业务从来都不是单点运行的。

公司原本解决的是什么

说到这里，我想起了经济学家罗纳德·科斯。

科斯出生于英国，是 1991 年诺贝尔经济学奖得主。他最重要的贡献之一，是把“交易成本”带进了对企业和制度的分析。

1937 年，他在《企业的性质》中提出了一个后来影响很大的问题：

既然市场可以通过价格和交易组织分工，为什么世界上还需要公司？

比如，一家企业需要设计、生产、销售和财务服务，理论上都可以临时到市场上寻找最合适的人。

任务来了就合作，任务结束就解散，似乎比长期维持一个组织更灵活。

但真实世界不是这样运行的。

每一次临时合作，都需要寻找合适的人，比较不同方案，解释需求，谈判价格，签订合同，监督过程，并在出错后确认责任。

这些动作本身也消耗时间和资源。

科斯把这类成本称为交易成本。公司的意义之一，就是把那些需要反复发生的市场交易，变成相对稳定的内部协作，从而系统性降低交易成本。

当组织内部协调的总成本低于每次重新到市场上交易的成本，公司就有了存在的理由。这也是科斯获得 1991 年诺贝尔经济学奖时被特别强调的贡献之一。

这个解释帮助我重新理解企业。

一家公司并不只是一群人待在同一个组织里。

它也是一种降低协作成本的安排。

很多岗位之所以长期存在，不只是因为它们完成了一项显性的任务。它们还保存了上下文，建立了信任，缩短了沟通路径，也承担了持续协作中的责任。

那么，AI 对企业更深的价值，也许不只是让某个人更快完成某项任务。

它还应该继续降低那些原本就促使公司存在的成本。

降低信息寻找的成本。

降低需求反复解释的成本。

降低跨部门同步的成本。

降低返工和异常升级的成本。

也降低事情出了问题以后，重新确认责任的成本。

这些成本很少被完整地写在财务报表里，却每天都在消耗一家公司。

一个节点的产出提升，很容易被计算。

但一次沟通少解释了多少背景，一个异常是否更早被发现，一个失败方案能不能被下一个团队复用，这些变化要慢得多，也不那么容易被看见。

所以，AI 的 ROI 如果只用“替代了几个人”衡量，可能会错过更重要的部分。

真正需要观察的，也许是交付周期有没有缩短，返工有没有减少，质量有没有提高，经验有没有被复用，以及同样规模的团队能不能承接过去无法承接的复杂度。

人力、Agent 和 Token 都是成本。

但最终要看的，仍然是整条业务链有没有变得更好。

当能力开始跨团队流动

如果个人与 Agent 已经可以稳定协作，多个超级个体也开始形成共享状态，接下来才会出现第三层问题。

一家公司通常不只有一个团队。

产品、研发、销售、交付、财务、法务和供应链，各自积累着不同的经验和能力。

一个团队可能沉淀了一套需求分析方法。

另一个团队可能拥有熟悉特定行业的专家。

还有一个团队可能建立了一套可靠的测试和合规检查流程。

今天，这些能力通常存在于文档、代码仓库和少数员工的经验里。

知道它们的人可以使用。

不知道它们的人，往往只能从头再做一次。

WorkBuddy 分享把不同团队之间的这层协作称为 L3，也就是组织层面的协议。

它关心的是：一种能力能不能被组织里的其他团队发现、获得授权、实际调用，并在使用之后得到评价。

比如，一套被验证过的需求分析方法，可以被封装成 Skill。

一位资深员工的部分经验，可以形成专家 Agent。

一套项目复盘，不再只是放进知识库，而是直接更新团队下一次任务会调用的检查规则。

到了这一层，知识不再只是供人阅读的静态内容。

它开始成为可以运行的组织能力。

这幅图景很吸引人。

但问题也会随之出现。

调用次数多的能力，是否一定更有价值？

那些长期重要、短期低频的能力，会不会被低估？

一个由员工经验训练出来的专家 Agent，究竟属于谁？

当它被跨部门调用，贡献、收益和责任又应该怎样分配？

所以，能力可以像市场一样流动，却不能只有市场。

它还需要治理。

这也是企业知识沉淀里最容易被忽略的一部分。

技术上，我们已经可以把一个人的文档、代码、方法和工作记录整理成知识库、Skill 或专家 Agent。

但能够沉淀，不等于愿意沉淀。

很多人的经验，本来就是他的职业价值。

假如组织只是要求员工把经验交出来，却没有解释贡献如何被记录、能力怎样归属、调用产生的价值怎样反馈，知识管理就很容易被理解成一种单向索取。

WorkBuddy 负责人在交流中给出的边界很克制：产品可以支持一个人分享专家能力和工作结果，但不能强迫他分享。

技术可以负责封装知识。

让知识真正流动起来，依靠的却是信任。

从一条工作流开始

回头看，L1、L2 和 L3 并不是三个需要记住的专业概念。

它们只是帮助我们看见，AI 进入企业以后，问题会怎样逐层变化。

最初的问题是：一个人怎样带着 Agent 完成工作。

接下来的问题是：多个被 AI 放大的个体怎样形成团队。

最后的问题是：多个团队之间怎样交换能力和价值。

第一层主要面对执行效率。

第二层主要面对协作成本。

第三层则开始碰到组织的信任和价值分配。

三层之间有顺序。

没有真实工作流里的个人实践，团队层的协议很容易变成一套空洞的制度。

没有稳定的团队协作、验证和经验沉淀，组织也很难建立真正可复用的能力体系。

所以，它们不是三个可以一次性采购的功能。

它们更像是 AI 能力逐层长出来以后，组织必须依次回答的三个问题。

当我们开始讨论超级个体、超级团队和超级组织，事情很容易变得宏大。

但企业的 AI 转型，可能不需要从一张未来组织架构图开始。

更现实的起点，仍然是一条具体的工作流。

这项工作的输入是什么？

中间需要哪些判断？

要调用哪些系统？

哪些步骤高度重复？

哪些异常必须由有经验的人识别？

谁来验收结果？

如果出错，谁负责停止和重启？

最后，这次任务形成的经验会被写回哪里？

管理层可以给出方向、资源和红线，明确数据、安全、权限与责任边界。

具体场景则应该从真实工作中长出来。

最熟悉一项工作的人，更容易看见哪些地方只是重复劳动，哪些地方看似简单，背后却隐藏着判断、信任和风险。

工具进入真实流程，才可能出现被 AI 放大的个体。

这些人开始共享状态，才可能形成新的团队协作方式。

团队的能力能够被安全地调用、评价和复用，才有机会沉淀为组织能力。

瓶颈会继续移动

以前讨论 AI，我也很容易先问：

这个岗位能不能被替代？

现在我觉得，这个问题有些太粗了。

它把公司理解成一堆岗位，又把岗位理解成一堆可以拆走的任务。

但一家公司真正运转的地方，往往不在岗位说明书里。

它在上下游的接口里，在异常出现的瞬间，在一次没有写进流程的判断里，也在一个人愿不愿意为结果负责的那条边界上。

AI 可以让执行变得更快，也可以让一个人拥有过去一个小团队的行动半径。

但速度提高以后，瓶颈不会就此消失。

它可能从产出移动到验证，从验证移动到协同，从协同移动到信任，再从信任移动到责任。

所以，我现在更愿意把问题换成：

这个流程里，真正的瓶颈在哪里？

如果瓶颈是产出，就提高产出。

如果瓶颈是信息，就重新组织上下文。

如果瓶颈是协同，就减少解释和交接。

如果瓶颈是判断，就先保护并放大那些判断。

如果瓶颈是信任，就不要用速度冒充信任。

如果瓶颈是责任，就不要把责任悄悄藏进自动化里。

AI Native 组织未必是人最少的组织。它可能只是更清楚：什么应该交给机器，什么必须留给人，以及两者之间应该怎样连接。

AI 让执行变便宜以后，我们真正需要重新学习的，也许不是如何少用几个人。

而是如何把更多分散的判断、行动和责任，重新连接起来。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

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

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单