前言

「曾几何时，代码敲击声回荡在深夜的办公室，你是否也曾幻想过有一个全能助手替你分担工作？如今，这个美好的愿景不再是空中楼阁。」

想象一下，当你正为「产品设计」苦思冥想时，突然耳边传来 AI 的灵感火花；

在「开发过程」中，AI 像是个比你还了解自己的最佳拍档，为你提供独到的建议；

当繁琐的「测试工作」如排山倒海而来，它早已帮你先行解决那些隐秘的 Bug；

「交付环节」则如同一个老练的质检专家，在每一个细节上都帮你擦亮眼睛；

而在「运维阶段」，它更是你的“夜间守卫者”，早早预警潜在问题；

有人说，AI 的到来让开发者的身份发生了质的飞跃，从“头发稀疏的代码独行侠”变成了“开挂勇士”。在 AI 的协助下，谁不想在产品设计上满怀创意、在代码编写上行云流水、在测试中无懈可击，在运维中高枕无忧呢？

在这个充满奇思妙想的科技时代，AI 既是你的忠实伙伴，又是你的全能助手，更是一位风趣的导师。它不知疲倦地助你不断攀登职业高峰，让每一步开发都像是一场精彩绝伦的探险。是时候跳出你的舒适区，体验 AI 如何点亮开发者们的星辰大海。

准备好了吗？接下来，我们将揭开这段「AI」助力开发的奇妙旅程，从产品设计到运维管理，为你重新定义“效率”、“质量”和“体验”。* 每一刻都充满了独特的惊喜和乐趣，相信这将是一段你不想错过的神奇之旅。让我们一起踏上这段充满无限可能的旅程，重新发现开发的独特魅力与无穷乐趣。

❝

“在「AI」 的魔法世界里，开发者不再是孤军奋战的英雄”

❞

助力业务发展

随着 LLM 能力的迭代和更新，越来越多过去 LLM 无法很好解决的问题重新进入了大家的视野。在人审领域下人们一般都会围绕着 「LLM 是否可以完全替代审核员对内容进行审核」进行讨论与探索。在进一步进行详细的 LLM 赋能人工审核流程相关的例子前我们需要先了解一下“人类审核员”面对的一些挑战和要求：

• 能处理复杂的内容（e.g.可能既可以是 A，也可以是 B，还可以是 C）并给出最合适的答案
• 质量 & 稳定性：对于相同类型的内容要给出相同的结果
• 效率：在不损伤质量的前提下需要达成一些数量上的要求

先说结论「目前 LLM 的能力还无法完全替代审核员」，更多的是在各方面「提供辅助」从而提升审核员的审核质量和效率。所以在产品结合的思路上，我们主要关注在如何利用 LLM 「简化或加速审核员对于单一任务的操作」并完成了一些功能的落地。

前置思考

❝

说到 LLM 最出名的当属于 ChatGPT 了，如 GPT-4o

❞

当我们思考 LLM 能为审核员带来什么样的「辅助」时我们首先想到的就是如何利用这些现有的天花板模型。这些模型一般都有「良好的指令执行能力」，并且在处理一些「通用文字相关的问题」时一般具有非常好的表现。

例如我们可以提供一段文字内容给模型，并告诉模型我们希望它帮助我们从中提取出「不符合某些规则的内容」如：潜在的语言攻击，歧视内容，潜在色情内容等等。

「当有了模型识别出来的内容后可以通过一些特殊的形式展示这些信息如高亮等。」 这可以帮助审核员在审核过程中快速捕捉到内容中存在的潜在风险并加速其对当前内容的审核。听起来是不是很简单？实际上将一个如此简单的辅助能力从离线验证到最终上线需要考虑的远远不止这些：

• 「成本」：模型是以 token 来进行计算的。一段文字会先被转换成 token 然后再传给模型，同时模型输出的也是一堆 token 然后会再被转换成我们看得懂的语言。所以如何无损高效的压缩传给模型的内容是一个非常重要的课题。（如删除重复的内容等）
• 「合规」：因为模型在迭代过程中需要大量的训练数据，厂商都会收集模型在实际使用过程中的数据以补充其训练数据集。如果将一些敏感或隐私数据不经过处理的直接传给模型可能会带来合规风险。（如公司的保密数据，或者用户的不公开信息等）我们可不希望当其他人问模型你的银行卡密码时模型能准确无误的回答上来hhh。
• 「时延」：模型能力强大是有取舍的。可以姑且先理解为（在计算资源不变的前提下）模型的规模越大->模型的能力越强 -> 每次回答你问题的速度就越慢。同时给模型输入越多时返回的时长也会相应的延长。
• 其他 n+ 问题：服务可用性，模型拒绝回答，模型选型等等...

