引用 Laurie Voss

Quoting Laurie Voss — simonwillison.net · 8 小时前 · 💡 观点 / 杂谈

当生成代码的边际成本趋近于零，软件工程的成本重心会转移到哪里？Laurie Voss 给出的回答是：写代码的成本已经崩塌，而审查、修复与运维代码的成本正在紧随其后，他假定它终将到达同样的位置。他把此后剩下的软件工作概括为三件事——弄清人们真正想要什么、把它精确定义出来、让它用起来令人愉快；而这部分成本是按「每一款软件」单独计算的，无法像通用库或基础设施那样一次投入、多处复用，所以当软件数量趋向无穷（需求没有天花板，软件数量就必然趋向无穷），这部分成本就会变成全部的工作。Simon Willison 以引用片段的形式收录了这段话，并链回原文《We are all Product Engineers》。这段话的价值不在于预测某个具体工具的兴衰，而在于给出一个成本转移的框架：AI 让「写」变便宜之后，瓶颈不会消失，只会沿着生产链条向后移动。若审查、修复、运维的成本确实跟随下降，工程组织的形态就会向产品工程师倾斜——同一个人从需求发现一路负责到上线运维，因为跨角色交接的开销同样无法随软件数量增加而被摊薄；若链条上的某一环没有跟上（人类注意力有限的代码审查是最可疑的一环），成本就会在那里堆积，表现为评审队列变长、变更集膨胀、发布节奏被少数能读懂全局的人卡住。对个人而言，职业安全从「写得快、记得住 API」转向「能否判断该做什么、能否把模糊诉求变成精确规格、能否为体验负责」；对团队而言，招聘标准、评审流程与度量指标都要重排，产出的计量单位不再是提交数或代码行，而是被验证过的用户价值。Voss 措辞里最锋利的一点是成本「不转移」：它不会因为模型变强、算力变便宜而被摊薄，只会随着软件数量增长而线性膨胀，直到占满整个工作日。

核心论点

• 「写代码的成本已经崩塌，审查、修复和运维它的成本正在跟随，我假定它最终也会到达同样的位置」——Laurie Voss 用这条成本传导链描述了 AI 时代软件工程瓶颈的迁移方向：编写环节的边际成本趋近于零之后，同样的力量会依次压低审查、修复与运维的成本。这条链条决定了组织把人力堆在哪个环节：传导顺畅时，团队规模与协作结构都要重写；若某一环因人类注意力有限而卡住（代码审查是最可疑的一环），成本就会在那一环堆积，表现为评审队列变长、变更集膨胀、发布节奏被少数能读懂全局的人卡住。
• Voss 把剩下的软件工作压缩为三件事：发现人们真正想要什么、把它精确定义出来、让它用起来令人愉快；他强调这部分成本按「每一款软件」单独计算且不可转移——它无法像通用库、框架或基础设施那样一次投入、多处复用，因此既不会被规模效应摊薄，也不会因为模型变强而自动消失。这一判断直接否定了「AI 会让软件工程工作消失」的担忧，把稀缺资源从代码产能重新定位为需求判断与定义能力：代码可以复制、可以生成，但「这款软件到底该做什么」这个问题每换一个产品就要重新回答一次。
• 需求没有天花板，所以软件数量会趋向无穷，那部分不可转移的成本最终会成为全部的工作。Voss 的推论是：只要人们对软件的欲望没有上限，被生产出来的软件就会持续增加，而每一款软件都需要有人去理解它要解决什么问题、定义它的行为边界、打磨它的交互；当这类工作成为唯一无法被规模化替代的部分时，它就等于整个职业的内涵，而不再是从编码工作中切出的一小块。这也意味着以代码行数或提交数衡量产出的做法会彻底失效，需要换成对用户价值的验证。
• 这段话出自 Laurie Voss 的文章《We are all Product Engineers》，标题本身就是结论：当编码、审查、运维都被压低成本，工程角色的重心从「实现者」移向「产品工程师」——对要解决的问题负责，而不是对某一层技术栈负责。对个人来说，职业护城河从「写得快、记得住 API」变成「能否判断该做什么、能否把模糊诉求转成精确规格、能否为体验负责」；对团队来说，招聘标准、评审流程和度量指标都要随之重排，产出的计量单位不再是提交数或代码行，而是被验证过的用户价值。

💡 为什么值得读: 它用一条清晰的成本传导链解释了 AI 时代工程瓶颈会搬到哪里，并直接给出个人与团队该把力气投向何处的判断依据。

🏷️ AI, coding, cost, product

---