AI时代的组织应该是 GitHub 模式

前两天我看到红杉的一段视频，讲“AI 时代要把公司变成 GitHub 模式”。

视频里核心的判断是：AI 时代的公司/组织，不应该是飞书式的协作，更应该是 GitHub 式协作。

其实这个判断和我目前的使用AI去做事情的体感是非常趋同的。

飞书模式是什么？

飞书是什么？是一个为团队协作设计的平台。它把即时消息、群组、云文档、多维表格、日历、会议、任务和知识管理等工具放在一起，让一个团队/一个组织可以围绕同一件事沟通、写下信息、分配事项、同步进度。飞书官方对核心模块的说明也很清楚：它解决的核心，是让组织里的信息和协作能够连起来。

所以，“飞书式组织”背后代表的是组织的基本工作单位仍然是“人和人协作”。一个项目被拆给不同角色；每个人通过聊天、会议、文档和表格存储和传递上下文；管理者靠OKR同步信息、对齐目标、明确分工、推动交接，让大家朝同一个方向走。里面所有的工具都是传统人类协作模式下的效率层面的究极形态。这种产品和模式在高度依赖人、需要人频繁互相配合的工作中非常有效。

如果把飞书式组织想成一个场景，它像一座协同办公楼。聊天是走廊，群组是项目房间，文档和表格是共享白板与档案柜，日历和会议是会议室预约系统。一个项目要往前走，人就要不断走进不同房间：问清背景、补齐材料、同步进度、确认下一步，再把接力棒交给下一个角色。这座办公楼的强项，是让很多人对同一件事保持连接：谁在做、做到哪里、还缺谁、接下来找谁，都可以被组织起来。

Github模式是什么？

GitHub 是什么？

先分清 Git 和 GitHub。Git 是程序员的版本管理工具，像代码的“修改记录本”：它记录改了什么，也能比较新旧版本或回到之前的版本。GitHub 则是代码托管与协作平台：它把用 Git 管理的代码仓库（repository）放到线上，让多人围绕同一组代码协作。Git 管“代码怎样变了”；GitHub 管“很多人怎样一起改同一套代码”。

大白话讲，可以把 GitHub 想成一棵不断长大的树。树干是团队约定要共同维护的基础；谁想试一个新功能或新做法，就先从旁边长出一根只承载这次改变的树枝，也就是 branch（分支），不直接动树干。branch 不是一个人或一个部门，而是一段有明确目标、范围和生命周期的变更空间。

树枝长出成果后，相关的人一起看：它改了什么、为什么要改、会不会影响别的地方。这就是合并请求（Pull Request）和审阅（review）的意义。经过负责人（owner）批准、必要的权限控制（access control）和自动检查（automated checks）后，改动才会 merge（合并）进主线；如果后来发现不合适，也可以回退或继续修正。GitHub 不是保证永远不犯错，而是让错误不会悄悄混进共同主线，并且能被追溯和处理。

为什么 AI 时代更适合 GitHub 模式？

过去很多复杂工作必须在多人之间不断交接：研究交给策略、策略交给内容、内容交给执行。飞书式协作擅长让每一棒交得清楚。

AI 让一个“人 + AI Agent”的工作单元能更快地完成更多事情，局部的尝试也因此变得更多、变得更快，减少大量过程必须由其他人来完成的必要性，当你把某个领域的需求传递给这个领域的专家并等他回复和交接给你结果的时间，可能都够你和AI尝试着去把这个事情做出来甚至优化一下了。

所以，协作的重点完全变了。组织新的难题是：这些快速生产的局部尝试里，哪些只是一次性的结果，哪些值得成为团队共同维护、反复复用的能力，甚至能成为整个组织的资产？

GitHub 模式管理的，正是这件事。一个人先在自己的 branch（分支）里把想法做出来，不直接动共同的树干；有了成果，再通过 Pull Request（合并请求）把“改了什么、为什么改、证据是什么”交给相关的人审阅。确认无误才 merge（合并）进主线，发现问题也能回退。它不要求把每一段 AI 对话都公开，而是要求每一次准备进入共同系统的改变，都说得清、查得到、有人负责。

