AI 编程新范式：80% 在想，10% 在写，10% 在验

一个有点扎心的问题

先说个最近常被问到、也有点扎心的问题。

有人问我：你现在用 AI 写代码，一天能多写几倍的代码？

我想了想，老实答：我写的代码可能比以前还少。

对方一脸"那你不就废了"的表情。可我心里清楚，这一年我交付的东西不比以前少，甚至更扎实。变化在哪儿？时间花的地方完全变了。 以前我一天里大半时间在敲代码、查 API、对着编译错误较劲；现在这些活儿大部分甩给了 AI，我的时间挪到了"想清楚"和"验明白"上。

如果硬要给个比例，我会说是 80% 在思考与讨论，10% 在编程，10% 在验证。

这个数字当然有点夸张，别拿尺子量。但它点出了一件正在发生的事：当写代码不再是瓶颈，瓶颈就回到了"你到底想清楚没有"。 这篇就掰开揉碎说说，这 80% 到底在想什么，剩下两个 10% 又该怎么花。

时间都去哪了：从"手熟"到"想清楚"

我以前写过一句话，叫"目的无他，惟手熟尔"——程序员的功夫，很大一块是在"手熟"上：API 记得牢、样板代码敲得快、调试有手感。这套功夫值钱，因为过去把脑子里的设计翻译成能跑的代码，本身就是个力气活。

AI 把这个力气活的成本打下来了。一个想清楚的接口，让 Claude Code 或 Codex 去实现，几分钟就有初稿。"手熟"这项技能，单价在贬值。

那什么在升值？想清楚。

这不是新道理。Fred Brooks 在《人月神话》里早就说过，软件开发真正的难点是"概念完整性"（conceptual integrity），是把需求想明白、把系统设计对，而不是把代码敲出来。他把前者叫 essential complexity（本质复杂度），后者叫 accidental complexity（偶然复杂度）。AI 干掉的，恰恰是偶然复杂度那一大坨；剩下来全是本质复杂度——也就是只能靠人想的那部分。

所以这个 80/10/10 不是我拍脑袋发明的新潮流，更像是一次"返祖"：软件这门手艺里最难、最值钱的部分，从来都是想，不是写。 只是过去写得太累，把想这件事的光芒盖住了。AI 帮我们把写的成本抹平，想的价值才重新浮出水面。

打个比方：以前盖房子，搬砖砌墙占了大半工期，图纸画得糙一点，靠施工队的经验还能现场找补。现在来了一支不知疲倦、砌墙飞快的施工队（AI），图纸画错一个承重墙，它会用极高的效率帮你把错的房子盖得又快又结实。这时候，画图纸的人就成了真正的关键。

那 80% 到底在想什么、跟谁讨论

"思考与讨论"听上去很虚，容易变成偷懒的借口——"我在思考"约等于"我在发呆"。所以得说具体：这 80% 不是空想，是有抓手、有产出的活儿。我把它拆成六块。

1. 架构：先把边界和数据流想对

代码可以重写，架构改起来要命。AI 最不擅长替你做的，恰恰是架构决策——它能给你三个方案，但哪个适合你的团队、你的历史包袱、你的运维能力，它不知道，你知道。

这一块我花时间在：模块怎么切、边界在哪、数据往哪流、哪些是核心域哪些是支撑域、一致性要求多强、未来最可能从哪儿长出来。这些想清楚了，写代码这件事才"配得上"交给 AI。想不清楚就让 AI 开写，等于让那支飞快的施工队照着一张错图纸开工。

我之前写领域模型、DDD 那几篇，本质都是在练这块功夫。架构想清楚的标志很简单：你能用一张图、几句话，把这个系统讲给一个新人听明白。 讲不明白，就是还没想清楚。

2. 流程：把"怎么干"也设计出来

过去我们设计系统，很少认真设计"开发这个系统的流程"。现在不行了。当 AI 能自己跑、自己改、甚至自己开 MR，流程本身变成了要设计的东西。

这就是我在 Loop Engineering 和 Harness Engineering 里反复聊的事：什么时候触发 Agent、谁来写、谁来审、跑到什么条件算完、状态记在哪。这些不是写代码，是设计一条让代码自己被生产出来的流水线。

一句话：以前你是产线上的工人，现在你得先去当产线的设计师。

3. 测试用例：先想清楚"什么叫对"

这一条我想单独拎出来，因为它被严重低估。

让 AI 写实现代码很爽，但实现对不对，取决于你有没有想清楚"什么叫对"。测试用例就是"什么叫对"的精确表达。边界值、异常路径、并发场景、幂等性、回滚……这些 corner case，正是 AI 容易糊弄、而人最该动脑的地方。