但是由于模型能力的局限性，我们只能对「标准文字内容审核」提供符合标准的辅助能力。那对于像视频或者音频中出现的文字，或者话语或者一些复杂的问题怎么办？

例如我们想对于一个歌曲中的歌词进行风险识别。

这个时候我们就要引入「分步」的解决思路，歌曲中歌词的风险识别可以被拆分成如下工作流

举例来说，在预处理环节我们可能会需要对 ASR 转换的文字内容进行整理如加入标点符号，分句断句等。「模型对于长文字内容的处理能力会随着内容变长而下降」。我们需要根据业务的诉求和实际情况进行灵活调整。抛去 ASR 环节不说，后边三步可以有两种实现思路：

1. 在一个 Prompt 中通过分步的方式指导模型进行处理

1. 会更好的保留整体的上下文，但是可能会碰到如内容太长超出 context window size 的情况并且随着内容的变长模型的完成时间也会变慢。

2. 将每一步拆分开然后通过串行调用的方式完成多次模型调用。

1. 可能会丢失一些上下文内容，但是因为进行拆分后每一部分的长度都是相近的所以在模型响应时长和 context window 上限的问题上则有比较好的表现。

如果我们想让模型帮我们翻译火星文呢（没办法，业务上就是有这个诉求 hhh）

对于一些有高定制化诉求的场景普遍厂商也会开放对现有模型就行二次训练的能力。比如对于将内容从 A 语言翻译到B 语言并且对语言风格/用词有明确需求时，可以考虑对基本模型做一次 「SFT」 「（」 「Supervised Fine Tuning」 「）」 。也就是对自身特殊诉求收集数据集并使用这个数据集对模型进行二次训练以达到更好的表现。

如果你说识别什么的还是太复杂了，有没有更简单的应用场景？

在实际产品开发过程中，我们经常性的需要对圈定/给定的一组数据进行频繁的离线验证以确保目前的能力表现是符合我们预期的。又或者在产品迭代的过程中我们时常需要一个指标/分数来量化当前的能力/体验。举例来说，在进行多目标语言混合翻译的能力开发过程中，我们在 prompt enginnering 过程中需要时刻关注模型的表现并确保每一次修改都不会对能力造成较大的退步。「Multidimensional Quality」 「Metrics」 「(MQM)」 是一个多维度指标翻译质量分析框架。我们可以通过自然语言的方式向模型输入我们的对于（译文与原文对比）不同维度上的要求如：

「翻译准确性」

❝

• 是否丢失一些信息
• 是否凭空捏造了一些信息
• 翻译错误/未准确翻译
• 未翻译
• ...

❞

「流畅度」

❝

• 语法是否正确
• 标点是否正确
• 拼写
• ...

❞

「风格」

❝

• 是否用了一些抽象的词
• 是否是正式文风
• ...

❞

得益于 LLM 优秀的自然语言处理能力和跨语言能力，LLM 可以基于我们输入的多个维度来对译文进行评估并最终给出评估结果。需要注意的是为了保证模型输出结果的准确性我们一般不会直接要求模型输出如：0-10 分的打分。我们会尽量让模型在一个给定的状态下进行枚举。如：严重程度（严重， 普通， 可忽略不计）并通过代码对枚举进行映射后计算出最终的得分。这样可以最大程度上避免 LLM 输出不稳定和幻觉等问题。

「实际上MQM这种多维度评估体系也可以应用在翻译之外的领域，如润色、故事生成等。甚至可以被用在图片打分。他们背后的原理都是类似的，都是通过发挥 LLM 出色的自然语言理解能力 + 通过自然语言描述框架来实现一些复杂的打分工作。」

功能落地

❝

上边我们只是利用了 LLM 的自然语言处理能力。如果我们想让模型帮我们回答一些不是通识性知识点的问题时该怎么办呢？

❞

模型也可以像人一样，碰到不会的东西时可以先去「查询」然后再「基于查询结果进行判断和回答」。

比如说我们想为审核员提供一个问答机器人回答一些审核领域相关的问题，或者基于以往的审核结果进行回答。

又或者我们想基于某一个数据库中的结果对审核员的问题进行回答

但是对于不同类型的内容，知识库在生产过程中采用的分割策略，结构等会大大影响最终问答质量的表现。如：

• 「Chunking」: 如当对于大段内容进行拆分时要拆分的多细，拆分后的信息是否应该保留整体上下文方便后续参考时使用等。
• 「Embedding」 「Model」: 需要针对需要支持的语言来选择向量化模型，不同的模型在召回准确度上也有不小的区别。

当我们检索到的相关知识后可以通过将这些信息连同原始问题一并作为输入给模型并让模型基于相关知识点尝试回答。

