Blog

Blog

PHODAL

如何构建全流程辅助的 AI4EE 能力:从 Team AI 到企业级 AI 辅助研发的思考?

AI4EE是指 "AI for Engineering Efficiency",即应用人工智能(AI)技术来提升工程效能。AI4EE 旨在利用 AI 技术来改善工程领域中的各个方面, 包括设计、需求、开发、测试和维护等环节,以提高工程过程的效率、准确性和可靠性。

年前,我们分析、调研了大量国内外 DevOps 工具链企业的 AI 采用点,思考 2024 的总体趋势, 即《2024 年 AI 辅助研发趋势预测》。从趋势上来看,领先的企业 已经在探索和构建端到端的 AI 辅助研发能力,相似的,我们也在 UnitMesh 开源方案中融入了一部分的思考。

在去年,我们便开始推荐,采用类似于《Team AI:简化繁琐日常任务,打造团队智能协作 》来提升团队的 开发效率,而在今年,越来越多的企业开始关注于如何构建全流程辅助的 AI4EE 能力。

引子 1:AI 打造研发数字化,重塑 DevOps 流程

尽管,大量的生成式 AI 工具厂商依旧在和企业鼓吹,生成式 AI 可以提升研发人员 40+% 的效率,但是,我们发现,企业对于生成式 AI 的需求已经发生了变化。 大量地研发负责人,不再是追求 “弯道超车”,而是寻找更好地落地场景 —— 诸如于改善流程的规范性, 提升过程指标。 此外,由于大量通用的生成式 AI 工具,缺乏企业的领域知识、 业务上下文与开发流程,往往很难达到预期的效果。

从 BizDevOps 的流程来看,生成式 AI 产生的价值点,主要集中在:

  • 需求与方案设计。基于知识库代码库的(两者不可或缺)智能业务辅助分析,如果缺少其中一项,很难达到预期效果。
  • 辅助架构分析与设计。基于架构规范架构资产代码库的架构辅助能力,即不仅仅是生成,还需要考虑到系统的现状与企业的情况。
  • 代码生成。基于内部规范化的代码库代码规范的代码生成,即结合组织内部的框架、规范与代码库,生成符合企业标准的代码。
  • 测试辅助。基于规范化的测试用例测试库的测试辅助能力,结合已有的良好的测试用例作为模板,生成符合企业标准的测试用例。
  • 开发实践辅助。诸如于代码评审、代码重构等辅助能力,都需要即结合已有的代码库代码规范,辅助开发人员进行代码评审、重构等工作。
  • 辅助问题排查。基于问题库日志库代码库的问题等作为上下文,辅助开发人员进行快速分析与问题排查。
  • ……

尽管在不同领域有所差异,但是基本要素是相似的:

  • 流程 - 知识流转的规范化流程。
  • 知识 - 研发资产管理与知识显性化。
  • 示例 - 团队实践与规范作为示例。
  • 工具 - 业务上下文与代码上下文的动态结合。

也因此,我们一直在强调的是研发数字化的重要性,即通过数字化的手段,将研发流程、研发知识、研发资产等数字化、平台化,以便于 AI 辅助研发。

引子 2:基于 AI4EE 流程的 Prompt 示例

在我们开源的 IDE 插件 AutoDev 中,便是通过自定义能力将 DevOps 过程中的知识、规范、示例、工具等进行了数字化,以便于进行更好的 AI 辅助研发。 由于短期内,多数企业并不会改善软件开发流程,因此更多的是结合现有的流程来引入生成式 AI。而为了提升 AI 辅助研发的效果,我们需要构建精准的 AI 上下文能力。

诸如于在 AutoDev 中,生成提交、文档等内容的 prompt 会分为三部分:

  • 浓缩的最佳实践。诸如引入 Conventional Commits 作为提交规范的基础,根据场景压缩提示词。
  • 历史示例。即根据历史提交、文档等内容,与最佳实践的示例作为参考。
  • 技术与业务上下文。即根据当前的业务上下文,即结合提交信息规范,构建更加精准的提示。

所以,在不同的阶段需要的 Prompt 也是不同的,它需要融合对应的知识、示例,并构建高效的 prompt 生成策略,与工具进行整合,才能实现真正的效能提升。 上述的 prompt 也就要求了,AI4EE 的企业需要具备上述的四项要素。

引子 3:软件开发中的知识切片化

在编写时,我们会关注于自顶向下的设计,从顶层的架构知识、编码知识、最佳实践等,逐渐切片化到代码层面。 诸如于,在设计 AutoDev 的 AutoCRUD 功能时, 会根据需求与方案设计的知识库与代码库,自动编写 Controller、Service、Repository 等代码。而由于生成式 AI 的能力限制,在这个过程中,我们会发现:

  • 业务上下文的动态切片化。即有些需求信息,并不需要后端开发人员关注,而有些则需要关注。
  • 每个阶段需要的知识是不同的。诸如于 Controller 与 Service 的知识是不同的,有对应的编码规范、最佳实践等。
  • 代码关键知识的提取。为了自动生成 Controller 代码,需要知道现有 Controller,以及对应的 Service、Repository 等代码。
  • ……

所以,为了达到这样的效果,架构规范、编码规范、最佳实践等知识需要动态结合到 AI 工具中,即结合 RAG(检索增强生成)技术或者手动配置的方式, 以便于生成更加符合企业标准的代码。

除了从现有的代码库提取作为示例之外,现有的架构规范等也需要重新思考如何动态切片化,以便于 AI 工具进行更加精准的生成。

