品味 + 工程思维：AI 时代最难被替代的两件事
导语
AI 把写语法、写样板、拼接胶水代码这些事变得便宜又快。厉害的是，这会让“出可跑代码”变得非常容易。糟糕的是，真正能决定项目能不能长期活着的是两样东西：做选择的品味和把结果做稳的工程思维。想每天能早下班一小时？别只学 prompt，要练这两样。😤
为什么不是“会写代码”最重要？
换语言、换框架，过去那种被语法折磨的日子，AI 能帮你抹平。Peter（ClawdBot 的创始人）用了 AI 从头做了个大项目，体会到：语法是可以交给 AI 的，但判断、设计、验收这些不能。
AI 能把你放大。你带来的东西决定放大到多少。基础能力为零，AI 再好也白搭；基础能力强，AI 就能把你放到更远的位置。
品味是什么（能被量化的直觉）
品味不是玄学。把它理解成“长期决策力”。在多个可行方案里，选一个更贴近目标、维护成本更低、让用户更容易成功的方案。
判断一个选择有没有品味，可以问三件事：
- 这是更贴近目标，还是只是更复杂？
- 这是降低长期维护成本，还是只是当下省事？
- 这是让用户更容易成功，还是让自己写得爽？
举例：
- 出错提示写“未知错误”还是“网络断了，点这里重试”？
- 引入外部库还是自己写一小段逻辑？
- AI 给你 200 行能跑的代码，你直接合并，还是停下来搞清楚为什么？
这些判断来自你踩过的坑、见过的好设计、长期积累的直觉。可以练出来，不是天生的。
工程思维是什么（让结果稳定发生）
品味偏感性，工程思维偏结构化。它回答的问题是：怎么把“能跑一次”变成“每天稳定运行”。
用开餐厅打比方：一盘菜能好吃是灵感；要把餐厅运营起来，你得有配菜标准、出餐流程、缺货预案、质量检查。工程思维就是那套流程。
我常用的三项核心习惯：拆分、全局、三问（边界/故障/验证）。
- 拆分：把大需求切成小任务。先看能不能跑通，再做扩展。
- 全局：不要只盯着当前改动。想想和系统其他模块的契合、扩展性和维护成本。
- 三问（每个方案都要回答）：
- 边界在哪？输入输出是什么？能错在哪些地方？
- 会在哪里坏？断网、权限、并发、脏数据……列出来。
- 怎样证明没坏？测试、日志、监控、可复现步骤。
一句话：把“我觉得差不多”换成“我知道在这些条件下它是对的”。
AI 时代更需要工程思维的三条理由
- 错误更隐蔽。AI 很会写看起来正常的实现。边界一来就露馅，坑藏得深。
- 复杂度容易爆炸。你叫 AI 加个功能，它可能引入三层抽象和两套依赖。短期看没问题，长期维护毁人不倦。
- 局部最优会打架。AI 每次解决当前问题，缺乏全局视角。你必须判断整体一致性。
这些问题看着小，却会把“能跑”变成“不能长期用”。你得用工程思维把这些不确定性关进笼子里。
如何培养工程思维（可立刻上手的练法）
下面给三条可以每天练的路径。别想一步到位，像练肌肉一样，拿出耐心。
-
先拆分
- 每个任务先写出最小可交付（MVP）清单。把大问题拆成若干个能独立验证的小问题。
- 练习题：把一个功能拆成 5 个最小子任务并排序。用 AI 分别生成每个子任务的实现草案。
-
先跑通，再优化
- 先用最简单可行的方法把结果做出来（哪怕丑）。确认业务逻辑正确后再回头优化。
- 练习题：把一个手写的笨实现做成可跑版，然后做一次重构，把重复抽象出来并写测试。
-
常复盘
- 每次交付后问三个问题：做了哪些取舍？最可能出问题的地方在哪？如果重做，会删掉什么、保留什么？
- 练习题：每周选一个已完成的 PR，写 200 字的复盘，重点说明边界和故障场景。
一个一分钟就能用的动作（最小规格模板）
下次在让 AI 干活前，先花 60 秒写下这几行：
- 目标（用一句话描述要达成的效果）
- 输入是什么，输出是什么
- 哪些必须正确，哪些可以先凑合
- 最容易出问题的地方
示例（产品文案）：
- 目标：写一段 200 字的产品介绍，让新用户一看就懂
- 输入：产品的三个核心卖点 + 目标用户画像
- 必须正确：不夸大、不虚假、有具体使用场景
- 可以先凑合：语气和细节可以后续调整
- 最容易出问题：写成模板化文案，缺少场景
把这几行给 AI，再让它开始写。输出质量会立刻提升。
示例（代码场景 prompt）：
- 目标：实现一个 POST /upload 接口，能安全接收文件并异步入队处理
- 输入：文件流 + 用户 token
- 输出：任务 id
- 必须正确：鉴权、文件大小限制、恶意类型拦截
- 可以先凑合：重试策略先用简单的指数退避
- 最容易出问题：并发上传导致磁盘高 IO、临时文件未清理
把这个最小规格发给 AI，让它先返回一个接口草案和简单的异常处理逻辑。你再审查“边界/故障/验证”。
Prompt 模板（给 AI 的结构化指令）
给 AI 的指令最好按这个结构写：
- 场景与目标（1-2 句）
- 输入输出约定（必须明确）
- 关键边界与故障场景（列点）
- 期望交付物（代码、测试、使用示例、运行命令）
- 代码规范或依赖限制（项目里已有库优先）
这样一来，AI 的输出更容易被你评估。
避坑清单（交付与复用时一定要查）
- 别盲目合并 AI 生成的 PR。先跑单元测试、集成测试、模糊测试。
- 别只看功能能跑。查下异常路径、资源释放、超时处理、并发场景。
- 别轻易引入新依赖。先确认项目里有没有类似的库可用。
- 别把设计分散成多个局部最优。合并前想想可复用性和一致性。
- 别省略日志和监控。发生问题时，没人能靠记忆回溯。
- 别把复杂度交给未来的自己。写文档、写运行指南、写回滚步骤。
小练习（30 分钟上手）
- 选一个你最近合并过的 PR。做这三件事：
- 写最小规格（目标、输入输出、必须对、可凑合、易错点）。
- 用 AI 生成一个替代实现（限定只用项目现有依赖）。
- 对比两版，列出 5 个工程风险并写出验证方法。
这个过程会立刻训练你拆分、全局思考，以及发现边界的习惯。
结尾（简短激励）
AI 会把你的手放到更高的起点。别只学会如何让机器写出代码。把注意力放在决定“做什么”和“怎么把它做稳”上。多练习拆分、常跑通、常复盘。犯几次错，慢慢你就能用 AI 做出既快又稳的结果。🚀
如果你想，我可以：
- 帮你把某个功能写成最小规格模板；
- 根据你的 repo，生成一个 PR 审查清单；
- 给你一个练习题并评审输出。
要哪个，直接说。