一份 MySQL 数据库设计评审清单，我把它拆成"建表""查询""特殊约束"三块，并逐条讲清楚背后的原因——为什么禁自增主键、为什么禁外键、为什么用 DATETIME 不用 TIMESTAMP、为什么少碰 JSON 和大字段。规则好背，难的是知道每条规则在防哪个坑。文末附一份可直接抄的自查清单。

有一次我认真读完一段完全由 AI 生成、且已经跑通的代码，越看越心惊。冷静下来复盘：一部分不能全怪 AI——我的 design 本来就没说清楚；另一部分确实是 AI 的锅。结论很简单：想把 AI 的改动用到产品线上，你必须收紧缰绳，用"人机接力"的流程，主要功能代码逐行看、验收测试亲自做。因为 AI 不会替你背锅，为最终结果负责的人是你。

框架每年换一茬，但有些技术书十年后翻开还是有用。这篇聊聊我书架上被翻烂、后来又买了第二本的那几本经久耐看的技术书——《数据密集型应用系统设计》《性能之巅》《UNIX 编程艺术》之类——以及为什么它们比追新更值得花时间。

AI 能让一个人像一支小队，但不能让一个人逃掉工程责任。真正的超级个体，不是炫耀百家招式，而是持续交付有价值的产品，满足用户需求，创造真实价值。

长久不用的知识会不会生锈？会。但真正危险的不是忘了细节，而是把生锈的手感误认为仍在巅峰。以大型 C++ 和 Audio/Video 项目为例，聊聊怎样让知识重新招之即来、来之能战。

AI 会写 WebRTC demo，也能解释 SDP、ICE、RTP、RTCP，但 RTC 应用真正难的是把音频、视频、网络、QoS 和用户感知串起来。高级程序员的门槛不在“懂得多”，而在对原理的深刻领悟、对失败模式的判断、以及从事故和教训里长出来的工程直觉。

Claude Code 和 Codex 把写代码这件事的速度推到 5 倍、10 倍，但人脑的阅读速度还是那个阅读速度。结果是：MR 排成长队，reviewer 心虚地点 Approve，bug 一个接一个上线。不看不放心，全看没时间——这篇文章给你一套既要速度又要质量的 review 分层策略。

AI 把写代码的门槛拉低了，把判断代码好坏的门槛拉高了。经验不会自动变成优势，反而容易变成包袱。咱们要做的，是用 DDD 守住业务语言，用 ROI 算清楚账，再用品味在多个可行方案里挑那个"长期最少后悔"的。