「当我们积累了一系列能力后，如果快速的向其他方向上推广和扩展？」

随着越来越多基于 LLM 能力的需求落地，我们发现其实所有的 LLM 能力都可以被总结为：「一个带顺序的分步流程」。其中模型调用只是工作流中的一个步骤/节点。如果我们能快速的复用这个「分步流程」就可以快速的对取得成功的能力进行推广。

                             （分步流程可视化示意图）

随着我们对现有的一些优秀 LLM 编排能力库/平台的深入了解，我们发现现有的方案都无法很好的对我们的业务场景提供100%的支持。甚至大多数都无法通过「合规」这一环节。更不用说可能「业务有自己的模型、数据库、基础能力」等等。我们需要在业务下实现一套「定制的」 「流程引擎」。

流程引擎本质上可以被拆解为一下两种图的类型：

• 「DAG」 「「「有向无环图」。一般用作承载」经典 Workflow 场景」。需要注意的是这种图不能包含循环所以一般被用作实现单一 Agent 能力。
• 「FSM」 「有限」 「状态机」。用作实现如 「Multi-Agent 场景或有环的场景」。是 DAG 的一个补充。但是需要注意的是因为状态机同时之后有一个激活状态所以并发分支等能力无法通过 FSM 实现。

当我们实现了上述两种流程引擎后可以进行组合实现更复杂的能力如：FSM 中嵌套 DAG，DAG 中嵌套 FSM 等等。

当我们有了上述流程引擎和对应的 DSL 之后。我们就可以在业务间快速复用能力（只要复制一下 DSL 或基于现有的 DSL 做二次开发就好了）。

可能你会问，为什么不根据需求直接把这些逻辑写在代码里呢？实际上在日常开发过程中我们发现大部分功能都是通过对有限能力的组合来实现的。如果不做流程引擎的建设会带来很大效率上的降低以及多余的开发量。

其他实践

Hornbill 是内部用于多个平台的 「Oncall 工单管理工具」，拥有三种升级策略。我们处理工单的团队包括用户运营团队和研发工程师，并在创建工单时自动拉入相关人员进行协作。由于审核员需要快速处理大量审核任务，Hornbill 通过 24 小时的用户运营团队快速解决问题，技术问题会被升级至研发解决。

Hornbill SDK 可整合到平台中，帮助用户在提交工单前通过 FAQ 寻找解决方案，从而减少不必要的工单。「每周约有 几百个由用户运营团队处理的工单，因此减少工单数量可以让团队将时间用于更高价值的任务。」

「为了提高工单解决的效率并减少工单数量，我们引入了」 「AI」 「功能。」

首先，「相似工单检测能够有效识别并链接具有相同问题的工单」，通过创建问题描述的嵌入向量，并使用向量相似性计算如余弦相似度，系统在用户提交新工单时可提示已有相似工单，推荐用户加入现有工单而非新建，或在工单提交后提醒用户操作团队进行链接，从而减少重复工单处理的工作量。

其次，「AI」 「摘要生成功能则通过自动生成问题的总结」，在群聊中梳理出问题描述、原因和结论，提供给不同班次的用户操作团队以保持问题处理的一致性。这一功能通过将所有的群聊内容传递给大型语言模型生成总结，从而避免因班次交接导致的上下文丢失，提高工单解决的连续性和效率。这些先进的 AI 功能减少了用户操作团队在票务处理上的重复性工作，让他们能够将更多时间投入到更具价值的任务中，不仅提升了团队的工作效率，也提高了用户问题解决的速度和质量，为用户提供了更优质的体验。

另外，Hornbill SDK FAQ 搜索功能旨在「解决用户自行反馈且可通过非技术知识解决问题的工单。」 通过将常见问题生成 FAQ，用户可以搜索相关知识库，并根据输入查询定制 FAQ 内容，使其更易理解。方法是为常见的可自解决问题创建 FAQ，并对 FAQ 问题进行向量嵌入，将其存储在向量数据库中。当用户输入问题时，我们利用余弦相似度比对向量嵌入，以找到匹配的 FAQ，并通过大型语言模型总结 FAQ 内容，展示给用户。这一功能减少了不必要的工单，提升了用户的自助解决效率。

总结

当我们完成了对流程引擎的落地，同时在流程中有技巧性的使用 LLM。基本上「领域下的产品/业务诉求」都可以基于这一套框架来实现。LLM 除了可以为我们做分类，识别等功能以外也可以帮助我们做离线验证/数据评估等工作。与可视化编排界面配合可以大幅降低使用门槛。「对于一个想要使用 LLM 能力来实现业务诉求的业务方，不论是」 「PM」 「同学还是运营同学都可以进行尝试可以大大解决研发的人力缺口。」

