“两天发一版。”

这句话从Elric Liu嘴里说出来时，语气平淡得像是聊“今天天气不错”。前一天刚采访完另一家AI公司，对方觉得“两周一个大版本”已经算很快了。到了MooxAI，这个周期直接压缩到2天。

Elric Liu是MooxAI的负责人。这家公司2023年成立，从大模型浪潮中成长起来，主营业务是To B——帮助大型企业落地AI，同时提供标准化AI软件产品。团队只有十来个人，却已经实现了盈亏平衡。

创始团队具备明显的To B基因。Elric之前在飞书，长期与企业客户和AI落地打交道。谈到组织方式时，他反复提到四个关键词：信息透明、协作效率、项目闭环、工具驱动。飞书的经历显然深刻影响了他对高效团队运作的判断。

MooxAI目前有两类业务。一类是标准化AI软件，围绕内容创作、带教陪练等场景打造产品；另一类是面向大型企业的AI落地实施，偏定制交付，依赖大客户项目和长期关系盈利。换句话说，它并非单纯做一个AI工具，而是把AI嵌入企业的真实流程、系统和项目交付中。这类业务不能只靠Demo讲故事。大企业的需求往往更复杂——涉及业务流程、内部系统、权限结构和使用习惯。AI虽然能提升开发和交付效率，但项目能否真正落地，最终还是要看它能否跑通真实流程，解决真实痛点。

在一个小时的访谈里，Elric拆解了这支小团队的运转方式。它还不是一个定型的“AI原生组织”，团队小，层级少，AI已经渗透到研发、项目管理、售前和交付环节，但关键决策仍然留给人来做。

01 售前也开始写Demo

MooxAI有部门划分，但不像传统公司那么严格。大体上分为技术Team和售前/CSM Team。技术侧负责产品和工程实现，售前与客户成功侧负责客户沟通、需求承接和交付推进。再往下就不再细分了。

日常项目更像“虚拟小组”。来了一个客户项目，临时抽几个人组成小组，谁更适合主导，谁就往前站。同一个人在A项目里可能偏售前，在B项目里可能偏客户成功，在另一个项目里又参与产品判断。

Elric认为，在AI原生组织中，人的能力边界正在变得模糊。过去软件公司讲全栈工程师，更多是指一个人能写前端也能写后端。到了MooxAI，这个概念被放到了组织层面——一个人不一定什么都精通，但不能只守着单一职责。

他们把岗位大致分成三类。第一类是“技术+产品”：技术工程师不只写代码，也要理解产品的基础逻辑，很多过去由产品经理拆解的事情，现在技术同学可以直接搞定一部分。第二类是“产品+运营”：产品人员不仅要设计产品结构，还要懂运营场景，知道产品最后怎么被客户真正用起来。第三类是“售前+CSM”：售前和客户成功不再完全隔开，一个人既可能参与前期需求沟通，也可能跟进后续交付和客户反馈。

这套结构的变化，在售前环节体现得最明显。MooxAI现在会让售前自己用Vibe Coding的方式给客户搭Demo。过去客户提出一个想法，销售先理解，再转述给产品，产品再跟技术沟通。每传一层，信息都会损失一部分。等到Demo出来，客户看到的东西往往已经和原始需求有了偏差。现在，售前可以直接把客户的想法做成一个可看的原型。它不一定是最终产品，但客户能直接感知效果，沟通成本被大幅压缩。Elric说，以前销售只能给客户截图，或者用语言描述。现在有了实体Demo，用户体感完全不一样。

02 没有中层之后

MooxAI几乎不设中层。Elric和另一位负责人直接掌控整体方向。产品和技术路线主要由Elric与CTO判断，另一位负责人更多负责运营和对客重大问题。大部分决策链条都被压得很短，因为AI让试错成本变低了。

过去讨论一个产品想法，往往要先评估需求、排期、设计、开发资源和机会成本。现在，很多想法可以先用AI搭一个MVP。花一两天，甚至半天，把东西做出来，比反复讨论可行性更有效。Elric说，除非问题很复杂，否则他们更倾向于先做出来，再看效果。

这也改变了组织管理方式。MooxAI每周会做一次同步，主要是减少信息差。团队里所有文档尽量全员开放，项目会议也会让相关成员参与。Elric认为，信息同步不是为了“看起来透明”，而是为了让人更快进入上下文。

但这种方式有前提。Elric也承认，层级少不等于效率一定高。团队成员如果缺少主动性，没有中层盯过程，问题反而可能被拖到最后才暴露。小团队能不能扁平运转，不只看组织图有多简单，更要看每个人能不能主动同步信息、推进任务，并对结果负责。

所以，MooxAI招人时看重两类人：一类是熟手，可以直接补上业务短板；另一类是高潜，未必眼下什么都会，但足够聪明有动力，也愿意折腾。Elric认为，AI让很多具体技能的习得速度变快了。一个人现在会什么没那么重要，更重要的是他能不能持续学习，并主动用AI把事情做出来。面试时，他们会重点看候选人怎么使用AI——看他最近用了哪些工具，怎么用，有没有自己做过东西。只听过、浅尝过，和真正拿AI做过小项目的人，差别很明显。

03 Token 剩80%，问题出在人身上

MooxAI的研发里，AI Coding占比已经超过90%。Elric说，几乎没有人实际去写代码了。他们会用Claude Code、Codex这类AI Coding工具，也会结合智谱等大模型能力完成开发。需求来源主要有两类：一类是团队自己发现的通用需求，另一类是客户提出的定制化需求。定制项目做多后，如果发现某些需求具备通用性，就会抽象成标准产品或模块。

这种方式让产品迭代节奏变得很快，现在基本两天发一版。研发成本下降之后，组织内部形成了一种新的工作习惯：过去，一个想法可能要开会讨论很久；现在，如果半天就能做出原型，就先做出来再说。讨论不再是唯一的前置环节，Demo本身变成了讨论材料。

但AI写代码并不等于质量问题消失。MooxAI把代码质量控制分成几个阶段。早期MVP阶段，重点不是追求并发、稳定性和完整工程规范，而是先确保基础架构没有硬伤，核心功能能跑起来。这个阶段CTO会看整体结构是否合理，产品侧则判断功能是否符合设想。到了产品成熟期，团队会把模块边界拆清楚，把模块说明、注意事项和上下文写进项目文档，让AI后续生成代码时可以遵循这些约束。代码提交时，还有两层审核：AI先做预审，看新代码和原有逻辑有没有冲突；之后CTO再快速review，重点看有没有遗漏和架构风险。

Elric认为，AI可以写代码，但不能无限制地改全局。越到后期，越要把AI的改动限制在具体模块里。这样即使某个模块出现问题，也不至于影响整个系统。这和很多AI原生组织的经验相似——AI把功能开发变轻了，但架构、边界和质量控制反而更重要。

传统企业想做AI转型，应该从哪里开始？Elric看来，最难的是两件事：第一是内部利益冲突，第二是执行者本身有没有意识到AI能带来什么。MooxAI自己也踩过类似的坑。早期他们给团队配了Coding Plan和各类AI工具，结果一两个月后发现，有些人的Token还剩下80%。工具给了，不代表大家真的会用。后来他们开始通过内部奖励机制，鼓励员工用AI做业务小闭环，并在周会上分享这些实践，团队的使用习惯才逐渐改变。