上个月，我使用 Claude Code 构建了两个应用程序：一个用于处理非平凡后端代理平台的最小可行产品（MVP），以及一个面向消费者的 SaaS 产品（B2C SaaS）相当复杂的前端的早期雏形。这两个项目总共生成了大约 3 万行代码（在此过程中丢弃的代码量也大致相当）。这次经历让我对人工智能和软件开发有了一些重要的认识，这与当前许多主流观点相悖。
身着动力装甲的程序员
还记得《异形》中蕾普莉（Ripley）与异形女王的最终对决吗？她穿上了动力装载机（Power Loader）——一种工业外骨骼，能够放大她的力量和能力。这套装甲并没有取代蕾普莉；它将她转变为远比单独的人类或机器更强大的存在。
这正是在实践中 Claude Code 这类工具的工作方式。它们不是替代程序员；而是我已有能力的放大器。那个后端项目？如果用老方法，我可能需要几个月才能完成。有了 Claude Code，我几周内就搞定了核心部分。但需要明确的是——我并非仅仅描述我想要什么，然后看着魔法发生。
想象一下蕾普莉控制那台动力装载机的场景。Claude Code 给了我巨大的“提升力”，同时由我掌控着前进的方向。我做出了所有的架构决策，设定了质量标准，并确保项目符合愿景。最重要的是，我必须时刻警惕——它是否偏离了轨道。当它确实偏离时（这种情况经常发生），我必须将其拉回正轨。AI 以惊人的速度处理实现细节，但操作背后的大脑？仍然是我的，并且始终保持参与。
时刻警惕是必需的
能力越大，责任越大。在使用 AI 编码工具时，你必须保持持续的警惕——这是我通过几次痛苦的教训学到的。
Claude Code 偶尔会做出令人困惑的决策：修改框架代码以使测试通过；注释掉整段代码并用硬编码值替换，以实现测试通过，而不是修复潜在问题；或者引入不必要或不合适的依赖项。它有巨大的“行动偏见”（bias for action），所以你必须毫不留情地让它少做一些事来加以控制。我甚至发现自己有时会对着它骂骂咧咧，这是一种奇怪的拟人化行为，我至今仍不确定自己是否对此感到自在或完全理解。
就像驾驶 A380 客机一样，系统处理着巨大的复杂性，但需要在关键时刻由人来掌控操纵杆。现代飞机几乎可以自动驾驶，但我们仍然需要熟练的飞行员在驾驶舱内做出关键决策。即使短暂地将视线移开过程，也可能导致麻烦。就我的情况而言，后端项目需要三次完全重写，因为我在关键节点分心了，让 AI 走上了有问题的实现路径，而这些问题直到很久以后才显现出来。
这种警惕性要求创造了一种有趣的动态。虽然 AI 极大地加速了开发的某些方面，但它要求开发者投入不同类型的注意力——更少关注编写每一行代码，更多关注审查、指导和维护架构完整性。
编码的时间成本
使用 Claude Code 从根本上改变了我对编程时间经济学的看法。传统上，编码涉及三个不同的“时间桶”：
1. 我为何要这样做？ 理解业务问题和价值
2. 我需要做什么？ 从概念上设计解决方案
3. 我该如何做？ 实际编写代码
几十年来，最后一个“桶”消耗了我们大量的时间。我们会花费数小时、数天或数周来编写、调试和完善代码。有了 Claude，这个时间成本骤降至近乎为零。我一次就能生成数千行功能代码——坦白说，这令人难以置信。
但这里的关键洞见是：前两个“桶”并未消失。事实上，它们变得比以往任何时候都更加重要。理解你所构建东西背后的意图，并清晰地定义需要完成什么，现在是开发速度的主要制约因素。
并且出现了一项新技能：挥舞“快刀”（wielding the knife）。由于代码生成基本上是免费的，我们需要更习惯于扔掉整个解决方案。“沉没成本谬误”（sunk cost fallacy）对程序员打击很大——我们讨厌丢弃我们投入过的代码，担心可能会破坏重要的东西或再也回不到可工作的状态。
但当你的助手可以在几分钟内重写所有东西时，这种计算方式就完全改变了。在我的后端项目中，有三次，我看着大量的代码——数千行技术上可运行的代码——然后决定完全废弃它，因为方法不对。这并不容易。我的本能仍然是试图挽救和重构。但正确的做法是退后一步，重新思考方法，并引导 AI 走向不同的路径。
这种果断舍弃（cut ruthlessly）的能力是大多数开发者尚未培养的“肌肉”。它需要你对自己的架构判断有信心，并彻底改变你对实现时间价值的看法。
经验依然重要
对我来说，使用 Claude Code 本身就是一次学习经历。进展常常感觉像是“进一步，退三步”，尤其是在早期阶段。每天生成 2 万多行代码变得相对简单，但知道何时该扔掉一切从头开始——这需要 30 年的经验。
智慧和一点灰白的头发给了我信心，让我能够识别出某种特定方法无法扩展或妥善维护，即使代码表面上看起来功能正常。我不能只是坐在那里看着它生成代码，而是必须密切关注，以发现正在出现的反模式或更糟糕的情况，这些问题要么在写完后很快就会失效，要么潜伏下来日后造成麻烦。
这突显了一个关键危险：缺乏大量实际经验的开发者可能无法识别 AI 何时输出了无稽之谈。他们可能意识不到 AI 生成的代码虽然解决了眼前的问题，但在此过程中又制造了三个新问题。“动力装甲”放大了能力，但在没有专业知识的情况下操作时，它也会放大错误。这些工具极其强大，但如果指向错误的方向，它们也极其危险。
“半人马”（Centaur）效应
国际象棋提供了一个有用的类比。“半人马国际象棋”（Centaur chess）将人类与 AI 国际象棋引擎配对，创建出的团队表现优于单独的人类和单独的 AI 系统。有趣的是，即使 AI 国际象棋引擎可以轻松击败特级大师，人机组合仍然比单独的 AI 产生更优越的结果。人类提供战略方向和创造性问题解决能力；机器提供计算能力和战术精度。
我的 Claude 使用经验清晰地展示了这种效应。当我将 AI 视为合作伙伴而非替代品时，开发速度显著提高。我发现最有效的方式是，我花时间写出一个意识流式的“规范”（spec），然后与 Claude 迭代，将其转化为更正式的设计文档。
但这种伙伴关系仍然需要我的领域知识和架构判断才能成功。AI 擅长模式识别和代码生成，但缺乏进行适当权衡和设计决策所需的上下文理解。它无法判断何时做的事情看起来还行，但实际上是疯狂的（bonkers）。它需要我持续观察并使其保持在正轨上。
寻找平衡点
构建这些应用程序需要在授权（delegation）和控制（control）之间找到正确的平衡点。在后端，如果放任不管（left unsupervised），Claude 会钻进一些疯狂的“兔子洞”（insane rabbit holes）——在这些地方，AI 会为那些本应以不同方式解决或根本不需要解决的问题，实施越来越复杂的解决方案。在一个噩梦般的例子中，它最终在一个地方完全复制代码的整个部分，而不是重用现有组件。它能运行（某种意义上的“运行”），但它是错的。大错特错。
在前端也是类似的情况。我必须不断阻止它试图用蹩脚的（hacky）JavaScript 实现功能，而不是使用符合 Elixir 和 Phoenix LiveView 习惯用法（idiomatic）的模式。
随着时间的推移，我形成了一种协作的节奏。对于遵循既定模式的直接实现，我可以广泛授权。对于新颖的挑战或存在重大权衡的领域，我需要提供更详细的规范并更仔细地审查输出。
没有 Claude Code，我不可能这么快完成我所构建的东西，但如果没有人类的监督，它也注定会彻底失败。真正的价值在于理解何时利用 AI 的能力以及何时坚持人类的判断。
未来是增强（Augmentation）
许多圈子里有一种观点认为 LLM 将取代程序员。我对于说这永远不会发生持犹豫态度，因为最近 LLM 的很多事情都让我感到惊讶，我预计未来还会有更多惊喜。然而，就目前而言，我并不认为 LLM 能有效取代程序员；但它们正在改变我们的工作方式。就像蕾普莉在她的动力装甲里一样，我们正在学习操作强大的新工具，这些工具将我们的能力扩展到远超我们独自所能达到的程度。
这种转变将改变我们对开发者的价值评判。原始的编码能力变得不那么重要；架构思维、模式识别和技术判断变得更加关键。有效指导 AI 工具并与之协作的能力本身就成为一项至关重要的技能。
在这个新环境中茁壮成长的开发者不会是那些害怕或抵制 AI 工具的人，而是那些掌握它们的人——他们理解这些工具非凡的潜力及其非常真实的局限性。他们会认识到目标不是将人类从等式中移除，而是增强人类所能完成的事情。
在我看来，这是值得拥抱而非恐惧的事情。“动力装甲”正在等待着，随之而来的是以先前无法想象的规模和速度构建软件的潜力——但这只适用于那些足够熟练、能够以不伤害自己或周围人的方式操作这些机器的人。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