我现在常见的姿势是反过来的：我先想测试用例，把验收标准列清楚，再让 AI 去写满足这些用例的实现。 测试用例成了我和 AI 之间的"合同"。合同写得含糊，交付物一定打折；合同写得严密，AI 反而成了靠谱的施工队。

老规矩送一句：写测试用例的过程，本身就是在逼自己把需求想透。这部分别外包给 AI，因为它不知道你真正在怕什么。

4. 度量：想清楚拿什么判断好坏

我写过一本书叫《微服务之道：度量驱动开发》，核心就一句话：没有度量，所谓的"改进"全是感觉。 这话在 AI 时代更狠了。

AI 一天能给你产出一堆 PR，你拿什么判断这些改动是真好还是看着好？延迟、错误率、覆盖率、复杂度、依赖健康度——这些度量指标，是你在一堆 AI 产出里分辨金子和镀金的筛子。想清楚"我盯哪几个数",比"我又合了几个 PR"重要得多。

5. CI/CD 自动化：把判断标准变成闸门

光想清楚标准不够，得把标准焊死成自动闸门。

fmt、vet、build、test、lint、安全扫描、端到端冒烟——这些能自动卡住的，绝不靠人肉记得。我习惯把它们收敛成一条命令（比如 make verify），让它成为 AI 产出能不能进主干的硬门槛。AI 写完自己跑一遍，不过就自己改，改到过为止。

这一步的价值在于：它让你敢放手。 你信的不是 AI 写得好，你信的是这道闸门够严。闸门设计，就是这 80% 里很硬核的一块工程活。

6. Harness 方法：把上面这些攒成一套马具

前面五块——架构约定、流程、测试标准、度量、CI 闸门——散落各处是没用的，得攒成一套能让 AI 稳定干活的环境。这就是 Harness（马具）：AGENTS.md / CLAUDE.md 写约定，SKILL.md 沉淀项目常识，reviewer subagent 当审查员，Hook 卡纪律。

我在 Harness Engineering 和三个设计 Skill 里详细聊过，这里就不展开。一句话：Harness 是把"你脑子里想清楚的东西"，固化成 AI 每天都能读到的文件。 想清楚而不固化，等于每天早上重新给一匹健忘的烈马解释一遍规矩。

这六块，就是那 80% 的去处。你会发现它们有个共同点：全是 AI 替不了、必须人来拍板的判断。

那 10% 编程：从"敲代码"到"接得住"

有人会问：照你这么说，是不是不用写代码了？

恰恰相反。这 10% 的编程含金量比以前高得多。

它不再是大段大段地敲样板，而是几种更"贵"的动作：

• 写关键骨架：接口定义、核心抽象、那段决定全局的脏活，我宁可自己写，因为它承载的是设计意图。
• 写示范代码：给 AI 打个样，"照这个风格、这个错误处理、这个命名来"，比写一长串 prompt 管用。
• 接手 AI 接不住的活：那种需要全局直觉、需要在五个约束之间走钢丝的改动，AI 一上手就跑偏，这时候得人亲自上。
• 改 AI 改不动的：它转了三圈还在原地打转，你看一眼就知道是哪个假设错了——这一眼，靠的是手还没生。

这也是为什么我坚持每周得自己手写一段代码、手 debug 一个问题。不是仪式感，是怕手生了，那"关键一眼"就没了。一个看不懂自己系统的人，是没资格也没能力去设计那 80% 的。

那 10% 验证：merge 之前，责任是你的

最后这 10%，是端到端的验证，也是整个范式里唯一不能打折的部分。

注意，验证和前面说的"CI 闸门"不是一回事。闸门是自动化的、跑给机器看的；验证是你亲自确认"这玩意儿放到真实场景里真的能用"。AI 跑绿了所有测试，不等于它真的对——它只是满足了你想到的那些用例，没想到的那些，它一无所知。

我的硬规矩，跟我在 Loop Engineering 里说的一致：任何 AI 产出的代码，merge 之前我至少读一遍 diff，关键路径还要亲手跑一遍端到端。 鉴权、计费、数据迁移这类，禁止全自动合并，必须人按按钮。

道理很朴素：AI 能"觉得完成了"，但不能"负责"。 "觉得对"和"真的对"之间，隔着的就是责任，而责任这东西，到今天为止还没法外包。你的工作早就不是产出代码，是产出你确认过、敢签字的代码。

几个得提前说破的边界

