品味 + 工程思维：AI 时代最难被替代的两件事

AI 时代，最难被替代的不是"会不会写代码"，而是两件事：做选择的品味和把结果做稳的工程思维。

最近看了一个 ClawdBot 创始人 Peter 的访谈《AI 是杠杆，不是替代品；编程语言不重要了，重要的是我的工程思维》https://baoyu.io/blog/2026/02/01/peter-steinberger-interview。

Peter Steinberger 是 PSPDFKit 的创始人，做了 20 多年 iOS 开发，去年用 AI 从零写了一个大项目 Clawdbot，换了自己完全不熟的语言。他最大的感受不是“AI 太强了”，而是：

“从 Objective-C 和 Swift 转到 TypeScript，问题不是难，而是痛苦。每个小东西都得查，你明明理解所有概念，但就是不知道语法。慢得让人想放弃。”

“有了 AI，这些痛苦全都消失了。你还是可以运用你的系统级思维、你对大项目的架构理解、你的品味。这些东西依然有价值，而且你可以更容易地把它们从一个领域迁移到另一个领域。”

他总结说：“语言不再重要了，我的工程思维才重要。”

这句话需要一个边界：不是说你可以完全不懂，而是说语法细节可以交给 AI，但你得能看懂它写的东西、能判断对不对。

我的结论是：语法可以交给 AI，但你必须练出工程思维——把需求想清楚、把系统设计清楚、把结果验证清楚的能力。

AI 消灭的是什么，保留的是什么

Peter 的核心观点是：AI 消灭的是语法层面的痛苦，保留的是工程思维和品味。

什么是语法层面的痛苦？就是你明明知道要干什么，但不知道怎么在这个语言里写出来。以前换一门语言，这种摩擦能折磨你好几个月。现在 AI 帮你抹平了。

但 AI 抹不平的是什么？

是你脑子里那个“这个项目应该怎么设计”的直觉。是你看到一段代码，能感觉到“这里不对劲”的嗅觉。是你选择用哪个库、不用哪个库的判断力。

Peter 管这个叫**"品味"（taste）**。

“那些 AI 做不到的事情是什么？是品味。它们确实很聪明，但如果你不好好引导它们，如果你没有一个清晰的愿景，产出的往往是能跑但不好用的东西。如果你不问对的问题，结果也不会对。”

我其实经常有提到：AI 像是能力倍增器，AI 是乘数，你的基础能力是被乘数。如果被乘数是零，乘什么都是零。如果被乘数是 100，AI 能帮你放大到 1000。

举例来说，我对视频制作能力就几乎为 0，就算借助 AI，我用 AI 做视频也远远不及像汗青、海辛和阿文这些专业视频创作者做出来的效果。但在我擅长的编程领域，我可以借助 AI 高效的完成复杂的任务。

什么是“品味”

这个词听起来很虚，但其实很具体。

品味不是审美偏好，也不是天赋。你可以把它理解成长期决策力——在多个可行方案里，选一个更贴近目标、更省长期维护、更让用户少犯错的方案。

怎么判断一个选择有没有“品味”？可以问三个问题：

• 是更贴近目标，还是只是做得更复杂？
• 是降低了长期维护成本，还是只是当下省事？
• 是让用户更容易成功，还是只是让自己写得爽？

Peter 描述了他做项目的方式：

“当我开始一个项目时，我只有一个很粗略的想法。然后随着我去构建它、把玩它、去感受它，我的愿景会越来越清晰。我会尝试一些东西，有些行不通，然后我的想法会演变成它最终应该成为的样子。下一个 prompt 是什么，取决于我看到当前项目状态后的感受和思考。”

这就是品味：你能感知到什么是好的，什么是不好的。你能判断下一步应该往哪个方向走。

举几个更具体的例子：

• 用户出错时，提示“未知错误”还是“网络断了，点这里重试”？后者需要多写几行代码，但体验完全不同。
• 一个功能可以用现成的库，也可以自己写。用库省事，但引入了一个你不完全理解的依赖。你怎么选？
• AI 给你生成了 200 行代码，能跑。但你看着觉得“怪怪的”，说不上来哪里不对。你是直接用，还是停下来搞清楚？

这种判断力不只在写代码时有用。换成日常场景：

