某集团落地实践 | AI原生开发平台，以AI赋能企业级研发全链路

原文内容来自：某集团研发团队成员的真实采访

去年年中，我们研发平台组被问了一个不太好接的问题：公司每年投在写代码上的人力，到底有多少是在"创造"，又有多少是在重复已经做过无数遍的事？

我们不是互联网公司。我们是一家业务横跨好几个品类、在海外也养着几个品牌的制造企业。研发体系摊得很大：不同产品线、不同技术栈，连不同国家团队的协作习惯都各搞各的。所以这几年，每当市面上冒出一个"AI 写代码"的新东西，我们几乎都试过。试完的结论出奇一致——放在个人桌面上挺好用，塞进公司那套又老又大的研发机器里，就哑火了。

我们为什么一直"试而不推"

后来复盘，问题不在模型不够聪明，而在三件事一直没解决。

一是单点工具只能打辅助。一个工程师用 AI 补全几行代码，效率确实上去了，但活儿还是他一个人的活儿，经验带不走，也复制不了。

二是我们的存量太重。大量老代码、私有协议、内部框架，通用模型根本不认识，生成的东西经常跑不起来。

三是从"写一段代码"到"交付一个功能"，中间隔着需求、设计、评审、测试一长串环节。工具只覆盖其中一格，闭环永远是断的。

这三条凑在一起，就有了那个熟悉的场景：试点的时候大家鼓掌，推广的时候没人接。

换思路：不上工具，上工程化打法

去年下半年，我们停掉了"逐个试点"的做法，改成先搭底座。底层选了 企业级 AI 原生全链路研发协作平台，但真正花力气的，是在它上面搭三层东西。

第一层，Prompt Engineering，解决"任务怎么说清楚"。我们给每个高频场景沉淀了专属提示词，工程师不再临场发挥。

第二层，Harness Engineering，解决"能力怎么留下来"。AI原生开发的能力被包成贴合我们自己技术栈的可复用组件——比如适配某条产品线构建系统的插件、符合内部代码规范的评审组件。

第三层，Loop Engineering，解决"怎么越用越聪明"。Agent 不再只答一次，而是嵌进研发循环：开 PR、自动评审、工程师改、再评审，一圈一圈转。

【AI原生开发平台 - 企业研发全链路逻辑架构】

链路，才是真正的难点

光有三层能力还不够。真正卡住我们的，是"链路"。

需求、设计、编码、测试、交付——这五个环节过去是五张皮。需求在 A 系统，代码在 B 仓库，测试在 C 平台，彼此之间靠人肉搬运上下文。AI 再强，也只能待在某一个格子里。

我们用 Graph Engineering 的思路把整条链路画成一张图：每个环节都是图上的节点，节点之间带着上下文和约束。这样，AI CloudOS 上的 Agent 就能顺着图走完一整趟，而不是停在某一格。

落地：先挑最疼的三个点

我们没有全面铺开，而是先挑了三个最疼的地方。

代码评审。以前一个变更要等同事排期 review，现在 AI 原生开发平台先在企业私有代码库上跑一遍，把明显的问题挡在前面，人只看剩下的。

单元测试。给存量模块补测试，过去没人愿意干，现在由 Agent 出初稿，工程师只改不对的地方。

需求拆解。一个新需求进来，先被拆成可执行的任务图，再往下分派，省掉了大量来回沟通。

半年之后

半年下来，我们最在意的不是"AI 写了多少行代码"，而是三件事：

这些数字不性感，但老板认这笔账。更让我们确定方向对了的是另一件事：工程师开始主动往回拉需求，问"这个能不能也交给 Agent 跑一遍"。一个工具能不能在企业里活下来，就看这个瞬间。

如果重来一次

复盘下来，有两点想提前说给同行。

第一，别一开始就追求全覆盖。AI 进研发，难的从来不是技术演示，而是把能力嵌进那条又老又长的链路里，还能让工程师愿意用。先把一个闭环跑通，比画一张大图重要得多。

第二，工程化投入要占大头。模型是别人的，Prompt、Harness、Loop 这三层才是自己的。我们花在这三层上的功夫，远多于选型本身。

AI 原生开发平台不是来替谁的。它把我们最重复的那部分活儿接走了，剩下的人，终于可以干点更像"创造"的事。