代码智能化在互联网大厂的规模化落地实践
今天想和大家聊聊一个火热又充满挑战的话题：代码智能化。最近两年，我和团队与时俱进加入到 AI 的时代浪潮中，亲身经历了代码智能化在万人研发企业中从“早期尝试”到“范式变革”的持续演进和规模化落地过程。
这个过程充满了探索、试错、惊喜和思考。今天我并不想谈什么高大上的概念，而是想把我们踩过的坑、总结出的方法论、看到的前景，原原本本地分享给大家。文章会分为四个部分：
宏观视角：我们当前正处在 AI Coding 技术变革的哪个阶段？未来将走向何方？
具体场景：在万人规模的公司，我们是如何将 AI Coding 以三种产品形态，在四个核心研发场景落地的。
技术实践：我们在代码补全、智能对话、代码评审和单元测试场景下的核心实践。
未来展望：当代码生成不再是瓶颈，我们下一个挑战是什么？
一张图看清 AI Coding 的过去、现在与未来
我们先来看一张图，这张图概要地描绘了代码智能化及研发范式的演进路线。
（图 1：代码智能化的演进路线）
这张图的横轴是时间，从 2022 年（过去）到 2025 年（现在），然后一直延伸到 2027 年（未来），纵轴代表了不同研发范式的采纳规模或影响力。
黑色的“传统手工编程”曲线：正如大家所知，自 2022 年 GitHub Copilot 惊艳亮相以来，纯手工编程的模式就开始受到挑战。开发者通过“幽灵文本”就能直接用 Tab 生成代码，这使得手工编程的使用量和主导地位逐步下滑。
绿色的“代码补全”曲线：这是 AI Coding 的第一波浪潮。从 22 年到 24 年，几乎所有公司都在“卷”代码补全。大家比拼的核心指标就是“采纳率”和“生成率”。这条绿线在初期涨得非常猛，并在 2024 年达到了顶峰。但目前已经遇到了增长的瓶颈，现在已经有更强大的研发范式作为补充，未来可能是替代关系。
紫色的“基于对话的代码生成”曲线：它不再是简单的补全，而是通过对话理解需求，帮开发者生成、修改甚至重构代码。这条线的斜率非常陡峭，意味着它正以极高的速度提升生产力。
橙色的“基于智能体”的曲线：这比 Chat 模式更进一步。我们不再是与 AI 一问一答，而是将一个完整的需求、一个任务“委托”给一个或多个 Agent。它们能够自主规划、拆解任务、调用工具、修改代码、运行验证，端到端地完成工作。这是我们今天正在积极探索的方向。
蓝色的“Agent 集群/舰队”曲线：我们合作的对象可能不仅仅是一堆 Agents，而是一个“Agent Manager”。你向它下达指令，它会去调度和指挥一个由多个专精 Agent 组成的“舰队”协同作战。
今天，我们处在 2025 年 7 月份这个时间点，正是上图绿、紫、橙三条曲线激烈交织的区域。这意味着在我们的日常工作中，代码补全、对话式编程和初步的 Agent 应用正同时存在。下面，我就带大家深入这几个“战场”，看看在真实的万人研发环境中，它们是如何落地的。
规模化落地：三大产品形态与四大核心战场
在腾讯，我们有数万名工程师，每天都在用我们提供的 AI Coding 产品开发各种业务系统，比如大家熟知的 QQ、微信、王者荣耀等等。我把这些落地实践总结为“三种产品形态”和“四个场景”。
三种产品形态：AI 能力如何触达开发者？
IDE 插件形态：这是最基础、最普遍的形式。比如我们给 VS Code 安装插件就具备了智能化能力，它轻量、易于上手。
AI 原生 IDE：这是更进一步的形态。突破原生 IDE 的 API 限制，将 AI 能力更深度的融入其中。比如现在大家熟知的 Cursor，以及字节、阿里、百度的相关产品，还有腾讯即将对外商业化的 AI 原生 IDE，都是致力于为开发者提供更无缝、更强大的用户体验。
Web 端：除了在 IDE 里写代码的开发者，我们还有很多“小众”一些编码场景，如数据分析师写 SQL，SRE 写运维脚本等。这些场景同样重要，虽然不是在 IDE 里面写代码，但也需要代码智能化，这些场景我们通过 Web 编辑器等模式去覆盖。
四大核心战场：AI 在研发流程中具体做什么？
代码补全：专注 IDE 编辑区的代码自动生成，结合上下文提升推荐准确性。
智能对话：提供实时编码指导和快速代码问答，帮助用户更好地理解、生成代码。
智能评审：支持代码提交前后的智能评审，并提供基于 AI 的快速修复功能。
单元测试：提供能直接执行的单元测试，帮助快速提升单测覆盖率。
代码补全：从基础 FIM 到全链路优化
这是 AI Coding 的第一个战场，也是目前最成熟的领域。
我们常说的代码补全，其核心任务叫做 FIM（Fill-in-the-Middle）。模型根据光标前的“上文”和光标后的“下文”，去预测并填充中间缺失的代码。但这种基础的补全方式绝不仅仅是拼凑上下文并调用模型 API 那么简单。它背后是一条完整的、经过深度优化的工程链路，从收集上下文信息的客户端、到负责路由和分发的网关、到负责场景识别和 Prompt 策略的后台，最后是模型训练和模型推理。
度量体系：告别虚荣指标，拥抱“CPO”以上每个流程步骤都涉及到非常多的细节，那我们在具体应用中应该从何下手呢？
我的建议是基于目标，对每个要素进行分解和优化。
对于代码补全这个场景来说，“采纳率”是最常见的指标，但它很容易被操纵。比如我们让工具只在最简单、最有把握的场景进行代码补全推荐，采纳率可以飙得很高，但对用户的实际价值并不大。
基于上述背景，我们借鉴并使用了业界提出的一个更科学的复合指标——CPO。它由一系列子指标相乘得到，能更真实地反映 AI 补全为用户带来的实际价值。
CPO = 尝试率 × 反馈率 × 采纳率 × 每次采纳平均 Token 数 × Token 平均字符长度
我们来拆解一下：
尝试率：AI 有多频繁地尝试给你推荐？如果 AI 总是不推荐，价值就无从谈起。
反馈率：推荐的内容有多大比例被你看到并反馈？这是个很关键但容易被忽略的指标。如果模型推理太慢，你手速又快，代码都敲完了，推荐结果才出来，那这次推荐就是无效的。
采纳率：你看到推荐后，有多大比例按下了 Tab 键（接受采纳）？这直接反映了模型能力的强弱。
采纳长度：这反映了补全的“粒度和质量”，是补全了一个词还是一个函数体。
我们对于代码补全的优化，就是围绕这个 CPO 指标，在全链路的各个环节持续进行。
智能对话与 Agent：从“陪聊”到“干活”
前面讲了这么多，不难看出代码补全能力的发展已经快到天花板了，下一步就是基于对话的智能体。
从“说”到“做”去年到今年，以 Cursor 为代表的产品及 Claude 为代表的大模型能力，引发了一场革命。我们与 AI 的交互，从“你告诉我怎么做”（AI 返回文本），变成了“你帮我做”（AI 直接修改代码）。这是一个重大的范式转变。AI 从一个“顾问”，变成了可以上手的“员工”或“助手”。
从 Chat 到 Agent
Chat 模式：通常是一问一答、无状态的。适合临时、简单的任务。
Agent 模式：是多轮交互、有状态的。它能自主规划、使用工具、并根据结果进行反思和调整，端到端地完成一个复杂任务。
Agent 的背后：Prompt、MCP、知识库要让 Agent 高效工作，背后需要一套完整的架构设计。
大模型能力是“上限”：Agent 需要推理与规划、执行能力，它的能力上限取决于大模型。业界有很多非常优秀的大模型，如 Claude4、Gemini 2.5 Pro、DeepSeek 系列模型，并且其能力还在快速演进。
Prompt 设计是“控制器”：首先要分 System Prompt 和 User Prompt。System Prompt 负责全局控制，设定 AI 助手的角色、框架和行为准则；而 User Prompt 则负责传入用户的具体问题、上下文历史以及环境信息。Prompt 设计是一套完整的工程体系，它通过结构化的指令、精细化的工具管理和智能化的信息压缩，将一个通用大模型“规训”成一个能够自主规划、精准调用工具并高效完成复杂编程任务的专业 AI Agent。
工具使用是“双手”：Agent 的能力边界取决于它能使用的工具。但这里有个坑：你不能把 100 个工具都塞给模型，这会让它“选择困难”。正确的做法是“工具精简”：先让一个轻量模型或规则，根据用户问题，从 100 个工具中筛选出最可能用到的 3-5 个，再交给主模型去决策调用。
CodeBase 可以提供“业务知识”：Agent 要修改代码，首先得理解代码。如何让它理解一个动辄几十上百万文件的代码仓库？通常有三种检索方式：
符号检索：基于 AST（抽象语法树）进行精确查找，比如找一个函数的定义。
全文检索：类似 Grep 的关键字搜索。
语义检索：基于向量数据库，能理解“等价语义”并查询，找到功能上相关的代码。
只有把这些要素结合，Agent 才能在我们庞大而复杂的代码库中游刃有余。
智能代码评审：让 AI 开口“一针见血”
“AI 做的代码评审效果不好”，这是很多人的普遍印象。没错，如果你直接用通用大模型，它给出的评审意见通常很“客气”、很“空泛”。我们的解法是：让 AI 知晓组织特有的代码规范。
我们把公司内部沉淀多年的、各业务线的代码规范文档，整理成一个结构化的知识库，然后把这些规则“注入”到模型中。在具体的代码评审中，我们会告诉模型：“请根据以下规则进行评审”，并附上相关的规则示例。这样一来，AI 的评审意见就变得极其具体和有说服力，开发者才愿意接受和采纳，这是目前一个很大的使用场景。在此基础上，我们还构建了“从提交前的 IDE 内预评审，到 MR 阶段的正式评审、代码修复”的闭环，大大提升了代码质量和评审效率。
智能单元测试：攻克“老大难”问题
单元测试是研发中的“老大难”，这个问题在 AI 出现之后依然没有好转，如果直接框选一段代码让 AI 生成单测，效果通常很差，代码多半跑不起来。
为此，我们把它变成了一个异步的、多阶段的 Pipeline。
被测代码分析：我们要分析被测代码的逻辑、调用链和外部依赖。
Prompt 组装：基于分析结果，我们会生成一个非常详细的 Prompt，里面包含了被测代码、上下文、依赖信息、项目使用的测试框架、Mock 框架以及代码风格要求。
单测生成：大模型根据这个“豪华”的 Prompt 初步生成单测代码，但这里产出的代码可能并不可用。
智能修复：初次生成的代码很可能编译不过，我们会捕获这些错误信息进行修复，根据错误日志去修改代码，直到编译通过、测试跑通。
整个过程对用户来说可能是异步的，用户发起一个单测生成任务，可以去干别的活。再回来时，一个高质量、高通过率、生产级可用的单测文件就自动生成好了。
未来展望：从“Pair”到“Peer”
讲了这么多实践，未来的研发模式会变成什么样？大模型发展太快了，当下是 Agent 元年，
从 Pair Programmer 到 Peer Programmer 最近听到微软前 CEO 在一次分享中提出的这个说法，深以为然。他说我们要从 Pair Programmer（结对程序员） 走向 Peer Programmer（平级程序员/数字员工）。
Pair Programmer：意味着 AI 和你必须“结对”工作，它无法独立完成任务，需要时刻引导。
Peer Programmer：意味着 AI 是一个“数字员工”，一个和你平级的同事。你可以把一个完整的任务委托给它，它能独立完成。
这正是 Agent 模式努力的方向。当下正是 Agent 的发展元年，接下来一个开发者可能不再是亲手写每一行代码，而是与一些 Agents 甚至是一个 AI Manager 协作。你向这个 Manager 下达战略意图，它会去调度和管理旗下的多个专精 Agent（需求分析 Agent、架构设计 Agent、编码 Agent、测试 Agent、部署 Agent…）协同完成。我们人类的工作，会更多地聚焦在创造力、复杂决策和系统性思考上。
但是有了这么一堆 Agent，研发效能就能提升吗？这里我想回顾一下软件工程中的一些基础理论。比如约束理论——当 AI 让编码本身不再是瓶颈时，瓶颈会转移到哪里？我听 Anthropic 的 CPO 分享过，他们用了 AI 工具后，开发者的编码速度和产出都大幅提升，结果导致每天产生海量的代码。新的瓶颈出现了：代码的 Merge 和上线。大量的代码提交导致了严重的合并冲突和集成问题。更上游的瓶颈也随之浮现：我们到底应该决定做什么？当“怎么做”的成本急剧下降时，“做什么”的决策就变得前所未有的重要。所以，研发效能的优化是一个持续识别并破解瓶颈的过程。AI 只是帮我们解决了旧的瓶颈，同时也会催生新的瓶颈。这需要我们用系统性的眼光去持续审视和改进、演化我们的研发体系。
最后的思考
大家或许见过那张著名的照片：马斯克用火箭把一辆红色的特斯拉跑车送上了太空，车里坐着一个叫 Starman 的假人。
去年，我们可能觉得大模型是“大规模应用”的元年。而今年，大家普遍认为是 Agent 元年。我们与大模型的交互，不应该再满足于像过去聊天一样简单地调用 API。我们应该考虑如何是设计、构造、训练出一个更好的 Agent， 然后让它帮我们更好的去思考、去规划、去完成任务。
这正是我们今天在 AI Coding 领域努力的方向——不仅仅是让 AI 成为我们的“副驾驶”，而是让它成为能够独立驶向星辰大海的“Starman”。
这条路还很长，但未来已来。感谢大家的阅读，希望能与各位同行一起，共同探索和构建这个激动人心的未来。
本文为张乐老师在 TiD2025-“数据 + AI：探索研发效能新范式”分论坛的演讲摘录，扫码可下载 PPT 材料：
数据分析驱动研发效能 2022-04-12 加入
思码逸研发效能分析平台，致力于帮助研发团队解决效率、质量和人才三大痛点，提升研发效率与软件工程质量，助力每一位开发者创造更多价值。
评论