• 同样是 AI 帮你写一段文案，是“看着顺”还是“像模板”？你能分辨吗？
• 同样是做一页 PPT，是“信息堆满”还是“重点一眼看懂”？你怎么选？
• 同样是让 AI 帮你写简历，是照单全收，还是觉得“这不像我”然后调整？

品味就是在这些时刻做出判断的能力。它不是天赋，是你踩过坑、见过好东西之后长出来的直觉。

什么是工程思维

品味是感性层面的判断力，工程思维是理性层面的结构化能力。

工程思维，通俗一点说就是**"把事情做稳、把结果做可复现"**。它不是“会写代码”，也不是“懂很多框架”，而是一种把不确定性关进笼子的习惯。

打个比方。同样是做饭，随手炒一盘菜，香不香全靠灵感，这叫“能跑一次”。开一家能稳定出餐的餐厅，才叫工程。你要有备料标准、火候控制、出餐流程、卫生检查、缺货预案，还得算成本。工程思维就是这套“让结果稳定发生”的方法。

怎么让结果稳定发生？

我自己总结的三个核心习惯（不是说只有这三个）：

第一，拆分：把大问题拆成小问题。

新手最容易被一个大需求吓住，不知道从哪下手。有工程思维的人会自动把它拆开：先做什么，后做什么；哪些是核心，哪些是边角；哪些可以先硬编码，哪些必须做成可配置的。

拆分能力也直接决定了你能不能把 AI 用好——后面会细说。

第二，全局：不只看当前问题，看整体。

新手容易只盯着眼前的问题，解决了就完事。有工程思维的人会多想一步：这个方案和系统里其他部分怎么配合？会不会给别的地方埋雷？三个月后要改需求，这个设计还能扩展吗？

全局思维的反面是“局部最优”：A 问题用一种方式解决，B 问题用另一种方式解决，单独看都挺好，放一起就打架。

第三，三问：边界、故障、验证。

这是我判断一个方案“工程不工程”的三个问题：

• 边界在哪？ 做什么，不做什么；哪里是输入，哪里是输出；哪些必须正确，哪些可以先凑合。
• 会在哪里坏？ 现实里有断网、超时、脏数据、权限问题、并发冲突（多件事同时发生导致的问题）。有工程思维的人写代码时，脑子里一直在跑这些故障场景。
• 怎么证明没坏？ 证明不是自信，是验证：测试、日志（程序运行的记录）、监控、可复现。你能给出一套让别人也信服的验证方式，这才叫"工程"。

一句话说：工程思维是把"我觉得差不多"替换成"我知道它在这些条件下是对的"。

为什么 AI 时代更需要工程思维

AI 让写代码变便宜了，但让“错误”和“复杂度”变得更贵了。

便宜在哪？语法、样板、胶水代码，AI 写得又快又多。你很容易在一天里堆出一个看似完整的功能。

贵在哪？

第一，错得更隐蔽。 AI 经常给你一个“看起来很像对的”实现，能跑，能过几个手工测试，但边界条件一来就露馅。更麻烦的是，它会把错藏在你不太会看的角落：出错时怎么兜底、用完资源有没有释放、多件事同时发生会不会打架。

翻译成生活场景：你约的是晚上 8 点，对方手机显示成了早上 8 点（时区问题）；你以为别人都能打开链接，结果只有你自己能看（权限问题）；两个人同时改同一个文档，最后谁的版本都不对（并发问题）。这些坑 AI 很容易漏掉。

第二，复杂度更容易失控。 人手写代码时会肉疼，会自然克制。AI 不会肉疼。你让它“加一个功能”，它可能顺手引入三层抽象、两套依赖、五个配置项。你以为你在加功能，其实你在加未来的维护成本。

比如我最近合并 baoyu-skills PR 的时候就发现，两个给 post-to-x 添加功能的 PR，Claude Code 是共同作者（说明是 AI 写的），都选择了复制已有的逻辑代码，而不是抽象相同的代码去重用，我只能合并后重新抽象精简了一下。

第三，AI 天然只看局部。 它每次回答都是针对当前问题的“局部最优”——你让它解决 A 问题用一种方式，解决 B 问题用另一种方式，放一起就打架。它可能为了解决当前问题引入一个新依赖，但你知道项目里已经有类似的库了。这些“整体视角”的判断，只能你来做。

