InfoQ 2025 AI Coding年终盘点：Spec蚕食人类编码，Agent造轮子拖垮效率

2025 年的 AI Coding 生态，正在为 2026 年的程序员定义一个新角色。答案可能藏在一堆冒烟的 Markdown 文件里。

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

但问题来了：这套契约，真能接住软件工程几十年的复杂度吗？还是说，程序员的终极价值，将从”写代码”转向”定义规则”——用 AI 听得懂的自然语言，驯服这场技术革命？

补全的天花板，与 Agent 的必然上位

AI Coding 的演进，已经清晰地分为了两个时代。

第一波由 Copilot 与 Cursor 开创：这是一种以人为主导的编程方式，AI 的角色是预测”下一个字符”或”下一个编辑位置”，在局部范围内提高速度和流畅度。

这种范式的边界其实非常清楚。补全必须足够丝滑，才能不打断心流，这意味着端到端时延被严格压在几百毫秒量级，可用模型规模和上下文长度都受到天然约束。

第二波，Agent 的崛起：它不再局限于”下一个字符”的预测，而是直接接管任务——从需求分析到代码生成，从工具调用到结果验证。

TRAE 核心开发者天猪指出，这并不意味着补全范式已经触及技术天花板：一方面，仍有大量开发者享受”亲自写代码”的过程；更重要的是，在 Agent 体系中，补全同样可以被复用来辅助 AI 自身的执行。

几乎所有头部编程工具都开始演化出三种形态并行的能力组合：IDE、CLI、Cloud。

• Claude Code 起源自 CLI，在 CLI 上可能更强
• OpenAI Codex 起源于 Cloud
• Cursor 起源于 IDE，是 IDE 领域最大的玩家之一

天猪判断 IDE 依然会是最多人使用的入口，原因很简单：它最符合程序员长期形成的工作习惯。IDE 的形态本身很可能在三年内发生根本变化，不再以 Editor 为中心展开。

用更直白的话说：IDE 正在从”给人用的工具箱”，变成”给 AI 和人一起共用的工具箱”。

Spec，真的能解决 AI Coding 的问题吗？

从这个词被喊热到现在，不过短短几个月，一个有些尴尬、却无法回避的现实逐渐浮出水面：大家口中的”Spec”，早就不是同一个东西了。

很多团队在实践中有一个直观感受是 AI 写代码时并不是缺 Spec，而是缺 Context。于是就有人干脆把两者画上了等号：“Spec 就是上下文工程”。

但国内一线工具团队更偏向认为”它们不是一回事儿”。在他们看来：

• Spec更像是上下文中最关键、也最稳定的一类内容，承担的是”指导性 Context”的角色：把目标、约束和验收口径讲清楚，相当于给 Agent 一份可执行的契约
• Context Engineering关注的是”在这一刻，模型是否拿到了足够的信息”

Spec 解决的是”我们到底要造什么”，而 Context Engineering 关注的是”在这一刻，模型是否拿到了足够的信息”。两者高度耦合，却无法相互替代。

Spec 是被”淘汰”的瀑布流程的回归？

一位敏捷实践者曾直言，SDD 的前进方向本身就是错的。在他看来，这套方法试图解决的，是一个早已证明走不通的问题：如何将开发人员从软件开发过程中剔除？

问题在于，软件开发是一个非确定性过程，规划无法消除不确定性，正如经典论文《没有银弹》所指出的那样。

从工程视角讨论 Spec，常见的落点并不是”要不要把思考写全”，而是”到底该结构化哪一部分”。在 CodeBuddy 产品负责人黄广民看来，Spec Coding 真正想结构化的并不是开发者的全部思考过程，而是那些最容易在长程任务里出错、也最值得被验证和沉淀的部分。

当前行业对 Spec 还处于探索阶段。Spec 更合理的形态是”活的契约”——它不是一份静态的、一次性的文档，而是 Plan-Execute 闭环中的关键中间态：

