关于AI-Native组织的思考

本文来自微信公众号：闲庭落木，作者：闲庭落木，头图来自：AI生成

折腾组织 AI 提效这事儿有段时间了，没有取得什么像样的成就。不过期间想法有过多次大幅转向，想想也是时候写篇文章记录下，以便将未来的思路理得更清楚。

风起

2024 年时，我对 LLM 已经有较深的认识了（也是为什么 2023 年底我决定离开抖音，前往更 AI 的业务）。彼时，我对于 AI 是否可能颠覆软件工程这个行业，尚有疑问。那会儿我开始深度使用 Copilot 和 Cursor，已经大幅提升我自己的效率了。但要知道提效 30% 与提效几倍、甚至几十上百倍不是一个概念。而且编码其实只是一个很小的环节，真实世界比编码复杂太多了。

不过整个 2024 年我的思考重心一直都不在 AI 提效上，而是思考 AI 到底能支撑什么样的商业模式？我当时一个结论是：AI 的价值不在提效，因为 AI 的边际成本不递减，提效带来的收益不递增，结合在一起不是门好生意。AI 真正的价值应该在于变不可能为可能，只有让我做到我之前做不到的事情，我才可能付费。

心动

2025 年是我开始真正关注组织 AI 提效的起点，因为 Claude Code。我当时发现 Claude Code 确实能做到很多我之前做不到的事情了，并且，Claude Code 我可以非常容易得用在非编码的工作中。尽管那会儿我对于 Agent 这个概念还相当不屑（主要是使用 Manus 后感觉能解决的问题太窄了），我仍然觉得需要结合 Claude Code 做点什么不一样的事儿。

2025年下半年，结合 2024 年的思考、2025年的实践以及团队内同学的探索。我有了一个激进的思路：组织 AI 提效不在于给员工提供 AI 工具提升已有工作的效率，而在于重新划分工作：识别出现在工作中适合 AI 完全能搞定（至少能搞定 90%+）的子工作项，构建 Agent 来全自动化搞定。然后随着模型迭代以及基建优化，不断扩大 AI 能完全搞定的工作项的范围。

从那会儿起，我一直在沿着这条思路探索和实践。期间我不禁会想：那终局会是什么呢？未来的公司还需要人类吗？需要什么样的人类呢？需要人类做什么事儿呢？我生平第一次，对软件工程这个行业的未来感到了担忧。不久后，我就不再担忧，因为对必然发生的事情没有理由担忧。

探索

也是在那时，我第一次听到 AI-Native 组织这个词。硅谷这边对 AI-Native 组织讨论得非常多。一方面是这边的人想法确实多，另一方面，这边的半吊子小型创业团队太多了，业务虽然没有啥正经的，但是 AI-Native 组织能跟你扯半个小时。期间有两篇文章引发了我的深度思考。

一篇是 Notion CEO Ivan Zhao 的Steam， Steel， and Infinite Minds，另一篇是 Block CEO Jack Dorsey 的那篇From Hierarchy to Intelligence。两篇文章核心都是在讨论 AI-Native 组织。前者主要在于回顾历史，推导出只有构建 AI-Native 的组织才能完全释放 AI 的生产力。后者则是直接提出 Jack 认为 AI-Native 组织的构建思路。我们就来详细讨论下 Jack 的思路，因为我一度也非常笃定这个思路。

这条思路是 AI 中心主义的，核心在于 Build a company as an Intelligence （将公司本身打造成一个智能体）。其中关键点在于：

• 公司所有的行为，都要有产物 （决策、讨论、设计、代码、计划、问题、进展等等）。不能有任何东西仅存在员工脑子里，或者两个员工私下的交谈里。必须沉淀为数字化产物。

• 必须将客户/用户的信号构建的足够强（使用、付费、问题、离开等等）。这一步听起来反而好做，但关键在于需要将客户/用户的反馈建设得足够强且快。当公司智能体做了某个重要的动作时，最好能立刻看到市场反馈。

• 人类将成为公司智能体的边缘节点，边缘节点即行动节点。本质上人类是公司智能体的一个可调用工具，与软件工具没啥区别。关键的作用就是与现实世界交互。

• 当公司智能体提出一个方法时，如果该方法不能实施，则这个失败信号就是公司未来的工作计划（补齐必要基建、工具或人类员工，以便公司智能体能落地它的方法）。

众所周知，LLM 想要高效工作，需要这三个东西：上下文、验证能力、工具。关键点 1 保障了上下文，关键点 2、3 保障验证能力和与现实交互的工具。“根据全面的上下文做决策、采取行动并且验证的反馈迭代决策”这件事儿，理论上确实 AI 能做得比人更好。

这个 AI 中心主义的思路核心点在于：“AI 驱动人”。或者说是“AI 驱动事”儿，因为“人”在这里与普通 AI 能调用的其他工具没有本质区别，仅仅是 AI 驱动事儿中的一个与现实世界交互的工具而已。

我确实一度十分认可这个思路，因为这本质上就是我一直在尝试的路。只是我的尝试是渐进的，让 Agent 逐步 Cover 原来越多的工作项。在 Agent 已 Cover 的工作项中，就是 AI 驱动事儿，人类只是辅助和支撑。

