传统企业 AI 转型的最短路径，藏在研发部门

作者 | 希希子

研发部门在公司里是个特殊且重要的存在。

系统正常运行时，没人想起他们；系统一出问题，电话第一个打过来。业务部门指望着需求今天提出、下周上线；管理层则常常把 IT 预算看成一笔不得不花的钱。但说起研发究竟创造了多少价值，却很难像销售额那样直接写进财报里。

但现在，这个部门的价值正在被重新定义。

在 AI 时代的传统企业里，研发部门正在完成一次角色翻转——从成本中心，到 AI 转型的发动机。人们常识里，先被 AI 改变的是研发部门；而现在，正在用 AI 能力推动组织转型的，也是它。

为什么 AI 转型能从研发出发？

最早被 AI 重塑的一群人，开始推动组织进化

企业 AI 转型从研发部门出发，并不是因为程序员学会了用 AI 多写几行代码。恰恰相反，代码本身正在变得没那么稀缺。真正值得注意的是，研发人员在这一轮 AI 应用中最早踩坑，也最早摸到了一些能在企业里复用的东西。

他们知道模型会一本正经地犯错，知道上下文给少了不行、给多了也不行；知道一句“帮我开发一个系统”基本等于什么都没说；还知道 AI 演示时有多惊艳，接进生产环境时就有多麻烦。这些经验听起来琐碎，甚至有点“给 AI 收拾残局”的意思，却可能比会不会写提示词重要得多。

研发人员既是 AI 的高频使用者，也是 AI 应用的生产者。研发过程天然包含明确目标、复杂上下文、工具调用、执行反馈和质量验证，这使得研发团队也是最早处理真实生产环境中处理 AI 的可靠性、安全性和可控性问题的部门。

现在，一些传统企业正在把这套经验从研发部门搬出去。研发人员先用 AI 改造开发流程，再去搭建供财务、供应链、生产、销售和客服使用的智能体。最早被 AI 重塑的一群人，开始反过来推动组织进化。

传统企业三重难恰是 Agent 进阶之路

● 传统企业数十年沉淀的庞大存量系统、复杂技术栈、隐性依赖关系，无法靠通用大模型一键适配，需要 Agent 读懂系统上下文、适配历史架构、规避改造风险；

● 企业专属的业务规则、行业经验、流程规范大多散落在员工经验与历史文档中，无标准化手册，需要 Agent 完成知识结构化、场景适配、精准落地；

● 多层级的组织链路、部门协作壁垒，导致通用 AI 能力无法直接穿透业务流程，需要 Agent 打通数据、工具、权限、审批全链路。

互联网企业的 AI 落地是“白纸作画”，而传统企业的 AI 转型是“在复杂实景中解决真实问题”，难度更高、壁垒更强、商业价值更扎实，这不是落后的转型路径，而是更具长期竞争力的进阶之路。而这三个看似阻碍的因素，恰恰是 Agent 最能发挥价值的场景。这是比互联网"更值得走"而非"迟到"的路。

AI Coding 演进：正式进入企业核心研发流程

很多人误以为研发 AI 工具、业务智能体是两套完全独立的体系，实则二者共享同一套核心工程底座，底层逻辑高度互通。无论是赋能研发的编码智能体，还是服务财务、供应链、生产、客服的业务智能体，都依赖统一的模型调用、上下文管理、工具编排、任务拆解、执行反馈、质量校验与权限管控能力。

研发团队在 AI Coding 实战中沉淀的整套工程化方法论，具备极强的跨场景可迁移性：通过 Spec 驱动解决需求模糊、执行跑偏的问题；通过闭环反馈回路实现 AI 持续自我迭代；通过约束与质量护栏规避模型风险；通过知识消解沉淀企业专属资产。这套经过复杂代码工程验证的成熟体系，无需重复试错，可直接复用、改造、落地到各类业务智能体的搭建、治理与迭代中，为企业全域 AI 转型提供标准化支撑。

AI Coding 的能力也在快速演进——从早期的代码生成和补全，到仓库级上下文理解、代码问答、解释、重构和跨语言转换，再到需求理解、任务规划、终端操作、调试测试和后台任务执行。AI 对研发的改造已不再局限于"某一段代码写得更快"，而是进入需求、设计、开发、测试和交付的完整流程。

这意味着，当 AI Coding 进入企业核心研发流程，企业需要的不只是模型能生成代码，还需要生成结果满足业务要求、工程规范和安全标准——需要一套工程化机制来保障。接下来三个企业案例，将呈现这套机制如何在不同场景中落地。

AI 企业实践案例：从研发能力到全域智能化跃迁

Harness 建设：海信——将 AI Coding 纳入可度量的研发工程体系

