一个天天用 AI 写代码的人，给的第一条建议居然是，别急着让 AI 写。

说这话的是 Simon Willison。他是 Web 框架 Django 的联合创建者，也是开源数据工具 Datasette 的作者，圈里公认最舍得拿各种大模型一遍遍实测的那批人之一。2026年2月他开了个连载，叫「Agentic Engineering Patterns」（智能体工程的套路），启动时他说希望每周补一两章，后来陆续写了十几章，专门讲怎么把 Claude Code、OpenAI Codex 这类「能自己写代码、还能自己跑代码」的编程助手用出最好结果。我最近在系统地过一遍 AI 圈这些人的分享，翻到这个连载，发现他讲的不是玄乎的方法论，是五个普通人也能照着做的具体动作。下面挨条说清楚，每条你都能直接拿去用。

先把一个容易混的事掰开。Simon 说的这套，跟最近很火的 vibe coding（凭感觉编程，不看代码直接让 AI 生成）不是一回事。vibe coding 是你压根不管它写了啥，能跑就行，是给外行兜底的。他讲的是另一端：你自己懂行，用 AI 来放大你的判断，而不是替你判断。这个区别贯穿后面每一条。

动作一，先写测试，再让它写代码。

这是最反直觉的一条，也是他说得最干脆的一条。正常人的顺序是先让 AI 把功能写出来，再想办法验。他倒过来：先把「这段代码要满足什么」写成测试，这时候代码还没影呢，测试一跑必然全红（失败）。然后让 AI 盯着这堆红色的测试改，改到全变绿（通过）为止。这套老办法在程序员圈叫红/绿 TDD（先让测试失败、再写到通过的开发法）。Simon 的原话方向是，用红/绿 TDD 是个简洁得让人舒服的办法。

为什么管用，说白了就一句：你给了 AI 一个能量化的成功标准。它不再是「我觉得写得差不多了」，而是「还有3个测试没绿，接着改」。有了这根标尺，它生成的代码反而更精简、更可靠，你也不用在提示词里反复啰嗦。

动作二，它写完，你先跑一遍测试，别直接用。

这条听着像废话，可恰恰是最多人栽跟头的地方。AI 甩给你一段代码，看着挺像那么回事，你一爽就拿去上线了。Simon 一句话戳破："If the code has never been executed it's pure luck if it actually works when deployed."（一段代码要是从没真正被运行过，那它上线能跑就纯属撞大运。）这就是 agent（智能体，能自己干活的 AI 程序）最坑人的地方，它写得又快又自信，可它没分寸。有点像一个手特别快的实习生，三下五除二把活儿交上来，态度诚恳、看着完整，但你要真不验就交差，迟早出事。

自动化测试在以前是可有可无的奢侈品，现在成了你必须配的安全护栏。

动作三，让它把陌生代码逐行走读给你听。

这条我自己最喜欢。不管是 AI 刚生成的、还是你接手的别人的项目，你都可以让它把整个代码库从头到尾给你「线性走读」一遍——一行行讲清楚这段在干嘛、当初为什么这么设计。它一边讲，一边顺手就把文档给你写出来了。Simon 自己有个挺逗的例子：他花45分钟随手让 AI 写了个网页演示小工具，叫 Present.app，全程用 SwiftUI（苹果的界面开发框架）写的，他连一次 Xcode（苹果的开发软件）都没打开过。事后他让 AI 走读，才发现这家伙居然没用任何现成的库，直接用最底层的 socket（网络通信的基础接口）自己手搓了一套 HTTP（网页传输协议）解析。他说，走读出来的那份文档是真有用。这条的价值在于，它把「AI 写的我看不懂」这个最大的不安，变成了「我让它讲明白」。

动作四，囤住你自己懂的东西，用它把 AI 推向走得通的那条路。

到这儿，话题就从「怎么用工具」深了一层，变成「凭什么是你来用」。Simon 有句话说得很实在："A big part of the skill in building software is understanding what's possible and what isn't."（做软件这门手艺，很大一部分是知道什么能做、什么做不到。）AI 擅长动手实现，但它缺一样东西——对「什么路根本走不通」的直觉。你脑子里囤的那些经验，比如「JavaScript 能不能在网页里原生跑文字识别」「iPhone 的 app 退到后台之后还能不能连蓝牙」，这些一眼就能判断可行不可行的判断力，正是你能把 AI 往对的方向推、而不是看它在死胡同里瞎试的本钱。这也是他反复强调的那条分水岭：内行用 AI，是拿专长去放大；外行用 AI，是闭着眼瞎生成。你越懂，AI 在你手里越值钱。

动作五，架构你来定，实现交给机器。

这是前面几条的总纲。系统怎么搭、分几层、按什么顺序来，这些拿主意的事归你；具体一行行码字的体力活，归 AI。光说显得空，他举了个有分量的例子：有个叫 Ladybird 的浏览器项目，要把里头的 JavaScript 引擎从 C++ 这门语言整个搬到 Rust（另一门更安全的语言）。用 Claude Code 加 Codex，两周写了大约2.5万行 Rust，换人工得好几个月。靠的是什么？现成的测试套件兜底、人主导着一步步给提示、再拿可信的老版本逐字节对照，最后输出跟原来逐字节一模一样，零出错。项目作者 Andreas Kling 的话很到位，大意是：这是人主导的，不是 AI 自己撒欢儿生成的，移植什么、什么顺序、Rust 代码该长什么样，都是我定的，是几百个小提示一点点把 AI 引到该去的地方。

五条说完，你大概能咂摸出底下其实是同一套动作。把它抽干净，就四步：先定好「什么算合格」，再让 AI 去产出，产出后马上验，验完让它逐行讲清楚自己干了啥。一句话概括，叫先定标准再放手。

最妙的是，这套根本不绑在写代码上。我不是天天写大型项目的工程师，可这四步我用在别的活儿上一样顺。让 AI 帮你写一份方案、一份分析报告、甚至一份合同初稿，道理完全一样：你先把「这东西怎样才算过关」列清楚（这就是测试），它写完你立刻拿自己懂的那部分去核（这就是先跑一遍），再让它一段段讲为什么这么写（这就是走读）。能不能用好 AI，差距往往不在工具，在你有没有先把标准立起来。

也别被工具名唬住。上面这套流程跟你用哪家模型没关系——DeepSeek、Kimi、通义、豆包，照样跑得通。核心从来不是模型多强，是你这个出题人会不会出题、验不验货。

我挺欣赏 Simon 的一点，是他不端着。同样这个人，一边推这套智能体工程，一边在5月又公开写文章说，vibe coding 跟它「近得让我有点不安」——他的立场会跟着实测随时改，不装一副早就想明白了的样子。还有个细节我觉得很有意思：一个天天靠 AI 写代码的人，却给自己立了条硬规矩，不在自己名下发表任何 AI 生成的文字。代码可以让机器代劳，署自己名字的话得自己说。这个分寸，比那五个动作更值得琢磨。

所以最朴素的一个问题留给你：你让 AI 帮你干活的时候，最先丢给它的，到底是一句含糊的「帮我写个东西」，还是一条清清楚楚的「怎样才算合格」？这俩的差距，可能就是用 AI 的人之间真正拉开档次的地方。

#马力的AI知识分享#
#马力在记录AI领域500位大佬的分享#