跨国深谈← 返回←当AI会写代码，工程师还剩什么？Kent C. Dodds 谈「做对的东西」

当AI会写代码，工程师还剩什么？Kent C. Dodds 谈「做对的东西」

关联

人物 Kent C. Dodds

概念 智能体 · 产品工程师 · 实现 · mom test · 验证 · 最小切片 · 变通办法

Kent C. Dodds 写了十多年软件，2014 年从 BYU 毕业，2019 年起全职做技术教育。

这场工作坊上，他讲了 AI 时代软件工程师最需要的一项耐久技能——产品工程（product engineering）：不是把东西做出来，而是判断什么东西值得做。

代码不值钱了，判断力才值钱

Dodds 的核心论断只有一句话：当 AI 智能体拉平了实现的门槛，差异化就变成了做对的东西。

他自己的经历就是注脚。

他的工作是教有经验的工程师学新技术，但今年圣诞假期他用了 AI 智能体后经历了两次存在危机：这东西写代码比我强。

一个写过 Vue 的有经验工程师，换到 React 项目根本不需要买课——指挥智能体干活就行，谁还在乎 useState 是什么。

他用射箭打比方：过去工程师苦练箭术，指哪打哪；现在的箭像装了制导装置，谁都能命中。

但靶子并不等值，真正的本事是知道哪个靶子值得打。

只会把工单变成代码的人，长得像智能体

Dodds 引用了他播客里多位嘉宾的话。Wayne Allen 说，产品关心的是做对的东西，工程关心的是把东西做对，而后者是前端的下游。

Julius Marming 则指出，难的是判断一个功能值不值得做、长期后果是什么。

如果有人问你什么就做什么，把一张工单变成一段实现——Dodds 说得直白：

那你在老板眼里「看起来太像一个智能体了」，非常容易被替代。

Dax Rad（OpenCode 作者）的警告更扎心：新的编码智能体默认会去做错误的事情，产品变烂的速度比以往任何时候都快。

智能体会加速坏实践在代码库里蔓延，你得主动勒住它。

产品工程师和产品经理的界线在哪？

Dodds 强调他不是让大家转行当产品经理。产品工程师的工作，是把对用户需求的理解连接到技术决策上：

数据模型、工作流形状、可观测性、约束条件、失败模式、最小切片。

这些决策为什么重要？因为改架构很贵。你也许觉得换数据库「不就是几百万个 token 的事」，但对团队和用户的影响是真实成本。

老板更愿意雇那个因为懂产品而第一次就做对的人。

Uncle Bob 讲过自己的经历：他给爬电线杆的修理工写软件，老板让他亲自上现场，看他挂在杆子上用软件，当场想到 30 个改进点。

Grady Booch 的总结是：工程判断力来自技术经验和对人真实需求的结合。

Instagram 是最小切片的经典案例：它最早叫 Bourbon，是个签到应用，团队观察用户行为后发现大家只在乎分享照片，于是砍掉其他一切。

结果众所周知。

想验证想法？别问你会用吗

工作坊现场观众投票选了一个练习题目：一个帮人快速挤进会议工作坊的应用。Dodds 带着大家用《The Mom Test》的方法验证它。

核心原则：不要让用户评估你的想法，也别让他们替你诊断问题。坏问题包括「你会用吗？」「这是个问题吗？」

——对方往往只想结束对话，什么都说是。书里管这叫讨恭维。

好问题问的是过去，不是未来：

• 上一次遇到这事是什么时候？具体发生了什么？

• 你当时怎么办的？绕过它的办法是什么？

• 这个变通办法花了你多少钱、多少精力？

最强的信号是：用户已经在花钱花力气用笨办法解决问题——那就是机会。

如果他记不清上次是什么时候、甚至干脆放弃了，那也是个信号，只是不是你想要的那个。

Dodds 还引 Don Norman 的观点：别问问题是什么，用户会告诉你症状，还会给你方案，而他们的方案跟你的方案一样不靠谱。

Norman 提出用户错误不存在——出错的往往是系统。1979 年三里岛核事故后他去调查，结论是操作员聪明称职，错在设计。

花了一年、120 万澳元，做出来没人用

Wayne Allen 在澳洲一家房地产公司的教训值得每个人记住：

团队花了整整一年做微服务架构，确保「全澳大利亚人同时登录都撑得住」，花了 120 万澳元（约合 90 万美元）——最后没有一个人用这个产品 。

他的反思是：本可以两周就上线，集成先手动做，先测市场。项目验证不只是产品经理的事。

