在快手全面推进“AI研发范式升级”的进程中，如何将个人使用AI带来的效率提升，转化为组织整体的交付效能，是必须攻克的核心命题。智能代码审查系统正是破解这一命题的关键环节——它作用于个人开发完成之后、团队交付合并之前，通过质量过滤和知识沉淀，让AI能力从“私人助理”升级为“团队协作者”。本文旨在通过梳理快手智能代码审查系统（Smart Code Review，以下简称智能CR）从1.0到3.0的完整演进历程，为开发者社区提供一份关于如何构建高可信、高采纳率自动化评审工具的系统性参考。欢迎对此话题感兴趣的开发者到 云栈社区 的 后端 & 架构 板块深入交流。
在传统研发流程中，Code Review（代码评审）往往面临人工复核成本高、标准不统一、评审深度难下沉的结构性痛点。本文总结了快手智能代码审查系统从“纯LLM启发式”到“知识引擎+规则确定性”，再到“Agentic自主决策”的三代架构演进。
针对AI幻觉这一核心顽疾，快手技术团队通过构建上下文引擎与沉淀1,100+条确定性规则，辅以三层过滤与BadCase反例库，将评审采纳率从7.9%跃升至54%，并将MR评审时长80分位显著缩短9.9%；通过“知识工程”提升大模型准确性，让智能评审真正落地为可信赖的生产力工具，也为AI时代如何实现“个人提效→组织提效”的传导提供了可复用的实践样本。
一、背景
1.1 效率与质量的博弈：传统CR模式的固有痛点
在快手高速迭代的业务场景下，代码变更的规模与日俱增，传统的人工代码评审模式逐渐不堪重负，其固有的三大痛点日益突显：
- 效率低下，响应看“缘分”：当代码变更量级较大时，人工CR的成本显著增加。评审周期被拉长，响应时效完全取决于Reviewer的忙闲程度，一个核心仓库的MR排队等待48小时已是常态，严重影响了业务交付的整体速度。
- 低级错误，防不胜防：人类的认知注意力是有限的。评审者在面对复杂逻辑时，往往会潜意识地忽略那些看似简单的低级错误。例如，
if((a || b) && c)在删除条件b时误改为if(a || c)，或出现 a.setId(a.getId())这样的明显赋值错误。然而，数据表明，这类“低级失误”在代码变更引发的线上故障中占有相当高的比例。
- 效果不稳，知识难传承：评审质量的高度依赖于评审者的经验和认知负荷。资深工程师的宝贵经验和隐性知识难以系统化沉淀为团队共识，而初级开发者则因经验不足容易遗漏深层缺陷。这种不稳定性导致代码质量时好时坏，增加了生产环境的风险，并阻碍了团队内部知识的有效传承。
1.2 AI的引入与新挑战：如何破除“信任危机”
面对传统CR的困境，智能化被视为必然出路。然而，在初期引入大模型进行代码评审时，我们遭遇了典型的AI信任危机，主要表现为如下几方面：
- “幻觉”问题：AI基于片面代码片段进行推断，容易产生大量不准确或错误的误报，降低了评审结果的可靠性。
- 低价值建议：AI生成的评论中包含大量通用性、无实质价值的建议，如“建议优化”、“可以考虑”等，导致开发者疲劳，降低了采纳意愿。
- 上下文缺失：仅分析Git Diff片段，无法理解代码在系统中的完整作用。
- 知识不可控：大模型的“黑盒”特性使得评审标准的沉淀和传承变得困难，难以形成统一的团队规范。
这些问题导致AI评审评论质量较低，开发者普遍产生抵触情绪，采纳率长期徘徊在10%以下，严重影响了智能CR工具的推广和应用。
二、效果
快手智能CR取得的效果如下：
- 评论质量稳步提升：评论采纳率持续提升，从智能CR1.0阶段的不足10%稳步上升，现阶段已稳定在50%+。
- 助力评审效率提升：2025年全年相对于2024年，快手MR评审时长80分位下降9.9%，从7.07小时下降到6.37 小时。特别是从2025年6月开始，评审时长呈现明显下降趋势，时间线与智能CR在公司层面大范围推广落地时间高度吻合。
- 覆盖规模与深度：智能CR在快手完成公司级落地，MR覆盖达74%，支持Java、C/C++、JS/TS、GO等主流语言，沉淀1,100+条CR规则。
三、实践1：核心技术实现—从启发式到确定性与自主性融合的演进
在智能CR系统的建设过程中，快手始终秉持一个核心理念：工具不仅要“可用”，更要成为开发者“可信赖”的智能伙伴。整个智能CR系统经历了三个关键演进阶段：从最初的「纯LLM启发式评审」到「知识引擎驱动的确定性评审」，再到最新的「Agentic自主决策评审」，每一次演进都是对前一阶段核心问题的系统性解决，持续推动系统向更高可信度和实用性迈进。最终构建了一套高可信的智能CR框架，实现了从基础功能到高可信评审能力的跨越。
3.1 智能CR1.0：纯LLM启发式评审探索期
为解决人工CR的痛点，快手在2024年Q2开始引入LLM建设智能CR的探索，整体设计采用“粗筛 + 精评 + 过滤”的三步串联流水线。
3.1.1 核心流程
- 步骤 1：CR必要性判断
- 输入：MR Diff片段
- 输出：布尔值（true/false）
- 目的：过滤无需评审的MR，降低成本
- 步骤 2：Review生成
- 基于模糊任务描述，LLM进行启发式评审
- 检查项：语法/逻辑错误、性能问题、安全漏洞、可读性、命名规范等
- 关键字检测：XSS相关API（dangerouslySetInnerHTML、v-html、innerHTML 等）、base64编码字符串
- 步骤 3：评论过滤
- 基于规则删除低价值评论：注释/版权建议、未定义对象问题、CSS问题、无效行号等
3.1.2 核心问题
- 上下文严重不足：仅提供MR Diff片段，缺少完整方法体和跨文件依赖。模型无法理解代码在系统中的完整作用，误判率高。
- 知识体系缺失，召回稳定性差：无规则库支撑，完全依赖模型“黑盒”能力。团队知识无法沉淀和传承。评审标准不统一，质量波动大。
- 任务定义过于宽泛：给模型的指令缺乏Know-how，过于依赖模型自主理解。检查项描述模糊（如“性能问题”、“安全问题”）。缺少具体场景和示例，模型难以准确把握评审重点。
- 优化手段有限：对于BadCase缺乏可操作的优化路径。无法系统性改进评审质量。
3.1.3 阶段总结
- 数据表现：评论采纳率7.9%，评论质量差、误报多、无价值建议泛滥。
- 技术验证：证明了AI代码评审的技术可行性，暴露了纯LLM驱动模式的根本性缺陷。
- 演进方向：构建工程化的上下文构造机制，建立领域知识体系（规则库、最佳实践），设计多层次质量保障机制。
3.2 智能CR2.0：知识引擎驱动的三阶段确定性评审
针对智能CR1.0阶段的上下文不足、知识缺失、质量不稳定和调优成本高的痛点，我们在深入分析问题后，摒弃了“纯LLM驱动”的思路，结合领域知识和工程链路，构建了“上下文工程 + 规则驱动评审 + 评论价值评估和BadCase拦截保障”的确定性评审框架，通过规则提供高确定性的知识，为LLM划定评审范围和重点，再结合LLM强大的代码理解与逻辑推理能力，两者的互补与融合确保评审结果的准确性和可解释性，实现了从基础功能到高可信评审能力的跨越。
3.2.1 上下文智能构造引擎
为解决“上下文缺失导致误判”的痛点，我们构建了多层次的上下文理解能力，旨在全面、准确地理解代码变更的“全貌”。从原始Git Diff到富上下文Prompt的生成，包含以下关键能力：
- 语言智能识别：自动识别Java、JS/TS、Go等10+种编程语言，适配差异化分析策略。
- 方法体扩展：突破Git Diff片段限制，从diff行扩展到完整方法体，避免断章取义。
- AST深度解析：通过抽象语法树理解代码结构语义和控制流。
- 跨文件依赖推断：识别接口、方法之间的调用关系，评估变更的潜在影响范围。
- Diff智能切分：将大型变更集拆分为逻辑独立的评审单元，突破token窗口限制，提升评审聚焦度。
- PRD 需求关联：通过关联需求文档（PRD），进一步丰富上下文信息，确保评审建议与业务目标对齐。
3.2.2 Map-Reduce长上下文处理
智能CR推进落地过程中，出现了因为大MR或大规则集导致模型注意力不集中引起漏召甚至超出模型上下文窗口的问题，我们采用类似于Map-Reduce的分布式处理逻辑，将长上下文问题分解为拆分→处理→合并三个阶段。
- 阶段1：Map阶段（拆分）：将大型Diff按照逻辑独立性进行智能切分
- 文件级分组：按修改文件进行初步分组
- 功能块识别：利用AST分析，识别相关的函数、类、模块等逻辑单元
- 依赖关系分析：分析不同块之间的依赖关系，确保切分不破坏逻辑完整性
- 大小均衡：确保每个分割后的Diff大小在LLM可处理范围内
- 阶段2：Process阶段（处理）：对每个拆分单元进行上下文融合和评论生成，规则引擎与LLM联合工作。
- 阶段3：Reduce阶段（合并）：通过分类、相似度计算、聚类合并和优先级排序，将多个单元的评论整合为高质量输出。
3.2.3 价值评估过滤体系：从“废话”到“金句”
为了从海量评论中筛选出真正有价值的“金句”，快手建立了三层价值评估过滤体系。
- 第一层：基础噪声过滤
- 通用废话模式识别：自动过滤“建议优化”、“可以考虑”等无实质内容评论
- 重复建议合并：相似评论智能聚合，避免信息过载
- 明显误判拦截：修改建议与源代码一致等
- 第二层：准确性校验，确保每条评论都具备充分的证据和合理性
- 证据充分性评估：评论必须有具体且合理的代码位置和问题描述
- 规则匹配度验证：检查评论是否基于有效规则触发
- 上下文一致性：确保建议在当前代码上下文中合理
- 第三层：价值密度评估，聚焦真正重要的问题
- 问题严重性分级：基于规则等级和上下文证据，将问题分为 P0（阻塞）、P1（严重）、P2（主要）等不同级别
- 影响面和开发者友好度评估：优先呈现高优先级的建议；根据变更大小动态调整单次评审输出的评论数量限制，避免评审疲劳；尽可能为每条评论提供具体的修改建议或示例代码
3.2.4 RAG增强的BadCase智能拦截
引入价值评估过滤体系后，透出的评论质量有明显提升，但日常分析BadCase过程中，识别到依然有部分误判评论透出，针对AI“幻觉”问题，我们建立了主动防御机制，LLM评估当前评论是否与历史BadCase属于同类误判，分析误判的根本原因：上下文误解、规则过严、场景不适等，动态调整评审策略，避免重复出现同类幻觉误判的情况。
(1) 历史BadCase向量库构建
- 构建已验证误判案例的BadCase向量数据库
- 收集用户反馈的所有误判案例
- 人工验证并标注误判类型和原因
- 提取BadCase的语义特征
- 使用多维度Embedding建立语义索引
- 对BadCase的问题描述、代码上下文、评论内容进行向量化
- 建立高维语义空间索引
- 支持快速相似度检索
(2) 实时BadCase检测流程
- 实时相似性检索
- 每条生成评论都进行BadCase匹配检查
- 计算评论与历史BadCase的向量相似度
- 识别潜在的同类误判
- LLM自检
- 当相似度超过阈值时，触发LLM自检
- LLM评估当前评论是否与历史BadCase属于同类误判
- 判断是否存在相同的错误模式
- 根因分析
- 分析误判的根本原因
- 上下文理解错误：缺少关键上下文导致误判
- 规则应用过严：规则在特定场景下不适用
- 场景识别失败：未能正确识别代码使用场景
- 记录分析结果，用于后续优化
（3）策略动态调整
- 根据根因分析结果调整评审策略
- 对同类场景应用修正后的评审逻辑
- 避免重复出现同类幻觉误判
3.2.5 阶段总结
通过系统性引入上下文工程、规则知识体系和多层质量保障机制，CR2.0架构从根本上解决了CR1.0的核心问题，将智能CR从“能用”提升到“好用”，实现了评论采纳率从7.9%到54%的跨越式增长，重建了开发者信任。
3.3 智能CR3.0：Agentic自主决策评审
智能CR2.0虽已显著提升评审效果（综合采纳率达54%），但在实际应用中暴露出三个层次的局限，制约了系统向更高层次演进。
(1) 上下文获取灵活性有限
上下文的获取采用工程化预定义策略，缺乏运行时自适应能力。这导致两个极端问题：一方面容易出现“过度获取”，将大量无关代码纳入上下文，造成token浪费并干扰模型注意力；另一方面又可能“获取不足”，对于需要深度分析的复杂场景，预定义策略无法动态扩展上下文范围，限制了分析深度。
(2) 深度缺陷识别能力边界
对于跨服务依赖分析、长调用链路追踪、架构级风险识别等复杂场景，预定义流程难以完全覆盖。系统缺乏自主探索能力，无法根据问题特征动态调整分析策略，导致在处理大规模重构、架构变更等复杂场景时存在明显短板。
(3) 创造性评审缺失
规则驱动模式虽能保证确定性和稳定性，但在创造性方面存在不足。系统难以产生让开发者“眼前一亮”的洞察性建议，评审深度主要停留在代码层面，缺乏对架构设计、业务意图的深层理解。
为此，我们继续推进系统向Agentic模式演进，核心思想是“该快则快、该深则深”，构建“自主规划 + 双路并行 + Agentic智能体”的确定性与创造性融合框架。
- 对于标准场景：保持CR2.0高效稳定的确定性流程
- 对于复杂场景：引入Agentic自主决策能力，实现从被动检查到主动协作的本质转变
为了降低团队AI场景Agentic建设成本，我们建设了一套以Metadata驱动的声明式可扩展AI Agent底座，旨在通过统一的底层能力和声明式扩展机制，支持快速构建领域特定的AI Agent应用。
- 应用层：通过注入业务规则、声明式配置工具和提示词，即可实现完整的Agent功能。
- Agentic底座层（核心）：提供五大核心能力——AgentExecutor（声明式执行引擎）、Tool Orchestration（工具调用编排）、Skills Manager（动态技能管理）、History Manager（历史管理）、Context Manager（上下文管理）。所有能力均通过METADATA动态驱动引擎实现，支持运行时动态加载和组装。
- 声明式扩展层：通过MCP Protocol、Skills、Tools、System Prompt四种扩展机制，支持热插拔式能力注册。基于FunctionDeclaration和AgentDefinition的声明式设计，使得扩展开发和集成变得简单高效。
- 基础设施层：提供沙箱隔离、本地操作、无状态化等基础能力，保障Agent的安全性、可靠性和可扩展性。
3.3.2 Planning智能规划层
Planning层作为MR级别的全局路由决策器，负责分析变更特征并智能决策评审路径。
（1）分析维度
- 变更复杂度量化
- 代码变更规模：修改文件数、代码行数、变更密集度
- 影响范围识别：跨文件/模块依赖、核心接口变更
- 逻辑复杂度：圈复杂度、嵌套层级、分支数量
- 规则特征识别
- 规则类型分类：标准通用规则 vs 需深度理解的特殊规则
- 上下文需求评估：预定义上下文是否充分、是否需动态扩展
- 执行复杂度预估：计算成本、多轮推理需求、外部工具依赖
（2）路由策略
- CR2.0版本三阶段架构：简单MR + 标准规则 → 高效、稳定、成本低
- Agentic 链路：复杂MR + 特殊规则 → 深度分析、灵活应对
3.3.3 双路并行架构
（1）路径一：CR2.0确定性链路
沿用CR2.0成熟架构，适用于标准评审场景。处理流程为：预定义上下文构造 → 规则匹配与LLM推理 → 三层价值过滤 → BadCase拦截。
- 核心优势
- 高吞吐：预定义流程，平均处理时间<1分钟
- 高稳定：基于成熟架构，质量基线有保障
- 低成本：Token消耗可控
（2）路径二：Agentic自主决策链路
CR3.0核心创新，适用于复杂/深度分析场景。
- 核心优势
- 自主上下文获取：采用ReAct思考-行动循环机制，实现上下文自主规划获取，确保有充足的依据支撑评论产出。
* **Agentic评论生成**：基于充分的上下文信息，Agentic评论生成具备三大深度能力：
* 深度逻辑推理：完整系统理解、潜在影响分析、架构层面洞察
* 跨边界分析：调用链追踪、跨服务一致性检查、系统级风险识别
* 业务意图理解：需求对齐检查、业务逻辑验证、用户体验评估
3.3.4 Agentic 评论评估智能体
CR3.0将评论评估环节升级为Agentic智能体，实现从规则评估到智能评估的跨越。
技术实现：
- 深度语义理解：评论价值深度理解、开发者需求洞察、上下文敏感判断
- 动态质量标准：场景自适应、团队规范适配、价值密度优化
- BadCase 拦截：保留CR2.0的RAG向量库机制，双重保障（Agentic智能评估 + BadCase向量库拦截）
3.3.5 阶段总结
智能CR3.0阶段，采用双链路模式驱动，对于标准场景，保持CR2.0的高效稳定，预定义流程，成本可控，对于复杂场景，提供深度分析能力，自主获取上下文，发现系统级、架构级问题。既有确定性保障，又有创造性突破，“该快则快、该深则深”。
四、实践2：知识自进化—越用越智能的知识底座
4.1 研发知识自进化：将隐性经验转化为可执行的评审规则
传统代码评审高度依赖工程师的个人经验，这些“隐性知识”难以规模化传承。我们通过系统化方法，构建了四层规则体系，将团队智慧转化为可复用的评审能力。通过业务场景驱动的代码评审，将隐性知识显性化，构建了四重维度的规则来源体系：
- 故障回溯规则：分析近两年公司线上问题的根因，提炼预防性检查规则（如空指针防护、资源泄漏检查）。
- 防坑指南与最佳实践标准化：将团队在实践中积累的典型“坑点”、编码规范、性能优化等经验固化沉淀为规则。将“事后救火”的经验转化为“事前预防”的检查规则。涵盖性能优化（如数据库查询、缓存使用、并发控制）、安全防护（如输入验证、权限校验）等关键维度。
- 历史评审知识挖掘：利用AI辅助分析历史人工评审评论，识别资深工程师的评审关注点和判断逻辑，提取高频问题模式，挖掘“潜规则”：团队约定俗成但未文档化的质量标准。
- 业务定制规则：支持各业务团队根据自身特性配置专属检查项，实现垂直场景的精细化管理。
通过这一体系，快手将碎片化的评审经验系统化，形成了覆盖代码质量、性能、安全、可维护性、最佳实践多个维度的规则库，累计规则数超过1,200条。这显著提升了团队的整体代码质量与稳定性。
4.2 实现自进化：构建数据驱动的持续改进闭环
快手智能CR系统能够不断提升并长期保持高采纳率的关键在于其数据驱动的自进化闭环。这一机制确保了系统能够根据实际反馈不断学习和优化，实现“越用越准、越用越智能” 。
- 反馈智能收集：开发者对每条评论的采纳、拒绝、修改等行为都被自动记录，作为系统学习的宝贵数据。
- 根因深度分析：每周分析BadCase，找出系统薄弱环节，并对其进行迭代改进。
- 渐进式优化：小步快跑，每次优化都经过严格A/B测试验证，确保每次迭代稳健有效。
- 知识持续沉淀：将验证有效的模式固化为新规则，不断丰富和更新团队的知识库，形成规则本身的自进化。
五、实践3：产品与运营策略—从精准试点到规模化落地
解决的问题：
- 如何让开发者无感接入，降低使用门槛
- 如何适配不同团队、仓库的差异化需求
- 如何从试点到规模化推广，建立用户信任
- 如何从“增量把关”延伸到“全链路质量护航”
5.1 无缝的研发体验：“滑滑梯”式集成
工具的价值在于使用，我们致力于将智能CR无缝集成到开发者日常工作中，做到“润物细无声”。
- 场景集成：
- 在开发者创建或更新MR时自动触发全量或增量评审。
- 通过IDE插件，将评审能力左移到编码阶段，实现即时反馈。
- 支持基于分支合并方向、MR标签等信息的自定义触发策略。
- 评审规则适配：
- 支持团队和仓库维度的规则自定义，满足不同业务的差异化需求。
- 针对大仓、多团队协作仓库和多技术栈仓库存在细粒度评审规范的诉求，我们建立了基于仓库路径、代码文件开发语言、MR发起人等。
5.2 循序渐进的推进策略
快手智能CR在落地过程中，采用渐进式推广方式，从精准试点开始，通过迭代优化建立信任，利用口碑效应扩大影响，最终实现全面规模化覆盖。
- 精准试点：选择对新技术接受度高的团队作为试点，集中资源打造成功案例，为后续推广奠定基础。
- 迭代优化：基于试点团队的反馈持续优化产品功能和体验，建立用户对产品的信任和依赖。
- 口碑推广：利用成功标杆的示范效应，吸引其他团队主动接入，形成自发的推广动力。
- 全面规模化：根据不同团队的特点制定差异化策略，最终实现全公司范围内的全面覆盖。
最终通过以上策略，在快手内部实现74%的MR智能CR覆盖。
5.3 开放共建生态：能力边界拓展
为拓展智能评审能力的边界，我们与各业务团队深度协作，共同打造了覆盖存量治理、业务逻辑和安全专项的三大共建能力，推动智能CR从“增量把关”走向“全链路质量护航”。
5.3.1 共建能力1：仓库级智能扫描——存量代码“深度体检”
- 背景：
- 存量代码引发线上问题占比高：2024以来年业务部门代码问题导致的线上问题中，其中有32%是源自存量代码问题。
- 存量问题发现成本高：存量问题发现成本高、治理推进难，成为业务稳定性的潜在隐患。
为此，我们与生活服务部门共建仓库级智能扫描能力，旨在以较低成本实现系统性隐患挖掘与闭环修复。
- 建设内容：
- 全量代码分析：利用AI对指定代码仓库进行深度扫描，快速识别编码缺陷、性能瓶颈及线上隐患。
- 问题分级与分发：对发现的问题进行严重程度分级，生成扫描报告，并分配至相应负责人，推动问题跟踪与修复闭环。
- 效果与挑战：
- 在试点业务仓库中，扫描准确率75%。
- 扫描问题示例：智能扫描发现前端代码中提示文案与实现逻辑不一致的问题。
说明：前端界面提示用户可上传10M大小的文件，但代码逻辑限制文件大小不能超过2M，严重影响用户使用。这类跨端的一致性检查是 运维/DevOps/SRE 质量保障中容易被忽略但影响巨大的问题。
5.3.2 共建能力2：业务逻辑评审——从“代码正确”到“业务正确”
- 背景：通用智能CR难以判断代码是否与业务需求一致，无法识别业务类缺陷，因此我们与商业化团队共建业务逻辑智能评审，旨在实现从“代码评审”到“业务逻辑校对”的跨越。
- 建设内容：
- 需求文档解析：自动关联代码变更与对应的需求文档（PRD），利用AI提取关键功能点，并将其转化为结构化上下文。
- 需求-代码比对：以标准化的需求描述为基准，由智能评审任务比照代码实现，识别业务逻辑层面的不一致、缺失或错误。
- 场景化提示：针对识别出的偏差，生成具体、可操作的业务逻辑建议，辅助开发者确认实现与需求对齐。
- 效果与挑战：该能力已在部分业务中试点，初步验证了技术路径的可行性。当前核心挑战在于对非标准化需求文档的深度理解与功能拆解，未来将重点优化需求理解能力，强化与业务场景的结合。
- 评论示例：
5.3.3 共建安全CR：将安全左移至开发早期
- 背景：为贯彻“安全左移”理念，快手与安全团队合作，将专业安全检测能力集成至 Code Review阶段，力求在代码入库前早期发现并修复安全漏洞。
- 建设内容：
- 安全检测Agent集成：接入安全团队提供的专业检测能力，以Agent形式融入到智能评审流程，识别注入、泄露、越权等常见安全问题。
- 评审建议融合：将检测出的安全漏洞以代码评审评论的形式直接呈现给开发者，提供修复建议与依据。
- 效果与挑战：试点期间，系统已帮助开发者识别并确认有效安全漏洞约200 个。当前采纳率约25%，反映出在漏洞检测准确性方面仍有优化空间。后续将持续协同，聚焦提升精准率与开发者接受度。
- 评论示例：
六、展望
快手智能CR的目标不止于发现代码层面的问题，未来还将致力于如下方向工作：
- 能力拓展：实现跨代码仓库的长链路缺陷识别，理解需求变更引发的跨服务、跨仓库的所有代码改动，识别潜在的链路级风险。
- 自动修复：对于高置信度的问题，提供“一键修复”能力，将开发者从重复的修复工作中解放出来。
最终，快手希望将智能CR打造为一名“架构顾问”，能够在需求设计和编码阶段就提供前瞻性的架构建议和风险预警，进一步提升研发效能和系统质量。这类关于 Agent智能体 在复杂工程场景中落地的探索，正是当前技术社区的热点。
快手智能CR的演进历程，是一次将AI能力深度融入研发核心流程、并不断解决实际信任与效果问题的系统性工程。从7.9%到54%的采纳率飞跃，背后是架构、知识、运营三方面的持续深耕。希望快手的实践能为业界探索AI赋能研发效能提供有价值的参考。
发表于 1 小时前
|
查看: 3|
回复: 0
