其中的部分知识几乎是我们先前达到一致的,所以让我们反过来来讲述这个故事。
0. 生成式 AI 倒逼的研发数字化
在开始新的趋势总结之前,我们不得不提及的一点是:研发数字化。在已往的一年里,我与差不多 10 家公司的研发相关负责人交流 AI 辅助研发。事实上,拦阻大部分企业应用生成式 AI ,原因除了模型限定之外,尚有研发的数字化水平差。
我们要面临的第一个问题是:标准化没有落地。简单来说,规范化、平台化、指标驱动四个成熟度来思量问题时,有些组织还处于规范落地难的问题,更谈不上指标驱动改进。幸运的是生成式 AI 结合工具可以改进规范落地难的问题,也算是一个潜在的弯道机会 —— 前提是要有充足的气概气派推进。
除此,我们还要面临的第二个问题是:知识的管理 —— 组织中存在大量不可言传的知识(歪个楼,比如内容八卦)。我们会碰到的挑战有:
没有记载、没有显性化。
大量的过时的知识 —— 你不知道哪个文档是旧的。
大量的非文本知识 —— 某天拍的会议白板,字都不认识了。
简单来说,这些是我们知识债务的一部分。
6. 代码翻译与系统间翻译
场景一:遗留系统迁移。生成式 AI 的特性在天然语言翻译上表达得不错,在编程语言上也有非常突出的体现。所以,去年我们也在 AutoDev 做了相关特性的分析,并构建了一系列相关的遗留系统功能。而在贸易产品上,我们也可以看到诸如 IBM watsonx Code Assistant for Z 如许的 Cobol 转 Java 专用工具。
而如何分析遗留系统迁移,仍旧是一个复杂的问题。现有的工具更多的是由人来设计迁移,由 AI 来辅助。
场景二:系统间翻译。随着,越来越多的大厂开始开发鸿蒙应用,我们在实践中也发现了生成式 AI 在这方面的优势。由于移动系统的 UI 差别并不大,可以通过翻译来实现部分功能迁移。只管,我们碰到大量的生成式 AI 缺少新的专有知识(ArkUI、ArkTS、HarmonyOS API),但是结合将思维链和 RAG 与之相结合可以达到更可担当的结果。
5. AI 辅助 UI 设计的涌现
AI 生成代码需要结合现有的规范等信息,才华生成行之有效的代码。对于 Spring 一统江湖的后端代码开发来说,构建这种生成式 AI 友好的架构是一件很容易的事。但是,由于大中小型组织都有自己的品牌指南、风格指南、设计系统,所以生成式 AI 在前端领域颇有挑战。
从现有的模式来看,主要 AI 辅助 UI 设计可以分为三类:
线上问题修复。在没有生成式 AI 之前,传统的判定式 AI 已经能实现大量的自动化。常规应用程序性能监控(APM)工具,可以从线上运行时报的错误,映射到对应的出错代码。PS:再结合需求与代码的关联信息,我们可以精确推断出哪次需求变动造成的影响。在有了生成式 AI 之后,线上的问题可以直接转换为问题的修复 PR,辅助你修复问题,诸如于 NewRelic 也有类似的功能上线。 故障定位。在包罗大量子系统(如单个微服务)复杂的系统中,网络与问题的排除变得非常重要。在缺乏工具时,人类也经常在某个丢失关键信息,而 AI 正好可以辅助我们去解决此类问题,诸如于 AWS 的 AI 辅助网络故障排除。
思量到我只是 Dev 领域的专家,而非是 Ops 领域的专家,也不能解读出更多了。
3. AI 应用的 DevOps 设施
现现在已经有大量的线上应用引入了 AI 本领,诸如于星巴克推出的换脸活动等等,这一类的 AI 应用引入了一系列的 AI 根本设施。因此,对于中大型组织来说 ,除了思量合适的私有化部署模型,还需要构建快速的 AI DevOps 根本设施,以作为支持。
除了大模型自己的各类监测之外,我们还需要模型自己的运营本钱 —— 特别是当你调用第三方 API 之后,以构建更好的 AiBizDevFinGitSecOps 体系(