AI编程2025：Spec驱动与Agent范式重塑开发生态

2025年，AI编程生态正悄然为2026年的程序员勾勒出一个全新角色。这个角色的秘密，或许就隐藏在那些冒着热气的Markdown文件之中。

近半年来，Spec驱动开发的热度急剧攀升。代码仓库中迅速涌现出大量面向Agent的“Markdown脚手架”，被视为AI编程的前沿解决方案：通过一份明确的契约，强制Agent真正执行任务。

然而，问题随之而来：这样的契约能否承载软件工程数十年来积累的复杂性？抑或，程序员的终极价值将从“编写代码”转向“定义规则”——用AI能够理解的自然语言，驾驭这场技术变革？

1

补全的极限与Agent的崛起

AI编程的演进路径，已明确划分为两个阶段。

第一波浪潮由Copilot和Cursor引领：这是一种以人为核心的编程模式，AI主要负责预测“下一个字符”或“下一个编辑位置”，在局部层面提升编码速度与流畅性。

这一范式的局限性显而易见。补全功能必须极其流畅，以免打断开发者的心流，这就要求端到端延迟被严格控制在几百毫秒以内，从而限制了可用模型的规模和上下文长度：模型参数不能过大，上下文也无法全面覆盖。

与此同时，补全的能力持续扩展——从行内预测延伸至跨行、跨函数、跨文件的续写与改写，甚至局部重构。尽管体验仍有优化余地，但在极短时间内理解全局意图、项目约束和依赖关系，已接近工程极限：这对泛补全系统的后训练、上下文选择、推理策略及工程链路提出了近乎极限的挑战。

第二波变革，尤其是在过去6至12个月间，我们见证了真正的范式革命：Agent的兴起。它不再局限于预测“下一个字符”，而是直接承担任务——从需求分析到代码生成，从工具调用到结果验证。

相比之下，补全范式存在修改范围有限、占用开发者注意力较多等不足，与能高效生成代码的Agent对话模式相比，其持续优化的边际收益正在递减。随着模型能力与工具链的完善，Agent将覆盖从需求到交付的更多环节，逐步成为主流流程；在Agent主导的场景中，补全可能退居幕后，成为支撑Agent精细执行的底层能力之一。

对此，TRAE核心开发者天猪表示，这并不意味着补全范式已达到技术天花板：一方面，许多开发者仍偏爱“亲手写代码”的体验，在这些场景下补全功能仍有优化空间；更重要的是，从能力角度看，补全始终解决的是同一个问题——在给定上下文中，预测下一步最合理的编辑动作。过去，这一能力主要用于辅助人类编码；而在Agent体系中，它同样可以被复用来辅助AI自身的执行。例如，Agent的对话面板、工具调用参数的生成与补全，本质上都可以视为不同形式的“补全场景”。

此外，今年观察到的一个有趣现象是：几乎所有主流编程工具都开始并行发展三种形态的能力组合：IDE、CLI、Cloud。许多产品从某一种形态起步，但迅速向另外两种延伸，因为用户真正需要的是“在不同场景下都能完成任务交付”的完整链路。这也让我们更清晰地理解代表性工具的“出身”与特质：Claude Code源自CLI，因此在CLI上可能更强；OpenAI Codex源自Cloud；Cursor源自IDE，是IDE领域的领先者之一。

其中，CLI和Cloud Agent自诞生起就是Agent主导的形态，它们对UI的要求较低，要么在终端中工作，要么采用简化的Web界面，再通过GitHub PR实现协作与交付。

然而，天猪认为IDE仍将是大多数程序员的首选入口，原因简单：它最契合程序员长期形成的工作习惯。他在团队早期的实践中就认识到：专业生产力工具的颠覆性创新，往往伴随着对开发者认知和工作方式的彻底重塑。在他看来，IDE的形态可能在三年内发生根本性变化，不再以编辑器为中心——TRAE的SOLO模式、Cursor的Agent模式，正是业界围绕这一方向的探索与实践。

