都说 AI 能给研发开外挂，可企业为啥总玩不转？答案来了！

原文出自：公众号“鹿爷聊数智化”

一提到 AI 赋能研发，大家脑海里可能会立刻浮现出 AI 生成代码的神奇场景，还有各种超酷炫的插件，或是那些 AI native 的 IDE（比如 Cursor、Trae 之类），感觉有了它们，编程就像开了挂一样。

也有人会想到听起来很 “高大上” 的氛围编程（vibe coding），就像有个超智能的黑盒子，能一键解决编程领域的所有难题，让程序员从此告别 “代码苦海”。

但实际上，在企业复杂而现实的场景中，上面这两种 AI 赋能研发的方式，就像两个 “不靠谱” 的伙伴，都没有从 “软件工程” 这个专业且实用的视角看待编程。在我之前的文章里（文末附有原文链接），已经给 “AI + 软件工程” 和 “氛围编程” 泼了冷水，让大家清醒一下。

今天，我打算再给 AI 生成代码泼泼冷水。先别急着反驳，AI 生成代码确实很厉害，这一点毋庸置疑。但它就像一个看似完美、实则暗藏玄机的宝藏盒子，打开后会发现几个让人头疼的问题：

1. 代码在程序员的价值版图里，其实只占可怜的 10%。也就是说，程序员的能力不只是写代码，还有很多其他重要技能和价值，比如理解业务需求、设计架构、优化代码性能等，这些都不是 AI 生成代码能轻松搞定的。

2. 俗话说：“种瓜得瓜，种豆得豆。”AI 生成代码也是如此，全靠你给出的指令（Prompt）。要是连清晰、准确、无歧义的需求都描述不清楚，就别指望 AI 能像 “读心术大师” 一样猜到你真正想要的。一个没经过专业需求分析训练的开发者，很可能给 AI 提模糊甚至错误的问题，最后得到的代码，看似功能正常，实则完全偏离核心业务逻辑，成了 “代码垃圾”，不仅没用，还可能把项目搅得一团糟。

那么问题来了，AI 赋能研发，到底该怎么做才能走上 “正轨” 呢？

首先，得把大家的认知拉到同一条起跑线上。来，我们一起回顾上篇文章的重要观点：

1. AI 赋能研发的核心，其实是 AI 赋能软件工程。这就像盖房子，软件工程是地基，AI 是上面的华丽装饰，没有坚实的地基，再漂亮的装饰也立不住。

2. AI 赋能软件工程，准确来说是 AI 辅助软件工程，而不是让 AI 当 “甩手掌柜”，完全驱动软件工程。AI 虽然厉害，但还无法完全取代人类在软件工程中的智慧和经验，只能作为得力助手，帮助我们提高效率，解决一些重复性、规律性的问题。

那 AI 辅助软件工程具体该怎么操作呢？我想答案应该是——统一的基础研发平台，这个平台得像 “全能管家”，把研发全流程都照顾得妥妥当当。

为什么非得要这样一个平台呢？这里面有两个重要的底层逻辑。

逻辑一：AI 三要素——算法、算力、数据

大家都知道，AI 要发挥 “洪荒之力”，得靠三个关键要素：算法、算力和数据。算法和算力这两个相对容易获取，就像去超市买东西，只要有钱，总能找到合适的。但数据就有点 “傲娇” 了，它才是最难搞定的。

举个例子，在 AIOps 场景中，假设有个微服务突然 “闹脾气” 出了故障，这时候我们得赶紧进行智能诊断，找出问题所在。要让 AI 的诊断结论像福尔摩斯破案一样精准，就需要各种数据来辅助，将这些数据融合分析。我给大家列举一下可能需要的数据（我能想到的就这些）：

1. 该微服务最近的日志信息，就像它的 “日记”，记录了近期的活动，说不定能从中找到故障线索。

2. 微服务的监控信息，比如 CPU、内存、网络等，就像给微服务做体检，看看是不是因为服务器资源不足，让它 “累坏了” 才出故障。

3. 它所依赖的服务信息也很重要，有可能是依赖的服务出了异常，把它 “连累” 了。

4. 全链路调用日志信息，就像完整的 “行动路线图”，能让我们清楚看到微服务在整个系统中的调用过程，说不定问题就出在某个调用环节。

5. 最近一次代码提交内容也不能放过，有可能是刚提交的代码有 “小毛病”，导致微服务罢工。

6. 部署微服务的虚拟机或容器集群运行情况，看看是不是 “居住环境” 不好，影响了微服务正常工作。

7. API 调用流量信息也得关注，说不定是流量突然激增，把微服务 “冲垮了”。

8. 它之前出现的历史故障也得翻出来看看，说不定是老毛病又犯了。

9. 还有故障处理案例库，里面都是以前处理类似故障的经验，说不定能从中找到解决办法。

当微服务出现故障时，怎么才能像超级英雄一样，快速收集上面这些数据，并且让它们 “手拉手” 关联起来，再交给模型分析呢？答案只有一个，就是靠基础研发平台。这时候可能有人会想，建一个统一数仓行不行？这是传统落地 AI 的一种方式，但我得泼盆冷水，这种方式非常不推荐。感兴趣的朋友可以在留言区留言，咱们找时间专门写篇文章讨论。

逻辑二：AI 赋能业务最好的用户体验是 ——AI Native APP 或者说 APP + AI

AI Native APP 或者说 APP + AI，到底是什么意思呢？我再给大家举个例子。假如企业想实现合同的 AI 审查，有两种方式可选：

1. 做一个单独的小 APP，功能单一，只有 “合同 AI 审查” 这一项。用户使用时，得先把合同上传到这个 APP，再点击审查按钮，等一会儿才能看到结果。这种方式就像去专门的小商店买东西，虽然能买到，但过程有点麻烦。

   
   

2. 另一种方式是在企业已有的合同管理系统里，在合同详情页加一个 “AI 审查” 的小按钮。用户查看合同详情时，想审查就直接点击按钮，非常方便。而且这个合同管理系统里，除了 AI 审查功能，说不定还有 AI 生成合同等其他实用功能，就像大型商场，应有尽有，用户不用在多个系统间来回切换，体验感特别好。

同样的道理，回到研发场景。还是以服务故障的智能诊断为例，如果在基础研发平台里，用户能随时查看服务运行状态，当服务出现故障时，旁边马上出现 “智能诊断” 按钮，用户一点击，系统就像勤劳的小蜜蜂，自动把前面提到的 9 类相关数据打包好，交给大模型分析，瞬间得出结果。整个过程流畅得就像德芙巧克力，纵享丝滑。

我们常说，企业里到处都是系统孤岛、数据孤岛，更别说让 AI 来赋能了。

那我想问，在研发领域，数据打通了吗？看看现状，是不是有一堆像孤岛一样的研发工具和平台，比如 Gitlab、IDE、Jira、CI 工具、k8s、日志系统、监控系统等，它们各自为政，互不干扰。这些数据到底该怎么打通呢？为什么不推荐统一数仓呢？

欢迎大家在留言区畅所欲言，一起讨论，说不定能碰撞出不一样的火花。