如果一条功能需求没有附带任何验证依据，产品工程师就该回去问清楚：这是一次性实验，还是业务命脉？

这直接决定你在技术上做怎样的取舍。

还有一条实用的：一个人闷头做几周最容易自我说服这想法真棒。

拿给人看，如果对方不明白你为什么这么兴奋，注意那个感觉——那就是信号。

本集带走

• 当 AI 让实现变得廉价，稀缺资源变成了判断什么值得做，这是 Dodds 认为工程师最后需要学的技能。
• 只把工单转成代码的工程师，在组织眼里和智能体没有区别；理解用户问题的工程师才难被替代。
• 验证想法时问过去，不问未来：上次发生是什么时候？你怎么绕过去的？花了多少代价？
• 用户已经在花大钱用笨办法解决的问题，才是真机会；记不起来上次何时发生的，不是。
• 先上最小切片测市场，再谈架构—— Wayne Allen 的团队花 120 万澳元、一年时间，换来的产品无人使用。

AI 改变了稀缺资源。做实现不再是稀缺的了。
AI changes the scarce resource. It’s no longer scarce to do implementation.
—— Kent C. Dodds · [14:04]

所以更有价值的事情是决定构建什么，以及它一开始是否值得构建。
So the more valuable thing is deciding what to build, whether it’s worth building in the first place.
—— Kent C. Dodds · [14:24]

所以我们正从「我们能不能构建它」转向「它是否值得构建」。
So we’re moving from can we build it to is it worth building.
—— Kent C. Dodds · [14:51]

相对于执行而言，想法正变得更有价值。
Ideas are becoming more valuable relative to that execution.
—— Kent C. Dodds · [16:31]

所以一名产品工程师能够认识到，即使完成了实现，如果它不能产生客户价值，你仍然可能是失败的。
So a product engineer is able to recognize that you can still fail after finishing the implementation if it doesn’t produce customer value.
—— Kent C. Dodds · [17:33]

把东西做对是做对的东西的下游。
Building the thing right is downstream of building the right thing.
—— Kent C. Dodds · [18:04]

他说，我们新的编码智能体能力默认都会流向「做错误的事情」。产品从好变坏的速度比以往任何时候都快。
He says that the default place for our new coding agent abilities to go to is work on the wrong things. Products go from good to bad faster than ever.
—— Kent C. Dodds · [18:41]

所以，放慢脚步、有意识地决定我们要往产品里加什么，以免它膨胀得过于荒谬，这是我们的责任。
It is our responsibility to slow down and be intentional about what we’re adding to our product so it doesn’t bloat up to something too ridiculous.
—— Kent C. Dodds · [19:14]

所以如果你不小心，你就能更快地把坏东西做出来。
So you can move bad faster if you’re not careful.
—— Kent C. Dodds · [19:32]

这之所以重要，是因为如果你知道自己会在凌晨两点被叫起来处理问题，你就会非常用心地打造系统、打造你为智能体创建的游乐场，确保它们在实现功能时能够成功。
If you know that you’re going to be paged at two in the morning to deal with issues, then you’re gonna take a lot of care in the system, in the playground that you create for your agents to make sure that they’re successful when they’re implementing things.
—— Kent C. Dodds · [20:35]

你可以极其快速地做错误的事情，还感觉自己取得了巨大的进展。
You can do the wrong thing incredibly fast and feel like you’re making a ton of progress.
—— Kent C. Dodds · [20:48]

这些人对自己的解决方案兴奋过头，以至于完全迷失了他们本来要为用户解决的问题的主线。
These people are so excited about their solution that they’ve totally lost the plot of the problem that they’re trying to solve for users.
—— Kent C. Dodds · [25:18]

让你在公司里作为工程师脱颖而出的一大方式，就是成为一个有产品思维的工程师。
A great way for you to stand out as an engineer at your company is to be a product-minded engineer.
—— Kent C. Dodds · [25:31]

你作为产品工程师要做的事情之一，就是为你的下属构建一个能让他们成功的系统。
One of the things that you are doing as a product engineer is building a system for your underlings to be successful in.
—— Kent C. Dodds · [28:23]

用户错误是不存在的。
User error does not exist.
—— Kent C. Dodds · [30:22]

在我看来，如果你不是产品工程师，如果你没有产品感或设计感，那么随着智能体持续变得更能干，你会非常容易被取代。
If you’re not a product engineer, if you don’t have product sense or design sense, that’s going to be really easy to replace you as the agents continue to get competent.
—— Kent C. Dodds · [36:15]