事情大概是这样发生的。

海信在 2026 年初接触 Qoder，2 月组织了近百人试用，3 月正式引入。后来使用规模扩展到 900 多人。它的研发环境很典型：数质中心服务集团 46 家产品公司，手里有 100 多套自研系统，技术栈不统一，新老项目混在一起。不是 AI 最喜欢的那种场景。

模型当然更喜欢从零开始。没有历史代码，没有前人留下的奇怪命名，也没有一句代码牵动七八个系统的隐性依赖。可现实中的企业软件很少是一张白纸。系统可能已经运行十几年，文档停留在几个版本之前，某段逻辑为什么不能动，往往只有一个快退休的老员工说得清。

说句程序员都懂的话：新系统写起来爽，旧系统才是日常生活。

海信选了 10 个项目做试验。全新系统开发的效率提高了 3 至 4 倍，效果不错；到了历史系统上，提升就没那么明显。问题并不是 AI 不会写，而是它不知道那些从未被记录下来的历史。

这个结果其实比“效率提升多少倍”更有意思。

它戳破了一个常见想象：仿佛只要模型足够强，企业里的旧系统和复杂流程就会自动变简单。并不会。那些年久失修的文档、靠口口相传维持的业务规则、不同团队各自形成的开发习惯，并没有因为大模型出现就突然消失。模型甚至会把这些问题放大。人类工程师不懂时，至少会停下来问一句；AI 有时不懂，但照样往下写。

所以海信后来做的重点，不是催着大家多生成代码，而是建立一套内部 Harness 工程体系。说白了，就是想办法把 AI 管起来。海信案例的核心不是某一次代码生成，而是构建了一套可度量、可控制的 AI 研发工程体系。

Qoder 让 AI Coding 进入可控的工程流程，主要体现在四个方面：

● Spec 驱动： 在开发前明确目标、范围、约束和验收标准，让 AI 先理解任务，再开始执行；

● 闭环验证： AI 不只生成代码，还会运行命令与测试，并根据结果持续调整，最终由开发者审查确认；

● 工程护栏： 将项目规范、开发工具、验证方法和安全边界纳入开发流程，减少偏离规范和不可控变更；

● 知识复用： 将项目规则、开发经验和历史决策沉淀为可复用的团队资产，降低对个人经验的依赖。

把 AI Coding 纳入企业现有研发流程，建立可复用、可衡量、可控制的工程体系——是 AI Coding 从"个人工具"升级为"组织能力"的关键一步。

跨部门协同：三一重工，从研发工具升级企业智能底座

不过，真正把这件事推到研发部门之外，还得看三一重工。

这家装备制造企业有上千名研发人员，业务覆盖全球 150 多个国家和地区。Qoder 起初进入核心研发部门，后来逐渐支持研发、大数据和 AI 等不同团队协同。再往后，企业做出了 50 多个 AI 智能体，场景从研发延伸到生产、销售和服务。

跨过这一步，事情就不再只是 AI Coding 了。

制造业的数据相当不规整。除了数据库里的数字，还有图纸、技术文档、设备记录和现场图片。很多判断依赖行业经验，并不是把资料扔进知识库就万事大吉。

Agent 要在这里工作，需要两种关键能力。一是多模态数据解析——能读懂图纸、技术文档、生产数据等非结构化信息，适配制造业的复杂数据环境。二是 Agent 自主任务执行——终端命令执行、自动调试、异步后台任务，研发人员可以"把任务交给 AI"，而不是"手把手带着 AI 干"。

同时，Agent 还得连接企业原有的数据库、存储、算力和业务系统。哪些数据能看，哪些操作能做，出了问题由谁负责，也都要提前设计。Qoder 结合阿里云数据库、存储、算力等基础设施，实现研发、大数据、AI 多部门在同一平台上协同作业，推进全链路的价值对齐。

写代码时，Agent 读取代码仓库，调用终端和测试工具，根据报错继续修改；处理业务任务时，它读取企业知识，调用内部系统，根据业务结果继续调整。对象变了，处理上下文、连接工具、控制权限和检查结果的方法仍然相通。

研发团队在 Coding Agent 上交过的“学费”，这时有了新的用途。

三一重工的 50 多个智能体，不只是 50 个新工具。更重要的是，企业内部开始出现一套可以反复生产 Agent 的办法。研发、大数据和 AI 团队不再各做各的项目，而是在一套相对统一的基础上协作，从"技术驱动"走向"全员 AI 化的组织进化"。

这件事说起来容易，做起来通常不太体面。系统接不通、数据格式混乱、权限审批迟迟下不来，往往比模型效果差更常见。一个 Agent 在会议室里演示成功，和它能每天稳定服务几百名员工，中间隔着大量没人愿意写进发布稿的工作。