好的 Spec 驱动实践不是”先写一份完美 Spec 再开始写代码”，而是用 Spec 把正确性口径说清楚，然后在推理-执行-反馈的过程中不断校准 Spec 和代码制品的一致性。

软件抽象：为什么 Agent 总爱”自己造轮子”

在 AI Coding 的实践中，有一个长期以来被大量开发者反复吐槽的问题：Coding Agent 极其偏好”自己从零开始实现功能”，而不是复用成熟库。

不过对模型来说，“自己写一个能跑的版本”往往是风险最低的路径。当它对某个库的版本、用法或边界不确定时，回退到”自己实现”几乎是必然选择。

关键不在于反复对 Agent 进行人工纠偏或微观干预，而在于补齐它可依赖的信息源。正如黄广民所强调的：与其在结果阶段不断”提醒”，不如在执行阶段把信息准备好——通过 Context7 这类 MCP 工具补齐版本、用法与示例，再用”渐进式披露”把正确用法注入任务上下文。

Token 工程的崛起：为什么成本突然失控

Token 是什么时候开始变得扎心的？不是在你第一次用完免费额度，而是在你意识到：它已经不再是”一次对话的消耗”，而是能直接左右工具定价、产品策略，甚至逼平台改规则的核心变量。

今年有两件事几乎同时把这件事推到了台前：

1. Cursor 连续五轮涨价与功能削减：有人在相对便宜的订阅档里，用特定方式跑出远超平台预期的调用量，成本边界被薅穿
2. Claude Code 的 Token 排行榜：全球榜一大哥用 200 美元套餐在 30 天里烧掉 77 亿 Token，折算账单约 5 万美金

为什么 Token 在 2025 年突然复杂了一个数量级？

根本原因并不在”模型更贵”，而在范式迁移：大模型应用正在从”问答”，跃迁到”Agent 做事”。当模型被要求”把一件事做完”，Token 成本就不再是单次输入输出，而是贯穿推理—执行—反馈链路的全生命周期成本。

最关键的变化是：工具调用的隐形成本开始吃掉大头。

为了完成一个任务，往往需要多轮对话；而每一轮对话背后又会经历几次到几百次不等的工具调用。这意味着上下文里存在大量可复用的稳定信息，也就留下了上下文缓存与重用的空间。

这也是为什么工程团队今年会特别关注 log 过滤、diff slicing、输出摘要等能力，本质上都是在控制”给模型看的 Token”，把无效信息从上下文里剔掉。

Token 工程的真正战场：上下文管理

在大多数模型平台里，上下文的执行依赖 KV cache。理论上，只要上下文没有变化，模型就可以直接命中缓存，避免重复计算；但在真实工程中，缓存命中远没有想象中理想。

上下文工程的技术演进：

1. 早期 Fine-Tuning：通过在大模型层面注入领域知识，补充其世界模型的盲区。但成本高昂、灵活性不足
2. RAG 外挂式知识补充：在 AI Coding 早期阶段，交互主要是一问一答的 Chat 模式，需要在提问时尽可能一次性注入相关背景
3. Embedding Search + Grep：随着 Coding Agent 的出现，协作模式从单轮对话转向多轮、长期的 Agent Loop。相关信息不再需要在第一轮全部给出，而是由 Agent 在执行过程中按需检索与召回
4. Agentic Search：随着任务复杂度和检索路径的增加，专门的 Search Agent 出现，负责多轮检索、筛选与验证

走到这一步，行业逐渐意识到：真正稀缺的不是上下文长度，而是有效 Context 的组织能力。

写在最后

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

• 模型负责”思考”
• Tool负责”行动”
• IDE承载人机交互
• 上下文负责”记忆与连续性”

模型层决定上限；Tool 决定它能不能真的做事；IDE 决定人是否能高效表达意图、及时纠偏；而上下文层把这一切粘合在一起，承载历史决策、工程约束与连续性，是长期可靠性的基础。

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