从设计到研发全链路 AI 工程化体系 | 新程序员

【导读】将大模型技术产品化和工程化已成为业界各大公司在研发AI大模型之后的重点发力方向。这一转变促使AI工程化从概念验证迈向实际应用，展现出广阔的应用前景。本文将从设计与研发领域出发，深度分享360在工程化流程中的独特实践经验以及对未来AI工程化发展方向的独到见解。

本文出自 2024 全球软件研发技术大会中的演讲，同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑，囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容，欢迎大家订阅年卡。

作者 | 杨龙辉

责编 | 屠敏

出品丨《新程序员》编辑部

在大语言模型迅速发展的背景下，AI工具和产品不断涌现，如广泛用于代码编写的ChatGPT、GitHub Copilot，可以文生图的Midjourney、轻松在本地运行大模型的Ollama，以及360的智脑、文心一言和通义千问等国产AI工具，几乎覆盖了我们日常设计、编码、办公、协作、聊天、音频、视频等方方面面。只要是涉及人机交互的场景，基本上都能找到一个具有AI功能的工具。

从工程化角度来看，AI工具在产品交付过程中，从需求分析到产品设计、开发再到上线运营，可以在很大程度上辅助人类工程师，提高工作效率和质量。我们团队早期就开始使用各种AI工具来提升效能，不过，这些多样化的工具，种类繁多，也带来了一些困扰。

首先，从应用性上来看，不同人对工具的使用效果差异很大。有些人使用ChatGPT生成代码时非常高效，而有些人则需要花费更多时间调试。此外，某些工具的使用方式复杂，未必适合所有人。

其次，团队协作也是一个问题。使用第三方工具时，往往依赖于它们的平台能力，导致与公司现有系统的集成度不高。如果遇到问题，解决方式通常是通过口口相传，缺乏系统化的知识共享。推广和培训这些工具需要成本，团队成员学习使用这些工具有一定难度，最终导致团队在一致性、标准化交付流程上也会存在差异化。

因此，我们团队内部讨论了两种解决方案：

• 第一种方案是开发AI工具。我们可以将外部的开源工具或插件（如VS Code中对接GPT的插件）集成到现有的软件中。经过研究，我们发现这种方式灵活性高、建设周期短、能够快速实现工具的统一和提升应用性。然而，缺点是集成度较低，只能在某些环节上起作用，无法进行上下游的深度集成，也容易形成数据孤岛。要想解决数据孤岛问题需要做更多的数据分析和整合，工具可能会演变成一个产品。

• 第二种方案是直接开发AI产品。我们思考是否要在软件开发的各个节点上使用领域模型，基于领域模型，再进一步构建AI服务，与工程化进行深度融合。这种方式不仅为平台提供AI能力，还能在模型之间实现互操作。例如，模型可以根据自然语言需求自动生成页面设计和代码，最终只需人工确认后上线。这种方式的优点集成度高、应用性强、数据可以在统一的工程服务中进行共享和二次调优。缺点是此方法建设成本高，需要在工作流程中构建领域模型。

两种方案各有利弊，究竟该如何抉择？当时的我们思考了一点，即这两种方式究竟哪一种可以实现工程效率最大化，因为工程的本质就是既提供了团队的规范，又能使团队的效能和产品质量达到最大化。基于这一点，我们选择了朝着AI产品化的方向发展，可以让整个工程化的链路能够迎来二次革新。

当然，这其中也有挑战：

• 成本问题：我认为对于小团队而言，直接使用开源工具或快速插件等AI工具即可，能够快速提高团队效率。但是，如果团队需要微调并部署一个大模型，还需要构建上层服务，那么首先要考虑团队是否具备相关专业能力。其次，微调模型需要依赖数据和机器成本，都是需要考量的因素。

• 安全隐私：隐私问题是一个重要考量，使用第三方模型可能会有数据泄露风险，尤其是对于以安全为主的360来说，这是不可忽视的。

• 能力限制：当前AI的泛化能力有限，对于未见过的数据，它往往会给出不准确的回答。其次是适配性问题，目前的AI在处理复杂任务时仍有局限性。

综合考虑这三个问题，可以发现AI在能力上有很大的改进空间。从AI的能力来看，它可以辅助人类完成一些工作，弥补人类在编码或设计上的不足，缩短交付周期。此外，AI还可以处理重复性工作，提高工作效率和产品质量，辅助团队实现效能最大化，进而提升业务结果。

360工程化流程的演进

现在，我们在朝着产业化方向发力的同时，360的工程化流程也在不断地演进。在内部，我们按照三个步骤推进（见图1）：首先建设统一的基础云服务平台实现自动化；其次基于流程自动采集数据构建数字化，因为在这个AI时代，数据至关重要；最后进入智能化阶段，建设领域专家模型赋能工程化。

