2025 年 AI 编程趋势:智能体 10 倍生产率放大下的“粪围”蔓延

2025 年注定不只是一个 “Agent 元年”,而是一个体系化跃迁的起点。在几个月过去,这个判断被不断印证,也不断被现实加速:

  • Cursor 和 Windsurf 正在从 AI Editor 升级成真正的 AI IDE,但是在编译器加入这场游戏之后,我们或许不需要传统的 IDE。
  • Claude Code 用模型能力重塑任务执行流程,让我们看到了:只靠模型的强大推理能力,如何让 AI 编码代理更智能。
  • Augment 强大的闭环验证能力,展现了他们对于软件工程的思考。

工具不再是工具,它们正成为开发流程的策划者与执行者。协作不是人与人,而是人与 Agent 们,还有 Agent 与 Agents。整个体系正在不断迭代, 然而我们所见证的:它并不是简单的提效,而是“放大” —— 即原来做得差的,现在会更差, ⚠️ AI 代码的副作用,比你想的要严重得多。

PS:在这篇文章里,我将使用“AI 代理”来指代 AI 智能体,因为代理更能体现它们的协作与执行能力。

1. 百花齐放的 AI 编码代理,再次爆发

在过去的半年里,我使用代码补全的频率显著降低。原因很简单:AI 智能体/代理的能力已远远超越了传统的代码补全。不只是能补代码,它们还能理解需求、预测操作, 并自动完成一系列开发任务——从生成代码、编写测试、执行构建,到校验结果、出错自动重试,全流程都能覆盖。我只需清晰描述目标 (太难了),AI 就能高效执行。

与此同时,AI 编程的竞争格局也发生了根本性的变化。如今,顶尖模型已经成为所有工具供应商都能接入的通用“智能引擎”,智能本身不再是差异化优势的来源。 真正的竞争,转向了围绕大模型打造怎样的工作流、用户体验与生态系统集成——谁能用这些能力构建出最具价值的开发平台,谁就能胜出。

这也解释了为什么市场上涌现出如此多的参与者:

  • AI 编程插件/编辑器:如 Cursor、Windsurf、Augment、AutoDev、JetBrains Junie 等;
  • 软件开发平台:如 GitHub Copilot(Web 版)、Atlassian Rovo Dev、Sourcegraph AMPCode 等;
  • 模型厂商:如 Gemini CLI、Claude Code、OpenAI Codex 等。

背后的推动力主要来自两个方向:一是基模型在理解、推理、上下文保持方面能力的跃迁;二是 Agentic 能力的成熟。这些进展降低了对自研或微调模型的依赖, 使得向量化模型、FastApply、NES 预测等架构成为可选项,而非刚需。

2. “计划先行,代码后行”:AI 代码正在变得有章可循

正确使用 AI Agent 的方式应该是:

  1. 规划与脚手架搭建:整个过程始于高层次的战略规划,通常在一个 Markdown 文件中进行。由 AI 协助创建一份开发路线图,将宏大的目标分解为更小的、可执行的任务,或者 mermaid 图来可视化整个开发流程。
  2. 详尽的任务定义:对于每一个子任务,应该编写一份极其详尽、自包含的提示(prompt),精确地定义 AI 需要完成的工作、遵循的约束和预期的输出。
  3. 受控的执行过程:开发者会一次只将一个任务指令交给 AI,并明确要求其在“完成后回报”,而不是让其连续不断地工作。
  4. 人在环路中的审查:AI 完成任务后,开发者会仔细审查生成的代码。如果发现问题(例如,AI 未能复用一个已存在的工具函数),开发者会进行迭代修正,直到代码质量达标,然后再进行下一个任务。

而由于编程可靠的提示词过程太复杂,我们通常不愿意这么做,进而导致 AI Agent 编程生成的质量参差不齐。大力飞砖,还是比较好玩的。

因此 AI Agent 编程在过去几个月里经历了一个显著的转变:从“代码直接生成”到“计划先行,代码后行”,这种转变不仅提升了代码质量,还让过程透明, 进而让结果更加可控。我们可以看到越来越多的 AI 编程代理开始采用这种方法:

  • Claude Code 实时更新任务:通过 TodoRead, TodoWrite 工具来实时更新任务列表,确保开发过程中的每个步骤都被记录和跟踪。
  • Windsurf 实时更新任务:通过 update_plan 在过程中动态更新任务计划,确保开发者可以随时查看当前进度和待办事项。

即由 AI 辅助人去生成初步 Task,然后人去审查,直到代码质量达标。

3. 自动验证的强化:从测试到上下文引擎

在我们先前的《AI 编码 2.0 分析、思考与实践:从 Cursor Composer 到 AutoDev Sketch》里, 我们介绍了看到的 AI 编程工具 2.0 的核心特点:

AI 编程工具正在从代码补全、代码预测,到更加智能、更耗费 token 的 AI 自动化编码与验证,以及正在发展中的异步 AI 编码

