← #807

Agent 时代的软件工程

文章摘要

这篇原文其实是 Simon Willison 在 2026 年 2 月 23 日写的项目发布公告，标题是《Writing about Agentic Engineering Patterns》——他宣布启动一个新项目，系统性地收集和记录「Agentic Engineering Patterns」（智能体工程模式），也就是那些能帮你从这一代 coding agent 里拿到最好结果的编码实践与模式。到本期周报出刊时（2026 年 8 月），这个项目已经长成了一份相当完整的指南。

他先做了一组定义上的区分，这也是整篇文章最有价值的部分：

Agentic Engineering（智能体工程）指的是用 coding agent 构建软件——像 Claude Code、OpenAI Codex 这类工具，其定义性特征是它们既能生成代码又能执行代码，因而可以自己测试、自己迭代，不需要人类监督者一轮一轮地手把手指导。
Vibe coding 他坚持使用最初的定义：完全不看代码的编码方式。今天这个词通常被用来指非程序员用 LLM 写代码。
两者是同一个尺度的两端：Agentic Engineering 是专业软件工程师用 coding agent 放大自己既有的专业能力，从而改进和加速工作。

他说自己在 ai-assisted-programming 标签下已经发了 345 篇（截至 8 月是 404 篇），但那些内容相对零散，新项目的目标是把「怎样才能从这套东西里得到好结果」的答案集中到一个地方。形式上，他借鉴了 1994 年《设计模式》那本书的章节化写法，把内容组织成一系列「模式」章节，每周新增 1 到 2 章。

发布当天他上线了头两章：《Writing code is cheap now》（写代码现在很便宜了）讨论智能体工程的核心挑战——把初版能跑的代码churn出来的成本已经降到几乎为零，这件事如何冲击我们对个人和团队工作方式的既有直觉；《Red/green TDD》（红/绿测试驱动开发）讲测试先行如何让 agent 用最少的额外提示写出更简洁、更可靠的代码。

有两个附带的表态值得注意。第一，他明确声明内容由他本人撰写，不是 LLM 生成的——他有一条强烈的个人原则：不以自己的名义发表 AI 生成的文字；他会用 LLM 做校对、补充示例代码和各种边角任务，但读者看到的文字都是他自己写的。第二，他为此发明了一种新的内容形式，叫「guide（指南）」：一份 guide 是章节的集合，每一章本质上是一篇淡化了日期、被设计成会持续更新而非在首次发表时冻结的博客文章。他说这是他找了很久的、在博客上发布「常青内容」的解法。实现上，Guide / Chapter / ChapterChange 三个模型和相关的 Django 视图几乎全部是由 Claude Opus 4.6 在 Claude Code for web 里写的，而他是通过 iPhone 访问的。

从该指南目前的目录看，内容已经远超最初两章，大致分为四大块：原则（什么是智能体工程、这是不是就是 vibe coding、写代码很便宜了、好代码仍然有成本、我们需要建立新习惯、囤积你会做的东西并重组它们、AI 应该帮我们产出更好的代码、避免背上技术债、AI 工具让我们能考虑更多方案、拥抱复利工程循环、反模式：把未经审阅的代码强加给协作者）、与 coding agent 协作（agent 的工作原理：大语言模型、chat 模板提示、token 缓存、调用工具、system prompt、推理，以及「LLM + system prompt + 工具跑在一个循环里」这个本质）、和 agent 一起用 Git（Git 要点、核心概念与提示词、改写历史）、子智能体（Claude Code 的 Explore 子智能体、并行子智能体、专家型子智能体），以及测试与 QA（红/绿 TDD 等）。

HN 评论精华

需要说明一下：本期周报收录的这条 HN 链接（id 49405117）只拿到 35 分、9 条评论，而且讨论基本没有围绕文章内容展开，一半在聊别的事。真正热闹的讨论发生在今年 2 月该指南本身的几次提交上（《Writing code is cheap now》384 分 499 评，《Agentic Engineering Patterns》543 分 310 评）。下面如实反映这条帖子里的实际内容。

pianopatrick 贡献了唯一一条真正的技术讨论。他说自己在琢磨一个理论：大家都说 AI 擅长 greenfield（从零开始的新项目），但在遗留代码库里做修改就吃力得多。那么，也许你干脆就把所有项目都当作 greenfield 来对待——比如你想改一个页面，就不要原地编辑，而是重新生成一个新版本的页面，然后把旧版本留着，一旦新版本出问题就回退。phyzix5761 的反驳很直接：代码一复杂起来，就很难把每个需求都当 greenfield 处理了——你每次都得把几十个功能重新构建进新页面里。
bigcat12345678 提了两条「吹毛求疵」的意见，其中第二条相当有意思。第一条是措辞：应该把「Writing code is cheap now」改成「Generating code is cheap now」，把「writing（写）」这个词留给 AI 之前的手工编写时代，他认为这是一个好的用词区分。第二条更根本：他要求这本书至少加一章是写给 agent 读的——也就是把「人类和 agent 协作时人类会怎么工作」这件事本身写成模式给 agent 看。他认为没有这一章，这本书的内容三个月后就会过时；有了这一章，它才算是一本 agent 原生的书。「这不是在耍聪明，我们现在必须为 agent 写作了。」
goeric 的评论完全跑题，但很典型：他说自己是 Simon 作品的超级粉丝，「Rodney CLI 对我的本地开发是改变游戏规则的」，但他提了几个 PR 一直没动静，想知道 Simon 还打算维护吗，还是他该 fork 出去。baron3dl 的回复是整个帖子里最好笑的一条：「用一张手绘的『鹈鹕骑自行车』SVG 来召唤 Simon。」（这是 Simon 用来横向对比各家模型能力的经典测试题的梗。）
剩下的讨论是关于 Simon 本人在 HN 上的存在感。stein1946 说：「我总觉得这个人在这个网站上制造了很多噪音，能不能给他限个流？」argee 的回复相当克制且有信息量：这个人基本上住在 HN 上；他个人确实认为高 karma 用户会助长一点群体思维的氛围，但 HN 的机制本来就对他们有利（能攒到那么多 karma 说明待得久、也懂什么内容在这里会被顶上去）；不过就「限流」这个诉求而言，这条提交并不是 simonw 自己发的，所以不清楚具体要求是什么——人们应该可以提交任何他们想提交的网站。他倒是觉得，禁止 simonw 自己的投票影响 simonwillison.net 的提交会挺有意思，但很难对所有站长公平地执行。glimshe 认为这不可取：只要用的是自己的账号而不是小号，就让人投自己好了——如果他们能拿到的只有自己那一票，HN 自然会把他们过滤掉。
xnx 只留了一句提醒：「（2026 年 2 月）」——指出这是半年前的旧文。