图1 效能云自动化与数字化建设

在自动化架构层面，当拿到产品需求后，我们会进行需求拆解，并自动分配给相应的设计和开发团队。设计师收到任务后，会创建对应的画板；研发人员则会创建相应的分支。通过任务这条主线，我们将工作流程串联起来。设计师完成视觉或交互设计后，可以提交给开发团队。开发团队通过视觉通信打开集成开发环境（IDE），进行编码、合并请求（MR）、提测。测试环节会自动创建提测单，进行冒烟测试、集成测试或验收测试。测试无误后，需求自动流转至上线，通过持续集成/持续部署（CI/CD）完成上线审批。需求完成后，我们会进行归档，并制作数据看板展示业务、性能和效能指标。

自动化架构的效能云基础服务包括数据、流程、权限、技术架构、规范和工具等。下一层则为需求池、代码库、设计工具、CI/CD、物料市场、审计流、安全、日志和监控等能力。最底层则是由360的三大平台提供支撑，分别是用于需求管理的极库云；用于管理设计物料如设计稿和设计工具的设计云；作为一站式研发平台的FinerWork。

360在数字化进程上从四个维度和三个视角展开，即从交付率、交付质量、交付成本和交付能力四个维度进行数据收集，立足于个人、团队和项目三个层面的视角。这一阶段的数据来源均是交付周期自动化采集。

数字化之后，进入智能化阶段。智能化分为两个方面：

• 一是构建领域模型：在办公、设计、代码、测试等不同领域建设专家模型，专家模型会根据对应在设计侧或研发侧的一些场景进行 AI的能力的提供。例如，设计侧可以利用文生图功能或对Sketch、Figma插件进行能力增强；开发侧则可以通过代码生成、AI IDE增强等方式提供支持。这些功能依赖于360智脑大模型。

• 二是基于领域模型构建Agent服务。在模型建立和服务能力就绪后，我们构建AI Agent，使其能够自动完成简单的重复性任务。

此处，我们将从设计和开发两个方面寻找机会点和探索方向，因为在产品交付过程中，设计和开发阶段的需求弹性较大，因此成为提升交付速度的关键。

我们对设计与研发的过程进行了分析，绘制了流程图（见图 2），从中发现了两个关键痛点：设计团队从灵感迸发到具体化设计、优化完善的过程可能充满反复和不确定性——我们称这一阶段为“绝望的深渊”，因为它往往需要大量的尝试和修改，甚至没有产出；开发团队从工程初始化到实际编写业务逻辑的过程同样增速缓慢。

图2 设计与研发过程分析

针对这两个核心场景的痛点，我们在模型构建时特别关注，通过建立领域模型赋能平台，向设计和开发平台提供AI能力。例如，通过文生图功能帮助设计师快速生成初步设计稿，从而显著提高设计效率；通过代码生成、代码审查和代码聊天等功能，协助开发人员进行代码设计和编写，提升开发效率。

360AI在工程化中的实践

基于行业痛点和应用场景，我们将领域模型与业务相结合，构建了设计侧物料平台和研发侧工程平台。

设计侧物料平台

在设计物料平台方面，我们内部开发了一款名为“缤果AI”的产品，该产品支持多端应用，包括Web端、Figma、Sketch以及Photoshop端。这款产品集成了设计广场、AI小工具和图片创作等功能。为了支撑这些功能，我们构建了一套产品架构（见图3），涵盖了从模型到应用场景的解决方案。

图3 缤果AI产品架构

在模型层面，我们依赖于Stable Diffusion，基于此模型，我们进行了大量的微调工作以创建多个基础模型。随后，我们利用LoRA技术进一步微调风格模型。最终，我们将基础模型与风格模型结合，形成融合模型，用于特定场景，这些模型通过Stable Diffusion提供的AI能力集成到产品中，进而构建服务层，提供文生图、图生图、图片反推、延展以及线稿上色等功能，从而支持营销电商、定制化以及其他通用场景。此外，“缤果AI”增强了设计工具Figma、Sketch以及Photoshop的功能。

在模型微调的过程中，我们总结出了一套被称为“631”的方法论：数据占6分，参数占3分，剩下的1分为“玄学”。之所以提及“玄学”，是因为在实际操作中，即使数据和参数都准备妥当，也可能得不到预期的结果，需要反复调试才能达到满意的效果。

微调过程包括数据准备、数据标注、参数调优、模型训练和结果测试。缤果AI产品中，我们主要是对基础、风格模型做数据采集。具体而言，我们使用Dreambooth来训练基础模型，而LoRA则用于训练风格模型。

