AI取代开发者？一年后我推翻了自己的判断

一年前，我写过一篇文章讨论AI是否会取代开发者。当时的结论是“不会”，AI只是让好开发者更好的工具，底层基础依然重要，大部分新闻都是炒作。一年后再回头看，有些判断我猜对了，有些则错得离谱。

从自动补全到代理编排：我的AI使用进化史

一年前的那篇文章有个有趣的细节：我几乎没有提及自己实际如何使用AI，只在评论区才承认。当时我主要用AI做基本的行内自动补全、快速查询语法、调试晦涩的堆栈信息，很少碰Agent模式。我尝试过更重度地依赖它，但很快觉得像拐杖——感觉自己什么都没学到，对代码库逐渐失去掌控，于是又缩了回去。

今天，我几乎每周都会触及Claude的7天使用上限。变化不是一瞬间的顿悟，而是日常交付压力倒逼的结果。2025年底，我从“自动补全”转向“任务委派”，不再问“这个函数怎么写”，而是说“去执行这个任务”。到了2026年，公司开始为所有人支付Claude订阅，从个人配置切换到企业级工作流，迫使我重新思考整个开发流程。

现在我不只是在聊天框里“用Claude”。我维护着一套个人开发框架，像生产仓库一样进行结构化和版本控制。这个私有仓库扮演着我的“个人工程操作系统”：

• 规则：关于代码质量、数据完整性、测试覆盖证据和Git安全的不可协商边界。强制执行“绝不静默吞掉错误”“标记任务完成前必须验证日志输出”等原则。
• 角色：结构化的多Agent工作流，包括专门的审查团队、执行者、将复杂规格拆分为独立PR的任务切片器，以及一位导师。
• 技能：确定性例程，用于PR创建、提交格式化、自动化自审，以及根据变更影响范围动态调整审查团队规模。
• 模组：直接在Claude Code之上构建的自定义调整和扩展。
• 个人文档库：活的知识库，包含系统上下文、架构决策记录、待办事项、已知陷阱和上下文包。Agent在启动会话前必须阅读，完成任务后必须更新。
• 迁移指南：换新机器时，克隆仓库并告诉Claude“读取并运行”，它就能启动环境、配置工具，立即采用我的工作方法论。

从孤立提示词到编排——Agent、子Agent、审查角色和确定性规则——才是从生成酷炫Demo到工程化生产级应用之间的桥梁。

Agent模式与任务委派是理解这一转变的关键。传统自动补全（inline completion）是模型根据当前光标上下文预测下一段代码，本质是模式补全；而Agent模式让大语言模型具备规划、工具调用、多步执行和结果验证的能力。用户只需给出高层目标（如“修复这个bug并提交PR”），Agent会自行拆解步骤、读写文件、运行测试，并根据反馈迭代。任务委派意味着开发者从“逐行写代码”转为“定义任务边界、验收标准与安全约束”，再审查Agent的输出。这种范式要求开发者具备更强的架构判断和结果验证能力，因为错误可能隐藏在看似合理的多步执行中。

我错在哪里

回看当初的预测，我有几个强烈的观点，但在多个层面都错了。

“氛围编程是死路一条”

我曾认为氛围编程只是非开发者的短暂潮流。我错了。氛围编程确实有效，而且会持续存在。但有个前提：只有用对了才行。氛围编程不是盲目接受生成的代码，而是像建筑师一样通过快速反馈循环引导AI。没有清晰计划会很快迷失，但有了良好的护栏，它是一种非常快速的构建方式。

**氛围编程（Vibe Coding）**一词由Andrej Karpathy于2025年初提出，指开发者用自然语言描述意图，让AI生成代码，自己以“感觉”快速迭代、少做逐行审查的编程方式。它降低了构建原型的门槛，但风险在于：若缺乏明确的计划、测试和架构护栏，代码库会迅速积累隐性缺陷和不可维护的耦合。作者修正后的观点是，氛围编程并非盲目接受生成结果，而是像建筑师一样通过快速反馈循环引导AI——先有清晰蓝图，再让AI填充细节，并用自动化验证兜底。因此它更适合探索期和低风险场景，生产系统仍需规则与多层审查。

S曲线判断

我曾论证AI进展遵循经典技术S曲线，我们已经过了炒作峰值。老实说，如果AI真的在S曲线上，我已经不知道平坦部分在哪里了。我对模型改进速度的怀疑严重不足，新的能力跃升不断让我惊讶。

“高级自动补全”

我曾把大语言模型称为“根本上复杂的模式匹配和自动补全系统”。这个描述现在太简单了。一年前，每个不同任务需要专门的AI模型；今天，最新模型以高精度处理复杂推理、规划和工具使用。它们不只是补全模式，而是在执行真实意图。

