科技 Bestblogs · AI Engineer · 10-25 07:00 · AI 生成
AI 写了代码，工程师还要做什么？Laurie Voss 谈产品判断与人才培养 Laurie Voss 用瓶颈转移框架分析 AI 编程：生成代码的边际成本趋近于零，但判断代码可否信任的成本未降，因此交付提速远小于代码产出增长。他认为工程师的核心价值将转移到发现用户需求、定义质量规格，并称这类角色为产品工程师。文章还讨论了初级工程师培养路径断裂的问题，承认热爱编程技艺者未必适应新分工，且其劳动力市场判断属长期预测。适合关注 AI 对工程组织影响的读者。原文 ↗ 原文 ↗
核心观点
▍ AI 让生成合理代码的成本骤降，但判断代码能否信任的成本丝毫未变，工程瓶颈从编写转移到评审、验证与需求定义，软件工作的重心将转向理解用户和定义质量。 ▍ 未来工程师的核心角色是产品工程师：既能发现用户真实需求，又能将其写成智能体可执行的规格，并对业务中的好做出判断。 01 代码产出大幅增长，但交付改善小得多，说明生成速度不是唯一瓶颈，评审吞吐能力限制了实际交付提速。 02 通过基准测试与合入代码仓库之间存在鸿沟：编码风格、外部系统依赖、副作用及仓库历史等背景，自动化测试和 AI 评审者难以完整表达。 03 产品工程师需要挖掘泛泛需求（如追踪订单）背后的具体业务规则，并将其写成智能体可执行的规格。 04 当智能体接手定义明确的编程任务，组织必须主动设计初级工程师的成长路径，教授需求探索和判断力，不能依赖从简单任务中自然成长。 05 实际操作建议：自动化容易验证的工作，把专家判断写进规格与评测，并衡量交付结果而非代码量。 反方 / 局限
— Voss 承认，热爱编程技艺的人未必喜欢这种转向产品判断和需求探索的新工作。 — Voss 对未来劳动力市场的判断属于长期预测，且演讲中引用的研究数字未在转录内容中得到独立证实。
前置背景 瓶颈转移：代码变便宜之后
Voss 借的是高德拉特 1980 年代的约束理论：任何系统的产出由最弱环节决定，非瓶颈环节提速不产生额外产出，反而堆出在制品。把它搬到软件上，写代码从瓶颈变成富余产能，评审、测试、运维接不住，交付就堵在原地。工厂算例里总装负荷 119% 时给注塑加压，交期一天都提前不了。
▸ 2 条关联资料
▼
论证骨架 评审接不住的真正原因
测试通过不等于能合入：编码风格、外部系统副作用、仓库历史都是基准测不到的背景。有团队推动 AI 评审三年，从行级建议到 LLM 沙盒都试过，工程师照样关掉页面——因为评审本身就是知识传递、架构协商、新人入门，不只是找 bug。Voss 的论证成立的隐含前提是「自动评审能接管这些判断」，这条链最脆的地方就在这。
▸ 2 条关联资料
▼
平行视角 代码涨 40%，交付慢 19%
一边是 METR 2026 年随机对照试验：16 位资深开发者在百万行级成熟仓库完成 246 个真实任务，自感提速 20%，实测慢了 19%，感知与现实差 39 个百分点。另一边是 Cognition 的 FrontierCode 2.0 榜单，主流模型真实工程任务得分集体跳水，Claude 从 54.6% 掉到 45.5%。同一件事两种证据口径：一边说效率幻觉，一边说基准有水分。
▸ 3 条关联资料
▼
未来推演 初级岗位的通道正在关闭
过去新人靠写小任务练级，如今这批任务正好是智能体最擅长的。脉脉《2025 年度人才迁徙报告》显示 1 年以内经验的新发岗位量下降 40%，AI 产品经理需求同比增 369%。但「产品工程师」在招聘市场仍是制造业口径的词，产品判断与客户沟通能不能被系统教会，要等第一批有意识设计的培养项目跑完两三年才看得清。
▸ 2 条关联资料
▼
延伸追问 该量的不是代码，是交付
用生成行数衡量 AI 收益，等于用印刷数量衡量文学价值，还会反向奖励冗余代码。更麻烦的是「每人每天省一小时」这类数字既不可验证也不能拿来做决策。可替代的口径是三层的：交付层的周期时间与变更失败率、质量层的返工率、采用层的场景覆盖率。真正值得追问的是——你的团队到底敢不敢把返工率摆上台面？
▸ 2 条关联资料
▼