提升开发体验

AI 编程在今年有了比较大的发展，因为出现了 Cursor、Windsurf、v0、bolt.new 这些，在不同场景下，成为了能指数级提升生产力的工具。这不仅仅得益于越来越强的模型能力，也得益于许多在应用/交互上的创新与探索。

工具形态

传统工具的替代品

❝

搜索、文档工具、设计稿代码生成工具等

❞

信息搜索（以前用 Google ）

文档查阅（之前文档站）

D2C

多智能体自然语言编程

❝

代表工具：gpt-pilot、gpt-engineer、MetaGPT

❞

这类工具直接通过自然语言与一个多智能体系统进行交互，多智能体系统会在内部划分多个角色/任务，如：程序员/开发/调试、架构师/设计、产品经理/拆解、项目经理/任务管理等。

但这类工具要将整个工程从新建到功能推进完全交给智能体维护，用户只能通过指令和自然语言对话对工程进行控制，并且受限于上下文窗口，也无法构建复杂的平台系统。使得这些工具都没有办法用于程序员日常的生产和实际的项目里。只能作为非专业人士的玩具，或者 AI 研究的尝试。

❝

• https://blog.pythagora.ai/2023/09/04/gpt-pilot-coding-workflow-part-2-3/

• https://github.com/geekan/MetaGPT/blob/main/docs/resources/software_company_cd.jpeg

❞

代码辅助工具

❝

代表工具：Github Copilot、Continue.dev、MarsCode

❞

以 continue.dev 为例，这类工具的核心功能大概就是上述几类：以代码块/文件为上下文 Chat、Tab 自动补全、选中代码块进行自然语言编辑、在聊天框中对代码块进行应用。

这些功能已经在开发中被普遍使用了，开源的模型、插件对这些功能的支持也非常成熟了，不同公司内部也有类似的解决方案。

❝

好用，但还不够强大，伴随着这些功能的组合和深度优化，期待更具生产力的工具逐步被开发出来并具备商业价值。

❞

🆕 复合型编程IDE/插件

❝

代表工具：Cursor、Windsurf、Cline

❞

已关注

关注

重播 分享 赞

关闭

观看更多

更多

退出全屏

视频加载失败，请刷新页面再试

刷新

视频详情

Windsurf 的 Cascade 工具，与 Cursor 的 Composer 类似

在代码辅助工具的基础上「进一步增强代码整合能力」，包括：

• 能够有效汇总上下文
• 能够将代码块转化为文件变更，以支持同时编辑多个文件
• 能够管理AI批量编辑后文件的暂存状态，并灵活跳转到不同历史编辑版本

这些能力大大提高了使用体验和生产效率。

Cursor 在刚出来的时候也收获了大量非程序员以及博主们的力捧，但我们在日常使用中依然不多。主要还是因为无法直接用于我们日常工作的工程，但随着一些使用方法的探索，以及模型能力/上下文检索能力的进一步提升，越来越多的编程人员开始在日常工作中使用，以提升生产效率。

❝

而下面的「最佳实践」也提供一种日常使用的工作流，该工作流基于文档，构建长期 AI 可维护的大型项目。

❞

🆕 快速原型构建机

❝

代表工具：v0、Bolt.New

❞

其实和上面的 IDE 差不多，但更多的结合了 WebIDE 和 WebContainer 的优势。

常规的使用场景是：「对于完全没有技术背景的角色来说，他们不知道如何为自己的需求创建一个工程并完成前期的原型验证工作，而这类」 「WebIDE」 「工具则提供了一个完美的平台让他们来得到一个可供」 「开箱即用」 「的工程原型。」

在此之后，则可以将这个工程下载到本地，使用 Cursor 继续进行工程的后续维护和开发。

最佳实践

「虽然新的工具将功能可用性提升了，但存在短板，需要结合一些使用的条件和方法：」

• 「需要应用一整套闭环的工作流」。其重点在各种文档的记录上（项目记忆力），让人和文档交互，完善设计，才能最终让 LLM 能更好的结合上下文生产出可靠的代码。
• 「不是所有场景都可以」。逻辑性代码完全没问题，但无法还原视觉设计的细节。因此，在工作流中，通过 AI 完成逻辑代码的部分后，样式工作还得需要前端工程师来编写。
• 「技术栈和工程结构有限制」。需要选择用比较老，且主流的技术栈和版本，社区训练物料比较多。
• 「合规和数据安全问题」。

工作流

这个工作流以文档为核心，适时的对项目和变更进行总结，以便在新增需求的时候，工具可以获得足够且精简的上下文，来精确生成新需求所需要的设计和代码。这些文档包括：

