代码写起来越来越便宜，但定义产品的成本却没降下来

写代码的边际成本正在崩塌，随之而来的就是 review、修复和运维的成本也在快速下降。在这种趋势下，软件开发的重心会彻底转移：最难的部分不再是实现功能，而是搞清楚用户到底想要什么，并把这个需求精准地定义出来，同时保证产品好用。因为定义需求这个环节的成本是跟具体产品绑定的，无法像代码那样通过规模化而降低。当软件数量趋向无穷大时，定义产品将成为软件工程师唯一的全部工作。

为什么写代码不再是核心竞争力

很多开发者习惯于把时间花在优化架构或死磕某个复杂算法上，但按照 Laurie Voss 的逻辑，这些事情的成本正在被 AI 迅速拉低。当你用 AI 生成代码的速度快到可以忽略不计时，那么「写出能跑的代码」就不再是一个竞争优势。

现在的真实情况是，无论 AI 能不能写出 1000 行代码，如果你对需求的定义模糊，最后出来的东西依然是垃圾。这种「定义成本」是无法转移的，你不能用在 A 产品上的需求定义经验，直接无缝复制到 B 产品上。每一个新功能、每一个新场景，都需要重新经历一遍「挖掘需求 -> 精准定义 -> 体验打磨」的过程。

从编码员到产品工程师的转型路径

如果代码成本趋近于零，那么一个合格的工程师应该把关注点从「怎么写」移到「写什么」上。这其实是对工程师能力模型的一次重构，具体体现在以下几个转变：

• 从关注语法到关注定义： 以前我们花 80% 的时间在调 Bug 和写逻辑，以后可能需要花 80% 的时间去写 PRD 或者跟用户沟通。精准定义需求的描述能力，将比熟练掌握某种语言的语法更重要。
• 从追求性能到追求体验： 当实现成本降低后，产品的竞争力将直接体现在「pleasant to use（好用/愉悦）」这一点上。这意味着对 UI/UX 的敏感度将成为硬指标，而不再是交给设计师处理的次要环节。
• 应对无限增长的需求量： 既然需求没有天花板，且软件数量会爆炸式增长，那么能够快速、精准地将想法转化为可运行产品的能力，就是唯一的护城河。

实际操作中的风险与成本

虽然写代码便宜了，但并不意味着开发过程变得简单。在这个过程中，我们需要面对新的成本分布：

• Review 成本的陷阱： 虽然 Laurie Voss 认为 review 的成本也会下降，但在实际操作中，AI 生成的代码如果缺乏深层逻辑自洽，人类 review 的心智负担反而会增加。如果完全依赖 AI 且不进行严格审计，技术债的累积速度会比手动写代码快得多。
• 需求定义失败的代价： 在代码极速产出的环境下，一个错误的定义会导致在极短时间内产生大量错误的废代码。这种「快速失败」虽然降低了单个功能的开发时间，但如果方向错了，整体浪费的时间成本依然很高。
• 运维成本的滞后性： 修复和操作代码的成本虽然在下降，但目前尚未完全触底。在完全自动化运维实现之前，开发者依然需要承担 AI 引入的潜在不稳定性。

总结来说，软件开发的终局可能就是一种「产品工程化」。当你不再为写不出某个函数而焦虑时，你才真正开始面对软件开发最核心的挑战：在无穷的需求中，精准地抓住那个让用户觉得好用的点。