# 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开发方法论


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://assemble.gitbook.io/assemble/v1.0/02-gong-cheng-shi-jian-375-ge-wen-jian-83.1/05.-ai/20251231-ai-coding-2025-nian-zhong-pan-dian-spec-qu-dong-agent-fan-shi-yu-shang-xia-wen-gong-cheng-d.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.