AI编程新纪元：Spec与Agent协同重塑开发生态

2025年的AI Coding生态，正引领2026年程序员迈向新角色。答案或许就藏身于那些活跃的Markdown文件之中。

近期，Spec驱动开发备受瞩目。仓库中迅速涌现出面向Agent的“Markdown脚手架”，被视为AI Coding的前沿解决方案：通过一份契约，真正激发Agent的潜力。

然而，这份契约能否应对软件工程几十年的复杂性？抑或程序员的终极价值将从“编码”转向“规则制定”——用AI能理解的自然语言，驾驭这场技术变革？

1

补全的天际与Agent的必然崛起

AI Coding的演进清晰分为两阶段。

第一波由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的要求没那么高，要么是Terminal里干活，要么是简化的Web界面，再加上GitHub PR来做协作和交付。

但天猪判断IDE依然会是最多人使用的入口，原因很简单：它最符合程序员长期形成的工作习惯。他在团队更早期的实践中就意识到：专业生产力工具的颠覆式创新，往往伴随着对开发者认知和工作方式的全面重塑。在他看来，IDE的形态本身很可能在三年内发生根本变化，不再以Editor为中心展开——TRAE的SOLO模式、Cursor的Agent模式，正是业界围绕这一方向展开的探索与实践。

更直白地说：IDE正从“给人用的工具箱”，变成“给AI和人一起共用的工具箱”。过去IDE里大量以人为中心设计的能力，现在正在被拆解为一个个更小的、更明确、更AI友好化的Tool，由AI Agent按需调用。于是IDE会随着技术演进，越来越像一个能力容器和执行环境，供Agent与人协作使用。

这三条路线最终在不同程度上向Agentic Behavior收敛。

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

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

当执行权从人转移到Agent，软件工程几十年来靠经验与默契兜底的复杂度被迫前置成显性规则——Spec也就在这一刻被重新召回。

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

2

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

这个词被喊热不过几个月，一个尴尬却无法回避的现实逐渐浮现：大家口中的“Spec”，早已不是同一个东西。

有人说Spec是更好的Prompt，有人理解为更详细的产品需求文档，也有说是架构设计文档。但对更多工程团队来说，Spec只是“在写代码时多用几个Markdown文件”。

于是你会看到Repo里迅速堆起gemini.md、claude.md、agent.md、cursor-rules、各种Skills等文件。过去几个月，大厂的各类代理工具都在推出“可复用上下文框架”：Claude Skills、Cursor Team Rules、GitHub Copilot Spaces等，整个工具链在一年内爆炸式演进。

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

但国内一线工具团队更偏向认为“它们不是一回事儿”。

在他们看来，Spec更像是上下文中最关键、最稳定的内容，承担“指导性Context”的角色：把目标、约束和验收口径讲清楚，相当于给Agent一份可执行的契约。因此Spec解决的是“我们到底要造什么”，而Context Engineering关注的是“在这一刻模型是否拿到了足够的信息”。虽然两者高度耦合却无法相互替代。

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

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

在这一轮Spec驱动开发的讨论中Kiro常被视为重要推动者之一。其技术负责人Al Harris曾在公开分享中提到为了找到合适的Spec形态团队内部前后尝试过大约七种不同实现——从ephemeral spec、分层spec到基于TDD的spec几乎“给所有东西都加过spec的后缀”。说到底他们是在反复回答三件事：Spec何时该“定稿”、定多细以及定下来的东西如何迭代不走样。

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

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

...（内容较多省略）...

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

...（内容较多省略）...

3

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

...（内容较多省略）...

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

...（内容较多省略）...

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

...（内容较多省略）...

写在最后

...（内容较多省略）...