基于这些特点,我们认为 AI 编程工具 2.0 的核心应该是:

  • Agent 驱动。依赖于基础模型的强大推理能力,结合在编程工具中提供更快、更好的获取上下文,可以让 AI 编程工具更好地理解开发者的意图,并编写出更加符合开发者预期的代码。
  • 开发者体验优先。结合开发者日常活动,更好的满足开发者的心流,诸如编辑预测、自动测试等;诸如 Cursor 结合开发者活动提供了大量机制来降低心智成本,以及应对失败和重试等。
  • 自动化校验。即自动化校验 AI 生成代码的质量、业务逻辑正确性、修复幻觉导致的问题,诸如 patch等,从而在机制上减少幻觉带来的影响;诸如 Cursor 集成大量实用的 Lint、Terminal 等工具,提供自动化检验手段。

在过去的几个月里,我们看到 AI 编程工具 2.0 的自动化校验能力得到了显著提升,特别是 Claude 与 Augment 在这方面展现了非常强大的能力。自动验证 不再只是单元测试,而是类似人类的代码校验技巧:

  • 连续试多种验证方式
  • 多轮自动测试和验证
  • 排除无关错误的自动校验:创建更轻量级的测试脚本

通过大量的自动化校验,可以降低人来审查代码的负担,进而让 AI Agent 编程更像是一个“闭环”的过程。

4. 异步 AI 编码:从前台到后台的转变

AI 编程的另一个重要趋势是异步化,诸如:Augment Remote Agent、Cursor Backend Agent。过去,AI 编程主要依赖于前台的交互式体验, 即开发者在 IDE 中直接与 AI 交互,实时生成代码和验证结果。而现在,AI 编程正在向后台异步执行转变,这种转变带来了更高的效率和更低的心智负担。 你只需要 review AI 给你的 PR 即可,

尽管 AI 编程的异步化仍处于早期阶段,但它已经展现出巨大的潜力,你可以将

  • 需求交给模型分析,在后台生成 Plan、代码,甚至是自动化测试脚本。
  • 开发任务交给 AI Agent,AI Agent 会在后台处理,并在完成后通过 PR 或通知的方式告知你。

当然了,AI 编码并非单一技术的突破,而是三大关键技术支柱——远程开发基础设施(VSCode Server 等、代码库集成)、 上下文引擎和模型上下文协议——协同演进的产物。

PS:随着,AI 编程工具在工程化落地的增强,在未来,我们可能要面临的问题,没有足够的 backlog 能给 AI 在后台进行编程,

5. 从单兵作战到 AI 代理团队协作

当前,AI 已经以“单兵作战”的形式渗透到 SDLC 的各个环节 —— 从市场研究(如 Google DeepResearch、Perplexity AI)、需求分析(如 Atlassian Intelligence)、 UI设计(如 v0.dev)、代码生成(如 Cursor、Augment)、代码审查(如 CodeRabbit), 到测试(如 BrowserStack AI)和运维(如 Datadog), 这些独立的AI工具正在为各自的领域带来显著但孤立的效率提升。

  • 市场调研:OpenAI/Google DeepResearch 等
  • UI 原型阶段:UX Pilot、v0.dev (by Vercel) 等
  • 需求阶段:结合 Atlassian Jira、Confluence 等
  • 代码生成:Claude Code、Cursor、Windsurf、Augment、AutoDev、GitHub Copilot 等
  • 代码质量:CodeRabbit、Qodo Merge、CodeAnt.ai、Greptile 等
  • 质量环节:Functionize、Testsigma、Appvance 等
  • 运维:Datadog/NewRelic 等

同样的,我们也可以看到越来越多的整合性方案:

  • GitHub Copilot Web 版本、CLI 版本、IDE 插件等,提供了从代码生成到版本控制的“全流程支持”。
  • Atlassian Rovo 是一个旨在将其整个产品套件(Jira、Confluence、Bitbucket)深度嵌入专业化 AI 智能体(“AI 队友”)的平台。 其的核心战略是利用其“团队协作图谱”(Teamwork Graph)来连接跨团队、跨项目和跨知识库的数据,通过 Rovo Studio,企业可以构建自己的定制化智能体;Rovo Dev CLI 则将这种集成的体验带入了开发者最熟悉的终端环境。

在进入下半场之后,显然我们会看到类似于这样一个场景:你输入一个想法,就可以自动上线。只需要借助于通用的 AI Agent(如 Manus)、或者 Agentic 浏览器(如 Fellou)将这些工具整合起来,形成一个完整的开发闭环。

6. MCP 架起协作之桥,构建企业级智能研发平台基石

