企业的AI建设，该统一推进，还是各部门自己做？丨ANC再认识建设分工

销售想让AI持续跟进客户需求，售后想让AI处理退换货。几项建设需求一起摆上桌，公司就要决定：都交给技术团队，还是让业务部门分别推进？

统一安排有很现实的好处。技术人员熟悉已有系统，相同的连接和维护工作可以一起做。业务部门自己推进，也有充分理由：客户需要什么、哪种安排不合适，业务人员最清楚，调整时不想隔着几层进行转述。

公司可以把两种安排结合起来，但要先分清各自负责什么。大家反复要用的能力，由公司安排建设和维护；具体业务怎么改，由业务负责人带着技术人员做；一个部门的改动会影响别人，就需要有人协调并作决定。先把这些工作分清，再决定建设人员集中在哪里，会比先把全部任务交给某一个部门更合适。

一｜大家要用的能力，不能每次从头建设

各部门提出的需求看起来不同，建设时却会碰到相同的事情：AI要连接公司的业务系统，在获准的范围内读取信息，还要把已经做过的处理和实际进展保存下来。每开展一项业务，都重新做一次这些工作，公司以后也就要分别维护多套相近的连接和记录功能。

这些适合共用的能力，可以由公司指定技术团队负责。先看已有的连接和信息访问方式哪些还能用，再补充当前业务共同需要的部分。一项业务有了新需求，也可以先与维护人员商量，判断能否在已有能力上改进，不必等一个覆盖所有未来业务的平台建完才开始。

公司让AI持续回应客户需求，就需要让它知道业务进行到哪里。客户改变要求、交货时间有变，AI要据此判断并推进下一步，这些工作都依赖及时有效的信息。

当公司主要依靠这样的AI创造核心价值，我们讨论的就是AI原生企业。AI Native Company，是以AI Agency为主力实现核心价值创造的公司。

为了让AI持续取得有效信息，业务系统调整后，维护团队要更新连接；运行记录有缺漏时，要查明原因并补好。几个业务共同需要的改进，也由维护团队组织落实。

因此，公司指定维护团队时，也要让业务人员知道怎样获得支持。哪些能力已经能用，使用时要遵守哪些共同要求，缺少某项能力应该联系谁，提出需求后什么时候能得到答复，都应讲清楚。维护人员则要了解需求会影响哪些正在进行的业务，给出可用的办法和支持安排，而不只是发一份规定。

共用到什么程度，要看具体工作。读取信息和检查访问权限的方法可以共用，销售与售后能读取的内容却可以不同。把这种能力建好，是让各项业务取得自己需要的信息，并不要求所有部门看到全部客户资料。

二｜业务怎么改，业务负责人要带着做

设想一家商贸公司，销售和售后都准备让AI持续处理业务，两边都需要读取同一笔订单。公司安排技术人员维护订单连接、访问权限和处理记录，两项业务便可以使用这些共用能力。

订单信息可以共用，销售跟进和退换货怎样处理，仍要由各自的业务负责人明确。销售负责人要确定AI怎样跟进客户需求和交货安排，售后负责人则要确定AI怎样结合已购商品、送达情况和客户当前要求，推进退换货。

以售后建设为例，售后负责人需要先说清准备改善什么。是缩短客户等待换货的时间，还是减少客户追问进度？AI负责到哪一步，哪些特殊要求需要负责人决定，现有人员的工作怎样调整，也要一并考虑。技术人员据此参与设计，检查订单和物流信息是否够用，说明哪些处理能够实现、哪些还缺条件，以及相应的投入。

这段工作需要来回讨论。业务负责人提出更及时地跟进，技术人员发现物流进展只能隔一段时间取得，就应一起重新安排查询与处理方式，并核实能向客户承诺什么。业务不能把希望写成要求后就离开，技术也不能只按文字把功能做出来，再等业务验收。

开始处理真实请求后，两方继续看同一批记录：AI在什么时候发现了变化，采取了什么行动，客户的换货有没有完成，等待和返工是否比原来减少。如果物流信息不能及时取得，技术人员先查明原因，与售后负责人一起确定可以怎样改善信息获取。售后负责人据此调整跟进安排和客户承诺，两方再共同验证新的做法。