企业级 AI4EE 能力构建

AI4EE是指 "AI for Engineering Efficiency",即应用人工智能(AI)技术来提升工程效能。AI4EE 旨在利用 AI 技术来改善工程领域中的各个方面, 包括设计、需求、开发、测试和维护等环节,以提高工程过程的效率、准确性和可靠性。

基于上述的思考,从工具与平台构建的角度来看,AI4EE 的企业需要具备的四项要素,即:

  1. 流程:知识流转的规范化流程
  2. 知识:研发资产管理与知识显性化
  3. 示例:团队实践与规范作为示例
  4. 工具:知识、实践与、规范到代码的动态结合

也就是前面我们提到的,构建精准结果所需要的上下文能力。

1. 流程:知识流转的规范化流程

结合与诸多企业的交流,我们不得不强调:数字化是应用生成 AI 的一个重要前提,即企业需要具备一定的 DevOps 成熟度,简单来说就是规范化的流程。 在此基础上,生成式 AI 才能发挥更大的潜力。 而对于这个过程中,还有一个点不得不强调的是:知识的流转。

在企业走向 DevOps、云原生的阶段时,不同的工具、实践与知识是处于不同的部门、开发团队中的。而在结合生成式 AI 时,则需要重写现有的工具,我们便需要 思考如何在不同的部门、开发团队间,将所需要的上下文知识在不同的工具中传递。

即:过去我们传递的是数据,现在我们需要传递数据 + 知识。诸如于:

  • 当测试人员在使用 AI 编写测试用例时,需要知道当前的需求、方案设计、架构设计等信息,以便于 AI 辅助进行测试。
  • 当开发人员在使用 AI 修复 bug 时,需要自动获得关键的日志、问题信息、复现步骤等,以便于 AI 辅助问题排查。
  • ……

我们不但需要考虑到数据的流转,还需要考虑到知识的流转,也就是在先前《LLM 应用架构设计原则》 中提到的知识的语言接口。

2. 知识:研发资产管理与知识显性化

受降本增效的影响,由我们 Thoughtworks 开源的架构治理平台 ArchGuard 也越来越受到企业的关注,以将组织现有的系统资产可视化。

即,大量的企业还没有将研发资产管理,并将架构进行显性化,而这也是生成式 AI 的一个重要前提。而在构建 ArchGuard 的治理功能时,我们的一个核心思考是: 架构规范显性化、工具化。即将架构知识显性化到工具中,以便于进行规范化的检查, 以减少人工的规范化检查。

相似的,如果我们想提升 AI 的落地效果,我们第一步要强化企业的知识体系,显性化高价值的知识,结合到工具中,以便于 AI 辅助研发。诸如于,在 AutoDev 中, 我们会构建了可配置化的 Dockerfile、CI/CD 脚本生成能力,以便于将企业的最佳实践、规范化流程显性化到工具中。同时,将一些通用的规范也显性化到工具中, 诸如于上述的提交规范、文档规范等。

3. 示例:团队实践与规范作为示例

在实际项目中,每个团队受限于发布节奏、人员能力、技术栈等因素,都会有自己的一套最快实践。它往往与企业的规范化流程有所差异,但是它是最适合团队的, 这种模式也被各个组织所认可。

作为工具的开发者,我们需要尊重团队已有的实践,而不是使用生成式 AI 强制性的规范化。因此,在构建工具时,需要从现有的实践中提取示例,以便于生成式 AI 理解团队的 “最快实践”。

典型场景示例:

  • 代码注释生成。从现有的代码库中提取注释作为示例,作为提示词的一部分。它也意味着,我们先前的代码库中的注释是有价值的。
  • 提交信息生成。结合现有的提交信息规范,提取现有的提交信息作为示例。
  • ……

在现有场景下,不改变团队现有实践的情况下,才能实现更有用的 AI 生成。

4. 工具:知识、实践与、规范到代码的动态结合

去年国外的 JetBrains 与其它厂商的 AI 调查报告中,免费可用 ChatGPT 是国外开发者最常用的 AI 工具之一,GitHub Copilot 排在其后。而 ChatGPT 的机制,使得我们需要准备大量的上下文,以便于 ChatGPT 生成更加精准的结果。所以,人们即觉得 ChatGPT 很强大,也觉得它很弱。

而为了改善这一点,我们需要将知识、实践与规范动态结合到代码中,以便于 ChatGPT 生成更加精准的结果。诸如于:

  • 生成测试时,需要结合开发框架的依赖信息、被测试的代码信息、测试用例的规范等,以便于生成更加精准的单元测试。
  • 编写需求时,需要构建语义化的代码搜索能力,以获取现有的需求信息。
  • ……

与此同时,我们还需要关注于不破坏现有的实践、工具,将 AI 工具与现有的工具进行整合,提升使用频繁,改善 AI 的落地效果。

最后,值得一提的是 开发者体验 也是 AI4EE 的一个非常重要的方面,让开发者更加高效地使用 AI 工具,以提升工程效能。

总结

尽管,我们可以看到生成式 AI 在起草文档、编写代码、生成测试用例等方面的潜力,但是,我们依旧要有很长的路要走。特别是,大量的企业和我一样处于没有 卡可用的阶段,如何平衡敏感信息与 AI 工具的使用,是一个非常重要的问题。

最后,AI4EE 是一个非常大的领域,它涉及到了工程的各个方面,我们仍然需要不断地探索、实践,以提升工程效能。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签