所以，飞书和 GitHub 的区别，不在于一个旧、一个新。飞书像一座协同办公楼，解决的是楼里的人怎样找到彼此、同步彼此；GitHub 像一棵被一群人共同维护的树，解决的是新的枝条怎样安全地长出来、哪些可以接到树干上。AI 让局部长枝条的人的效率大幅提高，如果这些人构成一个组织，自然需要一套管理“长枝—审阅—入主干”的方式。其实就是软件工程的协作方式。

AI Native 的人，走到下一步就是 AI Native 的组织

我之前出过一个内容，叫《到底什么是 AI Native 的人》。里面我用 Native Speaker 来比喻 AI Native 的人：AI 对他不再是偶尔打开的外部工具，而是已经进入思考和工作的“母语”习惯。

这样的人遇到问题，第一反应会是“AI 能怎样帮我把它做出来”；他也更能把问题、上下文、约束和验收标准直接交给 AI。他知道 AI 能做什么、不能做什么，知道什么时候该继续让 AI 执行，什么时候必须自己判断和验证。

但一个人形成了方法，不等于组织已经拥有了能力。如果一条有效的工作轨迹只存在于某位同事的电脑和脑海中，它仍然只是个人能力，并没有形成组织合力。AI Native 的组织，要关注和解决的正是这一步跃迁：它不收集所有人和 AI 的完整协作过程，而是把其中经过验证、值得复用的部分，变成共同维护的能力。

我认为，一个 AI Native 组织最终会长出自己的共同 AI 基底。它不只是一个让所有人来提需求的 AI 中台，更像组织可共同调用、共同维护的能力网络：哪些上下文和规则是真源，哪些 Agent、Skill 和 Workflow 已被验证，谁可以修改，怎样检查，出了问题怎样回退。

AI 基底怎样诞生？

如果把 AI Native 的组织想成一棵树，AI 基底不是买一棵树根树干过来就能解决的，因为没有养树的能力和环境必然也会给这棵树养死，这也是为什么我认为大部分企业AI转型必然失败。

真正的AI基地需要在合适的环境中重新长起来并被组织维护成一个参天大树。

第一，它需要一颗种子：创始人的愿景和发心。组织究竟想为谁创造什么价值？相信什么？又有哪些事情即使更有效率，也不愿意做？这些决定了树为什么要长，也给之后每一次树枝的尝试和合并提供了最根本的判断标准。

第二，它需要合适的土壤和环境：真实的用户、业务、团队和市场，也包括组织内部的信任。这里的信任，不是让 AI 获得所有数据，而是成员愿意把有效经验拿出来接受检查、修正和给其他人复用，组织也承诺这些成果有边界、有权限、有责任、有结果，不会因为共享就失去控制。这种信任绝对不是恐惧驱动的，也不是金钱能买来的，更多是基于第一点的愿景和文化驱动的。

第三，它需要根系。树的根系负责把养分送到树干和枝条；放到组织里，它就是一套人人都能接上的基础设施。不是再建一个大平台，而是让每个准备被复用的 Agent、Skill 或 Workflow，都能说清楚：它解决什么问题、要输入什么、会产出什么、怎样算通过、谁能使用、哪些数据不能使用。这样别人不必反复问原作者，也能理解、调用和维护它。没有这些，一次有效的尝试仍然只属于做出它的人，进不了组织的共同 AI 基底。

第四，它需要持续养护：明确的 owner、审阅机制和回退权。谁负责维护这项能力，谁可以修改，什么证据足以进入共享层，失效后怎样修正或退役，都要有人承担。GitHub 模式在这里发挥作用：让新的枝条先在局部生长，经过审阅后再接回树干，发现问题也能及时剪掉。

所以，AI Native的组织里的每一次来自树枝的合并，不只要问“它能不能跑”，还要问“它是否让这棵树长得更健康，是否仍然朝整个组织的人认定的方向去生长”。

这也是我理解的 AI Native 组织：人和 AI 可以不断长出新的枝条，但组织始终知道自己的种子是什么、树干在哪里，以及什么值得被接回共同的主线。