售后负责人主导的，是一项能够向客户交代的换货业务。即使物流联系、商品补发分别由其他岗位完成，售后负责人仍要检查整项换货有没有完成，而不是每个岗位都只验收自己的AI功能。涉及其他业务的安排，再找相关负责人一起处理。

这样的协作不要求售后另招一整支开发团队。公司可以统一安排技术人员，让他们与具体业务人员一起工作；需要外部落地团队参与时，业务负责人也仍要决定服务怎么做、检查实际成效。

三｜改动影响别人时，要有人能够作决定

销售后来提出一项调整：为了跟进分批交货，用每批商品的发货和签收进展，替换原来的整单送达状态。售后的AI却还在读取原来的状态，判断商品是否送达。如果直接停用原来的记录，售后就无法按现有方式继续判断，正在处理的业务也会受到影响。

修改之前，维护订单连接的技术人员先查清哪些业务还在使用原来的记录，说明怎样改、需要哪些配合。销售负责人讲清分批跟进需要什么，售后负责人确认判断送达仍需要哪些信息。业务与技术人员据此商定修改方案和实施顺序。

各方能够达成一致，就按商定的安排推进。若销售希望尽快调整，售后还需要时间修改处理方式，实施顺序又无法商定，就应由公司事先指定、分管这些业务的经营负责人作决定。他需要结合客户承诺、改动影响和技术方案，决定先改哪些部分、哪些等配套调整完成后再启用。

定下安排以后，技术人员完成相应修改，销售和售后再分别检查新的记录是否够用、原有业务能否继续处理，通过验证后按约定启用。

我们之前的文章「为什么很多系统不是死于错误，而是死于正确？丨FDE重新理解局部最优」讨论过，一个部门的决定会改变其他部门共同使用的条件。建设AI时，企业要把这种影响纳入决定，不能指望各部门分别把自己的事做好以后，自然就能配合起来。

协调应集中在确实影响别人的部分。在已经明确的业务范围和共同规则内，业务与技术人员可以及时改进处理方式；Agency也继续根据反馈自主学习、调整日常行动，不需要把每次变化都变成一次公司审批。

这些职责可以由现有人员承担。小公司里，同一个负责人可以兼顾业务改造和跨业务协调；随着业务增加，再把工作分开。

ANC视角

公司应统一组织共用能力的建设，由业务负责人主导具体业务改造，并明确跨部门问题由谁协调决定。

对AI原生企业来说，这种分工要延续到日常经营中。Agency持续处理业务、从反馈中学习，公司也要持续维护它使用的能力，检查业务有没有变好，并处理新的跨部门影响。项目上线只是交付了一次建设成果，不能成为技术人员结束维护、业务负责人停止参与的理由。公司要建立的是一种能够长期改进业务的合作方式。

写在最后

下一次安排AI建设，可以先选一项准备推进的业务，写清哪些已有能力可以使用、找谁获得支持，再明确业务改造由谁带着做、跨部门分歧由谁决定，随后安排实际建设人员。这样，团队开始工作时就知道哪些事情自己能推进，哪些需要找人一起解决。

先把工作分清，团队才知道怎样一起把业务做好。

来源与限制

1. AWS，Establishing an AI/ML center of excellence，2024年5月9日发布，2026年9月13日核验。该文讨论集中或分布式的AI/ML组织安排、跨业务共用能力以及业务与技术团队协作，本文仅将其作为公开实践建议的背景。
2. 上述来源不是组织模式的比较实验，不能证明本文分工最优或保证经营回报，也不构成企业必须成立AI/ML卓越中心的依据。本文没有采用其中二手调查数字或完整治理框架。
3. 商贸公司、销售与售后建设、订单记录变更均为综合设想，不是已验证的企业案例或行业标准流程。共用能力与业务协作并非ANC首创；本篇提出的三项分工及其在AI原生企业中的应用属于ANC建议。

感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：
「塔迪AI工程系列」FDE落地工程、ANC：AI Native Company未来公司系列、GEO、AI判断工程。
「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。