这套 80/10/10，用顺了会上瘾，但有几个坑得先讲清楚，不然容易走火入魔。

第一，比例是隐喻，不是 KPI。 别真去掐表统计自己 80% 的时间有没有在思考。不同阶段比例天差地别：搭原型时可能 90% 在写，做核心系统设计时可能 95% 在想。这个数字想说的只是重心的转移，不是考勤表。

第二，对新手，这可能是个陷阱。 80% 思考的前提，是你有值得信赖的判断力。判断力哪来的？是当年那 80% 时间敲代码、踩坑、debug 熬出来的。一个还没写够代码的新人，直接跳到"我只思考不写代码"，思考出来的多半是空的。老程序员的捷径，是新人的悬崖。 新手反而要多写、多踩坑，先把"手熟"和"判断力"攒够。

第三，思考能力会"温水煮青蛙"。 当 AI 替你做的决定越来越多，你会不知不觉懒得有自己的判断——它给啥你信啥。这是我最警惕的一条。所以前面才反复强调：留一块自己手写、手 debug 的自留地，别让脑子闲废了。这套范式用得好是放大器，用得差是麻醉剂，工具分不清，你能。

收尾：写得少，不等于干得少

回到开头那个扎心的问题：用了 AI，为什么我代码写得反而少了？

因为代码从来只是想清楚之后的副产品。过去这个副产品太贵，贵到我们误以为生产副产品就是工作本身。AI 把副产品做白菜价之后，工作的真身露出来了——它一直都是想清楚、定标准、验明白。

这对老程序员其实是天大的好事。咱们这代人最值钱的，本就不是手速，是这些年攒下的判断力、踩过的坑、对"什么叫对"的直觉。AI 没有抢我们的饭碗，它抢的是我们手里那把最不值钱的扫帚，把我们解放去干真正配得上经验的活儿。

前提是——你得真的去想，而不是把"思考"当成不写代码的借口。

行动清单

如果想往这个范式挪一步，给你一份能直接抄的小清单：

• [ ] 下次开任务，先写测试用例 / 验收标准，再让 AI 写实现，把它当合同；
• [ ] 把项目的检查项收敛成一条命令（如 make verify），让它成为 AI 产出进主干的硬闸门；
• [ ] 给系统挑 3 个核心度量指标，以后判断 AI 产出好坏先看它们，别看 PR 数量；
• [ ] 把项目约定写进 AGENTS.md / CLAUDE.md，把常识沉进 SKILL.md，别每天重讲一遍；
• [ ] 立一条铁规：AI 产出 merge 前必读 diff，关键路径亲手跑端到端；
• [ ] 每周留半天，关掉 AI，自己手写一段、手 debug 一个，保住那"关键一眼"。

最后留个问题给你：如果明天起，你写代码的时间被强行砍到只剩 10%，剩下 90% 必须用来思考和验证——你想得清楚吗？

想清楚的人，AI 是杠杆；想不清楚的人，AI 是放大镜，把你想不清楚这件事，放大给所有人看。

共勉。

思维导图

@startmindmap
* AI 编程新范式 80/10/10
** 核心观点
*** 写代码不再是瓶颈
*** 瓶颈回到"想清楚"
*** 重心从手熟转向判断力
** 80% 思考与讨论
*** 架构
**** 边界与数据流
**** 核心域与支撑域
*** 流程
**** 谁写谁审
**** 触发与停止条件
*** 测试用例
**** 先想清楚什么叫对
**** 当人和 AI 的合同
*** 度量
**** 拿什么判断好坏
**** 分辨金子和镀金
*** CI/CD 自动化
**** 把标准焊成闸门
**** make verify
*** Harness 方法
**** AGENTS.md / SKILL.md
**** reviewer subagent
** 10% 编程
*** 写关键骨架
*** 写示范代码
*** 接 AI 接不住的活
*** 保住关键一眼
** 10% 验证
*** merge 前必读 diff
*** 关键路径手跑端到端
*** 责任无法外包
** 边界
*** 比例是隐喻不是 KPI
*** 对新手是陷阱
*** 思考能力会退化
@endmindmap

参考资料

• Walter Fan, 从 Prompt Engineering 到 Harness Engineering：AI 编程的四次进化
• Walter Fan, Loop Engineering：别再手摇 AI 了，去设计那台摇柄
• Walter Fan, 拷问、共创、固化：把三个 AI Skill 串成一条设计流水线
• Frederick P. Brooks, The Mythical Man-Month / No Silver Bullet
• Walter Fan, 《微服务之道：度量驱动开发》(https://item.jd.com/69315415321.html)

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