在过去数月间，我们持续致力于探究：如何有效运用大型语言模型以增强研发效率？随着研究的不断深入，我们逐渐触及了一些复杂领域，比如：如何更高效地应用 AI 辅助进行架构设计？凭借我们丰富的架构设计与治理经验，我们认识到，开放服务能力是衡量架构优劣的关键指标之一，而 API 则是增强架构开放性及优化对外服务效能的核心途径。

我们之前的观察以及Unit Mesh在编程领域进行的LoRA试验表明，【开源大型语言模型结合LoRA微调】将成为多数企业更倾向于采纳的方案。因此，我们将在此详细阐述：企业应如何建立私有化的API设计能力，以打造更为开放、现代化且高效的架构体系。

传统的API设计弊端

传统的 API 设计往往面临三个挑战：

开放资源的决策过程颇具挑战。这涉及到确定哪些数据和服务应当被开放，以便最大限度地发挥企业的数字化价值并实现其商业转化。

点状需求驱动，导致缺乏全面的设计与规划，API最终演变成了交付成果，而非被视为数字化资产。

制定的标准难以实际执行。特别是在规模较大的研发团队中，技术水平的参差不齐往往会导致API设计所输出的标准存在较大差异。

同时，必须强化技术能力的培养以及知识的交流，以此提升组织内部在 API 设计方面的能力与统一性。

大语言模型友好的 API

在开源大语言模型（LLM）的加持之下，我们可以做到：

汇聚各方智慧以促进情境革新。将各领域已公开的专业知识及实践经验融入语言模型，进而助力发掘适宜的API服务应用场景。

资产建模作为核心驱动力，将研发团队所拥有的经典软件工程资产进行文本化和结构化处理，并将其转化为 LLM 的语料库，以此充分利用现有经验，从而定义出满足服务场景需求的 API。

内建标准设计及交付流程。我们将自然语言所描述的场景与需求，转化为明确的API设计方案，同时融合数据工程与平台工程的技术，不断汇聚整个组织的软件智慧与经验，助力我们打造优质的软件架构。

借助 LLM 的强大功能，我们能够更有效地解决 API 设计过程中的难题，并致力于实现数字化价值的最大化，以及将 API 转化为数字化资产的目标。

于是，我们对 LLM 与 API 的融合应用进行了深入的探讨，在此过程中，揭示了一些颇具启发性的模式。我们将适用于此的 API 模式命名为 LLM 模型友好的 API，其具体定义如下：

LLM友好的API旨在优化对大型语言模型功能的适应与运用，它是一种特定的软件API规范。这种规范的设计旨在简化LLM的指令构建和工具集成。其格式与输入输出需与大型语言模型的对应部分保持一致，确保LLM能更准确地解析输入信息，并生成符合预期的输出结果。

概括而言，需构建一个对大型语言模型（LLM）友好的应用程序编程接口（API）格式，旨在支持LLM的生成与识别功能，从而便于后续的代码自动生成等步骤。

模式：集体智慧飞轮

基于我们对大型语言模型（LLM）的深入理解和持续研究，依托于该模型的免费试用体验及其内在逻辑的解析，我们成功训练出了首个架构辅助设计工具LoRA。同时，我们依据自身的理解，绘制了一条可重复使用的设计流程路径。

在不同的阶段，我们有不同的关注点：

在此阶段，LLM的工程化过程涉及多个领域的复杂数据工程任务。实现这一工程的标准化、促进跨部门间的协作以及不断进行迭代，将成为我们未来面临的新挑战。

以 API 为例，我们将上述的三个阶段分解为六步：

阶段

阶段

针对于不同的场景下，可能略有差异。

三阶六步构建模型友好的智慧飞轮步骤 1：识别软件工程资产

在全面掌握工程流程的基础上，我们应进一步拓展至架构领域，探讨实现途径。首先，我们必须明确：确定软件工程资源。这涉及在着手实现目标之前，对现存的软件工程流程和其产生的资源，如文件、代码、测试案例等，进行梳理与认知，以便更有效地运用这些资源，并与大型语言模型相结合，从而提高研发效能。

在这个阶段，我们采用了经典的用户旅程分析方法：

上图中，包含了五个要素：

工序化，换言之，在理想状态中，对于API设计的整个生命周期，其流程应当是怎样的？

工艺现状。我们的现状现在是怎样的？

痛点问题。过程中，不同角色的主要痛点是什么？

工艺改进。如何针对于上述的痛点进行改进？

资产沉淀。过程中会产生哪些关键产出（软件工程资产）？

紧随其后，针对我们所创造的软件工程资源，我们将着手开展基于LLM的微调试点及深入研究。

在LLM赋能的API全生命周期管理中，我们确立了以下四个核心要素：API的规范与架构设计、针对软件的详细需求（即用户故事）、特定领域的模型构建以及API规格说明。

步骤 2：针对资产的 “语言建模”（格式化输出）