1. 整个项目的描述，包括：项目简介、技术栈、文档结构、项目架构等全局信息
2. Feature 文档，以及每个 feature 的技术实现细节
3. 模块文档，在每个模块下，对于该模块代码的总结和索引

本质上讲，现阶段，如果我们将 AI Coding 工具拟人化，它有很多缺点：「记忆力差，没有从」 「代码仓库」 「中持续积累特定于此仓库的经验，相当于每次找了一个新人来开发」

所以，一个好的工具、开发者，应该是能够合理组织和提供一个指令足够的上下文的；一个完全适配的项目应该是，简单化模块化的原子能力 + 清晰的模块声明。类似于微前端、微服务这种组织形式可能更有利于文档的组织

未来展望

工作模式

这有一篇来自于红杉资本的文章（中文版）描述了他们对生成式AI发展的展望：

虽然我对这个发展路径以及时间节点存疑，但也同样让我在想，结合AI，未来的编程是怎么样的呢？什么样的目的、什么样的实现方式、什么样的产品形态呢？「往大了想，这些都太难回答了」

「但在一些小点上，站在程序员的角度，还是有一些想象的：」

• 近几年，就可以看见程序员的能力模型要求会有一些变化，「更有」 「AI」 「辅助经验的，在生产力上会比纯手写更有优势」

• 就像在应用层，高级语言编程替代汇编语言（wiki：编程语言世代）

• 语言本身的学习变得简单，当 JS 开发工程师想使用其他语言时，变得没什么「门槛」了

• 没有「合规模型工具」的公司，在生产力上会落后，人也一样

• 会出现「便宜的」 「AI」 「辅助编程解决方案」，例如：

• 针对特定技术栈的小参数 LLM ，本地 32G 内存的笔记本，就可以足够提升生产力了

更远的未来，如果产品形态和生产方式发生质的改变：

• 那人可能可以专注于新的领域的扩展，而不用纠结于现有生产工具的「熟练度」了
• 模型越来越强大，实现这件事，真的可能会变成**「念咒语」**

工具链

现在的技术栈、工程化等方式还是基于人来建设的，但当 AI 编程占领主导之后，会有什么样的工具链来驱动呢？什么样的工具链对于 AI 编程更友好。

例如上面提到的最佳实践的工作流来说，整体围绕文档驱动，在生成文档的时候，我们也需要将项目代码转换成上下文提供给大语言模型，而 https://github.com/yamadashy/repomix 就是一种可以将仓库代码打包成 LLM 上下文的工具。

「这块还处于特别早期，因为具体的工作流还没有固化下来，但可以预见，会有越来越多的工具链产生。」

推动测试进程

为什么做单元测试

LLM 生成单元测试代码，在 22 年底就已经取得了非常惊艳的效果：用例工整，分支覆盖详尽，mock 数据齐全。生成的用例如果可用，提交到仓库后会成为代码资产的一部分。如果用例有问题，这部分代码也不会直接影响到生产环境。所以，AI 单元测试是大语言模型第一次尝试「落地工业生产环境」的完美试验场景。

另外，单元测试本身就是研发环节中非常重要的一部分。「全面的单元测试可以辅助发现很多变更引起的风险和问题。业界知名的开源软件必定包含大量自动化运行的单元测试」，这在多人协作开发过程中至关重要。

我们在 23 年也尝试过使用 AI 生成单测。但是当时代码报错多、人工修复成本大，初步尝试的结果不尽如人意，于是暂且搁置了。24 年中，在业务痛点的驱使下，我们重启了 AI 单测的调研。这一次我们找到了新的角度，解决了报错多和人工修复成本大的问题，让大家看到了 AI 单测落地的可能性。

AI 单元测试效果如何

衡量标准

「在讨论效果如何之前，首先要讨论如何衡量效果。怎样算效果好，怎样算不好？」

在 23 年的调研中，我们没有具体的评判标准，只通过看到的结果得出一些主观判断。在 24 年的实践中，我们尝试以客观的评判标准为主，主观的感受为辅。

由于评判标准是为了服务于我们的目标，所以我们先花了点时间思考我们到底希望 AI 在单测这件事上做什么？我们希望通过引入 LLM，对编写单测提效，同时通过大量单测代码的引入，提高 bug 召回率，提升代码质量，减少线上bug。

基于这个目标，最终我们梳理出这样的指标体系：

• 「核心指标」：bug 召回率

• 「准入指标」：单测可执行率，单测覆盖率

• 「过程指标」：

• 千行代码用例数、测试用例独立性
• 单测执行时长
• 项目渗透率、单测可维护性、研发接受度
• 单测生成速度

