亚信科技研发智能化实践之路

作者：亚信科技高级研发经理史伟星

亚信科技是一家专注于 To B 业务的公司。公司 1993 年成立，于 2000 年成为纳斯达克首批上市的高科技企业。2010 年，通过持续深耕，成为中国领先的通信软件产品服务商。2014 年，完成私有化；2018 年，再次在香港主板上市。2022 年，收购了艾瑞咨询，进一步完善了数字咨询业务的布局。目前，公司已构建起数字云网 IT 三大产品体系，成为领先的信息技术产品和服务提供商，以及全栈数据能力的领军企业。

再看亚信的营收，保持了持续增长，并且朝着百亿营收的目标不断努力。亚信的核心产品在通信行业业务支撑系统软件领域占据约 50% 的市场份额，处于全面领先地位。亚信的产品服务着超过 10 亿的用户规模。本文介绍亚信进行研发智能化实践的四个部分，包括实施研发智能化的背景、选择的智能编程助手工具、实践过程及评估效果，以及对未来的一些思考和规划。

亚信研发智能化的背景

当前，公司面临一定的压力，比如经营压力。从亚信和我们服务客户的财报中可以发现，整个通信行业的增长正在放缓。因此，我们需要开发出能降低成本、提高效率的工具和产品；第二，我们面临来自客户方面的质量压力。我们的大量客户实际上对安全和质量的管理有持续强化的趋势。因此，我们也是希望通过引入一些工具和产品，实现质量的提升，减少生产故障，以及高危漏洞的出现；第三，亚信是一家以技术人员为主的软件公司，拥有约 15000 名员工。通过研发智能化，哪怕只是实现 10% 或 5% 的提升，从总体规模来看，也能带来巨大的收益。因此，亚信在研发智能化方面有强烈的需求。

观察整个行业趋势，我们看到阿里、百度、微软等国内外大厂都推出了研发智能化产品。根据互联网上的数据，GitHub 的付费订阅用户已达到 180 万。根据 JetBrains 的开发者报告，超过 70% 的用户使用了生成式 AI 服务。因此，从整体趋势来看，研发智能化在技术上是可行的。同时，无论是国内还是国外的大型企业或初创公司，目前主要集中在开发环节实现研发智能化。

因此，在亚信内部，我们选择在开发环节实践研发智能化。既然我们已经决定要进行这项工作，接下来的问题就是如何选择智能编程助手。

选择通义灵码的理由

我们设计了一套全面的工具选型评估模型，该模型考虑了商业支持、安全支持以及场景适应能力等多个方面。在每个类别中，我们设定了详细的评估指标，评分标准从 1 分到 5 分不等。

例如，在商业安全方面，如果一个工具是免费提供的，我们给予 5 分；价格越高，得分越低。对于代码安全性工具，评分项可能包括是否支持私有化部署、安全管控能力，以及对常用开发语言的支持。

在场景能力方面，我们会考察代码续写、自然语言生成、代码注释和问答等功能，并设计了一套包含典型通用用例和业务开发过程中典型用例的测试用例。通过这套科学的评估模型，我们能够选择最适合的工具。

在本次工具选型评估中，我们有四款产品入围。其中包括国外的 Bito，其底层技术基于 OpenAI 的能力，以及拥有最大代码库的 GitHub Copilot。同时，国内的两款产品——阿里云的通义灵码和百度的 Comate 插件也成功入选。

针对这些产品，我们设定了各项能力的权重。我们结合内部的产品研发、项目交付、运维等相关工作，筛选出每一项能力的权重。

例如，在亚信服务 TO B 企业的过程中，代码安全性具有最高的优先级。经过信息的收集和评估以及用例执行，我们发现阿里云通义灵码在综合评价中表现最佳。 技术能力、工具能力不仅是一方面，对亚信多种场景的使用需求的支撑度也是非常重要的组成部分。

亚信并非仅适用于单一使用场景。经过内部总结，我们识别出三种主要使用场景。

首先是自用型场景，即在亚信内部使用，服务于公司内部产品研发。 这类场景的特点是参与人员的技能水平较高，团队规模数千人，按照季度或年度的时间节奏进行持续研发。整个使用环境是在公司内部。