在数据准备完成后，我们会进行数据标注，使用封装的Factory库，利用WebUI能力先自动打标，然后导入到第三方工具，再进行人工筛选二次打标确认。没问题后，我们对模型进行参数调优，其中训练轮次和学期率是最重要的两个参数。接下来是模型训练阶段，我们会监控损失函数(loss)的变化趋势，一般认为损失值接近0.08时，模型训练结果较为理想，但最终仍需以实际测试结果为准。

基于“缤果AI”，我们尝试将其应用于营销图片场景，还与智能硬件如360手表联动，通过使用“缤果AI”替换底图，可以大幅缩短交付周期并提高效率。

研发侧工程平台

在研发工程方面，基于一站式的研发平台FinerWork（见图4），我们为研发提供了三大场景AI能力加持：聊天、代码和工具。产品架构底层依赖于360智脑模型，微调出代码聊天、代码补全、代码审查等领域模型。这部分的模型微调方法与设计侧物料平台相同，因此不再赘述。

图4 FinerWork AI产品架构

接下来，我们将着重关注CodeChat模型数据方案中的npm私有源文档数据采集与处理（见图5）。这一过程分为数据采集、构建Prompt、数据标注三个阶段。数据采集主要来源于工程平台的自动流程，以及代码工程中的流水线安装错误日志、IDE 安装、运行错误上报、私有包服务数据。

从关键数据中我们去提取一些标注，比如一些OS版本、语义化版本号、主版本文档功能等。有了这些信息之后，构建指令供大模型进行分析，分析结果经过人工审核确认后，用于扩充数据集，确保数据集的质量。完成数据准备后，开始进行模型训练和结果测试。

图5 CodeChat模型数据方案

微调后的CodeChat能够提供代码解析功能，并允许用户一键打开IDE。应用场景包括流水线错误分析、IDE内解决问题、APM性能分析以及线上问题分析等。

AI IDE也是研发侧工程平台的另一个重要组成部分，我们通过AI IDE做场景融合，最初使用CodeServer，但后来选择了OpenSumi。选择OpenSumi的原因在于其开放的AI能力、高度定制化的特性以及兼容VS Code插件市场的优势。基于OpenSumi，我们提升了AI能力与IDE的集成度，实现了多种场景优化，如AI Code、Inline Chat、智能终端、APM性能分析、代码审查(Code Review)和即时通讯(IM)等。

AI工程化未来畅想

面向AI工程化未来，我们从三个维度进行了深入思考：

• 基于大语言模型微调，产出特定领域模型；

• 基于领域模型进一步构建Agent，增强复杂任务处理能力，让其能承担设计和研发中的重复性任务；

• 拥有Agent后，下一步可以实现多智能体系统（Multi-Agent）。

我认为Multi-Agent非常适合工程化，因为工程化的 SOP（标准操作程序）交付流程是固定的，从一个节点到另一个节点都是固定的，所以它可以对这些节点进行编排、共享、自主分工和协作。这也使得Multi-Agent能实现端到端的智能交付（见图6），即从用户需求的产生到最终产品的交付，全过程实现自动化和智能化。当然，这一过程中依赖一个Multi-Agent运行时系统，该系统包含三个部分：

• 消息中心（Shared Message Pool）：用于所有智能体消息共享、发布和订阅；

• 工具库（Tools）：底层依赖各种 API、企业私有库、外部设置、外部搜索等工具来支持多智能体的运行；

• Agent Detail：包含记忆模块、任务拆解和执行任务等。

举例说明，当用户提出开发一个To Do List的需求时，PM Agent会将消息发送给Engineer Agent。Engineer Agent收到消息后，会通过内部记忆模块查看是否有类似的项目代码，并进行任务拆解和执行。任务执行完成后，消息会返回消息中心，通知QA Agent进行自动化测试。 

图6 Multi-Agent实现端到端智能交付

整个过程非常流畅，而且每个Agent都可以有不同的演变，例如Engineer Agent可以进一步细分为专门负责写React工程的React Agent，或者User Proxy。同时，随着Agent模型的改进，未来工程化的各个节点可以实现从人类为主、Agent 为辅的参与模式逐步过渡到Agent为主导的过程，即实现从用户提出需求到Agent逐步完成所有开发和交付。

大模型刷新一切，让我们有着诸多的迷茫，AI 这股热潮究竟会推着我们走向何方？面对时不时一夜变天，焦虑感油然而生，开发者怎么能够更快、更系统地拥抱大模型？《新程序员 007》以「大模型时代，开发者的成长指南」为核心，希望拨开层层迷雾，让开发者定下心地看到及拥抱未来。

读过本书的开发者这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对 AI 的看法和经验和一些采访的内容，这些内容既真实又有价值。”

能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。