实际效果

所以实际效果如何呢？

横向观测下，我们对比生成 case 数、case 可执行率以及单测覆盖率。大部分模型都基本满足了准入要求，小部分模型可能由于发布时间较早或提示词适配度低等工程原因，没有取得可用的表现。

在解决了一些难点问题后，我们在试点仓库做了推进。对于千行以下源码的小批量生成，单测可用率保持在 100%，覆盖率保持在 80% 左右。「随着源码复杂度增加，可用率和覆盖率均略有下降，但整体表现已经进入了值得期待的状态。」

除了客观数据，研发接受度（主观感受）也很重要。通过阅读我们看到，纯逻辑类函数 AI 可以做到考虑各种情形、针对特定情形 mock 数据并给出断言；React 组件 AI 可以做到考虑多种情况，并且试图在渲染的 dom 结构中寻找关键元素做断言，配合人工矫正生成部分快照可以低成本、高覆盖率完成单测编写；同时AI在边界条件测试上比人类更加严谨，也会通过函数名、注释等信息发现人类考虑不周之处。

从效率和 bug 召回的角度，我们都看到了希望，因此，我们开始在部门内推进 AI 单元测试。

为何会取得不错的效果

首先，我们标准化了基础设施，解决了一些基建问题。如果一类 case 有 3 种写法，那么我们选择其中一种我们最希望的写法让 AI 固定下来，同时帮 AI 打通任何调用 API 上的难题。

其次，人类程序员要懂单元测试。比如 Arrange-Act-Assert 单测组织方式，如何 mock 数据，如何模拟交互，如何合理断言等等。「如果人本身不擅长做这件事，也就没办法更好地评判」 「AI」 「做的好还是不好。这和使用」 「LLM」 「学习其他领域、进行创意启发等场景是不同的，人类必须是相比 AI 更专业的角色。」

最后，靠业界优秀论文和公司内团队支撑。从 23 年到 24 年，在 AI 单元测试领域出现了不少靠谱的论文，比如 Meta 的 https://arxiv.org/pdf/2402.09171。市面上的产品、公司内的团队，都有在这些论文的基础上做工程化落地工作。Data-TnS 团队也是在调研之后，和公司内 Codeverse 团队一起，在我们的业务上落地了 AI 单元测试能力。

AIGC 落地的最后一公里

AI 单测真正的落地，还需要业务仓库研发同学的协助，不只是基础配置和存量单测代码的合入，还有对后续日常研发流程的改变。

接入AI单测能力，我们提供了3个模块：基础依赖包、流水线配置、ut-helper 本地工具。「由于模型在纯函数上表现更好，在组件上略有欠缺，所以我们的推进策略是优先覆盖」 「P0」 「仓库的所有工具函数和通用组件，对于业务属性较强的代码暂不推进。」 通过收集流水线上报的单测执行数据，我们建立了数据看板，展示仓库接入率、全量覆盖率、增量覆盖率和单测执行失败明细。

对于研发日常的影响，大家问的最多的问题是：生成了 case 之后还需要人类 review 吗？AI 有帮助人类纠错的能力吗？我们希望是不需要人工介入且能帮助发现潜在风险，而且也看到了一些希望。「随着存量代码的覆盖完成，增量代码的覆盖更是对人类和 AI 的协作的考验。」 AI 是否真的能在研发需求迭代过程中帮助研发规避潜在风险，部门的 bug 估分比是否能切实下降，这都是我们拭目以待的事情。

总结

在今年的实践中，我们对于 AI 落地这件事又有了更多的认识。「它不是人类驱使一个远远强大于自己的怪物，落地工业生产场景仍然是靠人类往前迈一步，指挥 AI 在指定范围内做事」。另外，AI 在真实落地中的挑战远不止模型训练，AI 和 AI、AI 和基建之间，有很多工程化的工作，它们可以在很大程度上改变最终的效果，有时会比实验室的大模型 pk 榜有趣得多。

保障交付质量

交付质量（Delivery Quality）是指在软件开发过程中，最终交付给客户或用户的软件产品所具备的质量水平。它涵盖了多个方面，包括功能性、可靠性、性能、安全性、易用性、可维护性等。「交付质量的高低直接影响到用户满意度、产品市场竞争力以及企业的声誉。」

交付质量对于软件开发非常关键，交付质量的劣化会带来用户满意度下降、维护成本增加、品牌声誉下降等问题，甚至会缩短产品的生存周期。交付质量的保障覆盖软件开发过程的所有环节，包括需求设计、开发、测试、发布上线、运维阶段，本文将从各个软件开发环节展开聊一下质量保障的手段和能力。

质量保障传统手段

