最近一个 Golang 新项目让我重新认识了 AI 编程：顶流大模型加各种 harness，仍会写出看起来漂亮、跑起来似乎也没问题、但可读性和可维护性不尽如人意的代码。带 AI 就像带一个刚毕业的博士生——它懂得多，却不知道什么最适合你的产品、环境、业务和那座“屎山”。上岗必须备齐指导手册、设计与代码规范、架构原则、编码规范、验收清单，一个都不能少。

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

过去写软件，大半时间花在敲代码上。AI 把"敲代码"这件事的成本压到接近于零之后，时间该怎么重新分配？我的答案是一个有点夸张、但越用越觉得对的比例：80% 在思考与讨论（架构、流程、测试用例、度量、CI/CD、Harness），10% 在编程，10% 在验证。本文聊清楚这 80% 到底在想什么、剩下两个 10% 怎么花，以及为什么这个转变对老程序员是好事、对新手是陷阱。