重构一个模块，过去要半天；现在一个 agent 会话，5 分钟。给项目补全测试，过去"不值得花时间"；现在 agent 跑一遍，1 分钟。当写代码的成本从小时级降到分钟级，程序员每天做的那些"值不值得"的判断，答案全变了。
Django 联合创建者 Simon Willison 最近发布了一份持续更新的工程实践指南——Agentic Engineering Patterns，核心是八个工程模式，另外还有注释提示词案例、常用提示词附录等补充章节。他定义的"Agentic Engineering"不是让 AI 自主做所有事，而是专业工程师用 coding agent 放大自身专长。
但社区并不完全买账。有人认为代码审查仍然不可省略，也有团队已经让 agent 全程自动化、工程师完全不看代码。以下是这份指南的核心内容，以及围绕它展开的争论。
一、2025 年 11 月，Coding Agent 跨过能力拐点
Willison 在 2026 年 1 月 4 日的博客中提出了一个判断：2025 年 11 月是 coding agent 的能力拐点。GPT-5.2 和 Opus 4.5 跨过了一条不可见的能力线，突然之间一大批更难的编程问题变得可以解决了。
这个拐点带来的变化不是"AI 能帮你写几行代码"——那个阶段早就过了。变化在于：coding agent 现在能独立完成需要长时间、多步骤推理的复杂工程任务。重构一个模块、给一个项目补全测试、把一个单文件脚本拆分成一个结构良好的包——这些过去需要半天到一天的工作，现在可以在一个 agent 会话中完成。
直接的后果是：过去大部分关于"值不值得写"的判断标准需要重新审视。 当编码成本从小时级降到分钟级，从"要不要重构"到"要不要加测试"，每一个日常决策的最优解都变了。
Willison 的八个模式就是在这个背景下提出的：工具变了，工作方式怎么跟着变？
二、八个模式
Willison 的指南包含以下八个核心模式：
| 原文 | 中文 | 一句话概括 | |
|---|---|---|---|
| 1 | Writing code is cheap now | 写代码变便宜了 | 代码生成成本暴跌，但交付好代码的成本没变 |
| 2 | Hoard things you know how to do | 囤积你会做的事 | 建立可复用代码片段库，AI 只需学一次就能反复用 |
| 3 | AI should help us produce better code | 用 AI 写更好的代码 | 别用 AI 交付更差的代码，用它做过去"不值得"的质量工作 |
| 4 | Red/green TDD | 红绿测试驱动 | 先写测试确认失败，再实现直到通过 |
| 5 | First run the tests | 先跑测试 | 每个新 agent 会话第一句话：先跑一遍测试 |
| 6 | Linear walkthroughs | 线性演练 | 让 agent 生成结构化代码讲解文档 |
| 7 | Interactive explanations | 交互式解释 | 文字讲不清的算法，让 agent 生成可视化动画 |
| 8 | Anti-patterns | 反模式 | 第一条：不要提交你没审查过的 PR |
指南仍在持续更新中。
模式一：写代码变便宜了
代码一直很昂贵。生产几百行干净代码，需要一整天或更长。而现在，这是从 8 小时到 5 分钟的数量级跃迁。
过去的工程习惯都建立在"写代码很贵"这个前提上。产品经理用开发成本衡量功能优先级，程序员写每段代码前都在掂量同一个问题——这值得花一个小时吗？
现在，这套逻辑崩了。重构只需 30 秒，生成测试只需 1 分钟，创建调试界面只需 2 分钟——大量"值不值得"的判断都要重审。
Willison 建议：直觉说不值得时，就发个提示词试试，最坏结果是 10 分钟后发现不值那几个 token。
但他紧接着泼了一盆冷水：代码变便宜了，好代码仍然昂贵。 能跑、有测试、可维护、优雅地处理错误、文档同步、为未来留空间——AI 能生成代码，但不能保证这些。他列出了一系列好代码的标准（从"代码能跑且没有 bug"到"设计为未来变更留空间"），开发者仍然有大量责任确保产出的代码满足这些标准。
模式二：囤积你会做的事
把解决过的问题存档。Willison 的个人博客、TIL 站点、上千个 GitHub 仓库，都是他的"技巧仓库"。
为什么要囤这些技巧？因为 AI 能把它们重新组合。
他举了一个例子：他之前分别研究过 Tesseract.js（OCR 库）和 PDF.js（PDF 转图片），但没组合过。于是他给 Claude 喂了两段代码，输入"组合起来，拖拽 PDF 进去，每页转 JPEG，然后 OCR"。完美运行。
只要 AI 把技巧弄懂一次，它就可以查阅、复用、重组。
模式三：用 AI 写更好的代码，而不是更多的代码
用 agent 交付更差的代码是一种选择。我们可以选择交付更好的代码。
过去因为"不值得花时间"而跳过的质量工作，现在可以交给 agent 做：API 重新设计（需要改几十个地方）、命名不一致的修正、重复功能的合并、过大文件的模块化拆分。让 agent 在后台的分支或 worktree 中处理这些事。
一个实用的补充习惯是：每个项目结束后做复盘，记录哪些 prompt 有效、哪些模式可复用，下次 agent 就能做得更好。
模式四：红绿测试驱动
"Use red/green TDD"——一句简短的提示词，浓缩了整套测试驱动开发流程：先写测试（失败/红），确认失败，写实现（通过/绿）。
为什么对 AI 特别有效？因为 AI 最大的风险是写出"能跑但不对"的代码，或"从不被用"的代码。测试先强制 AI 定义什么叫正确，再实现。
模式五：先跑测试
模式四是写新功能时的方法论（先写测试再实现），模式五解决的是另一个问题：启动新会话时怎么让 agent 快速了解项目？ 答案是每次开头第一句话就说"先跑测试"。
测试输出会告诉 agent 项目有多大、用了什么框架、当前状态是否健康，同时把 agent 带入测试优先的心态。
Willison 在 Pragmatic Summit 演讲中说：尽管他个人职业生涯中一直不喜欢 TDD，但让 agent 执行 TDD 感觉完全没问题——因为 agent 的时间是廉价的。自动化测试在使用 coding agent 时不再是可选的。
模式六：线性演练
让 AI 生成结构化代码讲解文档。
Willison 花 40 分钟用 Claude Code vibe coding（Andrej Karpathy 提出的概念——纯靠 prompt 生成代码，全程不看、不审、不改）了一个 SwiftUI 幻灯片 App（Present.app）。App 确实能跑，但他自己完全不懂 SwiftUI。
于是他让 agent 生成一份演练文档，详细讲解所有 .swift 文件。他说：
我从中学到了大量 SwiftUI 和 Swift 知识。
在这个过程中，AI 不但没有减少学习，反而成了学习加速器。
模式七：交互式解释
当文字解释不够直观，要求 AI 生成可视化。
图片来源于Simon Willison博客
Willison 遇到词云算法"Archimedean spiral placement"，看文档还是不懂。于是他让 Claude 生成动画演示页面，能看到每个词如何沿螺旋线找位置。这个动画让算法原理真正通俗易懂了。
如果担心 LLM 减慢学习速度，我强烈建议采用这类模式。
模式六和模式七共同指向一个问题——认知负债（Cognitive Debt） 。它和技术债不同：技术债是代码质量差，将来要还；认知债是你自己不懂，将来要学。
Willison 亲身经历了这个问题：他尝试过不审查代码就让 agent 完成整个功能，结果丢失了项目能力的心智模型，后续每个功能的推理难度都在增加。如果放到核心业务里，应用核心变成黑盒，无法自信推理，规划新功能变难。
他的解法不是"少用 agent"，而是用 agent 帮你还债——线性演练让你读懂代码，交互式解释让你理解算法。AI 不但没有减少学习，反而成了学习加速器。
模式八：不要提交你没审查过的代码
Willison 把这条列为第一反模式："不要提交你自己没审查过的 PR。" 提交几百上千行 agent 生成的代码而不自己审查，等于把实际工作转嫁给同事——他们本可以自己 prompt 一个 agent 来做。
好的 agentic PR 应该包含：你确信代码能工作的证据、适当的范围（多个小 PR > 一个大 PR）、上下文说明、手动测试记录或截图。
三、争议：Agent 写的代码，人要不要审？
Willison 的模式建立在一个前提上：人必须理解和审查代码。但社区中有人走向另一个方向——StrongDM 让 agent 自动编写和测试代码，工程师不看代码只做最终验证，他们的标准是"每个工程师每天至少花掉 $1,000 token"。
Willison 称这种方法"极其不负责任"，但也承认 StrongDM 建了一套自动化测试体系来兜底。Hacker News 上的开发者 mohsen1 则处于两者之间：不要求审查每行代码，但坚持测试验证和用 .md 文件做会话间记忆。
三方立场不同，但都同意一件事：验证不能省。 区别只在于验证的方式——人工审查、自动化测试、还是两者结合。
四、代码变便宜了，判断力变贵了
Willison 这份指南最有价值的不是具体的 prompt 技巧，而是它逼你面对一个问题：当写代码不再昂贵，工程师的核心价值在哪？
可能是三个能力：
第一，知道该写什么。 需求分析、架构设计、技术选型——这些决定了代码往哪个方向写。Agent 能写出你描述的大多数东西，但它不知道应该写什么。这需要对业务的理解、对用户的判断、对系统全局的把控。
第二，知道好代码长什么样。 Willison 列出了一系列好代码标准，agent 一条都不能自动保证。能区分"能跑"和"好"的工程师，才能从 agent 的产出中筛选出值得合并的部分。
第三，知道如何让 AI 不跑偏。 这正是八个模式在训练的能力——用 TDD 约束 agent 的输出、用测试验证 agent 的工作、用线性演练确保自己理解 agent 写的代码。
前两种能力依然需要深厚的工程经验才能撑起来。第三种能力是新的，但建立在前两种之上——不懂架构的人写不出好的 agent 提示词，不懂代码质量的人审不出 agent 的问题。
代码变便宜了，判断力变贵了。这可能是 AI 时代软件工程师的新价值所在。
参考来源
- Simon Willison: Agentic Engineering Patterns（2026.2.23 起持续更新）
- Simon Willison: The November 2025 inflection point（2026.1.4）
- Simon Willison: My fireside chat at the Pragmatic Summit（2026.3.14）
- Simon Willison: How StrongDM's AI team build serious software without even looking at the code（2026.2.7）
- Hacker News 讨论：Agentic Engineering Patterns
Coovally AI Hub 解读AI前沿——顶会论文解读、开源项目精选、企业落地案例，帮你技术进阶与商业破圈。如果您有技术交流或合作意向，欢迎联系我们和评论区留言讨论～
