✨ 审美 —— 在工程上意味着什么
对工程师来说，审美翻译成两件具体的事：(1) 知道什么时候算"够好了"。(2) 把这个判断，外化成可以跑的系统。
为什么是最后一道护城河
2026 年互联网正在被"灰色泥浆"淹没 —— 技术上没毛病、精神上空洞的 AI 内容。Eric De Castro："当创造的成本降至零时，品味是唯一的护城河。"
对工程师而言，AI 写代码很快。但 AI 写出来的代码"够不够好"——这个判断只能你做。一个能熟练用 AI 但没有审美的人，他的产出会沉到平均水平 + 5%；一个能熟练用 AI 又有审美的人，能做出别人做不出来的东西。差距越来越大。
给写代码少年的具体翻译
- 每个项目都有"完成定义"（Definition of Done）。不是模糊的"做完了"——是写下来的、可以 review 的清单。
- 用 LLM-as-judge 自动检查质量。本地跑通义千问当判官，给你的输出打分。审美的工程化，就是让自己的标准能自动跑。
- code review 自己的代码。每次 PR 之前，把代码当别人写的 review 一遍。
- 建立"漂移检测"。三个月前你觉得"好"的标准，今天还成立吗？写下来，定期回顾。
"工程美感不是奢侈品 —— 是可维护性的另一个名字。"
工程
审美的外化 —— Definition of Done
一段代码的"完成"，应该由什么定义？
- 跑起来没有bug就算完成
- 有一份写下来的、可以复审的清单说明什么算"够好"
- 测试覆盖率足够高
- 通过代码审查就算完成
- 部署上线就算完成
解释："完成"不能是模糊的感觉。一个有审美的工程师，会提前写下来"什么时候我认为这个工作是done"。这个清单可能包括代码可读性、性能指标、边界情况处理、甚至是"日志要长什么样子"。一旦写下来，你的标准就可以自动化检查——这就是工程美感。
工程
我的项目 "Definition of Done" 是什么？
任务：拿你最近的一个项目，写下至少5条"这个工作算完成"的标准。不要模糊——要能被自动化检查或者被别人验证。
已复制 ✓
看高级工程师的例子
某个做 LLM 应用的高中生的 DoD： 1. 延迟必须 < 2 秒（包括 model 推理） 2. 每个 prompt 有版本号，改 prompt 必须有 git commit 3. 用 deepseek-chat-as-judge 自动评分我的输出 4. 错误提示用户可以理解（不是 stack trace） 5. 代码库有一个 README，别人能在 5 分钟内跑起来 他甚至写了一个脚本来自动检查标准 1-3。标准 4-5 他定期手工检查。
这不是"完美主义"。这是把你对"好"的定义，变成可以衡量的东西。一旦你能衡量，你才能进步。
品味漂移检测 —— 你的标准在变
一个有趣的现象：你三个月前的 DoD，今天可能就过时了。这不是坏事，这是进步。
建议：
- 每个月回顾一次你的 DoD，问自己"还同意吗？"
- 如果不同意，新的标准是什么？
- 用 git 管理你的 DoD，这样你能看见自己的审美演化
- 写下变化的原因：为什么从"覆盖率 80%"变成"覆盖率 95%"
这个过程，就是一个工程师成熟的标志。