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 会分为三部分：

浓缩的最佳实践。诸如引入 Conventional Commits 作为提交规范的基础，根据场景压缩提示词。

历史示例。即根据历史提交、文档等内容，与最佳实践的示例作为参考。

技术与业务上下文。即根据当前的业务上下文，即结合提交信息规范，构建更加精准的提示。

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

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

业务上下文的动态切片化。即有些需求信息，并不需要后端开发人员关注，而有些则需要关注。

每个阶段需要的知识是不同的。诸如于 Controller 与 Service 的知识是不同的，有对应的编码规范、最佳实践等。

代码关键知识的提取。为了自动生成 Controller 代码，需要知道现有 Controller，以及对应的 Service、Repository 等代码。

……

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

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

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

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

流程：知识流转的规范化流程

知识：研发资产管理与知识显性化

示例：团队实践与规范作为示例

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

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

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

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

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

当测试人员在使用 AI 编写测试用例时，需要知道当前的需求、方案设计、架构设计等信息，以便于 AI 辅助进行测试。

当开发人员在使用 AI 修复 bug 时，需要自动获得关键的日志、问题信息、复现步骤等，以便于 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 是一个非常大的领域，它涉及到了工程的各个方面，我们仍然需要不断地探索、实践，以提升工程效能。