由于新一代的模型与 AI Agent 在现在已经充分展现了他的能力,对于企业来说,如何将这些能力整合起来,形成一个完整的开发闭环,是一个重要的挑战。 而 MCP(Model Context Protocol,模型上下文协议) 作为 AI Agent 的插件,可以让 AI Agent 可以无缝地调用一系列专业工具、上下文来完成特定任务:

  • 项目管理:通过连接 Asana、Atlassian (Jira) 或 Linear,智能体可以直接创建任务、更新项目状态、分析团队进度。
  • 基础设施与运维:集成 Cloudflare 或 Sentry,使其能够管理云部署、查询实时日志、分析应用错误。
  • 支付与金融:接入 PayPal、Plaid 或 Square,智能体可以处理交易、分析财务数据、管理客户支付信息。
  • 企业自动化:通过 Zapier 或 Workato,智能体能够连接数千个企业应用,执行发送邮件、更新 CRM、安排会议等复杂工作流。

简单来说,MCP 可以让你的 AI Agent 更容易获得模型所需要的相关、“高质量”上下文,以让生成的代码更符合预期。因此,在引入了 AI Agent 编程之后, 建立起组织级的 MCP 能力是至关重要的。

PS:当前,就算不讨论组织级 AI Agent 的能力建议,以 IDE + AI Agent 也需要 MCP 市场 + MCP 网关能力。当前由于 MCP 协议没有鉴权相关的能力, 因此这个能力就需要由企业自身去想办法。

7. AI 重构像赌命,没有架构一切归零

我使用 Augment 和 Cursor 等 AI 智能体开发了多个原型应用,它们的确能极大提升开发效率,但也暴露出一个严重问题:

仅凭一个模糊的想法或“氛围”,就让 AI 生成大量的代码,而完全没有一个连贯的、经过深思熟虑的架构计划 。这种做法产出的系统,初看可能功能完备, 但其内部结构却是一片混乱,充满了意大利面条式的代码和紧耦合的模块,几乎无法维护。

在经典的软件开发工程里,我们一直强调的是:持续优化和演进系统架构,而重构则是实现这一目标的核心手段。然而,在 AI 驱动的开发流程中,这一原则却很难实现,原因如下:

  1. 初始设计的固化:开发者通常会用一个相对简单、高层次的提示来启动一个项目。AI 基于这个初始提示生成了应用的第一个版本。
  2. 缺乏深层理解:AI 在生成初始架构时,缺乏对系统未来演进方向、非功能性需求(如可扩展性、安全性)以及复杂业务约束的深层理解。它选择的往往是统计上最可能、而非架构上最优的方案。
  3. 重构的阻力:当人类开发者在后期试图对这个由 AI 生成的架构进行重构时,会遇到巨大的阻力。如果开发者试图让 AI 辅助重构,AI 可能会将这些架构层面的改动误解为“错误”,并试图将其“修复”回最初那个有缺陷的设计。因为它不理解重构背后的战略意图。
  4. 人工重构的风险:如果开发者选择手动重构,同样困难重重。因为他们缺乏 AI 做出初始“决策”时的上下文,不清楚某些看似奇怪的设计背后是否有其隐含的(尽管可能是错误的)逻辑。这使得任何大规模的改动都充满了风险。

即重构和演进式架构不靠谱,而 AI 生成的代码往往是意大利面条式的架构,导致重构变得非常困难。那么,是不是传统的架构方式又需要回归呢?

8. 10 倍速度,还是 10 倍技术债?

来自 GitClear 发布的《2024 年 AI Copilot 代码质量研究》显示:在 2024 年期间,包含五行以上重复邻近代码的代码块出现频率增加了 8 倍,代码重复的普遍程度比两年前高出 10 倍。而结合我使用 AI Agent 编程的经验来看,我觉得这个数量级还可以翻倍。其原因是 AI 工具的另一个危险特性是它会不加分辨地放大输入给它的任何模式——无论是好的还是坏的。

正如我司 Thoughtworks 的专家所指出的,AI 会 “不加选择地放大”:如果你在犯错,它会帮助你更快、更大规模地犯错。 也因此极大地拉大了高质量代码库与低质量代码库之间的开发速度差距。

这种放大效应在“氛围编程”(Vibe Coding)这一现象中体现得淋漓尽致。开发者,尤其是经验不足的开发者,可能会陷入一种工作模式:仅仅依赖 AI 的快速响应来生成代码,而缺乏深入的思考和严谨的规划。AI 编程助手恰恰为这种反模式提供了便利,加速了缺乏结构和纪律的代码的产出, 最终导致了难以收拾的混乱局面。

如果你在犯错,它会帮助你更快、更大规模地犯错。

如何构建更好的代码质量门禁,成为我们的新挑战,

总结:从工具到流程,重构我们的开发范式

AI 智能体所承诺的“10 倍生产力”是真实存在的,但它附带着以技术债形式出现的高额且不断复利的“隐藏利息”。如果放任不管,这笔债务将最终压垮整个工程组织。在 2025 年及以后能够取得成功的领导者,将是那些能够清醒地认识到这一悖论,并主动构建相应的文化、流程和分层工具链来驯服这头智能体“野兽”的人。 只有这样,才能将其原始的、强大的力量,转化为可持续的、架构优良的商业价值。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806