技术S曲线描述一项技术从早期缓慢改进、经历快速爆发、最终趋于平缓的成熟过程。作者曾据此判断AI已过炒作峰值，但实际观察是能力跃升仍在持续。原因之一是现代大模型通过规模扩展、后训练（如RLHF）和工具使用，不断解锁规划、推理和多Agent协作等新能力，而非仅在同一维度上渐进。S曲线框架的局限在于：它假设技术沿单一性能指标演进，而AI的能力边界本身在被重新定义，新的应用层和编排方式会反复把曲线“续接”到新阶段。因此用S曲线判断“已过峰值”容易低估范式切换带来的非线性进步。

我猜对了什么

概念上，核心论点站住了脚——即使执行规模超出了我的想象。

• 提示工程正在消退：我曾称之为临时缺口，得到了验证。你不再需要魔法词。模型自然理解领域上下文，协助精炼自身指令，独立编排子Agent。你不是在雕琢提示词，而是在定义意图并审查执行。
• 打字部分被商品化：完全如此。手动将逻辑翻译成语法的行为不再是软件创建的瓶颈。
• 开发者向上层移动：我的日常工作从写代码转向意图规格说明、架构方向、系统引导和代码验证。
• 基础仍然重要：比以往更重要。当代码几秒内生成，你发现细微架构缺陷、内存泄漏和并发Bug的能力，是防止系统崩溃的唯一屏障。
• 恐慌被夸大了：技术转变一直在颠覆软件工程，AI只是压缩了时间线。

没人让我准备好的速度

在上一份工作中，我被分配了一个标准交付周期为2年的项目。利用Agent工作流，我在6个月内交付了它。更重要的是，它不是脆弱的原型——它安全、高性能、有弹性，目前在国家规模上运行。这种杠杆几年前在数学上是不可能的。

在当前工作中，我最大的运营挣扎是估算。我不断算错时间线，因为我的大脑仍然校准在手动编码速度上。估算过去是“我写这个实现要多久”，现在是“验证方案要多久，边缘情况崩溃时需要人介入的频率有多高”。

仍然会灼伤我的地方

尽管能力飞跃，当前范式仍有明显的失败模式：

• 规则退化：在长上下文窗口中，Agent仍然会偏离指令，忘记明确约束。
• 静默架构错误：它能生成干净、语法完美的代码，但做出根本有缺陷的系统设计假设。
• 上下文懒惰：如果代码库中存在坏模式或遗留技术债，Agent会将其视为权威示例，并将这些反模式外推到新功能中。

触发Agent、去睡觉、醒来看到能跑的代码，这越来越容易。但剩下的5%差距——细微边缘情况、竞态条件和安全漏洞隐藏的地方——正是严格规则和多层审查角色发挥作用的地方。

**规则退化（instruction drift）**指在长上下文窗口中，模型对早期系统指令和约束的遵循度随对话增长而下降。Agent执行多步任务时，中间产生的大量工具输出和代码会稀释最初设定的规则，导致它忘记“绝不静默吞掉错误”或“完成前必须验证日志”等硬性要求。缓解手段包括：将关键规则固化为可重复加载的技能或检查清单、在关键节点重新注入约束、把长任务切分为带独立上下文的子任务，以及用确定性脚本而非模型判断来做最终门禁。理解这一失败模式，才能把“触发Agent去睡觉”变成可控的工程流程，而非赌博。

学习陷阱变得更糟了

一年前，我担心过度依赖AI会侵蚀技术成长。这种担忧没有消失，而是演变成了一个主要的行业陷阱。

当Agent能在几秒内解决复杂Bug时，接受diff然后继续的诱惑是巨大的。但如果你不主动审计问题是如何解决的，你会逐渐从软件工程师退化为一个 glorified 的提示词操作员。

为了对抗这一点，我有意将学习重新工程化到环境中：

• 强制解释规则：核心指令要求Agent解释实现决策背后的架构权衡，明确标出非显而易见的代码路径。
• 摩擦注入：设置会标记出我应该手动实现逻辑路径的时刻，以保持肌肉记忆，而不是盲目委派。
• 计划优先执行：在Agent提出高层架构计划并获得明确批准之前，不写任何代码。
• 导师角色：功能合并后，专门角色会拆解所用核心概念，解释被拒绝的替代模式，并将关键经验记录到个人库中。
• 系统追踪技能：探索不熟悉的代码库时，我使用自定义例程追踪端到端事件流，并生成针对性的理解练习供我解决。

如果工具要接管打字，它必须被配置为加速你的理解。否则，你正在悄悄交出你的专业知识。

未来在哪里

我的答案和去年一样，只是赌注高得多。理解底层系统、领域建模、系统架构、安全、性能和长期可维护性仍然至关重要。代码生成的成本已降至接近零，这意味着价值完全转移到了辨别力、系统集成和领域专业知识上。

AI可以写代码和构建平台，但它不会理解你的业务领域，不会与利益相关者谈判需求，更不会建立让软件有价值的客户关系。

“怎么做”每个月都在变便宜。“做什么”和“为什么”才是你真正的工作。