AI 编程时代，品味比经验更重要

短大纲

• AI 让写代码更快，也让"选什么、不选什么"更难
• 经验的价值，不在于记住过去，而在于识别今天的约束
• 判断力要盯几个慢变量：领域、边界、代价、失败模式
• 用 DDD 给 AI 一张图纸，用 ROI 给技术判断算笔账
• 品味不是玄学，是一套能练出来的偏好
• 让经验不变成包袱，靠的是"拆旧账、做小实验、写决策日志"
• 末尾附一份明天就能用的工程品味清单

一、AI 把键盘踩冒烟，锅还是人来背

以前写代码，慢在手上。一个接口、一个 SQL、一个单元测试，敲敲改改半天过去了。现在有了 AI，慢的地方换了。

你让它写一个缓存层，它能甩出三种方案；你让它重构一段代码，它能顺手再造一个小型框架；你让它修个 bug，它有时真能修好，有时只是把异常从日志里挪到数据一致性里——问题还在，只是更难发现。

这时候，真正拉开差距的，不再只是"我会不会写"，而是这一句:

这段代码该不该存在。

这话听着有点扫兴。AI 都能生成了，老程序员还在旁边念叨"可维护性""边界""长期成本"，像极了饭桌上劝年轻人少喝冰奶茶的长辈。可是做过几年系统的人都懂，代码不是写完就完事。它会进仓库，会跑上线，会被同事接手，还会在凌晨三点给你打电话。

一句话, AI 把生成代码的门槛拉低了，却把判断代码好坏的门槛拉高了。

经验、判断和品味, 反倒比以前更值钱。只是这里有个坑: 经验也会过期，判断也会偷懒，品味也可能滑成"我以前就是这么干的"。

接下来我想聊的就是这件事——怎么把经验养成望远镜, 而不是后视镜。

二、经验不是老黄历，是约束识别器

经验最容易被误用的方式，就是把过去的答案直接搬到今天用。

比如, 一个老系统曾经被 ORM 坑过, 查询慢、事务乱、对象关系缠成毛线团。于是有人从此一看到 ORM 就皱眉, 像看见欠钱不还的老同学。可今天的场景也许只是一个内部小工具, 数据量不大, 团队熟悉框架, ORM 反而能省下不少重复代码。

再比如, 十年前我们说"不要过早抽象", 是因为很多人写到第二个用例都还没遇上, 就急着搞插件系统。现在 AI 写重复代码飞快, 复制三份不像以前那么肉疼, "先重复、再抽象"的账面也变了。不是原则失效, 而是原则背后的约束变了。

经验真正有用的地方, 不是告诉你"以前怎么做", 而是提醒你先问几个问题:

• 这个系统的寿命, 是三周、三个月, 还是三年?
• 谁会维护它, 一个人, 还是一个团队?
• 最容易出事的地方, 是性能、权限、数据一致性, 还是需求反复横跳?
• 这段代码一旦错了, 是页面丑一点, 还是钱算错、数据泄露、线上事故?

一句话, 经验不是答案库, 是约束识别器。

老程序员的优势, 固然有"见过很多坑", 可是更要紧的是知道坑为什么会冒出来。只记得"某技术不行", 容易长成偏见; 记得"在什么约束下它不行", 才是经验。

三、判断力, 看几个慢变量

AI 给出的方案常常快到一种程度: 你还没想清楚, 它已经写完了一堆代码。快不是坏事, 坏的是人跟着快, 脑子没跟上。

我越来越觉得, 工程判断力, 要盯住几个慢变量。

1. 领域: 先用 DDD 给 AI 一张图纸

AI 编程的方式变了很多, 可业务本身变化没那么快。

电商还是要把货卖出去, 协作软件还是要让人少开点无效会议, 安全系统还是要把不该看的人挡在门外。再往大处说, 赚钱的方法归根结底还是那一句: 满足人的需求。有些是物质的, 比如更便宜、更快、更可靠; 有些是精神的, 比如更省心、更有成就感、更被尊重。

所以, 让 AI 写代码之前, 不妨先用 DDD 把业务讲清楚。Martin Fowler 在 Domain-Driven Design 里说过, DDD 的核心是围绕领域模型组织软件, 并把统一语言嵌进系统。放到 AI 编程里, 这条更重要: 你不给它领域语言, 它就按通用模板发挥; 你不给它边界上下文, 它就可能把"订单""账单""发票""支付流水"和成一锅粥。

我现在更喜欢先这样问 AI:

先不要写代码。
请根据下面的业务描述，提取：
1. 核心领域对象
2. 关键业务规则
3. 不变量
4. 可能的边界上下文
5. 哪些概念容易混淆

等我确认领域模型后，再生成实现方案。

