内容
“AI 负责编码，人类只是流程中的协调者”
这正是当前业界热炒的观点：传统编程已名存实亡，规范驱动开发（Spec Driven Development，SDD）才是未来。你只需生成一份计划，然后彻底脱离代码编写。代理比你更懂如何实现，它们会处理所有具体实现。你的角色是作为专家，提供“良好品味”，审查输出结果，并不断引导代理执行你精心制定的计划。
目前，这类工作流程形态各异，但总体而言，其核心流程是：某人定义项目的需求（同时涵盖微观与宏观层面），生成计划，然后反复拉动老虎机拉杆，与多个代理实例不断迭代、重复，直到任务完成。在此过程中，“协调者”与实际生成并提交的代码之间，距离越来越远。
编码代理确实强大且有用，但已出现一些可量化的权衡，亟需讨论：
- 为缓解 AI 非确定性带来的模糊性，周边系统的复杂性显著上升。
- 广大开发者群体的技能正在退化。
- 个人乃至整个团队面临供应商锁定风险（Claude Code 的宕机已导致多个团队完全停摆）。
- 使用这些工具的成本波动且持续上涨。员工成本是固定的，而 token 消耗却是个不断变化的变量。
要成功采用这种代理式编程方式，关键在于一个至关重要的前提：只有具备批判性思维、熟悉架构层面操作的熟练开发者，才能在数千行生成代码演变为问题之前，及时发现其中的隐患。
然而，颇具讽刺意味的是，AI 工具已被证实会负面影响个体的批判性思维能力和认知清晰度——而这恰恰是有效使用这些工具所依赖的核心能力。
不只是“另一种抽象”
社区中常听到一种论调：程序员只是“向上迁移”到了另一种抽象层面。但这些工具是否真的构成抽象层，本身尚无定论；更高的模糊性并不等于更高的抽象层级。
暂且搁置这一争议，不可否认的是，程序员历来对新语言和新编程方式持谨慎态度。FORTRAN 问世时，程序员也曾对其表示怀疑。他们提出类似的担忧：它可能引入更多 bug 和不稳定性，直接编写汇编代码效率更高。后来，围绕编译器集成是否给流程注入了过多“魔法”的争论也层出不穷。这些都属于对新技术可能带来损失的规范性担忧。
而今天的情况不同之处在于，过去的担忧更多是推测性和理论性的。AI 工具问世短短几年，我们已观察到显著的实际影响。受影响的不只是初级开发者，甚至包括拥有十年（或更久）经验的开发者：
初级开发者面临的挑战更为严峻，因为我们正在削弱他们直接操作代码的能力，代之以审查生成代码。代码审查固然重要，但充其量只占学习过程的 50%。若缺乏直接编写代码所带来的摩擦与挑战，他们的学习能力将严重受限。
研究这一现象需要时间，因此收集 anecdotal evidence（个案证据）对于实时了解现状至关重要。但已有相关研究，多项 报告均表明，这确为真实存在的现象。
这次确实不同以往
当 C++ 开发者转向 Java 或 Python 时，并未抱怨思维模糊。当系统管理员转向 AWS 时，也未感到自己理解网络的能力在衰退。
高级工程师随着转向管理岗位、编码实践减少，编码能力逐渐“生疏”，这并非新现象。这是专业能力发展的自然路径：拥有数十年编码经验、历经无数摩擦与积累的工程师，才有足够时间和经验将技能与智慧固化。当工作重心从语法细节转向更高层的架构决策时，他们便可运用这些智慧。这类人才本就极其稀缺，而如果我们所有人都逃避编写、解决问题和调试所带来的摩擦，下一代高级工程师将无从产生。
当前的趋势是：那些从未经历过长期积累、缺乏 30 年以上编码摩擦以形成深刻理解的开发者，正被推向需要同等技能来管理 AI 代理的高层工作流——而这些技能本是高级工程师耗费数十年才掌握的。
然而，高级工程师也并非免疫。拥有近 30 年开发经验的 Simon Willison 曾坦言，自己“对应用程序能做什么、如何运作缺乏清晰的心智模型，这意味着每增加一个功能，理解起来都更加困难”。
“熟练协调者”困境
Anthropic 近期一项研究中，有一段出人意料的坦诚表述，谈及频繁使用编码代理的风险：
编码技能退化的问题之所以令人担忧，原因之一是“监督悖论”……有效使用 Claude 需要监督，而监督 Claude 又恰恰依赖于那些可能因过度使用 AI 而退化的编码技能。
LinkedIn 软件工程总监 Sandor Nyako 管理着 50 名工程师，他注意到这一现象在整个组织内蔓延，并已要求团队“不要将 AI 用于需要批判性思维或问题解决的任务”。
“技能成长需要经历困难。人们必须锻炼‘思考问题的肌肉’，”他说，“如果缺乏批判性思维，一个人又怎能质疑 AI 的准确性？”
此外，“过度使用”的界定也成问题。我们已有数据驱动和▶ 个案证据表明，这些技能可能迅速退化甚至消失（某些情况下仅需数月）。
这正是许多 AI 鼓吹者自相矛盾之处：使用编码代理的行为，正在主动削弱有效管理这些代理所必需的核心技能。
大模型加速了错误的方向
与当前主流叙事相反，我们未必需要更快地编写代码——尤其是那些我们不完全理解、且无法在合理时间内审查的大段代码。
在 AI 出现前，一名（优秀）开发者的优先级可能是：
- 理解代码及其在代码库中的关联
- 代码是否符合文档化的高效标准
- 用最少的代码行数达成目标（同时保持可读性）
- 交付周期
代理式编程及通用大模型，则完全颠倒了这一优先级。
它们的能力和使用方式往往聚焦于提升单位时间内生成代码的数量，从而追求速度。速度本应是高能力的自然副产品，若强行追求，必然导致准确性下降。这些工具的集成通常不注重深层理解或代码简洁性。
能否以正确方式使用它们？当然可以，只要有决心。
实际是否如此？并非如此。组织内部对 token 消耗的狂热追捧已充分说明问题。
编码 === 规划
开发者之间存在一个较少被提及的分歧：我们中有些人通过编写代码来更好地规划和思考。在代码中思考与工作并非无意义的苦差事；它迫使你从技术层面思考问题，涵盖安全、性能、用户体验到可维护性等方方面面。
在最近一次▶ 访谈中，OpenCode 的创建者 Dax（一个开源编码代理工具的缔造者）谈及“规范驱动开发”时表示：
“在处理新事物或挑战性任务时，我敲下代码的过程，就是理清我们到底该做些什么的过程。
我很难只是坐在那里，写出一份详尽的功能实现规范。我喜欢写下类型定义，喜欢勾勒函数之间如何协作，喜欢通过调整文件夹结构来探索不同概念的边界。我认为大多数程序员一直以来都是这样做的。我个人看不出有任何理由要停止这种方式，因为这是我理清我们到底该做些什么的方式。”
你所说的往往并非你所想，而大模型会用假设（或幻觉）填补模糊之处，从而导致：更多审查、更多代理修改、更多 token 消耗，以及更深的与创作内容的脱节。反过来说，即便你精心撰写了最清晰、无歧义、结构完美的提示词，大模型仍可能输出幻觉方法——因为它本质上是一个下一个令牌预测引擎，而非编译器。你无法用概率系统替代确定性系统，却期望零模糊性。
即便是最▶ 热衷 AI 的高级开发者，也开始意识到这种脱节正成为一个日益严峻的问题。
供应商锁定
不久前 Claude 宕机期间，我在浏览 LinkedIn 时注意到大量帖子指出，部分开发者和工程团队陷入停滞。他们的工作流程乃至自身编码能力，早已发展到严重依赖这些供应商的程度。曾经只需键盘和文本编辑器即可施展的技能，如今突然需要订阅 AI 模型服务。
你无法预测 token 成本。
模型提供商目前仍 heavily subsidized，而模型本身建立在流沙之上。每次新模型发布都遵循相同模式：高基准测试成绩 → 炒作 → 实际使用中的落差，众人抱怨模型“被削弱”，完成相同任务需消耗 2-3 倍 token。
你清楚员工的成本；却完全无法预知每日、每月、每年的 token 开销。若整个团队默认使用代理式编程，你的支出账户必须保持高度灵活。正如 Primeagen 最近所言：“当你使用这些完全自主智能工作流时，▶ 模型提供商 essentially own you。”
推演这一模式并不牵强：我们可能正在创造一个行业，其中必须支付 token 费用才能完成原本依赖自身批判性思维和问题解决能力的工作。这类似于一种“供应商锁定”，但锁定的是整个行业的核心技能集（我确信模型提供商正幸灾乐祸地搓着双手，期待这一天的到来）。财务与理智的割韭菜可能随时发生，而本地大模型远未准备好承接如此规模的使用需求。
这并非理论推测；▶ 当前已有报道。甚至模型提供商自身也在揭示这一问题。Anthropic 另一项研究显示，调试技能出现47% 的断崖式下跌：
“将 AI 激进地引入职场——尤其是在软件工程领域—— 不可避免地伴随权衡……开发者可能依赖 AI 快速交付成果，却以牺牲关键技能为代价——尤其是当事情出错时的调试能力。”
当然，有办法避免这一切。大模型是强大的技术突破，若负责任地使用，它们能成为学习与技能提升的绝佳工具。它们让我能更深入、更广泛地探索概念与技术，拓展理解边界， 促成对以往费时费力的 ideas 进行实验。我认为这正是它们能为行业带来长期最大价值的领域。
我的做法：降低 AI 的角色定位
我绝非主张手动逐字敲代码。程序员一直都在寻找创建代码而无需编写代码的方法。正因如此，我们才有了 Emmet、自动补全和代码片段。就连 COBOL 也通过使用 MOVE、WRITE 等“类英语”词汇，实现用更少代码封装更多指令。jQuery 的口号是“write less, do more”。大模型不过是这一系列代码生成工具中的新成员。
我真正倡导的是：将大模型与编码代理作为辅助流程使用，一种不牺牲个人技能以换取生产力的方式。你可以反转脚本，在规划阶段借助它们头脑风暴，同时在实现过程中保持主动参与，仅在必要时委派任务。如此，你既能享受生产力提升，又能减轻理解债务。
我的日常工作流：
- 使用大模型辅助生成规范与计划，而我主导实现。这是对“协调者”工作流的反转；根据任务不同，我仍手动编写 20% 至 100% 的代码。
- 与模型交互时，我经常编写伪代码，以缩短请求与生成代码之间的距离。
- 将模型作为委派工具，用于临时代码生成、交互式文档查阅及研究，以便持续提问、迭代、重构，厘清思路。
- 绝不生成单次无法 review 的代码量。若内容过多，我会放慢节奏，拆分任务，必要时手动重构，确保对最终结果有全面理解。
- 绝不要求大模型或代理实现我从未做过或无法独立完成的功能——除非纯粹出于教育或教程目的（且通常随后即弃用）。
若要用一句话总结：将它们当作飞船计算机使用，而非数据。
（任何《星际迷航》粉丝都应明白这个梗）
我并未更快，但工作质量更高。
这些模型带来的生产力提升是真实的，而频繁、 有形地参与工作所带来的摩擦与理解也同样真实。
尽管编程平民化而不理解编码的尝试屡遭失败，我们仍面临一个现实：不接触代码，就无法理解代码。而事实已表明，若不持续接触与编写代码，确实会丧失这种理解力，进而使你成为一名更不合格的协调者，使这一阶段的 AI 编程沦为一段奇怪且不必要的压力插曲。
或许我杞人忧天，但历史教训犹在。
这一切感觉似曾相识，仿佛我们又在对自己进行另一场大型实验。我们曾经历过社交媒体的引入，却未理解其长期影响，如今正面临注意力缺陷（及其他诸多问题）的广泛蔓延。
而这一次，我们赌上的是风险更高的东西。
“现在 all in AI 智能体的人，正在确保自己的淘汰。若将所有思考外包给计算机，你便停止技能提升、学习与变得更加专业能干。” —— Jeremy Howard，fast.ai 创始人