第一次跃迁：光标处补全
以 GitHub Copilot 为代表的 IDE 补全工具，形态是「灰字建议」：模型根据当前文件与光标前的内容，预测接下来要写的代码，你按 Tab 接受。本质是单文件、短程的续写预测——上下文主要来自当前文件及其邻近打开的文件。
它改变的是速度，不是模式：你仍然逐行思考、逐行确认，只是有一部分行是 Tab 按出来的。样板代码、常见算法、重复模式被大幅加速；但跨文件的改动、需要理解项目全局的任务，它无能为力。短板的根源很好理解：它的任务形态就是「给定前文、预测下文」，既装不下整个项目，也没有任何行动能力。
第二次跃迁：对话式多文件编辑
以 Cursor 这类 AI 编辑器为代表，形态变成「对话 + diff」：你在侧边栏用自然语言描述需求，模型读取 workspace 里多个相关文件，给出跨文件的修改方案，以 diff（差异对比）形式呈现，你逐块接受或拒绝。
两个关键变化：一是上下文从「光标附近」扩大到「项目级别」，配合代码库索引，模型能同时理解多个文件之间的关系；二是交互方式从「写代码」变成「描述需求、评审改动」。适合目标明确的中型改动。但它仍是回合制的：每一步都需要人来发起，人不发话它不动。diff 评审还带来一个容易被忽视的心理变化：接受一段 diff 的成本，远低于自己写出同样代码的成本，「全收」的诱惑始终存在——「改坏了大不了撤销」是危险的错觉，撤销得掉的是工作区，撤销不掉的是已经合进主干的坏改动。
第三次跃迁：Coding Agent
以 Claude Code 这类运行在终端里的智能体为代表（各家 IDE 也在快速吸收同类能力）。这一类工具的共性能力是：
- 自主规划：接到目标后自己拆解任务，形成执行清单
- 读写文件：按需检索、浏览、修改仓库里的文件
- 执行命令：跑构建、跑测试、执行 shell 命令
- 自我修复：根据报错输出定位问题、修改、重跑，循环迭代直到通过，或确认需要人决策
注意自我修复依赖外部信号：报错信息、测试输出、编译警告都是喂回模型的证据，修复循环是「读证据、改代码、再验证」，而不是模型凭空想象。
人的角色从「每一步都管」退到「给目标、给约束、看结果」。一次交互的粒度从「一段代码」变成「一个任务」。
跃迁背后的两个技术变量
三次跃迁不是凭空发生的，背后是两个技术变量各自往前挪：
上下文工程——能塞进什么。 从光标附近的几百 token，到整个仓库的语义索引、按需检索的相关片段、外置的任务清单、被压缩摘要的历史对话。模型看不见的就做不到，上下文工程决定了模型「知道什么」。
工具调用——能动手做什么。 从只会输出文本，到结构化的函数调用（模型按 schema 生成调用参数），再到稳定的工具执行循环（调用、观察结果、再决策）。工具调用决定了模型「做得到什么」。
每次跃迁都是两个变量同时跨过门槛的结果：只看得见一个文件，谈不上多文件编辑；不能执行命令，谈不上跑测试自我修复。两者还相互成就：上下文喂得越准，调用哪个工具的决策越对；工具执行的结果又能反过来扩充上下文——跑一遍测试，把失败输出读进来，就成了下一轮推理的证据。
工作流的真实改变
- 从写每一行到写规格：需求描述的精度直接决定产出质量，模糊的指令得到模糊的实现
- 从串行到并行：Agent 跑着任务 A，你可以同时推进任务 B，回头集中评审
- 评审成为核心技能：读 diff、判断改动边界与副作用的能力，比敲字符的速度重要得多
- 测试的价值放大：测试是 Agent 的反馈信号，测试越全，Agent 越敢改、改得越准
现实边界
- 架构决策：技术选型、模块边界、取舍权衡，需要组织上下文与长期责任，Agent 只见树木
- 安全审查：生成代码可能引入漏洞、引入不可信依赖，安全敏感路径必须人审
- 隐含需求澄清：「把登录优化一下」背后一半的真实需求在相关人的脑子里，Agent 不会主动去找该问的人
- 责任归属不变：合入主干每一行代码的责任，始终在按下合并按钮的人
工具负责加速，人负责判断——这个分工在可见的技术水平内没有变化。
小结
三次跃迁：补全让打字变快，对话式编辑把「描述需求」变成交互方式，Coding Agent 把交互粒度升到任务级。驱动它们的是上下文工程与工具调用两个变量的交替进步。开发者的重心随之从「写」移向「定规格、评审、并行调度」，但架构决策、安全审查与需求澄清仍然必须由人守住——工具加速，人负责判断。
读者留言
COMMENTS 暂无还没有留言，来说第一句？