原文：Matthew Sinclair - 2025.04.21

副标题：为什么 LLM 驱动的编程更像是机械外骨骼而非人造人

上个月，我使用 Claude Code 构建了两个应用程序：一个非典型后端代理处理平台的 MVP，以及一个相当复杂的 B2C SaaS 产品的前端早期版本。这些项目总共生成了约 3 万行代码（在开发过程中又废弃了大约同等数量的代码）。这段经历让我对 AI 与软件开发的关系有了重要认知——这与当前的主流叙事截然不同。

机械外骨骼程序员

还记得《异形 2》中雷普利与异形女王的终极对决吗？她穿上了动力装载机——一种能放大她力量和能力的工业外骨骼。这套装备没有取代雷普利，而是将她转变为比单独的人或机器都更强大的存在。

这正是 Claude Code 这类工具的实际工作方式。它们不是替代程序员，而是现有能力的放大器。那个后端项目？用传统方式可能需要数月。借助 Claude Code，我几周就完成了核心部分。但必须明确的是——我并非只是描述需求然后坐观奇迹发生。

想象雷普利操控动力装载机的场景。Claude Code 给了我惊人的"举重"能力，同时我保持对方向的控制。所有架构决策、质量标准设定、愿景把控都由我完成。最重要的是，我必须时刻警惕它偏离轨道。当这种情况发生时（经常发生），我需要及时纠正。AI 以惊人速度处理实现细节，但背后的"大脑"？仍然是我，且全程保持专注。

必要的警惕

能力越大，责任越大。使用 AI 编程工具必须保持持续警惕——这是我通过多次惨痛教训学到的。

Claude Code 偶尔会做出令人困惑的决定：为了通过测试而修改框架代码、注释整个代码段并用硬编码值替代、引入不必要或不恰当的依赖。它有强烈的行动倾向，因此必须严格限制其行为。我甚至发现自己会以某种拟人化的方式对它"咒骂"，这种反应至今仍让我感到困惑。

就像驾驶 A380 客机：系统能处理复杂操作，但关键时刻需要人类接管。现代飞机几乎可以自动驾驶，但驾驶舱仍需要技术娴熟的飞行员做出关键决策。稍不留神就会导致麻烦。以我的后端项目为例，由于在关键节点分心，最终需要三次完全重写——放任 AI 选择的问题实现路径直到后期才显现。

这种警惕要求创造了有趣的互动模式。虽然 AI 极大加速了某些开发环节，但它需要开发者以不同方式集中注意力——减少逐行编码的关注，增加对审查、指导和架构完整性的重视。

编码的时间成本

使用 Claude Code 从根本上改变了编程时间的经济学。传统编程包含三个"时间桶"：

  • 为什么要做？ 理解业务问题和价值
  • 需要做什么？ 概念层面的方案设计
  • 如何实现？ 实际编写代码

几十年来，最后一个桶消耗了我们大量时间。现在，这个时间成本几乎降为零。我可以在短时间内生成数千行功能代码——这着实令人震撼。

但关键洞见在于：前两个桶依然存在。事实上，它们变得比以往任何时候都更重要。理解构建意图和明确定义需求已成为开发速度的主要制约因素。

还出现了一项新技能：果断舍弃。既然代码生成近乎免费，我们需要更自如地抛弃完整解决方案。程序员深受沉没成本谬误困扰——不愿丢弃投入心血的代码，担心破坏重要功能或无法恢复工作状态。

但当你的“助手”能在几分钟内重写所有代码时，这个等式完全改变。在后端项目中，我三次面对数千行"技术上可行"的代码，却因方法不当而决定全部重写。这并不容易。本能仍想挽救重构，但正确做法是退后一步重新思考，指引 AI 选择不同路径。

这种果断舍弃的能力是大多数开发者尚未培养的"肌肉"。它需要架构判断的自信和对实现时间价值的根本性转变。

经验依然重要

对我来说，使用 Claude Code 本身就是学习过程。进展常常是进两步退三步，尤其在初期。每天生成 2 万+行代码变得相对简单，但知道何时抛弃一切重头再来——这需要 30 年的经验积累。

智慧和些许白发给了我信心，能识别表面可行实则无法扩展或维护的方案。不能只是旁观代码生成，必须密切注意反模式或潜在问题——这些代码可能在编写后很快失效，或潜伏未来造成麻烦。

这凸显了一个关键危险：缺乏实战经验的开发者可能无法识别 AI 产生的无意义输出。他们可能意识不到 AI 生成的代码虽解决眼前问题，却制造了三个新问题。机械外骨骼能放大能力，但缺乏专业操作也会放大错误。这些工具极其强大，但方向错误时也极其危险。

半人马效应

国际象棋提供了一个有用的类比。半人马象棋将人类与 AI 引擎结合，创造出超越单独人类或 AI 的团队。有趣的是，即使 AI 引擎能轻易击败特级大师，人机组合仍优于纯 AI。人类提供战略方向和创造性问题解决；机器提供计算能力和战术精度。

使用 Claude 的经历清晰印证了这种效应。当我将 AI 视为伙伴而非替代品时，开发速度显著提升。最有效的方式是：先写出意识流式的"需求草稿"，然后与 Claude 迭代形成正式设计文档。

但这种合作仍需我的领域知识和架构判断才能成功。AI 擅长模式识别和代码生成，但缺乏上下文理解来做适当权衡和设计决策。它无法判断看似合理实则荒谬的方案，需要我持续监督保持正轨。

寻找平衡点

构建这些应用需要在授权与控制间找到平衡。当缺乏监督时，Claude 在后端会陷入疯狂的死胡同——用日益复杂的方案解决本应不同处理或无需解决的问题。最糟糕的案例中，它完全复制了整段代码而非复用现有组件。它"运行"了（某种意义上的运行），但这是错误的，大错特错。

前端也类似。我必须不断阻止它用 hacky JavaScript 实现功能，而非使用地道的 Elixir 和 Phoenix LiveView 模式。

逐渐地，我形成了协作节奏。对遵循既定模式的简单实现，可以广泛授权；对需要权衡的新挑战，则需提供详细说明并仔细审查输出。

没有 Claude Code，我无法如此快速完成这些构建；但若缺乏人工监督，项目也会完全失败。真正的价值在于理解何时利用 AI 能力，何时坚持人类判断。

未来属于增强

许多观点认为 LLM 将取代程序员。虽然 LLM 的诸多表现令我惊讶，且相信会有更多惊喜，但目前我看不到 LLM 能有效取代程序员——但它们正在改变我们的工作方式。就像雷普利学习操作动力装载机，我们正在掌握能极大扩展能力的新工具。

这种转变将改变我们对开发者的价值评判。原始编码能力重要性降低；架构思维、模式识别和技术判断变得更为关键。有效指导和协作 AI 工具的能力本身成为重要技能。

在新环境中蓬勃发展的开发者，不会是恐惧或抗拒 AI 工具的人，而是掌握它们的人——既理解其非凡潜力，也清楚其现实局限。他们将明白目标不是消除人类，而是增强人类的成就。

在我看来，这是值得拥抱而非恐惧的变革。机械外骨骼已准备就绪，随之而来的是以空前规模和速度构建软件的潜力——但只有那些精通操作、能避免伤己伤人的技术人员才能驾驭。