简而言之：IDE正从“为人设计的工具箱”转变为“人与AI共享的工具箱”。过去IDE中大量以人为中心的功能，正被拆解为更小、更明确、更AI友好的工具，由AI Agent按需调用。随着技术演进，IDE将越来越像一个能力容器和执行环境，支持Agent与人的协作。

这三条路径最终都在不同程度上向Agentic Behavior汇聚。

IDE在“人+Agent”的协作体验上不断进化，CLI在工程自动化和流水线中强化Agent能力，而Cloud Agent则在时间和空间上拓展了研发协作的边界。

形态各异，但目标高度一致：以Agent为主导的范式。在Agent形态下，核心诉求趋于相同：正确使用工具、保持长程任务稳定性、在反馈信号下持续修正。因此，Coding Agent的能力，本质上就是长程任务稳定性与工具调用能力。

当执行权从人转移到Agent，软件工程数十年来依赖经验与默契的复杂度，被迫转化为显性规则——Spec在此刻被重新引入。

截图源自《“人人都是程序员的梦”该醒了！》评论区

2

Spec，能否真正解决AI编程的难题？

从“Spec”一词被热议至今，不过短短数月，一个略显尴尬却无法回避的现实逐渐显现：人们口中的“Spec”，早已内涵各异。

有人认为Spec是更优的Prompt，有人将其理解为更详尽的产品需求文档，也有人视其为架构设计文档，但对多数工程团队而言，Spec仅仅是“编码时多使用几个Markdown文件”。

于是，代码仓库中迅速堆满了gemini.md、claude.md、agent.md、cursor-rules、各类Skills，以及GitHub的配置文件。过去数月，各大厂商的代理工具纷纷推出“可复用上下文框架”：Claude Skills、Cursor Team Rules、GitHub Copilot Spaces，加上第三方的Tessl、BMad Method (BMM)等，整个工具链在一年内爆炸式演进，催生了一大批基础设施新物种。

许多团队在实践中直观感受到，AI编写代码时缺乏的并非Spec，而是Context。于是有人直接将两者等同：“Spec即上下文工程”，或“Spec驱动开发等价于上下文工程”。

但国内一线工具团队更倾向于认为“二者并非同一回事”。

在他们看来，Spec更像是上下文中最关键、最稳定的一类内容，扮演着“指导性Context”的角色：明确目标、约束和验收标准，相当于为Agent提供一份可执行的契约，界定其任务与完成标准。

在这一分工下，Spec回答的是“我们究竟要构建什么”，而Context Engineering关注的是“此刻模型是否获取了足够信息”。Spec本身不会自动转化为有效上下文，但往往是高质量Context的长期来源——二者高度耦合，却无法相互替代。

正因如此，Spec不应被局限在特定几种文档形态中。更准确地说，Spec是所有用于指导代码生成的契约的总和：产品文档、设计稿、接口定义、边界条件、验收标准、执行计划等，均可纳入Spec体系，只是处于不同阶段、不同粒度的子集。

然而，“覆盖范围广、形态多样、生命周期长”使得Spec格外难以标准化。

在此轮Spec驱动开发的讨论中，Kiro常被视为重要推动者之一。其技术负责人Al Harris曾在公开分享中提到，为找到合适的Spec形态，团队内部先后尝试了约七种不同实现——从ephemeral spec、分层spec到基于TDD的spec，几乎“给所有东西都加过spec的后缀”。归根结底，他们在反复回答三个问题：Spec何时“定稿”，应细化到何种程度，以及定稿后如何随迭代保持一致性。

不过他也强调，这套Spec驱动开发的实现仍在持续演进，而他们最终希望的方向是让Spec覆盖SDLC的完整链条，将需求、设计、任务拆解乃至验证机制一并纳入，从而将传统软件工程的严谨性带回AI开发。

