AI Coding 生死局：Spec 正在蚕食人类编码，Agent 造轮子拖垮效率，Token成本失控后上下文工程成胜负手

极客邦科技InfoQ·2025年12月30日 17:20

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

蚕食

天使轮江苏省2017-09

家政服务软件

36氪报道本地生活高新技术企业民营科技企业

我要联系

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，再加上 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 Coding 是否会因此走向一次“瀑布流程回归”？

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

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

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

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

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

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

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

在 AI Coding 的实践中，有一个长期以来被大量开发者反复吐槽的问题：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 Coding 场景下成本高昂、灵活性不足，且难以应对多模型频繁切换的现实需求。相比之下，以RAG为代表的 “外挂式知识补充” 在工程上更具性价比，也更符合 AI Coding 的实际使用模式。

在 AI Coding 的早期阶段，交互主要是一问一答的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 工程最终落地的地方。