AI Coding生态演进：从补全到Agent主导 - AI Coding的演进分为两个时代：第一波由Copilot与Cursor开创，以人为主导，AI角色是预测“下一个字符”或“下一个编辑位置”，端到端时延被严格压在几百毫秒量级，模型规模和上下文长度受天然约束 [2] - 第二波在过去6–12个月迎来范式颠覆：Agent崛起，直接接管从需求分析到代码生成、工具调用到结果验证的任务 [2] - 随着模型能力与工具链完善，Agent会覆盖从需求到交付的更多环节，逐渐成为主流程；补全范式可能退居幕后，成为支撑Agent精细执行的底层能力之一 [3] 工具形态演化：IDE、CLI与Cloud并行 - 头部编程工具演化出三种形态并行：IDE、CLI、Cloud，用户需要的是在不同场景下都能交付任务的完整链路 [4] - CLI和Cloud Agent从一开始就是Agent主导形态，对UI要求不高，在Terminal或简化Web界面工作，用GitHub PR协作和交付 [4] - IDE依然被判断为最多人使用的入口，最符合程序员长期形成的工作习惯，但其形态本身很可能在三年内发生根本变化，不再以Editor为中心展开 [4][5] - IDE正在从“给人用的工具箱”变成“给AI和人一起共用的工具箱”，大量以人为中心设计的能力被拆解为更小、更明确、更AI友好化的Tool，供AI Agent按需调用 [5] Spec驱动开发的兴起与挑战 - Spec驱动开发在过去几个月迅速流行，仓库中堆起面向Agent的“Markdown脚手架”，被视为AI Coding的前沿解法 [1] - 行业对“Spec”的定义存在分歧：有人认为是更好的Prompt、更详细的产品需求文档、架构设计文档，或是“在写代码的时候，多用几个Markdown文件” [8] - 一线工具团队认为Spec与上下文工程（Context Engineering）不是一回事：Spec是上下文中最关键、最稳定的一类内容，承担“指导性Context”的角色，相当于给Agent一份可执行的契约；而上下文工程关注模型在当下是否拿到了足够的信息 [9] - Spec是一切用于指导代码生成的契约总和，可包括产品文档、设计稿、接口定义、边界条件、验收标准、执行计划等，但因其覆盖范围广、形态多、生命周期长而难以标准化 [9][10] - Spec标准是否有效取决于应用场景，因为它本质上是用一种文档/结构去交换正确性、效率、维护成本三样东西，不同场景对这三者的权重不同 [12] Spec与软件工程复杂性的对接 - Spec试图接住软件工程几十年积累下来的复杂性，其标准本质上是软件工程理论在AI编程工具中的具象化 [10] - 争议在于Spec驱动开发是否会导致“瀑布流程回归”，即在编码前完成大量文档工作，试图将开发人员从过程中剔除 [13] - 从工程视角看，Spec Coding真正想结构化的并非开发者的全部思考过程，而是那些最容易在长程任务里出错、最值得被验证和沉淀的部分 [13] - Spec更合理的形态是“活的契约”，是Plan-Execute闭环中的关键中间态，在推理-执行-反馈过程中不断校准Spec和代码制品的一致性 [14] - 从软件抽象发展历史看，Spec被视为在自然语言层级上尝试迈出的下一次抽象升级，但自然语言的模糊性决定了这是一条充满挑战、尚无成熟范式的探索路径 [15] Agent的“自己造轮子”问题与抽象复用 - Coding Agent在实践中存在一个被大量开发者吐槽的问题：极其偏好“自己从零开始实现功能”，而不是复用成熟库 [16] - 对模型而言，“自己写一个能跑的版本”往往是风险最低的路径，当它对某个库的版本、用法或边界不确定时，回退到“自己实现”几乎是必然选择 [17] - 解决此问题的关键不在于对Agent进行人工纠偏，而在于补齐其可依赖的信息源，例如通过MCP工具补齐版本、用法与示例，再用“渐进式披露”把正确用法注入任务上下文 [17] Token成本失控与上下文管理成为核心 - Token成本在2025年突然复杂了一个数量级，根本原因在于范式迁移：大模型应用从“问答”跃迁到“Agent做事”，Token成本成为贯穿推理—执行—反馈链路的全生命周期成本 [18][19] - 关键变化是工具调用的隐形成本开始吃掉大头，为了完成一个任务往往需要多轮对话，每轮对话背后又会经历几次到几百次不等的工具调用 [20] - Spec Coding和多Agent协作让成本结构继续膨胀：Spec/Plan/ToDo/变更说明/验收清单等中间产物被反复生成、引用与迭代，形成新的上下文常驻内容；多Agent又把Token变成通信效率问题 [21] - Token工程的真正战场是上下文管理，目标是最大化KV cache命中率，避免在长程Agent任务中被重复、无意义的上下文刷新拖垮吞吐和稳定性 [22] - 上下文工程的技术演进从早期的Prompt Engineering，逐步演进到更系统化的Context Engineering，实践表明以RAG为代表的“外挂式知识补充”在工程上更具性价比 [23] 上下文工程的技术演进路径 - 随着Coding Agent出现，交互从单轮对话转向多轮、长期的Agent Loop，相关信息由Agent在执行过程中按需检索与召回，这催生了embedding search与grep等能力的逐步登场 [24] - Cline和Claude Code在今年就从传统的RAG转向grep [24] - embedding search并未过时，它更像是数据库中的index，在特定条件下能提升召回效率，而grep在确定性和精确匹配上具备优势，两者服务于不同的检索阶段和需求类型 [24] - 随着任务复杂度增加，Agentic Search逐渐演化出来，并与Sub Agent机制协同出现，例如专门的Search Agent负责多轮检索、筛选与验证 [25] - 行业逐渐意识到真正稀缺的不是上下文长度，而是有效Context的组织能力，需通过缓存、裁剪、摘要、检索等机制把Token的边际成本控制在工程可接受的范围内 [25][26] AI编程的系统工程视角 - AI编程被视为一个至少由四层构成的系统工程：模型层负责“思考”，Tool层负责“行动”，IDE层承载人机交互，上下文层负责“记忆与连续性” [27] - 模型层决定上限；Tool层决定它能不能真的做事；IDE层决定人是否能高效表达意图、及时纠偏；上下文层把这一切粘合在一起，承载历史决策、工程约束与连续性，是长期可靠性的基础 [27] - 未来AI编程的真正分水岭，或许并不仅仅在于“谁的模型更强”，而还在于谁能持续、准确地把工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构 [27]