这背后我们无法回避一个关键问题：Spec所要承载的，是软件工程数十年积累的复杂性。

在CodeBuddy产品负责人黄广民看来，Spec的标准，本质上是软件工程理论在AI编程工具中的具象体现。

但问题在于，软件工程理论历经多年发展，在生产实践中并未形成放之四海而皆准的统一标准。因此，不同的Spec变体实际上是在权衡不同的矛盾（如灵活性与严谨性），其最佳粒度也因任务而异。

他认为，Spec标准的有效性确实取决于应用场景，因为Spec本质上是用一种文档/结构去交换三样东西：正确性、效率、维护成本。不同场景对这三者的权重不同，因此不会收敛于单一标准，而是出现多种接受度较高的形态。

Spec是否意味着被“淘汰”的瀑布流程的回归？

软件工程本质上是一个高度不确定的复杂系统。在长程任务中，大模型可能出现幻觉、遗忘，甚至目标漂移；若缺乏机制弥补，Agent很容易偏离方向，返工成本急剧上升。正因如此，Spec才重新显得诱人——它试图将关键目标、约束与验收标准更清晰地固定下来。

但争议随之而来。一位敏捷实践者曾直言，SDD的前进方向本身就是错误的。在他看来，这套方法试图解决的，是一个早已证明行不通的问题：如何将开发人员从软件开发过程中剔除？在这种设想中，编程Agent被用来取代开发人员，并通过周密规划确保Agent能够实现目标。这几乎与瀑布模型的要求一致：在编码前完成大量文档工作，开发人员只需将规范转化为代码。

问题在于，软件开发是一个非确定性过程，规划无法消除不确定性，正如经典论文《没有银弹》所指出的。敏捷方法早已淘汰了以大量前置文档为核心的开发方式。那么，AI编程是否会因此走向一次“瀑布流程回归”？

从工程视角讨论Spec，常见的落脚点并非“是否要完整记录思考”，而是“究竟应结构化哪一部分”。在黄广民看来，Spec Coding真正希望结构化的并非开发者的全部思考过程，而是那些最容易在长程任务中出错、也最值得被验证和沉淀的部分。

当前行业对Spec仍处于探索阶段。Spec更合理的形态应是“活的契约”，它不是一份静态、一次性的文档，而是Plan-Execute闭环中的关键中间态：优秀的Spec驱动实践并非“先写完美Spec再开始编码”，而是用Spec明确正确性口径，然后在推理-执行-反馈的过程中不断校准Spec与代码制品的一致性。“这反而比传统开发更接近工程真实状态，需求会变、约束会变、实现会变，关键是让这些变化可追踪、可验证、可回滚。”

将视角拉长，这一讨论自然指向软件工程领域一个由来已久的母题。天猪在交流中提到，AI编程的一些探索，让他重新想起软件工程早期反复追求却始终未完全实现的目标：是否存在一份足够完备、可验证的描述，其本身就能清晰定义系统运作方式，并且可以被可靠地复现。

在这一愿景下，Spec不再仅是代码的前置说明或过程记录，而是被提升到一个更高的位置——有可能逐步演化为一种比代码更高层、也更稳定的工程产物。

若将软件工程的发展历史整体拉长来看，从最初的0和1，到汇编语言、高级编程语言、DSL以及各类配置与声明式规范，本质上都是在不断提升系统对“人类意图”的表达能力和抽象层级。沿着这一路径，Spec更像是在自然语言这一层级上，尝试迈出的下一次抽象升级。

当然，这条路并不轻松。自然语言的模糊性决定了它很难被直接工程化，也注定这是一条充满挑战、尚无成熟范式的探索路径。但正因如此，它才成为当下业界反复试探和逐步推进的方向，而非已被证明或被否定的结论。

软件抽象：为何Agent总偏爱“重复造轮子”