完整的质量保障策略，需要各个阶段的努力，常见的质量保障框架包括基础的规范、工具、质量防控手段和质量度量：

保障交付质量是一个比较大的话题，交付质量问题可能出现在软件的开发生命周期任意一个环节，需求设计环节中的需求逻辑问题、开发阶段的代码质量问题和测试阶段的测试漏放问题最终都会导致交付质量的下降，常见的质量保障手段和理论基础：

• 「持续集成」 「/」 「持续交付」 「（」 「CI/CD」 「）」 ：持续集成（Continuous Integration, CI）和持续交付（Continuous Delivery, CD）是一种自动化软件交付流程的方法，通过频繁地集成代码、自动化测试和部署，确保软件始终处于可发布状态。
• 「测试驱动开发（」 「TDD」 「）」 ：测试驱动开发（Test-Driven Development, TDD）是一种开发方法，要求开发者在编写功能代码之前先编写测试用例。通过这种方式，确保代码在开发过程中始终符合预期，提高代码质量和可维护性。
• 「行为驱动开发（」 「BDD」 「）」 ：行为驱动开发（Behavior-Driven Development, BDD）是一种协作开发方法，通过自然语言描述系统行为，确保开发团队、测试团队和业务团队对需求有共同的理解。BDD 强调从用户的角度出发，编写可执行的测试用例。
• 「DevOps」：DevOps 是一种文化和实践，旨在通过开发（Development）和运维（Operations）团队之间的紧密协作，实现快速、可靠的软件交付。DevOps 强调自动化、监控和反馈，确保软件在整个生命周期中保持高质量。
• 「质量保证（」 「QA」 「）自动化」：质量保证自动化工具和框架可以帮助开发团队自动化测试流程，确保软件在不同环境和配置下的稳定性和可靠性。

大模型如何赋能

LLM 的越加成熟为交付质量的提升带来了更多的可能，在整个软件开发生命周期过程中，「当前阶段下 LLM 想要替代某一个角色的所有工作还不太可能，但是 LLM 已经可以在各个阶段为各个不同角色带来正向的作用」，以下是一些相关的实践参考：

代码生成与重构

LLM 可以根据上下文生成高质量的代码片段，或者重构现有代码以提高其可读性和性能。代码生成能力在 LLM 上的应用和探索已经有较久的时间，随着模型能力的增强和各种工具的诞生和强化，代码生成和重构能力已经达到一个基本可用的状态，同时也有更多的专门为代码而生的代码模型逐步问世，例如 Claude 3.5 Sonnet、CodeGemma、Code Llama、Codex。

「相关实践：」

1. MarsCode：智能编程助手，提供以「智能」 「代码补全」为代表的核心能力，支持主流编程语言及 IDE，能在编码过程中提供单行或整个函数的建议；同时提供「代码解释、单测生成、问题修复、」 「AI」 「Chat」等辅助功能，提升编码效率与质量；

代码审查自动化

LLM 可以用于自动化代码审查，帮助开发者在代码提交前发现潜在的问题。例如，LLM 可以检测代码中的潜在错误、不规范的编码风格、安全漏洞等。

测试用例生成

LLM 可以根据代码逻辑生成测试用例，帮助开发者覆盖更多的代码路径，提高测试的全面性和有效性。例如，LLM 可以生成边界条件测试、异常处理测试等。

「自动化部署与监控」

LLM 可以辅助自动化部署流程，确保代码在不同环境中的正确性和一致性。此外，LLM 还可以帮助监控系统状态，及时发现和处理潜在问题。

「相关实践：」

• 基于日志系统的自动化归因和排障能力，能实现在大范围故障中实现智能归因，找到根因，在实践中已经取得较好的效果；

「团队协作与沟通」

LLM 可以促进团队成员之间的协作与沟通，例如通过自动生成会议纪要、任务分配建议等，帮助团队更高效地协同工作。

「相关实践：」

1. 飞书智能伙伴：飞书智能伙伴在群聊、会议、邮件等多个办公场景提供智能化能力，极大的提高了工作效率和沟通协作的质量；

展望大模型可探索方向

LLM 能力在交付质量保障中展现了较为强大的能力，在代码生成、代码审查、测试用例等方向已经存在一定的成熟度，但仍存在较大的潜力：

1. 准确性提升：通过不断优化模型、训练策略、评估指标完善等策略，不断提升模型能力的准确性，降低心智负担
2. 业务定制化：与现有的完善保障体系进行工具和流程的集合，融入业务特性，建设个性化 Agent，降低 LLM 使用成本，提升 LLM 能力覆盖度
3. 全流程自动化：探索 LLM 自动化保障体系，管控整个需求开发周期，能够在各环节产物进行自动化质量保障，例如需求文档质量保障、代码质量问题回捞、用例质量保障、发布过程保障、线上运维监控等功能串联，形成全套的自动化方案

