风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用类比和框架交叉验证每个论点。
引子：当写代码变得跟说话一样便宜
2026 年初，软件工程领域发生了一件安静但深远的事。
Simon Willison——Django 框架的联合创始人、datasette 的作者、长期跟踪 AI 工具的独立开发者——在 GitHub 上启动了一个叫 Agentic Engineering Patterns 的项目。他要做的事用一句话就能说清：把“如何跟编码代理合作”这件事，写成一套系统化的工程模式。
你可能会问，这有什么好写的？不就是用 Claude Code 或 Codex 写代码吗？
恰恰不是。Simon 在项目开篇就画了一条光谱——
一头是 Vibe coding：你几乎不看代码，不理解代码，把“能跑出结果”当终点。另一头是 Agentic engineering：由专业工程师用代理来放大专业能力，但仍保持对系统质量与结果的责任感。
这条光谱背后是一个被大多数人忽略的事实：编码代理最大的冲击，不是“写代码更快了”，而是“写代码的成本结构被彻底重排了”。
一、一个经济学框架：成本重排如何改变行为
1.1 三件事的成本比例
如果把传统软件开发抽象成三件事——把想法变成代码（Implementation）、证明代码是对的（Verification）、让代码能长期演进（Maintenance）——那么过去几十年，这三件事的成本大致是 5:2:3。写代码占大头，所以整个行业的习惯都围绕“编码时间稀缺”建立：大量前期设计、估算与排期、对每个小改动都在脑内做成本收益权衡。
而编码代理把第一件事的成本压到接近零。
这就像印刷机的发明。 在手抄书时代，你不会随便写一本书试试；每一本书都经过反复考量才值得“抄”。但印刷机出现后，出版成本暴跌，突然之间——不是“写得更快”变了，而是“什么值得写”的判断标准变了。
编码代理做的是同一件事：当“把字敲进编辑器”的成本接近零，你过去用来做权衡的直觉，开始系统性失效。
1.2 行为经济学的“锚定效应”
诺贝尔经济学奖得主 Daniel Kahneman 的研究告诉我们，人类做判断时会被“锚定”在最初接触到的信息上。工程师对“这件事值不值得做”的判断，长期被“写代码的时间成本”锚定。
当你脑内出现那句熟悉的“算了，做这个不值得花时间”——你以为这是理性判断，其实很可能只是旧锚点在作祟。Simon 提出的应对策略非常精准：当你本能觉得“不值得做”，反过来——先丢给代理跑一把。 最坏结果只是浪费了一些 token。
这条原则看似松散，但它隐含了一个极硬核的新成本模型：试错成本大幅下降，但验收与整合成本相对上升。你需要更强的测试、更清晰的边界、更严格的审阅，才能把大量产出“筛”成主线质量。
二、“好代码仍然贵”——但贵在哪里？
Simon 在《Writing code is cheap now》里给了一个非常实用的“好代码”定义框架。不是一句口号，而是一组可检查的性质。
这些性质包括：能工作、可被证明能工作、解决的是正确问题、异常与边界条件可预测、简单且最小化、有测试保护、有恰当文档且与现状一致、为未来变化保留余地但不过度设计，以及项目所需的各种“ilities”——安全性、可靠性、可观测性、可维护性等。
这份清单的真正价值不在于它列了什么，而在于它帮你看清一件事：编码代理可以帮你做其中的大部分，但仍然需要驱动它的工程师承担“让结果达到所需质量”的责任。
这让我想到管理学大师 Peter Drucker 的一个著名区分：效率（efficiency）是“把事情做对”，效能（effectiveness）是“做对的事情”。编码代理极大提升了效率，但效能——选择做什么、不做什么、做到什么程度——仍然是人的工作。
代理把“写”变成商品化，把“判断、取舍、验收、担责”变成更稀缺的能力。
三、四个词的魔力：为什么短提示能召唤复杂纪律
截至 2026 年 2 月 26 日，Simon 的项目已发布四个章节。它们有一个令人着迷的共同点：每个模式都可以浓缩成极短的提示语——有的甚至只有四个词——但能触发模型执行一整套复杂的工程纪律。
这不是提示词花活。这背后有一个深层原因。
3.1 语言哲学的“言语行为理论”
英国哲学家 John Austin 在 1962 年提出了“言语行为理论”（speech act theory）：语言不只是描述世界，还能改变世界。当牧师说“我宣布你们结为夫妇”，这句话不是在描述一个事实，而是在创造一个事实。
“First run the tests”和“Use red/green TDD”就是面向编码代理的言语行为。 它们不是在描述你想要什么，而是在把模型切换到一种特定的“心智模式”——一个受过大规模软件工程语料训练的协作者，用非常短的指令就能进入正确的行为框架。
这其实是一条隐藏的主线：未来的工程方法论，可能会越来越多地表现为“触发器式提示”（trigger prompt）。 不是几百字的流程说明，而是一句“行业暗号”，模型自动补全背后的隐含步骤。
四、模式一：First run the tests——反幻觉的第一道防线
4.1 从工程美德到生存必需
Simon 的态度非常明确：和编码代理一起工作时，自动化测试不再是可选项。
过去不写测试的借口——写测试太耗时、代码变化快测试跟不上——在代理时代被削弱了，因为代理可以在几分钟内把测试补齐或修到能跑。
但更关键的是他的一句现实主义判断：如果 AI 生成的代码从未被执行过，它部署后能工作几乎只能靠运气。
这句话把“测试”从工程美德升级成了“反幻觉机制”。大语言模型最大的风险不是写出错误代码——人也会写错——而是它会非常自信地告诉你“我写的是对的”。你不需要相信模型说它做对了；你让测试说话。
这跟科学哲学家 Karl Popper 的“可证伪性”原则完全一致：一个理论的价值不在于你能证实它，而在于你能尝试证伪它。测试就是对代码的证伪尝试——如果所有测试都没能让它失败，你就有合理的信心。
4.2 四个词解决三个问题
Simon 说他每次让代理接手一个已有项目，都会先丢一句：
First run the tests.
这四个词同时完成了三件事：
第一，让代理意识到“这里有测试套件”，并迫使它自己找出如何运行。一旦跑过一次，后续改动它更可能自觉回归测试。
第二，大多数测试框架会显示测试数量，这给代理一个关于项目规模与复杂度的粗略信号，也暗示“要理解功能就去看测试”。
第三，把代理切换到“测试心智”：跑过测试后，它更自然会在后续补充测试。
这就像你带一个新同事入职时，第一件事是让他跑通整个项目的 CI。 你什么都不用多说，他自然会从测试结构里读出项目的规模、风格和质量标准。
五、模式二：Red/green TDD——给代理的创造力装上护栏
5.1 “令人愉悦地简洁”
Simon 把这五个字称为一个“令人愉悦地简洁”的提示：只要你对编码代理说 Use red/green TDD，模型就会把一整套测试驱动开发的纪律补齐。
为什么 TDD 对代理是“天作之合”？
因为代理的两大常见风险——写出“看起来对但不能跑”的代码，以及写出“不必要、不会被用到”的代码——恰好被 TDD 对应地压制。Test-first 迫使代理先把需求“落地成可失败的断言”，再围绕断言实现最小代码。这同时约束了正确性和范围。
5.2 为什么“红”阶段不可跳过
Simon 强调了一个经常被忽略但极其关键的细节：一定要先确认测试会失败。
这不是形式主义。如果你写了一个“本来就会过”的测试，等于没有验证任何新实现。这在逻辑学里叫“空真”（vacuous truth）——“如果太阳是方的，那月亮是三角的”这个命题在逻辑上为真，但它不包含任何信息。
一个从未失败过的测试，就是一个空真命题。它什么也没验证。
红/绿循环的精髓是：红色给你信息（“需求还没被满足”），绿色给你信心（“最小实现通过了”）。跳过红色，绿色就失去了意义。
5.3 把红/绿变成节拍器
你可以把红/绿循环变成代理工作的四拍节奏：
- 澄清行为：把需求写成可观测的行为（输入、输出、边界、错误）。
- 写测试（红）：新增测试并运行，确认失败。
- 写实现（绿）：写最小实现让测试通过。
- 重构与回归：整理代码，确保所有测试仍通过。
每一拍都有明确的“可检查状态”——这正是代理最需要的东西。没有检查点的任务，对代理来说就是一片没有路标的旷野。
六、模式三：Linear walkthroughs——用证据链代替信任
6.1 当你不理解自己的代码
Simon 在第四章提出了一个非常坦诚的场景：他在 macOS 上用 Claude Code 做了一个 SwiftUI 幻灯片应用 Present，发到 GitHub 后发现自己其实不懂它怎么工作——因为是 prompt 出来的。
这是“代码产量远超理解能力”的典型场景。 在编码代理时代，你不缺代码，你缺的是对代码的理解。
他的解决方案是“线性走查”（linear walkthrough）：让代理按依赖关系，逐文件、逐模块地讲解代码库。
6.2 关键约束：不许模型“凭记忆抄代码”
这一章最值得学习的技术决策是 Simon 对幻觉风险的处理。他在提示里加了一个硬性约束：
用 sed/grep/cat 等命令把代码片段插到文档里，不要手工复制粘贴代码。
这条约束极其重要。大语言模型在“复述代码”时非常容易出现微妙的偏差——改了一个变量名、漏了一个参数、调换了两行的顺序。这些偏差在讲解文档里是致命的，因为它们会让读者建立错误的心智模型。
用命令输出代替模型记忆，就是把“解释”变成了“解释 + 证据链”。 任何代码片段都来自执行过的命令输出，而不是模型的记忆或想象。
这个思路其实来自一个更深的方法论：科学实验的可重复性原则。 一篇论文如果只写“我们观察到了 X”，没有实验数据和方法描述，就不是科学。同样，一份代码讲解如果只有模型的“叙述”，没有可验证的证据，就不是工程文档。
6.3 线性走查的“学习加速器”效应
Simon 还给出了一个反直觉的结论：如果你担心 LLM 会让你学得更慢，那么线性走查这种模式反而能把一个很短的玩具项目变成学习新生态与技巧的机会。
为什么？因为走查文档强迫代理“解释为什么这样写”，而不只是“写出能跑的代码”。当你读到“这个 SwiftUI view 用了 @StateObject 而不是 @ObservedObject，因为它是这个 view 的所有者”——你学到的不只是这个项目的实现细节，而是 SwiftUI 的设计哲学。
代理不是在替你学习，而是在给你一个结构化的学习路径。 前提是你要求它提供证据，而不是让它随意编故事。
七、隐藏主线：模式的组合效应
到这里你会发现，这三个模式虽然各自独立，但它们之间有一个精巧的组合逻辑。
它们对应的是工程师与代码的三种关系：
- First run the tests → 接手代码（建立可执行基线）
- Red/green TDD → 修改代码（用测试约束变更）
- Linear walkthroughs → 理解代码（用证据链建立心智模型）
接手、修改、理解——这就是一个工程师日常工作的完整循环。
更有趣的是它们的组合方式。当你接手一个陌生项目时，最高效的流程是：先做线性走查（理解），再 First run the tests（建立基线），然后用 Red/green TDD 做第一个小改动（验证你真的理解了）。
每个模式单独用都有价值，但组合起来形成的不是“1+1+1=3”，而是一个自我强化的循环。 理解越深，测试写得越准；测试越稳，改动越安全；改动越安全，你越敢深入理解——这是一个正向飞轮。
管理学家 Jim Collins 在《从优秀到卓越》里提出过“飞轮效应”：没有单一的突破性行动让一家公司从优秀到卓越，而是无数个小的推动力形成自我强化的循环。Simon 的三个模式，就是编码代理时代的工程飞轮。
八、一个更大的图景：从“模式语言”到“触发器文化”
Simon 明确说过，他的项目受到 1994 年“四人帮”《设计模式》一书的启发。那本书的核心洞见不是具体的 23 个模式，而是“模式语言”这个概念本身——当一群人共享一套命名好的模式时，沟通效率会指数级提升。
“Factory method”“Observer”“Strategy”——每个名字都是一个压缩过的知识包。你不需要每次都解释“我要创建一个对象，但不想让客户端直接依赖具体类”，你只需要说“用 Factory”。
Simon 正在为编码代理时代做同样的事情。 “First run the tests”“Use red/green TDD”“Linear walkthrough”——这些不是提示词技巧，而是新的模式语言。当你的团队都理解这些名字背后的含义时，你们的协作效率会跳一个台阶。
更进一步说，当这些模式被写进团队的 coding guidelines、CI 配置、PR 模板里时，它们就从“个人习惯”变成了“组织能力”。这才是 Simon 这个项目的终极野心——不是教你几个 prompt 技巧，而是为一种新的工程文化提供词汇表。
结语：代理让你更值钱，还是更不值钱？
回到开头的经济学框架。
当印刷机出现后，抄写员消失了，但作者变得更值钱。当数码摄影出现后，胶片师傅消失了，但真正懂构图和光影的摄影师变得更值钱。
编码代理也在做同样的事：消灭“把字敲进编辑器”的稀缺性，但放大“定义问题、建立证据、守住质量”的稀缺性。
Simon 用四个章节给出了一个非常可执行的起点：
- 接受现实：写代码便宜了，但好代码仍然贵。
- 用最短提示触发最强纪律：四个词就够。
- 用证据链让理解变得可验证。
如果你是一个工程师，你现在面临的选择很简单：继续当“把字敲进编辑器”的人，还是成为“判断什么值得敲、证明敲出来的是对的”的人。
前者正在变得便宜。后者正在变得昂贵。
而 Simon Willison 这套模式，就是帮你从前者走向后者的训练手册。