大语言模型本质上是文本形式，因此我们必须对现有的架构资源实施“语言建模”操作intellij idea uml，这实际上意味着对文本进行结构化处理，将其转化为一种特定且便于阅读与解读的格式，即所谓的领域特定语言（DSL），例如表格、UML等。

在同一情境中，我们期待 LLM 能够输出特定格式的数据，以便我们将其整合进工具使用。尽管缺乏可靠证据表明：在语料收集阶段，该格式作为数据来源，但从其频繁输出的结构以及呈现效果来看，这无疑是一种对 LLM 适应性较强的格式。例如：

随后，我们定义了 API 的 “语言模型”：

与常规表格相比，差异显著。然而，值得注意的是，我们在处理error时，采用了类似JSON的格式来进行表达。

此处一个至关重要的环节在于，需构建一个针对该特定格式的验证工具，如此一来，一旦出现错误，便能够重新尝试，从而有效提高数据质量并减少错误发生的概率。

步骤 3：MVP 微调试验

在开始训练之前，我们必须搜集必要的数据资料。对于目前使用的语言模型，我们一般会采用类似于“输入”这样的结构。此外，这一过程通常由人工操作或借助现有的AI应用程序来协助完成。

出自《A of Large 》

在进行 MVP 阶段数据处理时，可以考虑多种方式结合：

如下是我们根据 、 创建数据集的过程：

微调往往不能一蹴而就，我们需借助self-模式来构建若干通用指令。然而，鉴于众多企业均拥有AI领域的专业人才，他们或许能更有效地解决这一问题。

步骤 4：设计增量引导指标

为了对微调与训练成效进行衡量，我们必须打造一个基于增量引导的评估标准。在人工智能编程界，开放的数据集恰好提供了一个极具参考价值的范例。

自动对代码示例进行单元测试以判断其准确性。该数据集共计164个问题，每个问题都配备了单元测试。这些问题旨在考察语言理解能力、算法应用以及基础数学知识，部分难度甚至能与软件面试中的问题相匹敌。

在一定程度上，它也成为了其他人工智能在语言模型领域的标杆，并被广泛用于评估。以下是一个评估结果的示例：、

针对API，我们也在策划出一种与之相仿的构建方法。下面，请看我们经过微调后的API示例：

这里还有几个问题要考虑：

如何确保验证结果的准确性？尽管 API 的验证相对简单，但对于 CRUD 操作的合理性，我们又该如何进行有效验证呢？

数量级的全面性如何保证？

是否只针对特定领域编写？

尽管指标是衡量工作或项目进展的有效手段，然而过分依赖指标却可能带来指标导向的风险。然而，我们能够通过打造一个以反馈为基础的平台，对这一问题进行优化和解决。

步骤 5：LLM 体验设计与工具集成

在成功搭建起首个最小可行产品的同时，我们也在积极研究如何将之与各类工具进行整合。鉴于我们所处的具体环境，我们选择了集成 IDE 插件的方式，这就要求我们必须着手开发相应的 IDE 插件。

而针对于 IDE 来说，其过程比较简单，如下图所示：

尽管语法分析的难度有所提升，但这并非最大的难题。真正考验人的是，如何有效地进行交互设计。

该插件提供了出色的使用感受，涵盖了多种多样的交互方式（如快捷键、内嵌式操作、工具栏等）以及Code模式。在编辑状态下，IDEA内置的功能支持以下三种模式：，以及Block模式。

鉴于我们此前积累了丰富的体验设计实践，同时需关注的焦点包括：在AI时代，是否能够探索出更优的交互手段？

步骤 6：基于反馈的平台工程

在常规应用中，我们通常关注的度量标准与AI产品有所不同intellij idea uml，我们必须极为重视用户对结果的反馈，并且不断搜集这些信息：包括接受与否，以及改进后的版本（如有需要）。

相较于那些不具实用价值的类似选项，针对软件资产而言，企业更倾向于获取经过改进的版本，例如对需求进行更为详尽的优化。

以代码为参照，在人工智能编程软件中，每当用户输入指令或完成代码编写，我们便能够将这些数据记录下来。而且，一旦用户对代码作出调整，我们亦能将其纳入后续训练的数据集中。

因此，在打造端到端工具的过程中，我们必须精心规划内部平台架构，同时增强反馈机制，这样才能让我们的AI系统变得更加智能化。

总结

借助先进的大语言模型技术，我们得以借鉴众多领域的卓越API设计理念与技巧，并将研发团队自身的丰富经验和实际操作融入其中，参照业界通行的API规范。如此一来，不仅能够有效提升架构层面API设计的效率与水准，还能显著增强整个架构的服务效能和开放度。具体的效果提升情况如何，以及采用LLM增强的架构治理方法和路径是否会发生改变，这些都尚待通过更多的实际应用场景进行深入验证。

我们将在架构治理平台不断融入相关指标与操作规程，热切期待您的关注，详情请见：https://.com//。

参考资料：

如有侵权请联系删除！