从设计到研发全链路 AI 工程化体系

Ariers

大语言模型迅速发展的背景下，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还可以处理重复性工作，提高工作效率和产品质量，辅助团队实现效能最大化，进而提升业务结果。