Vibe 编码悖论

Source: Dev.to

AI 作为自有系统的协同开发者

我在 Nudges 的最后一次 PR 为 +96 −312，涉及 38 个文件，约 90 % 是 vibe‑coded。我对它很有信心。

当我在海拉尔（Hyrule）漫游时，两个不同的 AI 代理悄悄地重构 Kafka 消费者、验证负载结构，并提交了干净、范围明确、可直接投产的改动——而且感觉很好。

因为在那个系统里，AI 不只是猜测——它在我有意构建的系统内部工作。

同样的体验——AI 作为协同开发者，毫无摩擦且快速——在我的合同工作中却截然不同。那里我不拥有系统，甚至不信任系统。它仍然写代码，写出最好的代码。而这——比任何事都更能体现这个新时代的悖论：AI 消除了摩擦。

一切始于那张本不该出现的工单。客户想让 UI 在表单处于恰好状态时弹出警告——这些规则与其他十几条规则重叠。局面一团糟：逻辑纠结、命名不统一、以及多年“下个版本再处理”的技术债务。

我打开了 React 组件：1,100 行，大部分是条件判断。没有测试覆盖，也没有文档。只有 vibe 和层层嵌套的三元表达式。我启动 Copilot，按 Win+H，开始说话。我解释我想实现的目标、它为何重要，以及上下文在哪里。

随后我靠在椅背上揉了揉眼睛。一个 AI 代理写完了剩下的部分——一套全新的变量和检查，每个都做了 memo 化、每个都具备防御性、每个都承载了恰到好处的语义重量，让我无需重构整个文件就能继续下去。

而且更诱人的是：它的精确度超出了我本可能写出的水平。所以我保留了它，检查后发现它能正常工作。但我心里清楚——我刚刚又往一个本应只有 300 行的文件里添加了 30 行。我在延续不良模式。

合同工作悖论

更离谱的是，我提交了 PR。我本可以把它抽离出来，自己手写，但那样要花两个小时去理解这堆烂摊子。这就是现在的算式。

在一些合同项目中，我每周都会做数十次这样的权衡：

• “正确”方式： 抽离、文档、测试 — ≈ 2 小时。
• “够用”方式： 保持命名整洁、让它能跑、直接交付 — ≈ 5 分钟。

把这种决策乘以每周无数次，你就能看到它的整体形状。

我并不是因为自己写不来、懒惰或不在乎才使用 AI，而是因为我已经学会了把精力放在最有价值的地方。这正是游戏规则改变的地方：做“够用”之事变得极其轻松。AI 提供了整洁的命名、聪明的防护、可复用的模式。危险在于——你会逐渐不再注意自己其实在做的是临时救急。

“计算机是放大器。” – Richard Campbell

如果模式干净，它会放大清晰度。但它也会复制一切：

• 本该是服务的内联函数。
• 本该删除的组件防御性属性。
• 你本想以后再修正的模式，现在已经烙印在每一行新代码里。

而且它毫不抵触——没有红灯警告，也没有拼写错误。过去你会感受到这些问题，曾经与系统搏斗。差别不在于工具本身。

拥有系统 vs. 不拥有系统

在 Nudges，我拥有系统。当 AI 添加东西时，我会立刻看到：这东西该放在这里吗？它符合我想要构建的系统目标吗？ 如果不符合，我会停下来、修正它、把它重新调回正轨。因为我希望它能持久。此时，AI 成为关怀的放大器，却不牺牲我的标准——这些标准从一开始就在设计中嵌入。

在我的合同工作中，我不拥有系统。于是会出现以下问题：

• “这是最佳实践吗？”
• “它能正常工作吗？能交付吗？能在下次合并时存活吗？”

因为这就是工作本身。

结论

无论哪种情形，回报都是一样的。这不关乎技能、年龄或速度，而是我选择何时做什么。 我合并了那次 Nudges 的 PR——那是 AI 代理在我玩游戏时写的。它很漂亮，也很正确。但它之所以正确，是因为我花了两年时间构建了让它正确的约束。

明天我会再处理一个客户的工单。我会打开一个散发着 2018 年味道的文件，感到后悔，或许会让 AI 去修补一个我本该在源头解决的漏洞。它会很丑陋，会是“够用”。而且它正是系统应得的。

如果代码自己写出来了，我们的手离开键盘，但指纹遍布每一行。