MooxAI：十来人如何跑出 AI 原生组织

十来个人的团队，只有技术 Team 和 售前/CSM Team两个大块，中间没有任何中层管理者。

图由 AI 生成

文 | Alex

“两天发一版。”

Elric Liu 提到这里时，只是顺口带过。

前一天，我们刚采访完另一家 AI 公司。对方觉得“两周一个大版本”已经是很快的节奏。

到了 MooxAI，这个周期直接被压缩到 2 天。

Elric Liu 是 MooxAI 负责人。

MooxAI 成立于 2023 年，是一家从大模型浪潮里长出来的 AI 公司，主要服务 To B 场景，业务包括大型企业 AI 落地实施，以及标准化 AI 软件产品。团队现在十来个人，已经实现盈亏平衡。

Moox AI 的创始团队带有明显的 ToB 背景。Elric此前在飞书工作，长期关注企业客户和AI落地。

聊到组织方式时，他多次提到信息透明、协作效率、项目闭环和工具驱动。飞书经历显然影响了他对这件事的判断。

这家公司现在做两类业务。

一类是标准化 AI 软件，围绕内容创作、带教陪练等场景做产品；另一类是面向大型企业的 AI 落地实施，偏定制交付，通过大客户项目和长期客户关系获得收入。

也就是说，MooxAI 并非单纯做一个 AI 工具，它在企业内部真实业务里，把 AI 接进流程、系统和项目交付。

这类业务不能只靠 Demo 讲故事。

大型企业的需求通常更复杂，涉及业务流程、内部系统、权限结构和使用习惯。AI 可以提升开发和交付效率，但项目能不能落地，最终还要看它能否跑通真实流程，解决真实问题。

在 1 个小时的访谈里，Elric 拆解了 Moox AI 这支小团队的运转方式。

它还不是一个定型的“AI 原生组织”，团队小，层级少，AI 已经进入研发、项目管理、售前和交付环节，但关键判断仍然留给人。

01

售前也开始写Demo

MooxAI 有部门划分，但不像传统公司那样严格。

按照 Elric 的说法，公司大体分为技术 Team 和售前/CSM Team。

技术侧负责产品和工程实现，售前与客户成功侧负责客户沟通、需求承接和交付推进。

再往下，就不再细分出很多传统部门。

日常项目很像“虚拟小组”。

来了一个客户项目，就临时抽几个人组成小组。谁更适合主导，谁就往前站。

同一个人在 A 项目里可能偏售前，在 B 项目里可能偏客户成功，在另一个项目里又参与产品判断。

Elric 认为，AI 原生组织里，人的能力边界正在变得模糊。

过去软件公司讲全栈工程师，更多是指一个工程师既能写前端，也能写后端。

到了 MooxAI，这个概念被放到了组织层面。一个人不一定什么都精通，但不能只守着单一职责。

他们把岗位大致分成三类。

• 第一类是“技术+产品”。技术工程师不只写代码，也要理解产品的基础逻辑。很多过去由产品经理拆解的事情，现在技术同学可以直接完成一部分。

• 第二类是“产品+运营”。产品人员不仅要设计产品结构，也要理解运营场景，知道产品最后怎么被客户真正用起来。

• 第三类是“售前+CSM”。售前和客户成功不再完全隔开。一个人既可能参与前期需求沟通，也可能跟进后续交付和客户反馈。

这套结构的变化，在售前环节体现最为明显。

MooxAI 现在会让售前自己用 Vibe Coding 的方式给客户搭 Demo。

过去客户提出一个想法，销售先理解，再转述给产品，产品再跟技术沟通。

每传一层，信息都会损失一部分。等到 Demo 出来，客户看到的东西往往已经和原始需求有了偏差。

现在，售前可以直接把客户的想法做成一个可看的原型。它不一定是最终产品，但客户能直接感知效果，沟通成本被大幅压缩。

Elric 说，以前销售只能给客户截图，或者用语言描述。现在有了实体 Demo，用户体感完全不一样。

02

没有中层之后

Moox AI 几乎不设中层。

Elric 和另一位负责人直接看整体方向。

产品和技术路线主要由Elric与CTO判断，另一位负责人更多负责运营和对客重大问题会拿出来讨论，但大多数决策链条都被压得很短，因为 AI 让试错成本变低了。

