AI4EE是指 "AI for Engineering Efficiency",即应用人工智能(AI)技术来提升工程效能。AI4EE 旨在利用 AI 技术来改善工程领域中的各个方面, 包括设计、需求、开发、测试和维护等环节,以提高工程过程的效率、准确性和可靠性。
年前,我们分析、调研了大量国内外 DevOps 工具链企业的 AI 采用点,思考 2024 的总体趋势, 即《2024 年 AI 辅助研发趋势预测》。从趋势上来看,领先的企业 已经在探索和构建端到端的 AI 辅助研发能力,相似的,我们也在 UnitMesh 开源方案中融入了一部分的思考。
在去年,我们便开始推荐,采用类似于《Team AI:简化繁琐日常任务,打造团队智能协作 》来提升团队的 开发效率,而在今年,越来越多的企业开始关注于如何构建全流程辅助的 AI4EE 能力。
尽管,大量的生成式 AI 工具厂商依旧在和企业鼓吹,生成式 AI 可以提升研发人员 40+% 的效率,但是,我们发现,企业对于生成式 AI 的需求已经发生了变化。 大量地研发负责人,不再是追求 “弯道超车”,而是寻找更好地落地场景 —— 诸如于改善流程的规范性, 提升过程指标。 此外,由于大量通用的生成式 AI 工具,缺乏企业的领域知识、 业务上下文与开发流程,往往很难达到预期的效果。
从 BizDevOps 的流程来看,生成式 AI 产生的价值点,主要集中在:
尽管在不同领域有所差异,但是基本要素是相似的:
也因此,我们一直在强调的是研发数字化的重要性,即通过数字化的手段,将研发流程、研发知识、研发资产等数字化、平台化,以便于 AI 辅助研发。
在我们开源的 IDE 插件 AutoDev 中,便是通过自定义能力将 DevOps 过程中的知识、规范、示例、工具等进行了数字化,以便于进行更好的 AI 辅助研发。 由于短期内,多数企业并不会改善软件开发流程,因此更多的是结合现有的流程来引入生成式 AI。而为了提升 AI 辅助研发的效果,我们需要构建精准的 AI 上下文能力。
诸如于在 AutoDev 中,生成提交、文档等内容的 prompt 会分为三部分:
所以,在不同的阶段需要的 Prompt 也是不同的,它需要融合对应的知识、示例,并构建高效的 prompt 生成策略,与工具进行整合,才能实现真正的效能提升。 上述的 prompt 也就要求了,AI4EE 的企业需要具备上述的四项要素。
在编写时,我们会关注于自顶向下的设计,从顶层的架构知识、编码知识、最佳实践等,逐渐切片化到代码层面。 诸如于,在设计 AutoDev 的 AutoCRUD 功能时, 会根据需求与方案设计的知识库与代码库,自动编写 Controller、Service、Repository 等代码。而由于生成式 AI 的能力限制,在这个过程中,我们会发现:
所以,为了达到这样的效果,架构规范、编码规范、最佳实践等知识需要动态结合到 AI 工具中,即结合 RAG(检索增强生成)技术或者手动配置的方式, 以便于生成更加符合企业标准的代码。
除了从现有的代码库提取作为示例之外,现有的架构规范等也需要重新思考如何动态切片化,以便于 AI 工具进行更加精准的生成。
AI4EE是指 "AI for Engineering Efficiency",即应用人工智能(AI)技术来提升工程效能。AI4EE 旨在利用 AI 技术来改善工程领域中的各个方面, 包括设计、需求、开发、测试和维护等环节,以提高工程过程的效率、准确性和可靠性。
基于上述的思考,从工具与平台构建的角度来看,AI4EE 的企业需要具备的四项要素,即:
也就是前面我们提到的,构建精准结果所需要的上下文能力。
结合与诸多企业的交流,我们不得不强调:数字化是应用生成 AI 的一个重要前提,即企业需要具备一定的 DevOps 成熟度,简单来说就是规范化的流程。 在此基础上,生成式 AI 才能发挥更大的潜力。 而对于这个过程中,还有一个点不得不强调的是:知识的流转。
在企业走向 DevOps、云原生的阶段时,不同的工具、实践与知识是处于不同的部门、开发团队中的。而在结合生成式 AI 时,则需要重写现有的工具,我们便需要 思考如何在不同的部门、开发团队间,将所需要的上下文知识在不同的工具中传递。
即:过去我们传递的是数据,现在我们需要传递数据 + 知识。诸如于:
我们不但需要考虑到数据的流转,还需要考虑到知识的流转,也就是在先前《LLM 应用架构设计原则》 中提到的知识的语言接口。
受降本增效的影响,由我们 Thoughtworks 开源的架构治理平台 ArchGuard 也越来越受到企业的关注,以将组织现有的系统资产可视化。
即,大量的企业还没有将研发资产管理,并将架构进行显性化,而这也是生成式 AI 的一个重要前提。而在构建 ArchGuard 的治理功能时,我们的一个核心思考是: 架构规范显性化、工具化。即将架构知识显性化到工具中,以便于进行规范化的检查, 以减少人工的规范化检查。
相似的,如果我们想提升 AI 的落地效果,我们第一步要强化企业的知识体系,显性化高价值的知识,结合到工具中,以便于 AI 辅助研发。诸如于,在 AutoDev 中, 我们会构建了可配置化的 Dockerfile、CI/CD 脚本生成能力,以便于将企业的最佳实践、规范化流程显性化到工具中。同时,将一些通用的规范也显性化到工具中, 诸如于上述的提交规范、文档规范等。
在实际项目中,每个团队受限于发布节奏、人员能力、技术栈等因素,都会有自己的一套最快实践。它往往与企业的规范化流程有所差异,但是它是最适合团队的, 这种模式也被各个组织所认可。
作为工具的开发者,我们需要尊重团队已有的实践,而不是使用生成式 AI 强制性的规范化。因此,在构建工具时,需要从现有的实践中提取示例,以便于生成式 AI 理解团队的 “最快实践”。
典型场景示例:
在现有场景下,不改变团队现有实践的情况下,才能实现更有用的 AI 生成。
去年国外的 JetBrains 与其它厂商的 AI 调查报告中,免费可用 ChatGPT 是国外开发者最常用的 AI 工具之一,GitHub Copilot 排在其后。而 ChatGPT 的机制,使得我们需要准备大量的上下文,以便于 ChatGPT 生成更加精准的结果。所以,人们即觉得 ChatGPT 很强大,也觉得它很弱。
而为了改善这一点,我们需要将知识、实践与规范动态结合到代码中,以便于 ChatGPT 生成更加精准的结果。诸如于:
与此同时,我们还需要关注于不破坏现有的实践、工具,将 AI 工具与现有的工具进行整合,提升使用频繁,改善 AI 的落地效果。
最后,值得一提的是 开发者体验 也是 AI4EE 的一个非常重要的方面,让开发者更加高效地使用 AI 工具,以提升工程效能。
尽管,我们可以看到生成式 AI 在起草文档、编写代码、生成测试用例等方面的潜力,但是,我们依旧要有很长的路要走。特别是,大量的企业和我一样处于没有 卡可用的阶段,如何平衡敏感信息与 AI 工具的使用,是一个非常重要的问题。
最后,AI4EE 是一个非常大的领域,它涉及到了工程的各个方面,我们仍然需要不断地探索、实践,以提升工程效能。
围观我的Github Idea墙, 也许,你会遇到心仪的项目