这不是仪式感, 是防止 AI 带着我们跑偏。代码生成得越快, 越要先把"业务到底是什么"钉住。否则就好比请了一个手速飞快的装修队, 图纸还没定, 人家已经把墙砸了。

2. 边界: 这段代码该管什么, 不该管什么

很多坏代码不是因为写得丑, 而是因为边界糊。一个函数既查数据库, 又拼返回值, 又发消息, 还顺手记日志。AI 也很容易这么干, 因为它的目标是"把任务做完", 不是替你守住系统边界。

判断一个方案, 先问边界:

• 输入从哪儿来, 可信不可信?
• 输出给谁用, 是否会被二次消费?
• 错误在哪一层处理, 哪一层只负责传递?
• 这个模块知道的事情, 是不是太多了?

边界清楚, 代码长一点还能活; 边界糊了, 再漂亮的命名也像新刷的墙, 里头还是潮的。

3. 代价: 今天省下的时间, 明天要不要还

Martin Fowler 有个说法叫 Design Stamina Hypothesis, 意思是好设计能让项目跑得更久。刚开始不做设计可能更快, 可是技术债会慢慢拖慢你。

这事放到 AI 编程里更明显。以前写烂代码还得自己敲, 现在一句 prompt 就能生成一大片, "借债"这件事变得太容易了。

所以判断一个方案, 不妨问一句不中听的话:

这段代码明天需求变了, 我是愿意改它, 还是想装作没看见?

要是答案是后者, 它就不是生产力, 是债务自动化。

技术账之外, 还得算经济账。ROI 不是老板和产品经理的专利, 工程师也该会用。这个方案多花两周, 换来的是收入增长、成本下降、风险降低, 还是只换来"架构看起来更高级"? 说不清楚, 就先别急着上强度。

4. 失败模式: 它怎么坏, 坏了谁先知道

很多方案乍一看都能跑, 真正的区别在出事时能不能兜得住。

缓存会不会读到脏数据? 重试会不会把下游打死? 批处理失败后能不能重跑? 权限判断挂了, 是默认放行还是默认拒绝? 日志里有没有顺手把用户数据暴出去?

AI 生成代码时, 常常把 happy path 写得顺顺当当, 失败路径写得像赶末班车。经验的价值, 就在于你会盯住那些"不好看但要命"的地方。

好判断力, 不是每次都选最复杂的方案, 是知道哪些地方不能赌。

四、品味不是玄学, 是可以练出来的偏好

一说"品味", 有些人就紧张, 觉得这是审美问题, 像讨论咖啡该不该加糖, 各执一词没结果。

Paul Graham 写过一篇 Taste for Makers, 聊创造者的品味。放到软件里, 我理解的品味不是"我喜欢这种写法", 而是这一句:

在多个都能跑的方案里, 挑那个长期更少后悔的。

工程品味, 至少有四层:

第一层是 读得懂。代码不是写给机器看的, 机器看字节码就够了。代码是写给下一个维护者看的, 而下一个维护者, 通常就是三个月后的自己——那时候的自己脾气未必比现在好。

第二层是 改得动。一个方案要是只能凑合当前需求, 把下一次变化堵死, 它就像一次性雨衣, 看着便宜, 用完满地狼藉。

第三层是 错得起。系统不可能永远对, 关键是错了以后, 能不能隔离、回滚、补偿、追踪。

第四层是 少造概念。概念越多, 读者脑子里要加载的"包"就越多。一个只有两个用例的东西, 不必急着起名 AbstractUniversalStrategyFactory。要是你真这么命名, AI 还会礼貌地点头称赞, 这也是它让人害怕的地方。

品味不是天生的, 也不是熬年头熬出来的。很多人工作十年, 只是把第一年的写法重复了九年, 顺便攒了一点脾气。

品味要练。

五、练品味的三件小事

1. 做"代码回访", 不止做代码评审

代码评审通常发生在合并前, 那会儿大家关心的是能不能进主干。可很多设计选择好不好, 要过一阵子才显出原形。

我建议每个月挑一两个自己参与过的改动, 做一次"代码回访":

• 当初为什么这么设计?
• 后来需求改过没有?
• 改起来顺不顺?
• 线上有没有报警、工单、性能问题?
• 如果重来一次, 会删掉什么, 会保留什么?

这就像体检, 平时没感觉不代表指标好。代码也一样。

2. 让 AI 给多个方案, 但拍板的事自己来

不要只问 AI 一句"帮我实现这个功能"。

更好的问法, 是这样:

给我三个方案：
1. 最简单能上线的方案
2. 更适合长期维护的方案
3. 性能和可靠性更强但成本更高的方案

请分别说明：
- 适用场景
- 主要风险
- 未来改动成本
- 你不推荐它的情况

AI 很会摊开选项, 拍板这件事还得人来。