在AI编程实践中，有一个长期被众多开发者反复吐槽的问题：Coding Agent极其偏好“从零开始实现功能”，而非复用成熟库。

一方面在探索更高层次的抽象形态，另一方面似乎又在绕开软件工程数十年积累的抽象与复用体系，尤其是那些已被验证、优化过的库和接口。而现实中的开发，很少是从零开始构建全新的“绿地项目”，更多是在已有开源库的基础上改动、扩展现有应用，或进行修补工作。

但对模型而言，“自己写一个能跑的版本”往往是风险最低的路径。当它对某个库的版本、用法或边界不确定时，回退到“自己实现”几乎是必然选择。一方面，预训练语料在库层面的分布并不均衡；另一方面，对齐阶段的奖励更偏向“运行正确”，而非“是否优先复用既有抽象”。

再加上库知识的时效性问题：版本更新快、API频繁变更、文档缺失甚至相互冲突都很常见。即便用户明确指定了某个库，只要这些关键信息未被准确放入上下文，模型依然可能出错。

但这并非无解。关键不在于反复对Agent进行人工纠偏或微观干预，而在于补齐它可依赖的信息源。正如黄广民所强调的，与其在结果阶段不断“提醒”，不如在执行阶段准备好信息：通过Context7这类MCP工具补齐版本、用法与示例，再用“渐进式披露”将正确用法注入任务上下文；对于企业内部组件库，则需要系统性沉淀文档、示例、最佳实践与使用边界，才能让Agent稳定复用这些抽象，而非不断另起炉灶。

当新抽象未成熟、旧抽象被绕开、上下文不断膨胀，这些问题最终都会汇聚到同一个地方——运行时成本。

3

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

Token何时开始变得令人揪心？并非在第一次用完免费额度时，而是在你意识到：它已不再是“单次对话的消耗”，而是能直接左右工具定价、产品策略，甚至迫使平台修改规则的核心变量。

今年有两件事几乎同时将这一问题推至台前。一是Cursor：有人在相对便宜的订阅档中，以特定方式跑出远超平台预期的调用量，成本边界被突破。随后不到一年，Cursor连续五轮涨价与功能削减，试图弥补亏空。

另一事件发生在Claude Code的Token排行榜：全球榜首用户用200美元套餐在30天内消耗77亿Token，折合账单约5万美元。一个“使用排行”，迫使Anthropic直接为付费用户添加调用速率限制。

这两幕背后指向同一事实：Token已从“计费单位”演变为生死线。

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

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

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

为完成一个任务，往往需要多轮对话；而每轮对话背后又可能经历数次到数百次工具调用。这意味着上下文中存在大量可复用的稳定信息，从而留下了上下文缓存与重用的空间。模型平台的计价规则也存在差异，不同模型、不同厂商对输入/输出定价、缓存命中收益、工具调用的隐性开销并不一致，进一步放大了Token经济学的复杂度。

大模型刚出现时，成本主要来自对话本身。而现在，检索返回、文件diff、终端日志等大量工具输出，实际上是供下一轮模型阅读的，它们会反复回灌进上下文，成为新的主要成本来源。

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

Spec Coding和多Agent协作使成本结构继续膨胀：随着Spec Coding的兴起，Coding Agent的产出不再只是代码文件，Spec/Plan/ToDo/变更说明/验收清单等中间产物会被反复生成、引用与迭代，形成新的上下文常驻内容；多Agent又将Token转化为通信效率问题——传输什么、多细粒度、如何压缩、如何避免失真，本质上都是在成本与有效信息之间做取舍。

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

对开发者而言，关心的仍然只有三件事：效果、效率、成本。但决定这三件事的，早已不是某次Prompt写得好坏，而是Agent在背后如何组织上下文、如何调用工具、如何重试与纠错。

这也意味着，Token的复杂度真正落在了AI编程工具本身。