第二种是协作型使用需求，即在客户服务现场使用我们的工具产品。 这涉及到与亚信以及其他多个厂商共同使用该产品，涵盖了设计、开发、运维、运营等多个角色。整个团队将按月度、季度、年度持续长期使用。工具的使用环境为内部网络，并且对使用过程进行严格管控，包括对产生的代码资产和文档资产的完全管控。

第三种需求是项目协作型，这种需求同样适用于客户内部，但其目标是单一项目的交付。 因此，我们会根据这一场景合理配置高级、中级和初级开发人员。此场景的特点在于其持续时间相对较短，通常为 2 到 3 个月。此外，针对资产的管控也非常严格。

针对上述三种需求，通义灵码提出了两种解决方案：通义灵码专属版方案和通义灵码私有化版方案。

针对自用型需求，通义灵码推出专属版。该版本将在阿里云上划分 VPC 专属网络，并在其中部署通义灵码专属版供亚信单独使用。通过 VPN 和亚信内网的连接，开发者实际上可以访问一个内网服务。

通义灵码的专属版具有显著优势。这意味着整个产品部署，包括底层模型的计算和通信资源，都由阿里云提供。并且，通义灵码后续产品的升级和模型迭代也由阿里云负责。在成本方面，这同样显示出强大的竞争力。

第二种是协作型需求和项目型需求。通义灵码支持私有化部署方案，即使用方需准备部署资源，包括产品和模型升级的运维角色。其最大优点在于，系统在安全管控方面与互联网完全隔离，有效保护了整个过程中的资产。尽管成本相对较高，但综合来看，无论是技术产品能力，还是其对亚信场景化需求的支持度，通义灵码都是最佳选择。

实践过程及效果评估

通义灵码在亚信的实践流程

我们设计了一个完整的实践流程，分为三个阶段。首先，我们选择了不同类型的实践团队，包括数据研发团队、A 省交付团队和 B 省域外拓展团队。其次，我们规划了时间节奏，设置了三个实践阶段，每个阶段持续 2 到 3 周。在过程中，我们发现的缺陷问题会得到阿里通义灵码产研团队的快速支持。

设计效能、效益评估模型

同时，我们对使用过程中的成果进行分析，我们设计了效能评估模型和效益评估模型来科学地评估工具“阿里通义灵码”的适用性。这部分评估模型包括两部分：左侧是效能评估模型，我们对接每一项能力的使用情况和采纳情况，通过专家评估法设定采纳后节约的时间，计算单项能力的总体节约时间，并计算代码续写、注释生成、单元测试生成、开发知识问答等所有能力的节约时间的汇总。最终，按照程序员每周工作 40 小时的标准，我们计算出该工具带来的团队人均编程效率提升。

右侧展示了我们的效益评估模型，该模型分为两个部分：一是从需求端到端的交付率；二是产品缺陷的逃逸率。在使用工具前，我们会收集相关指标。在使用工具后的第一个月、第二个月，我们会持续跟踪这些指标，以观察需求交付效率是否呈现持续增长趋势，以及产品缺陷逃逸率是否呈现持续下降趋势。

评估指标可视化及使用运营分析

针对评估模型，我们内部开发了一个指标可视化看板。该看板显示了各个团队的使用情况以及各项能力的使用情况。我们发现，代码续写功能的使用频率最高，而在不同团队间的采纳率存在明显差异。知识问答功能的使用频率次于代码续写，但采纳率相对较低。

在指标可视化看板中，第二块是效能评估看板。它展示了各项能力汇总的数据以及专家评估的节时数值。通过汇总这些节时并运用我们的计算规则，研发团队能够实现 10% 的编码效率提升。 然而，对于交付团队来说，这种提升相对有限。

这是我们三个团队的关键指标。数智研发团队的代码补全采纳率达到了 36%，知识问答能力为 6.4%，整体编程效率提升超过 10%。A 省交付团队的代码补全能力为 22.7%，知识问答能力为 4.1%，编码效率提升仅为 1% ，需求交付效率下降了 1% ，但缺陷逃逸率显著降低了 71%。B 省的域外拓展团队的代码补全能力达到了 25.9%，知识问答采纳率也是 6.4%，编码效率提升为 1.2%，需求交付效率提升了 18.4%，缺陷逃逸率降低了 69%。