过去讨论一个产品想法，往往要先评估需求、排期、设计、开发资源和机会成本。现在，很多想法可以先用 AI 搭一个 MVP。花一两天，甚至半天，把东西做出来，比反复讨论可行性更有效。

Elric 说，除非问题很复杂，否则他们更倾向于先做出来，再看效果。

这也改变了组织管理方式。

MooxAI 每周会做一次同步，主要是减少信息差。团队里所有文档尽量全员开放，项目会议也会让相关成员参与。

Elric 认为，信息同步不是为了“看起来透明”，是为了让每个人更快进入上下文。

但这种方式有前提。

Elric 也承认，层级少不等于效率一定高。团队成员如果缺少主动性，没有中层盯过程，问题反而可能被拖到最后才暴露。

小团队能不能扁平运转，不只看组织图有多简单，更要看每个人能不能主动同步信息、推进任务，并对结果负责。

所以，MooxAI 招人时看重两类人：一类是熟手，可以直接补上业务短板；另一类是高潜，未必眼下什么都会，但足够聪明，有动力，也愿意折腾。

Elric 认为，AI 让很多具体技能的习得速度变快了。

一个人现在会什么没那么重要，更重要的是他能不能持续学习，并主动用 AI 把事情做出来。

面试时，他们会重点看候选人怎么使用 AI，看他最近用了哪些 AI 工具，怎么用，有没有自己做过东西。只听过、浅尝过，和真正拿 AI 做过小项目的人，差别很明显。

03

Token 剩80%

问题出在人身上

MooxAI 的研发里，AI Coding 占比已经超过 90%。Elric 说，几乎没有人实际去写代码了。

他们会使用 Claude Code、Codex 这类 AI Coding 工具，也会结合智谱等大模型能力完成开发。

需求来源主要有两类，一类是团队自己发现的通用需求，另一类是客户提出的定制化需求。

定制项目做多后，如果发现某些需求具备通用性，就会抽象成标准产品或模块。

这种方式让产品迭代节奏变得很快。MooxAI 现在基本两天发一版。

研发成本下降之后，组织内部形成了一种新的工作习惯。

过去，一个想法可能要开会讨论很久； 现在，如果半天就能做出原型，就先做出来再说。

讨论不再是唯一的前置环节，Demo 本身变成了讨论材料。

但 AI 写代码并不等于质量问题消失，MooxAI 把代码质量控制分成几个阶段：

• 早期 MVP 阶段，重点不是追求并发、稳定性和完整工程规范，而是先确保基础架构没有硬伤，核心功能能跑起来。这个阶段 CTO 会看整体结构是否合理，产品侧则判断功能是否符合设想。

• 到了产品成熟期，团队会把模块边界拆清楚，把模块说明、注意事项和上下文写进项目文档，让 AI 后续生成代码时可以遵循这些约束。

• 代码提交时，还会有两层审核。AI 先做预审，看新代码和原有逻辑有没有冲突，是否存在明显问题；之后 CTO 再快速 review，重点看有没有遗漏和架构风险。

Elric 认为，AI 可以写代码，但不能无限制地改全局。越到后期，越要把 AI 的改动限制在具体模块里。这样即使某个模块出现问题，也不至于影响整个系统。

这和很多 AI 原生组织的经验相似。AI 把功能开发变轻了，但架构、边界和质量控制反而更重要。

传统企业想做 AI 化转型，应该从哪里开始？

Elric 看来，AI 转型最难的是两件事：第一是内部利益冲突，第二是执行者本身有没有意识到 AI 能带来什么。

MooxAI 自己也踩过类似的坑。

早期他们给团队配了 Coding Plan 和各类 AI 工具，结果一两个月后发现，有些人的 Token 还剩下 80%。

工具给了，不代表大家真的会用。

后来他们开始通过内部奖励机制，鼓励员工用 AI 做业务小闭环，并在周会上分享这些实践，团队的使用习惯才逐渐改变。

栏目介绍

本文是「AI原生组织研究」系列访谈的一篇。我们正在系统观察 AI 原生企业的组织实践，关注 AI 如何进入研发、产品、销售、交付和管理流程，以及它如何改变岗位边界、协作方式和人才标准。后续将形成《AI 原生组织白皮书（2026）》，请持续关注。

如果你的公司属于 AI 原生组织，欢迎在评论区聊聊。我们也会持续寻找更多真实样本。