在大多数模型平台中，上下文的执行依赖KV cache。理论上，只要上下文无变化，模型即可直接命中缓存，避免重复计算；但在实际工程中，缓存命中远未达理想状态。一旦miss，便等同于为同一段上下文重新付费：API用户需重新承担prefill成本，订阅用户则会更早、更频繁地遭遇rate limit——而速率限制与缓存使用情况高度相关。

这也是为何上下文平台工程的目标听起来如此“功利”：最大化KV cache命中率。不是为了节省几分钱，而是为了避免在长程Agent任务中，被重复、无意义的上下文刷新拖垮吞吐量和稳定性。

哪些信息应长期保留，哪些仅为阶段性的中间产物；哪些内容在完成阶段目标后应及时清理——这些选择，直接决定了系统的成本结构、速率上限，以及Agent能否持续运行。

上下文工程的技术演进路径

回顾上下文工程的技术演进历程，天猪认为行业并无一劳永逸的解法。更多时候，是在不断试错中，从早期的Prompt Engineering，逐步演进至今天更系统化的Context Engineering。

早期，Fine-Tuning被视为直接方案：通过在大模型层面注入领域知识，弥补其世界模型的盲区。但实践迅速证明，这一方式在AI编程场景下成本高昂、灵活性不足，且难以应对多模型频繁切换的现实需求。相比之下，以RAG为代表的“外挂式知识补充”在工程上更具性价比，也更契合AI编程的实际使用模式。

在AI编程的早期阶段，交互主要是一问一答的Chat模式，模型对“首轮输入Context”的依赖极高，因此需要在提问时尽可能一次性注入相关背景，这直接推动了RAG召回机制的普及。

随着Coding Agent的出现，协作模式发生根本变化：交互从单轮对话转向多轮、长期的Agent Loop。此时，相关信息不再需在第一轮全部给出，而是由Agent在执行过程中按需检索与召回。这一变化催生了embedding search与grep等能力的逐步登场。

其中，Cline和Claude Code在今年从传统的RAG转向grep，Cline甚至直言“不能再用2023年的办法解决今天的问题”。

需强调的是，embedding search并未过时。它更像数据库中的index，在特定条件下能显著提升召回效率，而grep则在确定性和精确匹配上具备优势，两者往往服务于不同的检索阶段和需求类型。

进一步地，随着任务复杂度和检索路径的增加，Agentic Search逐渐演化出来，并常与Sub Agent机制协同出现。在复杂场景中，许多Tool Call的中间历史并不具备长期价值，因此会出现专门的Search Agent：它自身运行一个独立的Agent Loop，负责多轮检索、筛选与验证，而embedding search、grep、LSP等仅仅是其可组合使用的工具能力。

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

将上下文拆分为稳定信息与变化信息，使变化部分足够精准、长度可控、可验证；再通过缓存、裁剪、摘要、检索等机制，将Token的边际成本控制在工程可接受的范围内，同时避免因关键信息缺失而放大返工成本——这正是Token工程最终落地之处。

4

结语

若将AI编程视为一个系统工程，它至少由四层共同构成：模型负责“思考”，Tool负责“行动”，IDE承载人机交互，而上下文负责“记忆与连续性”。

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

因此，未来AI编程的真正分水岭，或许不仅在于“谁的模型更强”，而在于谁能持续、准确地将工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构。在天猪看来，AI编程从来不是单一模型能力的比拼，而是工程体系与模型能力共同作用的结果。

这，才是AI编程正在补齐的那几块“工程短板”。

想看更完整的对话与细节展开：

《对话 CodeBuddy 黄广民：一堆冒烟的上下文，正在决定 AI 编程的成败》（https://www.infoq.cn/article/j8jMvIOfmZS8M33t72uP）

《对话 TRAE 天猪：AI 时代的挑战与程序员的认知进化》（https://www.infoq.cn/article/EiO80Aacx4sMZHjtXqNR）

采访嘉宾 | 黄广民、天猪（按嘉宾姓氏首字母排列）