以我了解到的某大厂业务部门实践为例，详细讲讲怎么成为AI Native组织。 1. 先搭建AI基础设施 首先需要解决模型接入、使用成本和工具复用的问题，让员工主动使用AI。 他们搭建了一个模型广场，作为公司统一的模型API入口，员工接入外部模型可以通过这个平台完成，同时分成个人空间和业务空间。个人空间有独立额度，供员工自行探索；业务空间则分配给具体业务团队，方便管理使用额度和成本。 另外还建立了Skill和MCP中心，员工可以把自己开发的Skill、MCP上传共享，其他人直接复用。平台也制定了接入规范和身份鉴权标准，避免不同团队重复造轮子。对于使用量和人气排名靠前的Skill，每个月还有相应奖励。 在这些基础设施之上，开始出现实际的效率提升。一些可以参考的数据：coding和测试提效约三成，内容审核的初审工作基本可以由AI承担，AI告警定位平均可以在分钟级完成定位，三分之一的告警能够通过AI完成处理。 2. AI Coding到产品经理交付 下一步需要解决的是如何让AI从一个员工主动使用的工具，变成能够主动承担完整任务的生产力。 他们把AI封装成不同层级的任务执行能力，并开发了一个接入企业IM的研发数字人，员工可以像和同事沟通一样直接提交任务。 像是L2层级，主要面向研发人员，属于研发辅助模式。研发已经拿到产品需求文档，可以直接让数字人完成写代码、部署、测试环境验证。如果结果不符合预期，就退回去重新修改，直到验证通过，最后由研发人员完成代码合入和正式发布。 L3则更进一步，面向产品经理，属于自主交付模式。产品经理可以直接向数字人描述一个简单需求，Agent首先判断这个需求是否适合自主开发，符合条件后再进行写代码和验证。 这套模式目前主要适用于B端简单需求，C端业务还比较复杂，无法直接套用。 提效还是很明显的，原本需要十几个小时的简单需求，现在可以压缩到约1小时。 但也带来一个问题，个人效率提高了，组织效率却没有同步提高。 3. 重新设计研发工作流 为什么个人效率提高了，组织效率却没有同步提高？ 研发流程存在大量交接。产品经理完成需求分析，需要把信息传递给研发；研发完成代码，又要交给测试；测试完成后，还要经过审核和发布。 每个环节都有自己的上下文，信息在不同岗位和工具之间不断损耗。即使AI已经大幅提高了coding速度，其他环节的等待和交接依然存在。 因此，他们把原来的研发工作流拆成需求流和发布流。 需求流负责从一个想法开始，一直到代码合并；发布流负责把一段时间内完成的多个需求整合起来，统一发布到线上。 为什么需求和发布要分开处理呢？ 我觉得核心原因是，多个需求还需要进行整合、版本管理和发布验证。 B端和C端的流程也有明显差异。 B端业务的需求流相对简单。像是一个中间件业务，用户反馈或系统工单可以自动进入平台，由产品Agent完成需求分析和方案设计，人工确认需求文档后，再交给研发Agent写代码，最后由人工完成发布。 C端业务则复杂得多。以小游戏业务为例，需求可以从用户反馈VOC进入工作流，经过产品设计、研发实现、测试验证，最后还要进行效果回收。中间可能涉及设计、翻译、埋点等多个专业环节。 发布阶段还涉及客户端、服务端等多端协同，现在仍然以人工发布为主，AI目前无法取代。 4. 专业能力沉淀为公共Agent 重新设计工作流之后，还需要解决不同专业领域的能力如何参与的问题。 过去设计、翻译、埋点、测试等工作都需要对应岗位的人员参与，现在逐渐把这些领域的专业知识和工作方法封装成公共Agent，不同业务可以直接调用这些能力，也可以根据自己的实际需求进行定制。 在实践中发现，测试和翻译Agent的接入率、采纳率都比较高。但设计Agent的表现相对有限，原因在于设计本身具有较强的主观性，简单的L1、L2级需求可以交给AI处理，涉及复杂审美判断的设计仍然需要人工参与。 发布Agent目前也主要打通了B端业务。 很多人没意识到，这是一个显著变化：现在不同岗位积累的专业经验，能变成其他岗位直接调用的Agent。 5. 建设平台 有了工作流和公共Agent，还需要一个统一的平台，把任务、知识和上下文连接起来。 他们建设了两套基础设施，一套叫知识库，另一套叫交付平台。 知识库最初从代码仓开始建设，定期同步代码信息，同时允许员工上传业务文档和其他资料。 但有价值的往往是员工在日常工作中产生的经验。代码和文档只能提供一部分信息，比如一个需求为什么提出，中间遇到了哪些问题，为什么最终采用某个方案，这些信息也应该被记录下来。 因此，知识库与交付平台进行了打通。交付平台负责管理整个工作流，把不同任务交给对应的Agent，同时让人和Agent共享上下文。 举个例子，产品经理完成需求设计后，研发Agent可以直接获得需求背景、目标和交付要求，不需要重新解释一遍。即使研发人员使用Cursor或Codex等外部工具，也可以通过MCP把执行结果和状态回传到平台，后续环节继续沿用之前的上下文。 交付平台还支持流程回退。如果研发发现代码不符合预期，可以退回编码节点重新执行；如果发现产品需求本身有问题，也可以直接退回需求设计环节，重新走后续流程。 6. 组织结构的调整 当工作流、专业Agent和知识库都建立起来之后，才真正有条件尝试改变原来的组织协作方式。 一些真实业务场景进行试点，在新的工作模式下，人主要负责需求判断、关键决策和最终结果，Agent承担更多具体执行工作。原来依赖不同岗位之间反复沟通才能完成的事情，现在可以通过统一工作流和公共Agent完成协作。 很多人理解的AI Native组织是给所有人买ChatGPT Pro，这是错误的。 就像给汽车装上飞机发动机，汽车也不会因此飞起来。原来的工作流程没有改变，再强的AI也只能提高其中某些环节的效率。 企业引入AI，最初改变的是员工完成工作的方式，随后改变的是不同岗位之间的协作方式，最后才可能改变整个组织的结构。