这个动作的价值, 不在于 AI 的答案一定对, 而在于它逼你比较。比较, 才是品味的训练场。没有比较, 就容易把"能跑"误当成"合适"。

3. 写决策日志, 给未来的自己留个证词

很多技术争论之所以变成口水仗, 是因为大家只记得结论, 不记得当时的约束。

一段很短的决策日志就够用:

## Decision

我们选择方案 B，而不是方案 A。

## Context

- 需求预计会在两个月内变化三次以上
- 团队只有两个人熟悉底层实现
- 当前性能瓶颈不在这里

## Trade-offs

- 接受多一次网络调用
- 换取更清楚的模块边界
- 后续如果 QPS 超过 X，再引入缓存

## Review

一个月后回看：是否真的出现了预期变化？

别写成长篇论文。写太长没人看, 最后跟某些会议纪要一样, 存在的意义主要是证明有人曾经很努力。

决策日志真正的好处, 是让经验有出处。以后复盘时, 你会知道自己当时是判断错了, 还是前提变了——这两件事差得远。

六、让经验不变成桎梏

经验最大的敌人, 不是无知, 是懒得更新。

年轻时, 我们容易相信新东西能解决一切; 年纪大了点, 又容易相信旧原则能解释一切。两种都危险——前者像没刹车的新车, 后者像只看后视镜开车, 都能动, 但不一定能到。

让经验不变成包袱, 我觉得有三条原则。

第一, 把结论还原成条件。不要说"微服务不好", 要说"在团队运维能力弱、边界未稳定、调用链观测不足时, 微服务会放大复杂度"。这样经验就不会沦为口号。

第二, 允许小规模推翻自己。选一个低风险场景, 去试试过去不喜欢的工具或写法。不是为了赶时髦, 是为了更新样本。老中医也要看新化验单, 不能只靠把脉。

第三, 用结果校准口味。你喜欢的设计, 后来是不是更容易改? 你讨厌的方案, 后来是不是真的出过事? 事实反复打脸, 就别硬撑。工程师的面子不值钱, 线上稳定才值钱。

一句话, 经验不是用来证明自己对的, 是用来让团队少走弯路的。

说起来容易, 做起来要点修养。毕竟承认"我以前那套不适合这里", 有时比修一个复杂 bug 还难。bug 不会顶嘴, 人的自尊会。

七、工程品味 CheckList

下次让 AI 动手之前, 或者看完它给你的实现之后, 不妨快速过一遍这张表:

如果只能挑一个问题, 我会选第一个: 这段代码该存在吗?

因为写代码最难的部分, 常常不是怎么写, 而是忍住不写。

总结

AI 编程让"生成"变便宜了, 也让"判断"变贵了。会写代码固然重要, 可更重要的是知道什么该写、什么该删、什么该先放一放。

经验有价值, 可是要不断校准; 判断很稀缺, 可是能通过复盘练出来; 品味听起来玄, 落到工程里, 不过是这一句——在多个可行方案里, 挑那个长期最少后悔的。DDD 帮咱们守住业务语言, ROI 帮咱们守住投入产出。一个管"做对事", 一个管"值不值得做"。

最后送给自己, 也送给还在键盘前敲代码的老伙计们一句话:

工具越聪明, 人越要清醒。
经验不是护身符, 品味才是方向盘。

思维导图

@startmindmap
* AI 编程时代的工程品味
** 核心变化
*** 写代码更快
*** 选择更多
*** 判断更贵
** 经验
*** 不是答案库
*** 是约束识别器
*** 把结论还原成条件
** 业务锚点
*** DDD 统一语言
*** 边界上下文
*** 满足人的真实需求
*** ROI 判断投入产出
** 判断力
*** 看领域
*** 看边界
*** 算代价
*** 查失败模式
*** 区分 happy path 和真实系统
** 品味
*** 读得懂
*** 改得动
*** 错得起
*** 少制造概念
** 训练方法
*** 代码回访
*** 让 AI 给多个方案
*** 写决策日志
*** 用结果校准偏好
** 避免包袱
*** 小规模推翻自己
*** 不拿过去压今天
*** 让经验服务团队
@endmindmap

扩展阅读

• Paul Graham: Taste for Makers
  聊创造者的品味, 虽是讲设计与创作, 放到软件工程里同样有启发。
• Martin Fowler: Design Stamina Hypothesis
  好设计不是为了显得优雅, 是为了让项目跑得更久。
• Martin Fowler: Domain Driven Design
  DDD 的核心不是画几张图, 而是用领域模型和统一语言组织复杂业务。
• Joel Spolsky: The Law of Leaky Abstractions
  抽象总会漏水。AI 生成代码时, 这道理并没有失效。
• Tim O'Reilly: The End of Programming as We Know It
  从更宏观的角度看 AI 对编程工作的影响, 当背景读物挺合适。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。