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

极客邦科技InfoQ
个人专栏
热度: 5167

文章探讨传统企业AI转型的实践路径,指出研发部门正从成本中心转变为AI能力中心,通过AI Coding工程化体系沉淀可复用的方法论,并将经验扩展至财务、供应链、生产等业务领域,形成智能体平台与组织级AI能力循环。

摘要由 Mars AI 生成
本摘要由 Mars 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 能力的流水线。

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

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

本文来自微信公众号 “InfoQ”(ID:infoqchina),作者:希希子

声明:本文为入驻“火星财经 专栏”作者作品,不代表火星财经官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
本内容旨在传递行业动态,不构成投资建议或承诺。