通过对关键指标的分析，我们可以得出一些结论。通义灵码在代码补全方面的表现优秀，准确率在 20% 到 30% 之间。然而，它的知识问答采纳率仅有个位数，这表明有较大的提升空间。在编程效率提升方面，我们观察到不同团队之间存在显著差异。对于需求交付效率，各团队的表现也大相径庭，既有下降也有提升。

深入分析后，我们发现智能编程助手仅是软件开发流程中的一个环节，要实现整体团队效能的提升，必须结合 DevOps 的全套体系。通过识别团队中的瓶颈环节和产出有限的关键角色，结合智能编程工具，可以实现整体提升。

同时，我们也收集了实践团队提供的主观反馈。从工具能力角度来看，超过 50% 的开发者认为代码续写和知识问答功能是有用的，有 16% 的开发者认为非常好，49% 的开发者认为比较好。大多数开发者认为通义灵码能够有效提升开发效率。

研发智能化未来思考

展望未来，我们不仅致力于在编码阶段实现智能化赋能，还保持更为积极乐观的思考与规划。例如，我们是否可以将赋能的范围扩展至软件开发的全流程，以解决初级和中级开发者效率提升有限的问题。我们是否可以开发场景化的智能工具，以降低使用门槛。因此，我们计划推出软件开发的新工具集，旨在通过智能化工具集来提升效率。

我们利用阿里云通义灵码及其底层基座大模型能力，构建一个具有智能体的新工具。期望智能体能够在设计阶段理解需求并生成需求文档，以及开发设计文档。在开发阶段，我们希望智能体能够一键生成前端设计稿转前端代码。在后端开发过程中，我们希望通过智能体一键生成数据模型和后端构成代码，以降低使用门槛。

在部署方面，我们是否可以利用以往成功的部署案例来生成本次项目的部署方案，并分析在构建和发布过程中出现的错误及其原因，提供解决方案？针对安全性问题，我们是否可以利用智能体技术主动识别高危漏洞并提前优化？在运行态方面，我们是否可以对接线上的一些 APM 监控工具以及我们的搜索执行工具，针对高频接口、慢接口、高频 SQL 慢接口进行主动优化。接下来将介绍两款典型的智能体工具。

首先是 ChatDoc，这是一款文档智能编写的工具。它主要用于生成设计文档，包括项目应标文档，可能包括以下能力：生成 Word 文档，包括整个目录、章节以及局部内容的改写，甚至整个文档中的结构图、流程图。

我们利用多模态大模型融合技术实现这一功能。第二是 PPT 文档的生成能力，可以整体生成 PPT 的章节，生成每一页 PPT 的内容，甚至可以基于 Word 文档一键生成整个 PPT。此外，还包括其他文档协作和共享能力。我们希望通过这个工具实现设计态的效率和质量提升。

第二块是关于 D2C，这是一款能够快速生成前端代码的工具。以往在前端开发和设计人员之间，这是一个高频交互的过程，需要沟通设计细节，甚至在某些项目中，前端设计稿频繁变更时，这一过程尤为耗时费力。我们希望这款工具能够解析 Figma 设计稿中的设计，并结合 DSL 模板化技术，一键生成前端代码，从而大大减轻前端开发人员的工作负担，让他们只需专注于前端业务逻辑。

我们规划使用多模态大模型来理解图片设计稿，并一键生成前端代码，以提高开发效率。通过这样的工具，我们期望能够显著提升开发团队的效率。这就是亚信在研发智能化方向的实践。

总结起来，主要包括两个方面：

一是我们利用阿里云的通义灵码在开发（coding）环节进行赋能，这一实践在公司内部持续扩大应用范围，目前正处于推广阶段。

二是面向未来，我们希望构建一套能够赋能软件开发全流程的智能体工具集。我们正在与阿里积极探讨这一领域。我们希望利用阿里云通义灵码的能力，即底层大模型、基座大模型的能力，构建出一套赋能全流程的智能工具集，以显著提升亚信各个团队的研发效率和质量。