一提到 AI 赋能研发，大家脑海里可能会立刻浮现出 AI 生成代码的神奇场景，还有各种超酷炫的插件，或是那些 AI native 的 IDE（比如 Cursor、Trae 之类），感觉有了它们，编程就像开了挂一样。
也有人会想到听起来很 “高大上” 的氛围编程（vibe coding），就像有个超智能的黑盒子，能一键解决编程领域的所有难题，让程序员从此告别 “代码苦海”。
但实际上，在企业复杂而现实的场景中，上面这两种 AI 赋能研发的方式，就像两个 “不靠谱” 的伙伴，都没有从 “软件工程” 这个专业且实用的视角看待编程。在我之前的文章里（文末附有原文链接），已经给 “AI + 软件工程” 和 “氛围编程” 泼了冷水，让大家清醒一下。
今天，我打算再给 AI 生成代码泼泼冷水。先别急着反驳，AI 生成代码确实很厉害，这一点毋庸置疑。但它就像一个看似完美、实则暗藏玄机的宝藏盒子，打开后会发现几个让人头疼的问题：
- 代码在程序员的价值版图里，其实只占可怜的 10%。也就是说，程序员的能力不只是写代码，还有很多其他重要技能和价值，比如理解业务需求、设计架构、优化代码性能等，这些都不是 AI 生成代码能轻松搞定的。
- 俗话说：“种瓜得瓜，种豆得豆。”AI 生成代码也是如此，全靠你给出的指令（Prompt）。要是连清晰、准确、无歧义的需求都描述不清楚，就别指望 AI 能像 “读心术大师” 一样猜到你真正想要的。一个没经过专业需求分析训练的开发者，很可能给 AI 提模糊甚至错误的问题，最后得到的代码，看似功能正常，实则完全偏离核心业务逻辑，成了 “代码垃圾”，不仅没用，还可能把项目搅得一团糟。
那么问题来了，AI 赋能研发，到底该怎么做才能走上 “正轨” 呢？
首先，得把大家的认知拉到同一条起跑线上。来，我们一起回顾上篇文章的重要观点：
- AI 赋能研发的核心，其实是 AI 赋能软件工程。这就像盖房子，软件工程是地基，AI 是上面的华丽装饰，没有坚实的地基，再漂亮的装饰也立不住。
- AI 赋能软件工程，准确来说是 AI 辅助软件工程，而不是让 AI 当 “甩手掌柜”，完全驱动软件工程。AI 虽然厉害，但还无法完全取代人类在软件工程中的智慧和经验，只能作为得力助手，帮助我们提高效率，解决一些重复性、规律性的问题。
那 AI 辅助软件工程具体该怎么操作呢？我想答案应该是——统一的基础研发平台，这个平台得像 “全能管家”，把研发全流程都照顾得妥妥当当。
为什么非得要这样一个平台呢？这里面有两个重要的底层逻辑。
逻辑一：AI 三要素——算法、算力、数据
大家都知道，AI 要发挥 “洪荒之力”，得靠三个关键要素：算法、算力和数据。算法和算力这两个相对容易获取，就像去超市买东西，只要有钱，总能找到合适的。但数据就有点 “傲娇” 了，它才是最难搞定的。
举个例子，在 AIOps 场景中，假设有个微服务突然 “闹脾气” 出了故障，这时候我们得赶紧进行智能诊断，找出问题所在。要让 AI 的诊断结论像福尔摩斯破案一样精准，就需要各种数据来辅助，将这些数据融合分析。我给大家列举一下可能需要的数据（我能想到的就这些）：
- 该微服务最近的日志信息，就像它的 “日记”，记录了近期的活动，说不定能从中找到故障线索。微服务的监控信息，比如 CPU、内存、网络等，就像给微服务做体检，看看是不是因为『服务器』资源不足，让它 “累坏了” 才出故障。它所依赖的服务信息也很重要，有可能是依赖的服务出了异常，把它 “连累” 了。全链路调用日志信息，就像完整的 “行动路线图”，能让我们清楚看到微服务在整个系统中的调用过程，说不定问题就出在某个调用环节。最近一次代码提交内容也不能放过，有可能是刚提交的代码有 “小毛病”，导致微服务罢工。部署微服务的虚拟机或容器集群运行情况，看看是不是 “居住环境” 不好，影响了微服务正常工作。API 调用流量信息也得关注，说不定是流量突然激增，把微服务 “冲垮了”。它之前出现的历史故障也得翻出来看看，说不定是老毛病又犯了。还有故障处理案例库，里面都是以前处理类似故障的经验，说不定能从中找到解决办法。
当微服务出现故障时，怎么才能像超级英雄一样，快速收集上面这些数据，并且让它们 “手拉手” 关联起来，再交给模型分析呢？答案只有一个，就是靠基础研发平台。这时候可能有人会想，建一个统一数仓行不行？这是传统落地 AI 的一种方式，但我得泼盆冷水，这种方式非常不推荐。感兴趣的朋友可以在留言区留言，咱们找时间专门写篇文章讨论。
逻辑二：AI 赋能业务最好的用户体验是 ——AI Native APP 或者说 APP + AI
AI Native APP 或者说 APP + AI，到底是什么意思呢？我再给大家举个例子。假如企业想实现合同的 AI 审查，有两种方式可选：
- 做一个单独的小 APP，功能单一，只有 “合同 AI 审查” 这一项。用户使用时，得先把合同上传到这个 APP，再点击审查按钮，等一会儿才能看到结果。这种方式就像去专门的小商店买东西，虽然能买到，但过程有点麻烦。
- 另一种方式是在企业已有的合同管理系统里，在合同详情页加一个 “AI 审查” 的小按钮。用户查看合同详情时，想审查就直接点击按钮，非常方便。而且这个合同管理系统里，除了 AI 审查功能，说不定还有 AI 生成合同等其他实用功能，就像大型商场，应有尽有，用户不用在多个系统间来回切换，体验感特别好。
同样的道理，回到研发场景。还是以服务故障的智能诊断为例，如果在基础研发平台里，用户能随时查看服务运行状态，当服务出现故障时，旁边马上出现 “智能诊断” 按钮，用户一点击，系统就像勤劳的小蜜蜂，自动把前面提到的 9 类相关数据打包好，交给大模型分析，瞬间得出结果。整个过程流畅得就像德芙巧克力，纵享丝滑。
我们常说，企业里到处都是系统孤岛、数据孤岛，更别说让 AI 来赋能了。
那我想问，在研发领域，数据打通了吗？看看现状，是不是有一堆像孤岛一样的研发工具和平台，比如 Gitlab、IDE、Jira、CI 工具、k8s、日志系统、监控系统等，它们各自为政，互不干扰。这些数据到底该怎么打通呢？为什么不推荐统一数仓呢？
欢迎大家在留言区畅所欲言，一起讨论，说不定能碰撞出不一样的火花❇️。
感谢阅读，如果觉得不错就点个“赞“和“在看”吧。
如果喜欢我的文字，WX关注“鹿爷聊『数字化』”，一起交流吧。
