PS：本文节选自开源电子书《AI 辅助软件工程：实践与案例解析》第一部分《AI4SE 体系设计》（https://aise.phodal.com/design-aise.html）
受限于自身企业的规模与人员结构，AI 辅助软件工程（AI4SE）的设计与实施过程会有所差异。诸如于：
研发外包型企业，对于 AI 辅助研发的需求并没有特别强烈？（待进一步调研）
小型研发组织，生存是主要问题，因此对于数据敏感度不高，可以采用 SaaS 方案；当团队中出现能力较强的人员时，会基于开源工具进行简单的开发。
中大型研发组织，对于数据敏感度较高，因此会选择自建 AI4SE 体系，以保证数据的安全性。
结合我们在其它组织的经验，以及 ChatGPT 给我们的建议，可以得到以下的 AI4SE 体系设计流程：
初步明确 AI4SE 设计目标：确定通过 AI 实现的可落地目标，如提高开发效率和提升代码质量。
识别痛点和需求：评估当前软件工程流程中的痛点和瓶颈。
选择合适的AI技术：根据业务需求选择合适的 AI 技术，如机器学习、深度学习、自然语言处理等。
构建跨学科团队：组建包含数据科学家、AI 工程师、软件工程师和业务专家的团队，并提供AI相关培训。
开发原型与集成：开发和测试 AI 应用的原型，并将有效模型集成到现有工具链中。
逐步实施与评估：采用小规模试点逐步扩大的策略，并定期评估体系绩效，使用关键绩效指标进行衡量。
持续改进与技术更新：收集用户反馈，持续优化工具和指标，并跟踪引入最新技术和工程方法。
除此，设计适合自身公司的 AI4SE 体系是一项复杂且难度极大的工作。这一过程需要综合考虑公司的具体情况、业务需求以及现有的资源。
尽管生成式 AI 技术在软件工程领域的应用已经取得了显著进展，但在实际应用中，AI 技术的效果并不总是如人们所期望的那样。诸如于：
环境适配问题。生成式 AI 可以根据一张图片生成前端代码，但由于每个企业内部使用的前端框架、组件库等不尽相同，生成的代码往往无法直接在实际项目中使用。这意味着，生成式 AI 必须考虑到不同组织的技术栈和环境需求，才能真正发挥其作用。
代码质量不稳定。由于生成式 AI 的固有限制，生成的代码质量并不总是稳定或符合最佳实践标准。在实际应用中，人工审核和质量保证仍然是必不可少的。这种人机协作的方式可以弥补 AI 的不足，确保代码的可维护性和可靠性。
能力限制。生成式 AI 更擅长生成新的代码，而不是修改现有的代码。这意味着在处理现有系统的维护和升级时，生成式 AI 的作用可能有限。因此，AI 需要具备与现有代码库互动的能力，才能在实际应用中提供更大的价值。
上下文理解不足。生成式 AI 在生成代码时，常常无法充分理解项目的整体上下文或业务逻辑。这种上下文理解的不足，可能导致生成的代码与项目 AI 需要适当补充背景信息，才能更好地满足项目的实际需求。
复杂任务处理能力有限。尽管生成式 AI 在简单的编码任务上表现出色，但在处理复杂的系统设计、架构决策或多模块集成时，其能力仍然有限。面对这些高复杂度的任务，生成式 AI 可能需要更多的人工干预与支持。
……
除此，AI4SE 的设计目标还应该考虑到企业的具体情况和需求。例如，对于一家初创公司来说，提高开发效率和降低成本可能是首要目标；而对于一家传统企业来说，提升软件质量和可维护性可能更为重要。
小型研发团队：提升开发人员体验 or 改善流程规范？
对于小型研发规模的组织来说，ROI 是一个重要的考量因素 —— 与规模化提升效率相比，提升开发人员的体验是一个更合适的目标。也因此，直接采用现有的 SaaS 服务是一个更为经济的选择，结合一些 “免费” 的 AI 工具，并 提供一些内部的培训和文档，就可以实现部分 AI4SE 的关键目标。
同时，在这一阶段，我们可以通过分析现有的 AI4SE 相关工具，来了解市场上的最新技术和趋势。诸如于，我们先前分析的一些工具链示例：
除此，由于小团队并没有规范的流程，在关键环节上可能是缺乏的，到底是结合 AI 来引入流程，还是放弃某个流程，是一个需要考虑的问题。除此，由于过往缺少 相关的规范，AI 并不定带来很大的受益，还可能会带来额外的成本。
中大型研发团队：提升软件质量 or 降低流程成本？
对于中大型研发规模的组织来说，由于企业已经有成功的商业运营模式，与提升开发效率相比，提升软件质量和降低流程成本是更为重要的目标。毕竟，在过去的几十年间， 大量的企业在迭代自己的软件工程，从瀑布、敏捷到 DevOps，形成了一系列经典的工具和流程方法。
对于质量要求高的组织来说，软件质量远比开发效率更为重要。
对于流程成本高的组织来说，流程才是限制开发效率的瓶颈。
对于大型系统来说，沟通成本和协作成本是更为重要的问题。
……
尽管，我们会统一来看待大型组织中的 AI4SE 体系设计，但是实际上，每个组织所考虑的首要问题是不同的。我们应该根据企业的具体情况和需求，来确定我们的目标？
服务型团队：改善开发体验 or 提降低迁移成本？
除此，我们还需要考虑到团队的结构和组织文化带来的影响。诸如于，团队的拓扑结构会影响到团队的目标：
对于诸如平台型团队、SaaS 企业、云服务提供商等服务型团队来说，他们的目标可能是：
降低用户的迁移成本：诸如结合平台的特性，构建结合 AI 的迁移工具，以降低用户的迁移成本。
提升开发人员的体验：构建辅助编码、部署等相关的 AI 工具，以提升开发人员的体验。
提供基于平台的知识问答：降低用户的学习成本、知识负载。
……
当然可能还存在其它类型的团队，受限于笔者的经验，这里不再一一列举。
通常来说，目标是分为多级的，类似于 OKR 的自上而下的目标设定。在 “初步明确 AI4SE 设计目标” 中指的是由高层决策者确定的目标，而在这里， 通常是真正的痛点和需求，需要由组织的中层管理者，诸如研发效能/工程效能团队等来确定。当然了，再往下，就是由团队的一线开发人员来确定，诸如更详细的 实施细节和指标等。
基于软件生命周期分析/DevOps 流程分析
当企业构建成熟的 DevOps 流程时，AI4SE 的实施会更加顺利。下图是，Thoughtworks 在 2023 年初对 AI 辅助软件工程的流程分析，即在软件开发的不同阶段，AI 可以提供哪些辅助功能：
我们就可以探索如何在不同阶段使用 AI 工具，而在这时需要不同的角色参与到这个过程中，以确保我们设计出来的体系符合不同角色的需求。例如：
产品经理：在需求分析和项目规划阶段，AI 可以帮助自动生成需求文档，或进行需求优先级排序。
开发人员：在编码和测试阶段，AI 工具可以辅助代码生成、代码审查以及自动化测试。
运维人员：在部署和监控阶段，AI 能提供智能化的日志分析、自动化故障排除和性能优化建议。
……
而随着我们探索的进一步深入，可以建立多阶段协同的 AI4SE 体系，如：AI 根因分析时能自动修复代码问题。
基于数据分析与识别
市面上已经有大量的关于软件工程效率和 AI 相关的数据分析报告，诸如于 JetBrains 和 GitKraken 的 2024 State of Git Collaboration 年度报告，会指出：
较小的团队通常在敏捷性和满意度方面表现优于较大的团队。
团队成功的关键似乎在于团队成员数量与任务管理之间的平衡。
而其中会发现团队在上下文切换、不明确的优先事项和无效会议等方面存在问题，导致浪费时间和精力，真正在编码的时间不到总工作时间的 40%。
Context Switch
除此，再加上不明确的优先事项，使开发人员不确定哪些任务需要立即关注，这些陷阱可能会创造一个充满挑战的工作环境。为了解决这些问题，团队应实施清晰的沟通渠道，以减少上下文切换的需求，并简化会议议程，以确保每次会议都有明确的目的和清晰的结果。
"上下文切换、不明确的优先事项和那些永无止境的会议。它们感觉像是烦恼，而 GitKraken 的这份报告有数据证实它们确实是烦恼。作为开发人员和开发团队， 是时候寻找匹配我们需求的工具和工作流程，消除让我们不开心的噪音。进入状态，构建出色的软件！" —— GitKraken CEO：Matt Johnston
通过识别这些痛点并针对性地引入 AI4SE 工具和流程优化，团队可以显著提升工作效率和满意度，为构建更高质量的软件奠定基础。
在原型开发阶段，可以尝试不同的 AI 技术，如机器学习、深度学习、自然语言处理等，以确定最适合公司需求的技术。而在实际应用中，需要考虑 AI 模型与基础设施的集成、数据安全性、模型解释性等因素。
结合内部技术栈
由于，大量的 AI 科研人员使用的是 Python 语言，已经有大量的 AI 开发框架和基础设施， 因此人们喜欢优先考虑 Python 作为 AI 开发语言。这种趋势也从科研和一些基础设施影响到了应用层。如在 2023 年，Python 生态下的 LangChain 和 LlamaIndex 是人们构建生成式 AI 的两个主要框架。
回到企业应用开发时，可能更倾向于使用 Java、C++ 或其他语言。诸如于我们在设计 Unit Mesh 相关开源方案时，由于内部大量的基础设施是建立在 JVM 上，因此我们选择了 Kotlin 作为主要的开发语言，开发了对应的 LLM 开发框架 ChocoBuilder，以支持 AI 模型的快速构建。如今不同的语言也有不同的 LLM 开发框架，如：Spring AI 等。
在典型的向量数据库层面，没有技术栈限制的组织，可以灵活地选择新的向量数据库，如：Milvus、Qdrant 等，以支持 AI 模型的快速检索。而有技术栈限制的组织， 往往会结合过往的技术栈，如支持向量搜索的 ElasticSearch 版本，PostgreSQL + pgvector 等。
采用主流 AI 工具的技术栈
在另一方面，我们注意到，国内的AI辅助编程工具，早期大多采用与 GitHub Copilot 类似的技术栈、算法和交互方式。许多领先的AI辅助编码工具，在代码分层、 文件命名以及变量命名等方面，都展现出高度的相似性，其精细程度，宛如天工。
考虑到在这些 AI 辅助研发领域，诸多东西都是相似的，我们可以参考主流的技术栈实现与实现思路：
结合 TF/IDF 或者 BM25 算法改进代码检索的效果，提高代码检索的准确性。
采用 Jaccard 相似度算法，提高代码相似性检测的效果。
使用 TreeSitter 或者 AST 技术，进行语法分析，以构建更好的交互体验。
……
只是呢，算法、工具和技术栈等都存在学习成本，还需要结合团队的实际情况，选择合适的 AI 技术。诸如：Continue.Dev 采用 Javascript + WASM + LanceDB 作为本地向量技术栈， 而通义灵码采用的是 RocksDB 作为本地向量技术栈。
在构建 AI4SE 体系时，跨学科团队的协作至关重要。AI 工程师与数据工程师通常在算法设计、模型训练和数据处理方面具有专长，但他们可能不熟悉软件工程的最佳实践、 架构设计和代码维护。而软件工程师则在构建可靠、高效的软件系统方面有丰富的经验，但在 AI 模型的开发和调优方面可能缺乏深入的了解。
跨学科团队
创建一个跨学科团队，结合两者的优势，是成功实施 AI4SE 体系的关键。：
互补能力：通过培训和知识共享，让团队成员了解彼此的工作领域。AI 工程师可以学习基本的软件工程原则，而软件工程师可以学习如何利用 AI 工具和模型。
协作工具：使用协作工具和平台，如知识库和实时协作软件，帮助团队成员共享信息和进展。
定期沟通：定期组织团队会议，确保每个成员都能了解项目的整体进展，及时解决跨学科合作中的挑战。
当然了，如果能定期与其它团队进行交流，也是非常有帮助的。诸如于我们在 Thoughtworks 的开源项目中，我们会定期与其它团队进行交流，以了解其它团队的 AI4SE 体系设计，以及其它团队的 AI4SE 体系设计的优势和不足。
相似的，构建这种跨团队的激励机制和协作，也是另外一个非常大的挑战。
软件工程是 AI4SE 的基础
笔者作为一个典型的工程师，会更倾向于认为软件工程是 AI4SE 的基础。理解软件工程的基本原则和最佳实践，是这个团队必须要具备的能力。诸如，你需要理解
开发人员如何编码测试，才能设计好 AI 生成测试。
团队中的人员能力差异，以设计适合不同梯队的功能需求。
软件开发的编码规范与习惯，以设计出规范化的代码生成。
理解如何编码，以在 IDE 的不同触点上提供 AI 功能。
……
诸如此类的还有开发人员的日常工作流程、代码审查、代码合并、代码测试等是如何进行的，这些都是 AI4SE 体系设计的基础。尽管，你可以通过对开发人员进行 访谈、观察开发人员的日常工作流程等方式，来了解这些基础知识，但是，如果你自己不具备这些基础知识，那么你很难设计出一个符合实际需求的 AI 工具。
一个早期可工作的原型是整个体系的关键，它可以帮助团队快速验证可行性，并决定下一步的发展方向与资源的多少。通常来说，在当前阶段，我们可以看到诸多 企业会基于市面上开源的成熟或者半成熟的 AI4SE 工具，进行原型开发。
基于开源软件构建原型：AutoDev 示例
我们在 2023 年的早期构建了开源的 AI 辅助研发工具 AutoDev，作为国内首个开源的 AI 辅助研发方案。通过 GitHub 的 issue，我们看到了大量的企业和团队基于其进行原型开发：
结合免费的 SaaS/MaaS 服务，以让自己有一个 “免费” 的 AI 编码助手。
使用 Ollma 在本地运行 LLM，以探索 AutoDev 的能力。
在企业内部部署 One API 服务，以试验不同的模型在实际项目中的效果。
基于 AutoDev 定制，以满足特定的业务需求。
……
类似的，我们也可以在企业内部以相似的方式，基于市面上的开源工具，进行原型开发。
构建适合原型开发的 SDK
我们在设计 LLM 开发框架 ChocoBuilder 时，构建了一系列帮助开发人员快速构建原型的能力， 以验证 AI 模型在实际项目中的应用效果。如下是 ChocoBuilder 构建 RAG 的示例：
在这个示例中，我们使用 RAG 脚本将文档内容分块并进行索引，然后通过查询相关内容，展示了如何在开发环境中快速测试和集成 AI 功能。
在企业中，由于多数工具团队在过往有失败的工具推广经验，所以在推广工具时，往往会采用渐进式的策略，以有效降低风险，并使团队能够逐步适应新技术。也因此， 如何设计合理的度量体系来监控和评估 AI4SE 的效果是至关重要的。
通常来说，我们会关注于以下几个方面：
开发效率：评估引入 AI 工具后，编码速度是否得到了提高，例如，代码接受率、代码入库率、响应时间等。
代码质量：使用静态分析工具和代码审查来衡量 AI 生成代码的质量，评估 AI 生成质量和代码可维护性。
用户满意度：收集开发团队对 AI 工具的使用反馈，分析其在实际工作中的体验和效果。
功能使用频次：监控不同 AI 功能的使用频次，了解团队对 AI 工具的偏好和需求。
业务指标：通过业务关键绩效指标（KPI）来衡量其对整体项目进展和成功率的影响。
……
需要注意的是，由于统计口径上的差异，会导致不同的度量体系下的同一个指标有不同的结果。诸如于，AI 代码入库率可能会涉及到 3、 5、10 分钟内的代码变更， 又或者是用户无操作等不同口径；代码接受率会受到语言因素影响较大，如有的模型 Python 代码接受率可能会高于 Java 代码接受率，而静态类型语言的代码接受率 远高于动态类型语言。
这些指标都需要在初步运行后，根据团队的实际情况进行调整，以确保度量体系的有效性和可靠性。
AI 技术在过去的一年里发展迅猛，新的 AI 工具和模型不断涌现，为软件工程带来了更多的可能性。这也是笔者构建《AI 辅助软件工程：实践与案例解析》（https://github.com/phodal/aise ）这个开源项目的原因之一。
对于企业来说也是相似的，我们还需要：
反馈回路：建立高效的反馈回路，收集团队对 AI 工具和模型的使用体验，及时调整和优化。
技术跟踪：定期更新和引入新技术，保持体系的竞争力。关注业界最新的 AI 发展趋势，并评估其在现有体系中的适用性。
培训与支持：为团队提供持续的培训，帮助他们跟上技术更新，确保团队始终具备必要的技能来使用和维护 AI4SE 体系。
此外，还应该提供以下支持：
建立支持渠道：确保团队成员在遇到问题时能够及时获得帮助，可以是通过内部的交流群组、论坛或者专门的 support team。
鼓励知识分享：定期组织知识分享会，鼓励团队成员分享他们的经验和学习心得。
跟踪技术进展：持续关注 AI 领域的最新进展，通过内部研讨会或外部培训，让团队成员了解最新的技术动态。