AI 很擅长把你骗进"完成感"，你觉得它写完了，其实只是"能跑"，离"能用"还有一段距离。

还记得前面那个公式吗？AI 是乘数，你是被乘数。前面说的拆分、全局、三问，就是那个被乘数——它决定了 AI 能把你放大到什么程度。

怎么培养工程思维

工程思维不是听懂了就有，它更像肌肉，得靠反复练才能长出来。

培养它的方法有很多，我自己最受用的是三个习惯：先拆分、先跑通、常复盘。不一定适合所有人，也不一定是完整的，但可以作为一个参考。

先拆分

每次遇到一个任务，先别想着一口气做完，先问自己：这个任务能不能拆成更小的任务？

我最近在辅导一年级的小儿子做数学，给他出了一道题：1+2+3+……+100 等于多少？他一看就懵了，不知道从哪下手。

我没有直接教他公式，而是引导他先做一个更小的问题：1+2+3+……+10 等于多少？这个他能算，一个一个加，得出 55。

然后我让他算 11+12+……+20，他又算出来了，是 155。

就这样一段一段算下去，最后把十个小结果加起来，得到 5050。

这就是拆分：把一个让你发懵的大问题，拆成一堆你能下手的小问题。

不写代码的场景也一样。比如你想让 AI 帮你写一篇产品介绍，与其说“帮我写个产品介绍”，不如拆成：先写一句话说清楚这是什么 → 再写三个核心卖点 → 最后写一段使用场景。拆开之后，每一步你都能判断对不对，AI 也更容易给出你想要的东西。

先跑通，再优化

还是那道数学题。孩子用笨办法算出 5050 之后，我带他回头复盘。

我们从 1 到 10 开始，换一种算法：（1+10）+（2+9）+（3+8）+……每一对都是 11，一共 5 对，所以是 55。

他在我的引导下发现了规律。然后用同样的思路算 1 到 100：（1+100）+（2+99）+……每一对是 101，一共 50 对，101×50=5050。比笨办法快多了。

这就是“先跑通，再优化”：先用笨办法把结果做出来，再回头找更好的方法。

很多人的问题是反过来的，还没跑通就想优化，结果两头都没做好。先让它跑起来，哪怕丑一点、慢一点；跑通之后再回头看，哪里可以做得更好。

常复盘

每次做完一件事，问自己三个问题：

• 这次我做了哪些取舍？为什么这样选？
• 如果出了问题，最可能是哪里？
• 如果重做一次，我会删掉什么、保留什么？

这三个问题不只能帮你提升工程思维，也能帮你练品味。品味不是天赋，就是靠这种“做完了再想想”的习惯慢慢长出来的。

一个可以马上用的动作

下次让 AI 干活之前，先花一分钟写几行“最小规格”：

• 目标一句话
• 输入是什么，输出是什么
• 哪些必须对，哪些可以先凑合
• 最容易出问题的地方是什么

举个非技术的例子。假设你想让 AI 帮你写一段产品介绍：

目标：写一段 200 字的产品介绍，让第一次听说的人能理解
输入：产品的三个核心卖点 + 目标用户是谁
输出：标题 1 个 + 正文 200 字左右
必须对：不能夸大、不能有虚假承诺、要有具体使用场景
可以先凑合：语气风格可以之后再调
最容易出问题：写得像模板、没有具体场景、卖点说得太抽象

把这几行发给 AI，再让它开始写。你会发现，生成的东西比“帮我写个产品介绍”好一大截。

很多时候，“写不出来的规格”，本质上是你自己还没想清楚要做什么。

长期这样练，你会明显感觉到变化：你越来越少被“不知道从哪下手”卡住，越来越多在做“拆解、取舍、验证”的决定。这就是工程思维在发芽。

最后

Peter 在访谈最后说：

“你得自己去探索，找到自己的路。你需要时间才能变好。你得犯自己的错误。这是你学习任何东西的方式，学这个也一样。只不过这个领域变化特别快。”

工程思维最后会变成一种气质：你不再追求“写得出来”，而是追求“交付后还能稳定运行”。

不知道从哪开始？

可以从今天就尝试一下：下次让 AI 干活之前，先和 AI 对话，一起写几行“最小规格”。坚持几次你会发现，AI 越来越聪明越来越懂你，你越来越能掌控 AI。