# AI Coding 2025年终盘点：Spec驱动、Agent范式与上下文工程的胜负手

> **来源**：[InfoQ - AI Coding 2025 年终盘点：Spec 正在蚕食人类编码，Agent 造轮子拖垮效率，Token 成本失控后上下文工程成胜负手](https://www.infoq.cn/article/5lxt9ibO77f3HKbITN5s)\
> **作者**：Tina（采访嘉宾：黄广民、天猪）\
> **发布时间**：2025-12-31\
> **核心观点**：AI Coding生态正在为2026年的程序员定义新角色，从"写代码"转向"定义规则"，用AI听得懂的自然语言驯服技术革命。

***

## 📊 执行摘要

2025年的AI Coding生态经历了范式转换：**从补全时代走向Agent时代**。Spec驱动开发成为新趋势，但Markdown脚手架的爆炸式增长也暴露了工程复杂度管理的挑战。真正的胜负手在于**上下文工程**——如何高效组织有效Context，控制Token成本，同时保证长期可靠性。

**核心洞察**：

* ✅ **范式转换**：补全范式（Copilot/Cursor）→ Agent范式（接管任务全流程）
* ⚠️ **Spec驱动**：Markdown脚手架爆炸式增长，但能否接住软件工程复杂度存疑
* 🎯 **胜负手**：上下文工程成为AI编程的真正分水岭，而非单一模型能力

***

## 🎯 一、范式转换：从补全到Agent

### 1.1 补全范式的边界

**第一波：Copilot与Cursor开创的时代**

**核心特征**：

* **以人为主导**：AI角色是预测"下一个字符"或"下一个编辑位置"
* **局部优化**：在局部范围内提高速度和流畅度
* **严格约束**：端到端时延被严格压在几百毫秒量级

**技术边界**：

* 模型参数不能太大
* 上下文长度远不可能用全
* 补全能力从行内预测走向跨行、跨函数、跨文件的续写与改写

**能力极限**：

* 要在如此短的时间内理解全局意图、项目约束和依赖关系，接近工程极限
* 对泛补全系统的后训练、上下文选择、推理策略与工程链路提出接近极限的要求

### 1.2 Agent范式的崛起

**第二波：真正的范式颠覆（过去6-12个月）**

**核心变化**：

* 不再局限于"下一个字符"的预测
* 直接接管任务：从需求分析到代码生成，从工具调用到结果验证
* 交互从单轮对话转向多轮、长期的Agent Loop

**补全范式的局限**：

* 修改范围小
* 占用开发者注意力多
* 与能高效生成代码的Agent对话模式相比，持续优化的边际效用正在递减

**未来定位**：

* Agent会覆盖从需求到交付的更多环节，逐渐成为主流程
* 在Agent主导的场景中，补全可能退到幕后，成为支撑Agent精细执行的底层能力之一

### 1.3 补全能力的复用价值

**TRAE核心开发者天猪的观点**：

**补全未触及技术天花板**：

* 仍有大量开发者享受"亲自写代码"的过程
* 补全体验本身仍有不小的提升空间

**能力层面的复用**：

* 补全解决的核心问题：**在给定上下文下，预测下一步最合理的编辑动作**
* 在Agent体系中，同样可以被复用来辅助AI自身的执行
* Agent的对话面板、工具调用参数的生成与补全，本质上都可以视为不同形式的"补全场景"

***

## 🏗️ 二、工具形态演进：IDE/CLI/Cloud三形态并行

### 2.1 三种形态的必然性

**行业现象**：

* 几乎所有头部编程工具都开始演化出三种形态并行的能力组合：**IDE、CLI、Cloud**
* 很多产品会以其中一种形态起家，但很快就会把触角伸向另外两种

**根本原因**：

* 用户真正需要的不是某一种交互方式
* 而是"在不同场景下都能把任务交付出来"的完整链路

### 2.2 代表性工具的"出身"和气质

**工具定位差异**：

* **Claude Code**：起源自CLI，所以在CLI上可能更强
* **OpenAI Codex**：起源于Cloud
* **Cursor**：起源于IDE，是IDE原生体验的典型代表

**形态选择的影响**：

* 不同形态决定了工具的交互哲学和核心能力
* 但最终都会向三形态并行演进

***

## 📝 三、Spec驱动开发：Markdown脚手架的爆炸

### 3.1 Spec驱动的兴起

**现象描述**：

* 这半年，Spec驱动开发火到爆炸
* 仓库里迅速堆起一层层面向Agent的"Markdown脚手架"
* 被捧为AI Coding的最前沿解法：用一份契约，逼Agent真的干活

### 3.2 核心问题

**关键质疑**：

> 这套契约，真能接住软件工程几十年的复杂度吗？

**潜在挑战**：

* Spec驱动能否真正应对软件工程的复杂性？
* Markdown脚手架是否只是权宜之计？
* 程序员的终极价值是否从"写代码"转向"定义规则"？

**核心思考**：

* 用AI听得懂的自然语言，驯服这场技术革命
* 但自然语言能否精确表达软件工程的约束和规则？

***

## 🔄 四、Agent造轮子：效率拖垮的困境

### 4.1 现象描述

**核心问题**：

* Agent在开发过程中"造轮子"现象严重
* 重复实现已有功能，拖垮开发效率

**影响**：

* 开发效率不升反降
* 代码库中堆砌大量重复代码
* 维护成本增加

### 4.2 可能的解决方案

**需要思考的方向**：

* 如何让Agent更好地理解现有代码库？
* 如何建立有效的代码复用机制？
* 如何优化Agent的决策流程，避免重复造轮子？

***

## 💰 五、Token成本失控：上下文工程成为胜负手

### 5.1 成本问题的本质

**核心挑战**：

* Token成本随上下文长度线性增长
* 大上下文窗口带来成本压力
* 如何在成本与能力之间找到平衡？

### 5.2 上下文工程的演进路径

#### 阶段一：Fine-Tuning的局限

**早期方案**：

* 通过在大模型层面注入领域知识
* 补充其世界模型的盲区

**实践证明的问题**：

* 成本高昂
* 灵活性不足
* 难以应对多模型频繁切换的现实需求

#### 阶段二：RAG的兴起

**外挂式知识补充**：

* 以RAG为代表的"外挂式知识补充"在工程上更具性价比
* 更符合AI Coding的实际使用模式

**早期交互模式**：

* 一问一答的**Chat模式**
* 模型对"首轮输入Context"的依赖极高
* 需要在提问时尽可能一次性注入相关背景
* 直接推动了RAG召回机制的普及

#### 阶段三：Coding Agent的转变

**交互模式变化**：

* 从单轮对话转向多轮、长期的Agent Loop
* 相关信息不再需要在第一轮全部给出
* 由Agent在执行过程中按需检索与召回

**技术演进**：

* **embedding search**与**grep**等能力的逐步登场
* Cline和Claude Code从传统的RAG转向**grep**
* Cline甚至直言"不能再用2023年的办法解决今天的问题"

#### 阶段四：Agentic Search的演化

**复杂场景的需求**：

* 随着任务复杂度和检索路径的增加
* **Agentic Search**逐渐演化出来
* 常与**Sub Agent**机制协同出现

**Search Agent机制**：

* 许多Tool Call的中间历史并不具备长期价值
* 出现专门的**Search Agent**：自身运行一个独立的Agent Loop
* 负责多轮检索、筛选与验证
* embedding search、grep、LSP等仅仅是其可组合使用的工具能力

### 5.3 上下文工程的核心原则

**稀缺资源认知**：

> 真正稀缺的不是上下文长度，而是**有效Context的组织能力**。

**工程实践**：

* 把上下文拆分为稳定信息与变化信息
* 让变化部分足够精准、长度可控、可验证
* 通过缓存、裁剪、摘要、检索等机制，把Token的边际成本控制在工程可接受的范围内
* 避免因关键信息缺失而放大返工成本

**embedding search vs grep**：

* **embedding search**：像数据库中的index，在特定条件下能够显著提升召回效率
* **grep**：在确定性和精确匹配上具备优势
* 两者往往服务于不同的检索阶段和需求类型

***

## 🎯 六、AI编程的系统工程视角

### 6.1 四层架构体系

**天猪的观点**：如果把AI编程看成一个系统工程，它至少由四层共同构成：

```
┌─────────────────────────────────────┐
│  模型层：负责"思考"                  │  ← 决定上限
├─────────────────────────────────────┤
│  工具层：负责"行动"                  │  ← 决定能不能真的做事
├─────────────────────────────────────┤
│  IDE层：承载人机交互                 │  ← 决定人是否能高效表达意图、及时纠偏
├─────────────────────────────────────┤
│  上下文层：记忆与连续性              │  ← 长期可靠性的基础
└─────────────────────────────────────┘
```

### 6.2 各层的作用

**模型层**：

* 决定能力上限
* 负责"思考"

**工具层**：

* 决定能不能真的做事
* 负责"行动"

**IDE层**：

* 决定人是否能高效表达意图、及时纠偏
* 承载人机交互

**上下文层**：

* 把这一切粘合在一起
* 承载历史决策、工程约束与连续性
* 是长期可靠性的基础

### 6.3 真正的分水岭

**核心观点**：

> 未来AI编程的真正分水岭，或许并不仅仅在于"谁的模型更强"，而还在于谁能持续、准确地把工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构。

**天猪的总结**：

> AI编程从来不是单一模型能力的比拼，而是工程体系与模型能力共同作用的结果。

**这，才是AI Coding正在补上的那几块"工程短板"。**

***

## 💡 七、核心洞察与实践启示

### 7.1 对程序员的启示

**角色转变**：

* 从"写代码"转向"定义规则"
* 用AI听得懂的自然语言，驯服技术革命
* 但需要清醒地认识到自然语言的局限性

**能力要求**：

* 掌握上下文工程技巧
* 理解Agent的工作机制
* 建立有效的工程约束和规则体系

### 7.2 对工具开发者的启示

**技术方向**：

* 上下文工程成为核心竞争力
* 需要建立有效的Context组织机制
* 平衡Token成本与能力需求

**产品策略**：

* IDE/CLI/Cloud三形态并行是必然趋势
* 不同形态需要不同的交互哲学
* 但最终都要提供完整的任务交付链路

### 7.3 对技术选型的启示

**范式选择**：

* 补全范式仍有价值，特别是在"亲自写代码"的场景
* Agent范式适合复杂任务和全流程交付
* 两者可以协同，而非替代关系

**技术栈选择**：

* 上下文工程能力 = 竞争优势
* 需要建立混合检索机制（embedding search + grep + Agentic Search）
* 根据场景选择合适的技术组合

***

## 🔮 八、未来展望

### 8.1 技术趋势

**短期（2026）**：

* Spec驱动开发继续演进，但需要解决工程复杂度问题
* Agent范式进一步成熟，工具链完善
* 上下文工程成为关键竞争点

**长期**：

* AI编程工具的三形态融合
* 上下文工程方法论的系统化
* 工程约束与AI能力的更好平衡

### 8.2 关键挑战

**技术挑战**：

* 如何用自然语言精确表达软件工程约束？
* 如何建立有效的上下文组织机制？
* 如何平衡Token成本与能力需求？

**工程挑战**：

* Spec驱动的可维护性
* Agent造轮子问题的解决
* 上下文工程的标准化

***

## 📚 延伸阅读

### 相关文章

* [对话 CodeBuddy 黄广民：一堆冒烟的上下文，正在决定 AI 编程的成败](https://www.infoq.cn/article/j8jMvIOfmZS8M33t72uP)
* [对话天猪：AI 时代的挑战与程序员的认知进化](https://www.infoq.cn/article/EiO80Aacx4sMZHjtXqNR)

### 知识库相关文档

* `[2025-10-01] # 🚨 RAG讣告批判性阅读报告：Agent Search是革命还是过度乐观？.md` - RAG与Agent Search的对比分析
* `[2025-10-01] # 🏗️ Claude Code的grep策略：无状态设计与Agent Search的技术哲学.md` - Claude Code的技术哲学
* `🗁 Anthropic/02 Effective context engineering for AI agents - 上下文工程的系统性方法论.md` - 上下文工程方法论
* `[2025-01-15] 提示词工程与上下文工程核心洞察总结报告.md` - 上下文工程核心洞察

***

**文章标签**：#AI Coding #Agent范式 #上下文工程 #Spec驱动 #Token成本 #2025年终盘点

**文章类型**：技术趋势分析\
**学习价值**：⭐⭐⭐⭐⭐\
**适用场景**：AI编程工具选型、上下文工程实践、Agent开发方法论