软件工程核心成本向需求定义转移，Laurie Voss指出产品工程成为未来主要工作

一句话结论

随着代码生成成本崩溃，软件工程重心转向需求精准定义与体验设计，成为不可规模化的核心成本。

关键要点

• Laurie Voss 认为代码编写成本已大幅降低，代码审查、修复与运维成本正沿此趋势同步下降。
• 软件开发的剩余核心工作被界定为识别用户真实需求、精确需求定义以及打造愉悦使用体验。
• 上述核心工作的成本属于单次软件成本，不具备规模转移性，无法通过软件数量增长而摊薄。
• 由于软件需求存在无限性且无天花板，单次核心成本将在行业未来构成整体工作的全部比重。
• 这一结构性变化使得“产品工程师”（Product Engineer）成为所有软件从业者的必然角色定位。

背景与事实

Laurie Voss 在其文章《We are all Product Engineers now》中提出的上述判断，由科技博主 Simon Willison 于 2026 年 9 月 14 日进行引用与传播。该观点基于当前软件开发工具链演进的实际数据观察，明确划分了“代码生成”与“软件定义/设计”两类工作在不同阶段的成本结构。Laurie Voss 指出，代码生成的成本崩溃已发生，代码审查、修复及后续运维操作的成本下降处于正在跟进阶段，并预判这一趋势最终会完全兑现。基于这一预判，她进一步推导出现代软件工程中真正剩余且无法被规模化分摊的工作部分，即确认用户实际想要什么、将这些需求转化为精确的技术规格，以及确保软件在使用层面的愉悦感。这部分工作的成本特征被定义为“按软件单件计算”（per piece of software），其核心属性是“不可转移”，即随着软件生产数量的急剧扩张，这部分单件成本的绝对比重将趋近于整体工作的全部。

同期发布的其他文章显示，大模型（LLM）的能力迭代与成本变化正在重塑开发工具生态。包括 2026 年 9 月 22 日提及的 Claude Opus 5.5、GPT-6 Sol、GPT-6 Luna 等模型版本引发的新一轮价格战，以及 9 月 21 日提及的由 Jev 推出的新形态 LLM（即 System One 或决策模型）。这些底层模型的价格竞争与技术形态演进，构成了支撑 Laurie Voss 关于“代码编写成本崩溃”这一前提的客观技术背景。相关工具链的普及使得生成可运行代码的边际成本迅速逼近于零，从而在工程经济学层面彻底改变了软件开发的价值分配比例。

影响分析

对于中文开发者与行业从业者而言，这意味着传统的“代码实现工程师”角色定位正在加速失效。单纯具备编写语法正确代码能力的个人，其市场价值将随着工具自动化程度的提高而急剧贬值。开发者必须在职业发展中强制提升产品思维与用户洞察能力，主动参与到需求发现、定义与体验优化的全链路中。对中文互联网公司及初创团队而言，研发管理层的考核维度必须做出对应调整，减少对单纯“代码产出量”或“功能实现速度”的考核权重，转而增加对产品指标达成度、用户留存率、交互满意度等反映“软件价值”的指标权重。技术团队内部的架构设计也需适应这一变化，工程架构不仅要考虑技术可行性，更要在需求定义阶段就介入，通过技术手段将模糊的用户诉求转化为精确、可测、可迭代的系统规格。

适用边界

该结论主要适用于通用软件产品、互联网应用及面向消费者的 C 端软件领域，在这些领域，软件需求呈无上限增长，且体验与定义是核心壁垒。然而，对于强合规性、强确定性、低用户体验权重要求的基础设施软件、核心系统级代码或高度受限的安全关键系统（如航空航天、核心金融交易系统），代码的精确性、可验证性与安全性依然是绝对核心成本，不可转移的需求定义与体验成本在这些场景中的占比将远低于一般软件领域。

孤本观察

在生成式 AI 彻底拉平代码产出门槛的技术周期下，具备将模糊业务意图转化为精确技术规格的能力，正成为独立于编程语言的通用型护城河。这意味着软件工程的学科重心正在不可逆地从工程实现层向产品定义层上移。

来源：Simon Willison