2024 年 AI 辅助研发趋势:从研发数字化到 AI + 开发工具 2.0,不止于 Copilot

2024年 3月 5日 106.4k 0

在上一年里,已经有不少的企业在工具链上落地了生成式 AI,结合我们对于这些企业的分析,以及最近在国内的一些 “新技术” 趋势,诸如于鸿蒙原生应用的初步兴起。从这些案例与趋势中,我们也看到了一些新的可能方向。

结合我们在 LLM as-Copilot,LLM as-Integrator,LLM as-Facilitator 的三阶段框架,以及我们内部的分析材料,我大体将其总结为 6 个趋势:

  • 从单角色辅助到端到端辅助。
  • 辅助决策的知识管理。
  • AI 应用的 DevOps 设施。
  • 线上故障定位和问题解决。
  • AI 辅助 UI 设计的涌向。
  • 代码翻译与系统间翻译。
  • 其中的部分知识几乎是我们先前达到一致的,所以让我们反过来来讲述这个故事。

    0. 生成式 AI 倒逼的研发数字化

    在开始新的趋势总结之前,我们不得不提及的一点是:研发数字化。在过去的一年里,我与差不多 10 家公司的研发相关负责人交流 AI 辅助研发。事实上,阻碍大部分企业应用生成式 AI ,原因除了模型限制之外,还有研发的数字化水平差。

    我们要面临的第一个问题是:标准化没有落地。简单来说,规范化、平台化、指标驱动四个成熟度来考虑问题时,有些组织还处于规范落地难的问题,更谈不上指标驱动改进。幸运的是生成式 AI 结合工具可以改进规范落地难的问题,也算是一个潜在的弯道机会 —— 前提是要有足够的魄力推进。

    除此,我们还要面临的第二个问题是:知识的管理 —— 组织中存在大量不可言传的知识(歪个楼,比如内容八卦)。我们会遇到的挑战有:

    • 没有记录、没有显性化。
    • 大量的过时的知识 —— 你不知道哪个文档是旧的。
    • 大量的非文本知识 —— 某天拍的会议白板,字都不认识了。

    简单来说,这些是我们知识债务的一部分。

    1. 代码翻译与系统间翻译

    场景一:遗留系统迁移。生成式 AI 的特性在自然语言翻译上表达得不错,在编程语言上也有非常突出的表现。所以,去年我们也在 AutoDev 做了相关特性的分析,并构建了一系列相关的遗留系统功能。而在商业产品上,我们也可以看到诸如 IBM watsonx Code Assistant for Z 这样的 Cobol 转 Java 专用工具。

    而如何分析遗留系统迁移,依旧是一个复杂的问题。现有的工具更多的是由人来设计迁移,由 AI 来辅助。

    场景二:系统间翻译。随着,越来越多的大厂开始开发鸿蒙应用,我们在实践中也发现了生成式 AI 在这方面的优势。由于移动系统的 UI 差异并不大,可以通过翻译来实现部分功能迁移。尽管,我们遇到大量的生成式 AI 缺少新的专有知识(ArkUI、ArkTS、HarmonyOS API),但是结合将思维链和 RAG 与之相结合可以达到更可接受的结果。

    2. AI 辅助 UI 设计的涌现

    AI 生成代码需要结合现有的规范等信息,才能生成行之有效的代码。对于 Spring 一统江湖的后端代码开发来说,构建这种生成式 AI 友好的架构是一件很容易的事。但是,由于大中小型组织都有自己的品牌指南、风格指南、设计系统,所以生成式 AI 在前端领域颇有挑战。

    从现有的模式来看,主要 AI 辅助 UI 设计可以分为三类:

  • 辅助需求沟通的原型生成。
  • 结合低代码平台的 UI 设计生成。
  • 结合 IDE 插件的 UI 代码生成。
  • 考虑到前端需求的复杂式,显然如果能从第二种场景入手会更容易,而场景三更适合于新手学习和使用框架、开发人员使用新框架。

    3. 线上故障定位和问题解决

    线上问题修复。在没有生成式 AI 之前,传统的判定式 AI 已经能实现大量的自动化。常规应用程序性能监控(APM)工具,可以从线上运行时报的错误,映射到对应的出错代码。PS:再结合需求与代码的关联信息,我们可以准确推断出哪次需求变更造成的影响。在有了生成式 AI 之后,线上的问题可以直接转换为问题的修复 PR,辅助你修复问题,诸如于 NewRelic 也有类似的功能上线。

    故障定位。在包含大量子系统(如单个微服务)复杂的系统中,网络与问题的排除变得异常重要。在缺乏工具时,人类也经常在某个丢失关键信息,而 AI 正好可以辅助我们去解决此类问题,诸如于 AWS 的 AI 辅助网络故障排除。

    考虑到我只是 Dev 领域的专家,而非是 Ops 领域的专家,也不能解读出更多了。

    4. AI 应用的 DevOps 设施

    现如今已经有大量的线上应用引入了 AI 能力,诸如于星巴克推出的换脸活动等等,这一类的 AI 应用引入了一系列的 AI 基础设施。因此,对于中大型组织来说 ,除了考虑合适的私有化部署模型,还需要构建快速的 AI DevOps 基础设施,以作为支撑。

    除了大模型本身的各类监测之外,我们还需要模型本身的运营成本 —— 特别是当你调用第三方 API 之后,以构建更好的 AiBizDevFinGitSecOps 体系(🐶🐶🐶🐶)。自然而然的,我们需要有一个 AI 对您的 AI + Finance 进行建议,诸如构建缓存机制、 Prompt 长度优化等等。

    5. 辅助决策的知识管理

    知识管理在过去的是一个头疼的问题,现在变成了一个全身疼的问题(暂时想不到更好的词)。相信各位读者已经非常理解生成式 AI 了:

    • 如果你不给他足够的信息,它生成的结果能不能接受要靠运气。
    • 如果你给他足够的信息,它总会忽略一些重要的信息,以让你生气。

    不管气不气的,当你开始思考落地的时候,就会开始假设:当我有一个架构规范的时候,生成式 AI 可以辅助会做架构决策。然后,你会发现找不到一个符合要求的架构规范。相似的,在其他的场景之下,也有类似的问题。

    PS(歪个楼):所以,你应该考虑到知识管理的优先级也提上去,这样当你和领导汇报的时候,就可以合理的甩锅了。

    6. 从单角色辅助到端到端辅助

    事实上,上述的大部分内容都是关于 AI 如何从单角色辅助转换为端到端辅助,只是需求从不同的场景出发。

    端到端辅助的难点并非工具或者 prompt 本身的设计难问题,而是流程、规范是否实施到位。如果流程与规范本身存在问题,那么就需要从不同的场景出发,探索是否存在更合适的策略。

    其它以及 AI 的总结

    当然了,还有过去我们讨论的即时辅助问题修复等等 AI 辅助研发场景。

    这篇文章展望了 2024 年 AI 辅助研发的趋势,特别强调了 AI 技术从简单辅助单一角色向端到端辅助的发展。作者首先提及了研发数字化在AI应用中的重要性,并指出了标准化和知识管理的挑战。然后,他详细介绍了六大趋势:

  • 从单角色辅助到端到端辅助:AI 技术不再局限于单一角色的辅助,而是扩展到整个研发流程的各个环节。
  • 辅助决策的知识管理:AI 在知识管理方面的应用变得更加重要,但也面临着信息不完整和信息选择的问题。
  • AI 应用的 DevOps 设施:AI 应用的引入需要建立适应性强的 DevOps 基础设施来支撑其运行和监控。
  • 线上故障定位和问题解决:AI 在线上故障定位和问题解决方面的应用也逐渐成熟,能够帮助快速定位问题并提供解决方案。
  • AI辅助UI设计的涌现:AI 在 UI 设计方面的应用呈现出多种形态,包括辅助需求沟通、低代码平台的 UI 设计生成以及 IDE 插件的 UI 代码生成。
  • 代码翻译与系统间翻译:AI 在代码翻译和系统间翻译方面的应用逐渐成熟,特别是在遗留系统迁移和系统间功能迁移方面的表现。
  • 文章最后提到了即时辅助问题修复等其他AI辅助研发场景,并总结了端到端辅助的难点在于流程和规范的实施。

    相关文章

    JavaScript2024新功能:Object.groupBy、正则表达式v标志
    PHP trim 函数对多字节字符的使用和限制
    新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
    使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
    为React 19做准备:WordPress 6.6用户指南
    如何删除WordPress中的所有评论

    发布评论