最近，我深入阅读了ClawdBot创始人Peter Steinberger的一篇访谈。作为一名拥有20多年经验的iOS开发老兵，Peter在AI时代完成了一次惊人的“技术栈迁徙”——他利用AI，从零开始用完全不熟悉的TypeScript构建了一个包含30万行代码的复杂项目。
他最深刻的感悟并非“AI太强了”，而是“编程语言不重要了，重要的是我的工程思维”。
这句话揭示了一个残酷的真相：在AI时代，语法层面的痛苦被彻底消灭了，但“工程思维”和“品味”成为了区分平庸与卓越的唯一护城河。AI是乘数，而你的工程思维，就是那个被乘数。
一、 核心洞察：AI消灭了什么，又保留了什么？
Peter的经历告诉我们，AI最大的价值在于抹平了语言转换的摩擦。过去，从Objective-C转到TypeScript，你需要花费数月去记忆语法、查阅文档，这种“不知道怎么写”的痛苦会消磨人的意志。现在，AI帮你完成了从“想法”到“语法”的翻译。
但是，AI无法替代的是“品味”与“工程思维”。
- 品味：是在多个可行方案中，选择那个更贴近目标、维护成本更低、用户体验更好的方案。
- 工程思维：是把不确定性关进笼子的能力，确保结果不仅“能跑”，而且“稳定”。
二、 深度解析：什么是AI时代的“品味”？
“品味”听起来很玄学，但在工程实践中，它具体表现为长期的决策力。当AI给你生成了一段代码或一个方案时，拥有“品味”的人能敏锐地察觉到“这里不对劲”。
如何判断一个选择是否有“品味”？请问自己三个问题：
- 是更贴近目标，还是只是做得更复杂？（拒绝过度设计）
- 是降低了长期维护成本，还是只是当下省事？（拒绝技术债务）
- 是让用户更容易成功，还是只是让自己写得爽？（拒绝自我感动）
案例对比：
- 无品味： 用户出错时，提示“未知错误”。
- 有品味： 提示“网络断了，点这里重试”。
- 无品味： 直接合并AI生成的200行代码，虽然能跑但看着“怪怪的”。
- 有品味： 停下来重构，直到代码逻辑清晰、符合系统整体架构。
三、 落地实操：如何构建你的“工程思维”？
工程思维不是天赋，而是一种可以训练的肌肉记忆。它要求我们将“我觉得差不多”替换为“我知道它在这些条件下是对的”。
以下是三个核心习惯的落地执行方案：
1. 拆分：把大问题切碎
AI很擅长解决小问题，但不擅长处理模糊的大需求。新手容易被大任务吓住，而工程师会自动拆解。
- 落地动作： 下次让AI干活前，不要只说“帮我写个产品介绍”。
- 执行步骤：
- 先写一句话定义产品是什么。
- 再列出三个核心卖点。
- 最后描述一个具体的使用场景。
- 效果： 拆开之后，每一步你都能判断对错，AI的输出质量也会指数级上升。
2. 全局：拒绝局部最优
AI天然具有“局部视野”，它为了修补A漏洞可能会引入B依赖，导致系统臃肿。你需要站在上帝视角审视全局。
- 落地动作： 建立“全局依赖检查”机制。
- 执行步骤： 在采纳AI建议前，思考：这个方案与系统其他部分兼容吗？三个月后需求变更，这个设计还能扩展吗？
- 警惕： 避免A问题用方案甲，B问题用方案乙，最后两者在系统中打架。
3. 三问：边界、故障与验证
这是判断一个方案是否具备“工程级”水准的试金石。
- 落地动作： 在代码合并或功能上线前，强制执行“三问检查表”。
- 执行步骤：
- 边界在哪？ 输入是什么？输出是什么？哪些必须正确，哪些可以妥协？
- 会在哪里坏？ 断网了怎么办？数据脏了怎么办？两个人同时操作会冲突吗？
- 怎么证明没坏？ 不要靠自信，要靠测试、日志和监控。
四、 进阶指南：最小规格法
为了将上述思维固化，我推荐一个可以立即使用的“最小规格”工作流。这能有效防止AI产生幻觉或过度设计。
在发送Prompt之前，先花1分钟写下以下要素：
表格
| 要素 | 描述示例（以写产品介绍为例） |
|---|---|
| 目标 | 写一段200字介绍，让小白也能看懂 |
| 输入 | 3个卖点 + 目标用户画像 |
| 输出 | 标题1个 + 正文200字 |
| 必须对 | 无虚假承诺，必须包含具体场景 |
| 可凑合 | 语气风格可后续调整 |
| 易错点 | 避免像模板，避免抽象词汇 |
为什么这样做有效？
很多时候，“写不出来的规格”，本质上是你自己还没想清楚要做什么。通过定义“最小规格”，你实际上是在训练自己的拆解能力和边界意识。
结语：做AI的驾驭者
Peter Steinberger在访谈最后提到：“你得自己去探索，找到自己的路。”
AI时代，语法不再是门槛，但工程思维是。它让你从“写代码的人”进化为“系统设计者”。不要追求“写得出来”，要追求“交付后还能稳定运行”。
从今天开始，尝试在让AI干活之前，先和它对齐“最小规格”。坚持几次，你会发现AI越来越懂你，而你，也越来越能掌控AI。