当前的发展现状来看，LLM 的能力还是在融入当前成熟的质量保障框架能力中，提升软件研发生命周期的的效率和质量，长期展望来看，LLM 会逐步接管质量保障的各个环节，实现高度自动化

运维管理优化

为什么需要更智能的运维

研发同学的一天，可能大部分时间不是用于开发，而是在处理各种各样的信息，比如告警、oncall、指标异常等等。

从这个角度讲，日常的运维管理比单纯的开发占据了研发的更多时间。「从时间分配的角度上来说，对运维提效，可能比对开发提效相比带来的体感提升更大。」

传统运维从触达渠道上可以分为两种方式：

1. 系统日志上报，总结出各种各样的指标，当指标出现异常时，发送告警给研发
2. 某系统 fatal 故障，发送卡片让研发检查自己负责的服务是否有问题

在这种模式下，主要的痛点在于：

1. 收到这些运维管理的信息后，研发需要查询大量的上下文，然后定位问题
2. 对于没有达到告警阈值的一些 case，缺乏触达能力

「在这个基础上，我们需要更智能的定位分析能力和」 「数据处理」 「总结能力」

AI 落地的思路

• 如何处理海量的数据

用 AI 来分析海量数据，一个痛点就是受限于现在AI的语境，无法直接把所有数据都扔进去分析。

但是如果用知识/向量库的方法，用 RAG 的方法去分析，又无法让 AI 站在所有数据的角度去分析。

所以其中的一个思路是把分析的步骤拆解，一次给出局部的数据，然后通过对局部数据的分析，一步步缩小数据范围，在这个范围内给出更大体量的数据，然后让其做出更具体的分析。

• 更多的上下文

在AI对于数据分析的基础上，查找出对应数据的上下文，然后让其总结分析。

比起单纯的数据类告警，这种分析帮助研发节省下在不同平台里查询上下文的时间。举个例子，当我们收到监控平台报警，可能会需要去埋点上报、流量监控等多个平台再去找一些次级数据，验证一些初步的判断。

在这一步，「如果可以自动化的取到数据，然后给出初步的分析，就可以提高处理的效率。」

• 趋势性的数据分析

把尽可能多的数据提供给 AI，相当于 AI 帮我们观察了各种 dashboard，比如很多需要人去分析得出的尖刺，就可以让 AI 去查找。「相比写」 「死代码」 「去分析，更加的智能弹性和节省开发人效。」

数据分析的实践

目前 PAI 的数据分析，即遵循了这样的步骤：

1. 观察整体PAI数据，分析出有尖刺的时间点
2. 在有尖刺的时间点内，给出PAI的全部次级数据，深入分析
3. 基于次级数据查找监控平台的对应错误，提供上下文以供分析
4. 总结所有分析，并结构化数据发出推送卡片

总结

一个很深入的感受是，随着 AI 能力的进化，对 AI 的使用反而应该更加的精细。

使用他要像对待一位新加入的同事，如果要让他负责你日常中的运维管理工作，你需要注意：

1. 整理好并清晰的告诉他「做这件事的步骤」
2. 准确的提供数据和「保持」 「语义」 「化」
3. 尽量「充分的上下文」

结语

回顾过去的一年，AI 技术的飞速进步已深刻改变了团队的工作方式，也让我们逐渐认识到，「AI 早已不再是遥不可及的梦想，而是我们日常工作中的得力助手。」

团队在过去一年中对 AI 进行了大量的探索和研究。AI 单测的引入如及时雨，不仅提升了测试覆盖率和代码质量，还显著减少了人工修复的成本。AI 在内容审核领域极大地提升了审核员的工作效率和质量。在开发效率方面，AI 提供了全方位的智能代码补全、自动化代码审查、代码生成与重构、代码审查自动化等能力，涵盖了开发的方方面面，这极大的提升了我们开发效率。「尽管目前 AI 相关工具还有很多不足之处，但 AI 发展的速度已让我们不得不正视起来。未来，当模型的准确性进一步提高，AI 有望在开发和生产的各个环节中提供更加全面和高效的解决方案。」

技术的进步和应用场景的拓展，预示着 AI 将在我们日常开发中扮演愈发重要的角色。通过与 AI 的协作，我们相信技术生产力将达到新高度，为用户带来更好的体验。在这场技术革命中，我们迎风破浪，勇敢前行。以更开放的心态拥抱变革，用创新推动技术进步。每次新场景的落地和应用，都是团队智慧与汗水的结晶。

「未来已来，我们早已做好准备，你呢？」