企业 AI 转型最容易被低估的，恰恰是这些脏活。

全域赋能：孩子王，搭建企业智能体工厂落地全业务

到了孩子王，这条路又往前走了一段。

孩子王没有满足于给现有业务加几个 AI 功能，而是自研了一个名为“智枢”的企业智能体平台。这个平台以千问大模型为基础，集成知识库、工作流、Skills 和多 Agent 协同能力，能够连接公司内部不同业务场景。

智枢原本接近半年的开发周期，被缩短到了两个月。过去需要一周左右的前后端需求，有的可以在一天内完成。

如果只写到这里，它还是一个研发提效故事。

后面的数字才说明问题发生了变化：智枢目前覆盖 400 多个业务场景，运行着 300 多个智能体，还形成了十余个“专家智能体”，涉及数据分析、财务、供应链、客服和内容创作等岗位。

财务核对原来需要人工处理 3 天，现在缩短到 20 分钟；数据分析效率提高近 3 倍；智能结算助手可以解决一半以上的问题；内容创作专家节省的产能，相当于 30 多人。

这些智能体不是研发部门关起门来想出来的。

孩子王的做法，是让一个专家智能体尽量对应公司里一类真实的工作。财务专家对应财务团队，供应链专家对应供应链团队。这样一来，谁会使用它、它要解决什么问题、做成什么样才算有效，至少有了比较清楚的答案。

这比从“AI 还能干什么”开始靠谱得多。

现在企业里并不缺 Agent 创意。开一次脑暴会，列出几十个场景很容易。难的是三个月后还有多少人在用，以及一个看起来很聪明的 Agent 到底有没有省下真实的工作。

孩子王的分工也比较务实。研发团队负责模型、平台、工具、权限和安全，业务人员负责场景、知识、流程和反馈。业务人员不需要学会搭建整套基础设施，研发人员也不用假装自己比财务更懂对账、比供应链更懂履约。

两边在平台上碰头。

业务部门使用后提出新要求，研发再用 Qoder 调整智枢；平台能力变得更完善，业务人员又可以建设新的智能体。孩子王还把“会不会用 AI”纳入能力考核，希望这种协作不只依赖少数积极分子。

我对“全员 AI”这类说法一直有点警惕。

每一轮技术热潮里，企业都容易给全员发一个工具账号，组织几场培训，然后把登录率和调用次数当作转型成果。几个月后，新鲜感过去，大部分人还是回到原来的工作方式。

孩子王的案例比较有价值，不是因为智能体数量多，而是它试图把智能体对应到真实岗位，并用财务核对时间、问题解决率和实际产能来判断效果。这些指标不一定完美，至少比“调用了多少次模型”更接近业务。

结语：

我们把三家企业放在一起看，会发现一条清晰的路径：海信把 AI Coding 纳入了一套可度量的工程体系；三一重工把研发工具扩展成了跨部门协同的智能底座；孩子王搭出了供业务部门持续建设智能体的平台。

这条路径之所以对传统企业尤其重要，是因为它回应了开篇提到的三件事。

• 存量系统复杂？研发部门恰好是最懂存量系统的团队，借助仓库级上下文理解，他们终于敢对老系统动手了。

• 领域知识壁垒深？Harness 工程化体系把隐性知识变成了可复用的组织资产。

• 组织链条长？智能体平台让研发和业务在同一个平台上碰头，AI 能力不再卡在部门墙中间。

或许，研发部门确实是一个企业 AI 转型的起点。

不是因为研发比其他部门更重要，而是这个部门同时靠近模型和业务系统。研发人员既能直接使用 Agent，也能看见它进入生产环境后会遇到的麻烦。更关键的是，他们有能力把一次成功尝试变成平台、接口、规范和工具，让其他部门不必从头再踩一遍坑。

传统企业过去积累的旧系统和行业知识，经常被视为 AI 转型的包袱。换个角度，它们也是互联网公司很难复制的东西。Agent 如果真能进入这些系统，读懂这些知识，并参与那些具体但繁琐的流程，产生的价值可能比再做一个通用聊天助手大得多。

AI 转型的关键不是部署一个模型，而是建立能力循环。研发部门正在从成本中心变成 AI 能力中心。AI Coding 的终点不是"一个更快的程序员"，而是一家企业开始拥有持续生产 AI 能力的流水线。

但是，研发部门也不会突然变成一家公司的“超级英雄”。它只是从不停接需求的人，慢慢变成一个搭台子的人。

至于这个台子最后能搭多大，要看业务部门愿不愿意上来，也要看企业能不能耐着性子，把那些远没有产品演示好看的基础工作继续做下去。