Jack 则认为应该以终为始，一开始就应该这么构建组织。毫无疑问，他是 CEO，他可以这么做。这么做也确实更容易扫清相应的障碍，最快的暴露出失败信号，然后可以集中精力去搞定这些失败信号。而我的尝试则会遇到很多不张扬的阻力，将失败信号隐蔽起来，难以真正优化问题。

近期我在与一些尝试过程中发现的关键 case 又做了更深入的分析，使得我不得不重新思考人类的价值了。

深思

这些异常 case 的本质都是类似的，AI 能把结果完成，但是结果并不是我想要的。例如代码，功能都实现了，但是架构的抽象并不是我想要的。为什么架构 AI 做不到我想要的呢？因为我脑子里面隐隐约约有幅关于未来的画面，没有用语言描述过。

我慢慢地发现了越来越多类似的 case，就像那句老话说的“情不知所起，一往而深”。“情”并非莫名其妙的起了，而是语言没有很好地描述，日常点点滴滴汇聚到潜意识里了。很多好的“idea ”都是这样，电光火石间突然就出现了。产生好的“idea”的能力，我确信 AI 是不具备的，因为语言无法描述。当然，“idea”出来后，事后我们可以用语言去总结，但事前它出现的时候，往往不来自语言。

这类需要“idea”的问题，我称之为“开放问题”。与之对应的是“封闭问题”，例如线上出现了一个 bug，这个 bug 就是“封闭问题”，解决问题本身就是全部。而且对于“开放问题”来说，提出正确的问题才是最重要的。

例如：我想利用 AI 给组织提效 N 倍？这就是一个典型的“开放问题”，你没有办法直接回答问题。当然很多拙劣的管理者可以立刻马上做一二三四五件相关的事儿，这种解法与 AI 的解法还真就没有区别了，并不真正解决问题。我认为对于这种“开放问题”就需要好的“idea”。这并不容易。当然我相信，若干年后，当这个问题被彻底解决了，人类能很容易用语言把这个“idea”描述清楚，那会儿的 AI 应该可以很轻易的解决这个问题。

总的来说，我认为针对“封闭问题”，可以由“AI 驱动事”，人仅作为 AI 与现实交互的工具，即智能体的边缘节点。但对于“开放问题”来说，必须由“人驱动事”，AI 反过来作为人的工具。“人驱动事”和“AI驱动事”毫无疑问有本质的区别，在“人驱动事”的场景下，AI 如何最大程度发挥作用？AI-Native 的组织又应该长成什么样呢？

思路

在我看来，不同的组织中“开放问题”与“封闭问题”占比是不相同的。偏创意的业务会有更多“开放问题”，偏生产的业务会有更多“封闭问题”。所以 AI-Native 组织也应有不同的样子，而且肯定不是所谓的“一人公司（OPC/OPT）”的样子。

理想来说，部分员工负责“开放问题”，在解决开放问题时所产生的封闭子问题，均由 AI 完成，使其能一直保持心流（flow）。这时必须给这部分员工提供理想的“AI 控制台”，用于最大化的让其指挥 AI 解决封闭问题。

保持员工本身的 flow 不被打断、分心，专注思考和探索。而另一部分员工（与第一部分员工物理上可以重合）则作为 AI 解决“封闭问题”的边缘节点，在“Agent 平台”的指挥下工作，辅助 AI 完成各类需要与现实世界交互的封闭问题。

• 针对“开放问题”的“AI 控制台”：核心是保护探索者的心流（Flow）。在这个控制台中，AI 的角色是超级副驾。人是发号施令的中枢，AI 负责快速提供选项、验证假设、扫清认知障碍。这使得工程师或管理者可以一直停留在“idea”的高维空间里，而不必被迫降维去处理琐碎的实现细节。

• 针对“封闭问题”的“Agent 平台”：核心是“工业化”。当开放问题被人类拆解成一个个边界清晰的子任务（例如某个明确的 DevOps 流程、特定模块的自动化验证）后，直接抛给 Agent 平台。在这里，AI 变成了调度中心（AI 驱动事），它负责执行、调用工具，并在遇到无法逾越的物理或权限障碍时，将人类作为“边缘节点”呼叫进来进行授权或现实交互。

这就是我的新思路，相对之前激进的想法，倒显得平平无奇了。我现在在探索的就是这套“AI 控制台”应该怎么做，怎么让使用者能专注探索，保持 flow 不断？如何能将其中产生的“封闭问题”很好的交给我之前做的“Agent 平台”来承接？之前做的“Agent 平台”又如何能泛化适应各类的“封闭问题”，如何使其最高效与边缘节点（人类）协作？未解的问题还太多。

其实写到这里，我心里还是蛮高兴的。起码在我自己经过实践的推演终局中，人类并没有消失，或者沦为一个纯粹的工具。人类毕竟不是神，人类也许终究无法做出超越自己的东西吧。

本文来自微信公众号：闲庭落木，作者：闲庭落木