2025 年注定不只是一个 “Agent 元年”,而是一个体系化跃迁的起点。在几个月过去,这个判断被不断印证,也不断被现实加速:
工具不再是工具,它们正成为开发流程的策划者与执行者。协作不是人与人,而是人与 Agent 们,还有 Agent 与 Agents。整个体系正在不断迭代, 然而我们所见证的:它并不是简单的提效,而是“放大” —— 即原来做得差的,现在会更差, ⚠️ AI 代码的副作用,比你想的要严重得多。
PS:在这篇文章里,我将使用“AI 代理”来指代 AI 智能体,因为代理更能体现它们的协作与执行能力。
在过去的半年里,我使用代码补全的频率显著降低。原因很简单:AI 智能体/代理的能力已远远超越了传统的代码补全。不只是能补代码,它们还能理解需求、预测操作, 并自动完成一系列开发任务——从生成代码、编写测试、执行构建,到校验结果、出错自动重试,全流程都能覆盖。我只需清晰描述目标 (太难了),AI 就能高效执行。
与此同时,AI 编程的竞争格局也发生了根本性的变化。如今,顶尖模型已经成为所有工具供应商都能接入的通用“智能引擎”,智能本身不再是差异化优势的来源。 真正的竞争,转向了围绕大模型打造怎样的工作流、用户体验与生态系统集成——谁能用这些能力构建出最具价值的开发平台,谁就能胜出。
这也解释了为什么市场上涌现出如此多的参与者:
背后的推动力主要来自两个方向:一是基模型在理解、推理、上下文保持方面能力的跃迁;二是 Agentic 能力的成熟。这些进展降低了对自研或微调模型的依赖, 使得向量化模型、FastApply、NES 预测等架构成为可选项,而非刚需。
正确使用 AI Agent 的方式应该是:
而由于编程可靠的提示词过程太复杂,我们通常不愿意这么做,进而导致 AI Agent 编程生成的质量参差不齐。大力飞砖,还是比较好玩的。
因此 AI Agent 编程在过去几个月里经历了一个显著的转变:从“代码直接生成”到“计划先行,代码后行”,这种转变不仅提升了代码质量,还让过程透明, 进而让结果更加可控。我们可以看到越来越多的 AI 编程代理开始采用这种方法:
TodoRead
, TodoWrite
工具来实时更新任务列表,确保开发过程中的每个步骤都被记录和跟踪。update_plan
在过程中动态更新任务计划,确保开发者可以随时查看当前进度和待办事项。即由 AI 辅助人去生成初步 Task,然后人去审查,直到代码质量达标。
在我们先前的《AI 编码 2.0 分析、思考与实践:从 Cursor Composer 到 AutoDev Sketch》里, 我们介绍了看到的 AI 编程工具 2.0 的核心特点:
AI 编程工具正在从代码补全、代码预测,到更加智能、更耗费 token 的 AI 自动化编码与验证,以及正在发展中的异步 AI 编码。
基于这些特点,我们认为 AI 编程工具 2.0 的核心应该是:
在过去的几个月里,我们看到 AI 编程工具 2.0 的自动化校验能力得到了显著提升,特别是 Claude 与 Augment 在这方面展现了非常强大的能力。自动验证 不再只是单元测试,而是类似人类的代码校验技巧:
通过大量的自动化校验,可以降低人来审查代码的负担,进而让 AI Agent 编程更像是一个“闭环”的过程。
AI 编程的另一个重要趋势是异步化,诸如:Augment Remote Agent、Cursor Backend Agent。过去,AI 编程主要依赖于前台的交互式体验, 即开发者在 IDE 中直接与 AI 交互,实时生成代码和验证结果。而现在,AI 编程正在向后台异步执行转变,这种转变带来了更高的效率和更低的心智负担。 你只需要 review AI 给你的 PR 即可,
尽管 AI 编程的异步化仍处于早期阶段,但它已经展现出巨大的潜力,你可以将
当然了,AI 编码并非单一技术的突破,而是三大关键技术支柱——远程开发基础设施(VSCode Server 等、代码库集成)、 上下文引擎和模型上下文协议——协同演进的产物。
PS:随着,AI 编程工具在工程化落地的增强,在未来,我们可能要面临的问题,没有足够的 backlog 能给 AI 在后台进行编程,
当前,AI 已经以“单兵作战”的形式渗透到 SDLC 的各个环节 —— 从市场研究(如 Google DeepResearch、Perplexity AI)、需求分析(如 Atlassian Intelligence)、 UI设计(如 v0.dev)、代码生成(如 Cursor、Augment)、代码审查(如 CodeRabbit), 到测试(如 BrowserStack AI)和运维(如 Datadog), 这些独立的AI工具正在为各自的领域带来显著但孤立的效率提升。
同样的,我们也可以看到越来越多的整合性方案:
在进入下半场之后,显然我们会看到类似于这样一个场景:你输入一个想法,就可以自动上线。只需要借助于通用的 AI Agent(如 Manus)、或者 Agentic 浏览器(如 Fellou)将这些工具整合起来,形成一个完整的开发闭环。
由于新一代的模型与 AI Agent 在现在已经充分展现了他的能力,对于企业来说,如何将这些能力整合起来,形成一个完整的开发闭环,是一个重要的挑战。 而 MCP(Model Context Protocol,模型上下文协议) 作为 AI Agent 的插件,可以让 AI Agent 可以无缝地调用一系列专业工具、上下文来完成特定任务:
简单来说,MCP 可以让你的 AI Agent 更容易获得模型所需要的相关、“高质量”上下文,以让生成的代码更符合预期。因此,在引入了 AI Agent 编程之后, 建立起组织级的 MCP 能力是至关重要的。
PS:当前,就算不讨论组织级 AI Agent 的能力建议,以 IDE + AI Agent 也需要 MCP 市场 + MCP 网关能力。当前由于 MCP 协议没有鉴权相关的能力, 因此这个能力就需要由企业自身去想办法。
我使用 Augment 和 Cursor 等 AI 智能体开发了多个原型应用,它们的确能极大提升开发效率,但也暴露出一个严重问题:
仅凭一个模糊的想法或“氛围”,就让 AI 生成大量的代码,而完全没有一个连贯的、经过深思熟虑的架构计划 。这种做法产出的系统,初看可能功能完备, 但其内部结构却是一片混乱,充满了意大利面条式的代码和紧耦合的模块,几乎无法维护。
在经典的软件开发工程里,我们一直强调的是:持续优化和演进系统架构,而重构则是实现这一目标的核心手段。然而,在 AI 驱动的开发流程中,这一原则却很难实现,原因如下:
即重构和演进式架构不靠谱,而 AI 生成的代码往往是意大利面条式的架构,导致重构变得非常困难。那么,是不是传统的架构方式又需要回归呢?
来自 GitClear 发布的《2024 年 AI Copilot 代码质量研究》显示:在 2024 年期间,包含五行以上重复邻近代码的代码块出现频率增加了 8 倍,代码重复的普遍程度比两年前高出 10 倍。而结合我使用 AI Agent 编程的经验来看,我觉得这个数量级还可以翻倍。其原因是 AI 工具的另一个危险特性是它会不加分辨地放大输入给它的任何模式——无论是好的还是坏的。
正如我司 Thoughtworks 的专家所指出的,AI 会 “不加选择地放大”:如果你在犯错,它会帮助你更快、更大规模地犯错。 也因此极大地拉大了高质量代码库与低质量代码库之间的开发速度差距。
这种放大效应在“氛围编程”(Vibe Coding)这一现象中体现得淋漓尽致。开发者,尤其是经验不足的开发者,可能会陷入一种工作模式:仅仅依赖 AI 的快速响应来生成代码,而缺乏深入的思考和严谨的规划。AI 编程助手恰恰为这种反模式提供了便利,加速了缺乏结构和纪律的代码的产出, 最终导致了难以收拾的混乱局面。
如果你在犯错,它会帮助你更快、更大规模地犯错。
如何构建更好的代码质量门禁,成为我们的新挑战,
AI 智能体所承诺的“10 倍生产力”是真实存在的,但它附带着以技术债形式出现的高额且不断复利的“隐藏利息”。如果放任不管,这笔债务将最终压垮整个工程组织。在 2025 年及以后能够取得成功的领导者,将是那些能够清醒地认识到这一悖论,并主动构建相应的文化、流程和分层工具链来驯服这头智能体“野兽”的人。 只有这样,才能将其原始的、强大的力量,转化为可持续的、架构优良的商业价值。
围观我的Github Idea墙, 也许,你会遇到心仪的项目