公众号名称：ChallengeHub

作者名称：ChallengeHub

发布时间：2026-06-12 13:31

写代码已经不值钱了:Simon Willison 把”怎么用好 Claude Code”写成了一本书,这篇带你读完全部干货

这两天刷到「Agentic Engineering Patterns」——Simon Willison 从 2026 年 2 月开始写的一份在线指南,每周新增 1～2 章,目前仍在持续更新。文字由他本人撰写,示例与代码借助 LLM 辅助,某种意义上,这本书就是用书里讲的方法写出来的。

先交代下作者。Simon Willison,Django 联合创始人之一、Datasette 作者,“prompt injection”这个词就是他提出来的。过去两年,他是英文圈跟进 LLM 编程实践最勤的博主,几乎没有之一。这种常年在一线真刀真枪写代码的人,坐下来认真总结”如何与 coding agent 协作”,含金量不用多说。

“ 在线阅读地址:https://simonwillison.net/guides/agentic-engineering-patterns/

全书的核心目标一句话:如何用好 Claude Code、Codex 这类既能写代码、也能执行代码的 coding agent,拿到可靠、可维护的结果。 笔者把目前已上线的全部章节都啃了一遍,这篇按全书六大部分,把干货整理给大家。文章有点长,建议先收藏。

一、先把概念掰清楚:这不是 Vibe Coding

开篇第一章,Simon 就先划清了一条线。

什么是 agent?这个定义吵了三十年,但他给出的版本极其简洁:在循环中调用工具以达成目标(Agents run tools in a loop to achieve a goal)。所谓”agent”,就是一层软件:它带着你的 prompt 和一组工具定义去调 LLM,LLM 要用哪个工具,它就去执行哪个,再把结果喂回给 LLM,如此循环。

而 coding agent 的关键差异在于,它的工具箱里有一个能执行代码的工具。这一点是整个 agentic engineering 成立的前提——没有执行能力,LLM 输出的任何代码价值都有限;有了执行能力,agent 才能不断迭代,逼近”确实能跑”的软件。

那人还剩下什么活儿?Simon 的回答是:多得很。写代码从来就不是软件工程师的全部,这门手艺的核心一直是想清楚该写什么代码。任何一个软件问题都有几十种解法,各有取舍,工程师的工作就是在这些选项里找到最适合自己处境的那一个。具体到 agent 协作上,人要做的是:给 agent 配好工具、把问题描述到合适的颗粒度、验证并迭代结果直到可信。还有很关键的一条——LLM 本身不会从过去的错误中学习,但 coding agent 这套系统可以,前提是你主动把踩过的坑沉淀回指令和工具链(harness)里。

至于 vibe coding,这个词是 Karpathy 在 2025 年 2 月提出的——巧的是,就在 Claude Code 首次发布前三周——指的是让 LLM 写代码、而你”忘掉代码的存在”。有人把这个词扩大到”一切用 LLM 写代码的行为”,Simon 认为这是个错误。Vibe coding 应该保留它的原始定义:未经审查的、原型质量的 LLM 生成代码。我们需要这个词,恰恰是为了把它和作者已经打磨到生产级标准的代码区分开。

二、全书最重要的判断:写代码便宜了,写好代码并没有

如果整本书只能记住一句话,就是这句。

过去几十年,代码一直是昂贵的。写几百行干净、带测试的代码,大多数开发者要花上一整天甚至更久。我们的工程习惯,从宏观到微观,都建立在这个约束上。宏观层面:大量的设计、估算、排期,本质是为了让昂贵的编码时间花在刀刃上,一个功能必须数倍覆盖其开发成本才值得做。微观层面:每天上百个决定都被时间约束裁判着——这个函数要不要重构得更优雅一点?文档写不写?这个边界 case 要不要补个测试?给这个内部工具配个 debug 界面值不值?大部分时候答案是”算了”。

Coding agent 把”往电脑里敲代码”的成本打到了地板上,这一下子冲垮了无数旧直觉。更要命的是并行 agent:一个工程师现在可以同时在多个地方实现、重构、测试、写文档,旧的权衡框架彻底失效。

但是——交付新代码近乎免费了,交付好代码依然贵得多。Simon 给”好代码”列的标准,一条都没降:代码能跑,且你确认过它能跑;解决的是对的问题;优雅地处理错误路径而不只是 happy path,报错信息要能帮到未来的维护者;简洁、最小化,只做必要的事;有测试保护,既证明当下能用,也防止未来悄悄坏掉;文档与系统现状同步;设计为未来留出演进空间——既要守住 YAGNI(不为可能永远不来的需求堆复杂度),又不能把路堵死;以及一堆”-ility”:可访问性、可测试性、可靠性、安全性、可维护性、可观测性……

这些东西 agent 能帮上大忙,但确保产出是”好代码”的责任,依然压在驾驶 agent 的那个人身上。

那新习惯该怎么建?整个行业都还在摸索,Simon 自己也在摸索。他目前给出的实操建议很有意思:学会怀疑自己的直觉。每当本能告诉你”别做了,不值得花这时间”,就反手扔一个 prompt 给异步 agent 跑着。最坏的结果不过是十分钟后回来看一眼,发现这点 token 白花了。

三、囤积你会做的事:你的”存货”就是 agent 的弹药

这一章的思路,是 Simon 职业生涯老经验在 agent 时代的延伸:囤积你知道怎么做的事。

做软件的一大本事,是知道什么可行、什么不可行,以及大概怎么实现。这类问题可大可小、可正可偏:网页能不能纯靠 JavaScript 跑 OCR?iPhone 应用能不能在没运行的时候跟蓝牙设备配对?Python 能不能不把 100GB 的 JSON 全加载进内存就完成处理?这类答案攒得越多,你越能看到别人看不到的解法。而最可靠的答案,不是”理论上可行”,而是你亲眼见过它在跑的代码里成立。

Simon 的囤法:博客和 TIL 博客记满了”我搞明白了怎么做某事”的笔记;GitHub 上一千多个仓库,很多是验证某个关键想法的小型 PoC;tools.simonwillison.net 收集了他所有 LLM 辅助做的单页 HTML 小工具;simonw/research 仓库则放更大的实验——让 agent 研究一个问题,带着能跑的代码和书面报告回来交差。

囤这些干什么?除了攒能力,这些资产会变成喂给 agent 的强力输入。他最喜欢的 prompt 套路之一,就是让 agent 把两三个现成的、已验证可行的例子组合成一个新东西。

书里给了一个让这个套路”封神”的案例:浏览器端 PDF OCR 工具。他想要一个纯浏览器的工具,给扫描版 PDF 做 OCR。他手里正好囤着两段验证过的代码:一段用 Tesseract.js(Tesseract OCR 引擎的 WebAssembly 版)在浏览器里识别图片文字,另一段用 Mozilla 的 PDF.js 把 PDF 每页渲染成图片。于是他把两段代码原样贴进 prompt,最后加一句需求:做一个单页 HTML,用户把 PDF 拖进来,每页转成 JPEG 展示,然后跑 Tesseract OCR,结果显示在每张图下面的文本框里。一把过,几分钟就得到一个他用到今天的工具。注意,这是 2024 年 3 月的事,比 Claude Code 发布还早近一年。

到了 coding agent 时代,这套玩法更猛了。agent 有网络访问能力,你可以直接说:“用 curl 抓取我这两个工具页面的源码,然后组合出一个新工具”(他特意指定 curl,因为 Claude Code 默认的 WebFetch 工具会把页面摘要化,拿不到原始 HTML)。agent 擅长搜索,你可以指路:“给 A 项目加 mock HTTP 测试,参考 B 项目是怎么写的”。他的研究代码大多公开,所以也经常让 agent “把 simonw/research 克隆到 /tmp,找到 Rust 编译 WebAssembly 的例子,照着给当前项目做个 demo 页”。

这一章的核心思想就一句:有了 coding agent,任何有用的技巧只需要被搞明白一次。只要它被记录在某个带可运行示例的地方,你的 agent 以后就能随时调取它,去解决任何形状相似的问题。

四、AI 应该帮我们写出更好的代码,而不是更烂的

很多开发者担心:把代码外包给 AI,质量会下滑,烂代码产得足够快,老板就睁一只眼闭一只眼了。Simon 对此的态度很硬:如果用了 coding agent 之后代码质量明显变差,那就直接去修流程里导致变差的环节。用 agent 交付更烂的代码是一种选择,我们完全可以选择交付更好的。

他用技术债来展开这个观点。技术债的来源是权衡:“正确的做法”太耗时,所以先凑合,祈祷项目活到还债那天。而最好的还债方式是从一开始就别欠。他观察到,很大一类技术债的修复都是概念简单但极其耗时的活儿:早期 API 设计漏了一个后来才浮现的重要场景,修好它要改几十处代码,于是大家宁可加一个略有不同的新 API 忍受重复;早期命名失误(比如该叫 groups 的叫了 teams),全量清理工作量太大,只在 UI 层面糊弄一下;系统长出了重复又略有差异的功能,需要合并重构;某个文件膨胀到几千行,早该拆成模块。

这类任务恰恰是 coding agent 的理想应用场景。开一个 agent,告诉它改什么,然后扔到后台的分支或 worktree 里让它自己磨。Simon 通常用异步 coding agent 干这个——Gemini Jules、Codex web、Claude Code on the web——这样不打断他在笔记本上的心流。结果以 PR 形式评估:好,合;差一点,再 prompt 一句让它调整;不行,扔掉。这类代码改进的成本已经低到,我们可以对小的代码坏味道采取零容忍态度。

另一个角度是选型。最大的技术债往往欠在规划阶段——漏掉了某个显而易见的简单方案,或者选了个后来发现不合身的技术。LLM 能兜底”明显方案没想到”的问题,它们只会推荐训练数据里常见的方案,但那些恰好就是最不容易翻车的”无聊技术”(Boring Technology)。更重要的是探索性原型:对技术选型建立信心的最好方式是用原型证明它合用。Redis 适不适合做一个几千并发用户网站的动态流?最靠谱的回答方式是搭一个模拟系统跑压测,看什么时候崩。这种实验,coding agent 一个好 prompt 就能搭出来,成本低到可以同时跑好几组,横向对比选最优。

这一章结尾引出了”compound engineering”(复利工程)的概念,出自 Every 公司的 Dan Shipper 和 Kieran Klaassen:每个编码项目结束时做一次复盘,他们称之为 compound step——把这次有效的做法记录下来,供未来的 agent 运行使用。小改进会复利。那些过去因为耗时而被搁置的质量提升,现在成本低到没有借口不做。Coding agent 意味着我们终于可以既要新功能、又要高质量。

五、全书唯一被重点点名的反模式:把没审查的代码甩给别人

反模式这一章目前只写了一条,但分量很重,而且戳中了很多团队的现状:不要提交你自己都没审查过的 PR。

如果你甩出一个几百上千行、全是 agent 生成、你自己都没验证过能不能跑的 PR,你实际上是在把活儿转嫁给别人。Simon 的灵魂拷问是:他们自己也会 prompt,要你何用?

把代码放上去给人 review,你就得确保它值得别人花时间。第一遍审查是你自己的责任,不能外包给同事。 他给”合格的 agentic engineering PR”画了像:代码能跑,而且你有信心它能跑——交付”被证明能跑的代码”是你的本职;改动要小到能被高效 review,几个小 PR 永远好过一个巨型 PR,而且现在有 agent 帮你做 Git 上的拆分,没有借口偷懒;PR 要带上下文,说明这次改动服务的上层目标,关联相关 issue 或规格文档;还有一个容易被忽略的点——agent 写的 PR 描述看起来头头是道,但你也得审,让别人读你自己都没读过、没验证过的文字,是很失礼的。

他还建议在 PR 里主动附上”我确实下过功夫”的证据:手动测试的记录、对具体实现选择的说明、功能跑起来的截图甚至视频。这些东西能极大地向 reviewer 证明:你的时间不会被浪费。

六、拆开引擎盖:coding agent 到底是怎么工作的

这是全书科普浓度最高的一章,但讲得非常清爽。一句话框架:coding agent 是 LLM 的一层 harness(挽具),通过隐形的 prompt 和可调用的工具,给 LLM 扩展出额外能力。

从底层往上捋。LLM 本质是续写机器:给它”the cat sat on the “,它大概率补”mat”。模型不直接处理文字,处理的是 token(整数序列),这一点值得搞懂,因为厂商按 token 计费,模型一次能处理的 token 也有限。现在的主流模型大多是多模态的,图片输入并不是先走一遍 OCR,而是同样被转成 token,跟文字一视同仁地处理——这是个常见误解。

早期模型就是裸的补全引擎,不好用,后来才演化成 chat 模板:把交互包装成一段模拟对话的特殊格式文本,让模型去补”assistant:“后面的内容。关键认知:LLM 是无状态的,每次调用都从零开始,所谓”多轮对话”是客户端软件每次都把完整历史重放一遍。这意味着对话越长,每轮的输入 token 越多、越贵。厂商用 token 缓存来缓解:短时间内重复出现的相同前缀可以享受低价,因为底层基础设施能复用计算结果。Coding agent 在设计上刻意配合这个机制——尽量不修改对话早期的内容,把缓存利用率拉满。

然后是 agent 的灵魂:工具调用。说穿了一点都不神秘。系统提示词里告诉模型”需要查天气就输出 get_weather(城市)”,模型真这么输出了,harness 软件(很可能就用个正则)把函数调用抠出来、执行、再把结果拼回 prompt 喂给模型,模型拿着结果继续回答。Coding agent 通常定义十几个工具,其中最强的就是能执行代码的那几个——比如跑终端命令的 Bash 工具。

系统提示词是用户看不到的那份开场指令,动辄几百行,定义了 agent 的整个行为方式。Simon 推荐去读 OpenAI Codex 公开在 GitHub 上的系统提示词,是理解这类工具如何被”调教”出来的绝佳样本。再加上 2025 年的大进展——推理(reasoning):模型在正式回答前先花额外的时间和 token “自言自语”地推演问题。这对调试代码尤其有用,模型可以在推理阶段穿插工具调用,顺着函数调用链摸到问题根源。

最后他把谜底揭开:LLM + 系统提示词 + 工具,放进一个循环里——这基本就是 coding agent 的全部了。 想真正理解这些工具,他强烈建议自己从零写一个:在现成 LLM API 上搭一个简易工具循环,几十行代码就够。当然,“好”的工具循环要难得多,但基本原理就是这么朴素。

七、Git 在 agent 时代,反而更重要了

这一章可能是全书”即学即用”密度最高的一章。核心论点:Git 是和 coding agent 协作的关键工具——版本控制让你敢放手让 agent 大改,因为一切错误都可追溯、可回滚。而且所有 coding agent 都对 Git 的基础和高级特性烂熟于心,这意味着我们自己可以更野:不需要记住怎么做,只需要知道什么是可能的。

Simon 列了一串他实际在用的 prompt,全是大白话,任何 agent 都能听懂。比如开新仓库就说 “Start a new git repo here”;让它提交就说 “Commit these changes”。其中几个特别值得说道:

**“Review changes made today”(看看今天改了什么)**——他把这个当作新会话的标准开场。agent 会去跑 git log,瞬间把最近的工作内容(改动的代码加描述它们的提交信息)装载进上下文。开局先喂饱上下文,接下来聊修复、提问、规划下一步,都顺了。

**“Sort out this git mess for me”(帮我收拾这个 git 烂摊子)**——他自己说这个万能 prompt 用得出奇地频繁。rebase 撞上合并冲突、stage 加错了东西,这些过去是 Git 最折磨人的部分,现在 agent 能在最离谱的冲突里推理出新代码的意图,决定保留什么、怎么合并。如果项目有自动化测试,agent 还会确保测试通过后再敲定合并。

**“Use git bisect to find when this bug was introduced”**——git bisect 是 Git 武器库里最强的调试工具之一,通过二分搜索定位最早引入 bug 的提交,但学习曲线劝退了大多数人。现在这些样板活儿 agent 全包,bisect 从”偶尔想起来才用”升级成”随手就能丢出去”的工具。

更进阶的是改写历史。Simon 的观点很有意思:别把 Git 历史当成”事情真实经过的永久记录”,把它当成一个被刻意创作的故事,用来描述项目的演进,服务于未来的开发。仓库作者有权做编辑决定。“Undo last commit”背后那条 git reset --soft HEAD～1 他从来记不住,现在也不需要记了;“把 uv.lock 从上个提交里拿掉”这种精细手术、“把最近三个提交合并并写个更好的提交信息”这种整形操作,agent 都驾轻就熟。他还坦白了一件事:他曾经坚持提交信息必须自己写,但现在接受了——前沿模型写提交信息的品味通常很好,经常比他自己写的还好。

压轴的骚操作是从老仓库的边角料里长出新仓库:比如把项目里的某个模块抽成独立的开源库,同时把这部分代码的关键提交历史(作者、日期)原样迁移过去。这种活儿过去麻烦到大家都直接放弃历史、拷一份了事,现在一句 prompt 的事。

八、Subagents:上下文才是最贵的资源

这章解决的是一个越来越要命的问题:上下文限制。过去两年模型能力突飞猛进,但上下文窗口基本没怎么涨,普遍上限在 100 万 token 左右,而且各种基准测试反复表明,20 万 token 以内的表现质量明显更好。把上下文管理在限额之内,是出好结果的关键。

Subagent(子代理) 是个简单但有效的方案:父 agent 派出一个全新的自己,带着一个新开的上下文窗口去完成指定任务,做完只汇报结论。对父 agent 来说,调用子代理跟调用其他工具没区别——派出去,等结果。

书里用 Claude Code 的 Explore 子代理做了个完整解剖。Simon 给 Claude Code 发了个需求:让他网站上的章节 diff 视图支持字符级高亮(行内具体变化的片段用更深的红绿色标出)。Claude Code 干的第一件事,是构造了一个详细的探索 prompt 派给子代理:去找实现 diff 视图的代码,模板在哪、生成 diff 的 Python 在哪、有没有相关 JavaScript、红绿背景的 CSS 在哪,把 templates/、static/、blog/ 目录翻个底朝天,关键词盯住 diff、chapter、revision、history、compare。子代理几秒钟后带着一份完整的”侦察报告”回来:diff 是 views.py 第 139-202 行的 chapter_changes() 函数用 difflib 生成的……父 agent 拿着报告直接开改。Simon 感叹,看模型给自己写 prompt 很有意思——它们的 prompt 品味通常相当好。

子代理还有两个进阶玩法。一是并行:让父 agent 同时派多个子代理,甚至用 Haiku 这类更快更便宜的模型跑子任务。对于要改多个互不依赖的文件的任务,直接说 “Use subagents to find and update all of the templates affected by this change”,速度提升立竿见影。二是专家化:部分 coding agent 允许给子代理配自定义系统提示词和专属工具,变成不同角色——代码审查员(找 bug、找设计弱点)、测试运行员(特别适合测试输出又大又啰嗦的项目,子代理把完整输出吞掉,只回报失败详情)、调试专家(用自己的 token 额度去推理代码、跑片段、定位根因)。

但他也泼了盆冷水:别上头拆几十个花式子代理。子代理的核心价值始终是保护宝贵的根上下文、消化高 token 消耗的操作。只要 token 够用,你的主 agent 自己审自己的代码、自己调自己的 bug,完全没问题。

九、测试与 QA:三个四字咒语

这部分目前三章,每章都围绕一个可以直接抄走的短 prompt。

“Use red/green TDD”

Simon 称之为”令人愉悦地简洁”的提效咒语。TDD 即测试驱动开发,最严格的形态是测试先行:先写测试,确认它失败(红),再写实现让它通过(绿)。这套纪律和 coding agent 是天作之合,因为它同时防住了 agent 的两大典型翻车:写出不能用的代码,和写出根本没人用的多余代码。先看到红再看到绿这一步不能省——跳过它,你可能写了个一开始就能通过的测试,等于什么都没验证。妙处在于,所有好模型都懂 “red/green TDD” 这六个字母背后的完整纪律,你不用展开解释。示例 prompt:“Build a Python function to extract headers from a markdown string. Use red/green TDD."

"First run the tests”

在 agent 时代,自动化测试不再是可选项。过去不写测试的借口——费时、代码库快速演进时要不停重写——在 agent 几分钟就能把测试敲定型的今天已经不成立。而且测试是确认 AI 生成代码真的能干它声称的事的命门:从没被执行过的代码,上了生产能跑纯属运气。

Simon 每次对着已有项目开新会话,第一句话就是 “First run the tests”(他的 Python 项目配好了 pyproject.toml,所以直接说 “Run uv run pytest”)。这四个词一石三鸟:第一,逼 agent 搞清楚测试怎么跑,之后它几乎必然会主动跑测试确认自己没改坏东西;第二,测试数量是项目规模和复杂度的代理指标,也暗示 agent 想了解项目可以去翻测试;第三,把 agent 调成”测试心态”,后面顺手扩充测试就是自然而然的事。

Agentic manual testing:让 agent 替你做手工测试

测试全绿不等于功能正常——干过自动化测试的人都见过:测试全过,但服务一启动就崩,或者关键 UI 元素压根没显示。自动化测试替代不了手工测试,Simon 坚持要亲眼看到功能跑起来才放心上线。而他发现,让 agent 做”手工”测试同样高产,经常揪出自动化测试漏掉的问题。

具体手段看代码类型。Python 库就用 python -c "..." 直接对解释器灌代码试边界 case;其他语言可以让 agent 在 /tmp 写 demo 文件编译运行(放 /tmp 是防止这些临时文件后来被误提交);JSON API 就一句 “Run a dev server and explore that new JSON API using curl”——“explore”这个词很妙,agent 会自发地把 API 的各个角落都戳一遍。手工测出问题之后,接一句”用 red/green TDD 修”,新发现的 case 就顺势进了永久测试集,闭环了。

Web UI 则交给浏览器自动化。Playwright 是当前最强选项,很多时候一句 “test that with Playwright” 就够;Vercel 的 agent-browser 是专为 agent 设计的 Playwright CLI 封装;Simon 自己还造了个轮子叫 Rodney,走 Chrome DevTools 协议直接控制 Chrome。他的典型 prompt 里藏着三个小心机:写 “use uvx rodney —help”——uvx 会在首次调用时自动装好工具;rodney 的 —help 输出被刻意设计成”agent 说明书”,一条命令就把工具教会了;再补一句 “look at screenshots”,提醒 agent 截图,并用自己的视觉能力去检查页面长得对不对。顺带解决了一个历史顽疾:浏览器测试因为”页面 HTML 一动就碎一片”的脆弱名声,过去大家不敢多写,现在维护成本被 agent 摊薄,这个顾虑大大减轻了。

这部分最有意思的工具是 Showboat——Simon 做的”让 agent 展示工作过程”的工具,核心命令三个:note(往文档里追加 Markdown 笔记)、exec(记录一条命令,执行它,并把输出一并记录)、image(插图,配合 Rodney 截图用)。其中 exec 是防作弊设计:命令和真实输出绑定记录,agent 没法把”它希望发生的事”编进文档里。一句 “Run uvx showboat —help and then create a notes/api-demo.md showboat document and use it to test and document that new API”,你就能拿到一份带真实执行记录的测试文档,既是证据也是文档。

十、理解代码:对抗”认知债”

这部分回答一个被严重低估的问题:agent 写的代码,你自己看不懂了怎么办?

Simon 给这个状态起了个名字:**认知债(cognitive debt)**。很多时候无所谓——查个库转个 JSON 这种代码,猜都能猜对。但当应用的核心变成黑盒,你就没法自信地推理它,规划新功能变难,进度迟早被拖慢,效果跟技术债积累如出一辙。还债的方式只有一个:重建对代码的理解。书里给了两个模式。

Linear walkthroughs:让 agent 给你写代码导览

背景故事很有戏剧性。Simon 用 Claude Code + Opus 4.6 在 Mac 上 vibe coding 了一个 SwiftUI 幻灯片应用,用来做演讲——彩蛋是在演讲结尾揭晓”你们刚看的幻灯片软件本身就是 vibe coding 的产物”。代码发上 GitHub 之后他才意识到:整个项目是他一路 prompt 出来的,他对代码怎么工作一无所知。

于是他开了个新的 Claude Code 会话,prompt 大意是:通读源码,规划一份解释代码工作原理的线性走读;然后学习 showboat,用它在仓库里建一个 walkthrough.md,用 note 写讲解,用 exec 配合 sed、grep、cat 把谈到的代码片段摘进来。最后这个细节是点睛之笔——强制用 shell 命令摘录代码,而不是让模型手抄,从根上掐死了幻觉和抄错的风险。结果是一份把六个 .swift 文件全部讲透的文档,Simon 说自己靠它学到了大量 SwiftUI 应用结构和 Swift 语言本身的知识。他的结论:如果你担心 LLM 拖慢自己学新技能的速度,强烈建议养成这个模式——哪怕一个 40 分钟糊出来的玩具项目,也能变成探索新生态的学习机会。

Interactive explanations:看不懂的算法,让 agent 做成动画

第二个模式更有想象力。起因是 Max Woolf 在一篇文章里用”写一个 Rust 词云生成器”测试 LLM,Simon 一直好奇词云算法的原理,就发了个异步研究任务。Claude Code for web 给他造出了能产出这种图的 Rust CLI:

但报告里写的”阿基米德螺旋布局、每词附加随机角度偏移”让他完全摸不着头脑。先要了一份 linear walkthrough,理解了 Rust 代码结构,但对那个螺旋算法还是没有直觉。于是他再下一城,让 Claude 读完 walkthrough 文档后,做一个动画版词云页面:粘贴文本就开始构建词云,但全程动画演示算法过程,带可暂停、调速、逐帧步进的滑杆,任意时刻能把当前画面导出 PNG。

动画演示:单词逐个出现,小方框展示算法尝试放置的位置,与已有单词重叠就换地方重试

盯着动画看,算法瞬间就”通”了:每个词先在某处试探性放一个框,检测与已有词是否相交,相交就沿着从中心向外的螺旋继续找位置。Simon 评价 Opus 4.6 在构建解释性动画上”品味相当好”。这一章的洞见在于:好的交互式解释从来都是理解复杂概念的利器,只是过去制作成本太高——现在,一个好的 coding agent 可以按需生产它们,无论是解释自己写的代码还是别人写的。

十一、带注解的实战 prompt:看高手怎么下 prompt

这是笔者个人最推荐的部分:Simon 把真实项目的原始 prompt 贴出来,逐句解释为什么这么写。看十篇方法论,不如看一场带解说的实战录像。

案例一:GIF 压缩工具(prompt 是在 iPhone 上敲的)

需求背景:他的博客常放 LICEcap 录的 GIF 动图,体积感人,他最喜欢的压缩工具是 30 岁高龄的 C 语言命令行程序 Gifsicle,但他想要个网页版,能在浏览器里可视化对比不同压缩参数。于是他在 iPhone 的 Claude 应用上,对着自己的 simonw/tools 仓库发了个 prompt,大意是:文件叫 gif-optimizer.html;把 gifsicle 编译成 WASM,做一个网页,拖入 GIF 后用多组不同参数压缩并列出预览,每个预览带体积和下载按钮;再加一套手动参数控件,每个预览带”微调这组参数”链接,点了就把该组参数填进手动控件供继续调;最后跑 uvx rodney —help,用 rodney 测试成果,测试用这个 GIF(给了 URL)。

成品长这样:

GIF Optimizer 工具界面:大虚线框拖放区,下方是 URL 输入框

实际使用动画:拖入 GIF,页面列出多组优化结果,微调参数后下载

逐句拆解里的干货非常密集。第一行只写文件名就够了——agent 跑一下 ls 就明白这个仓库里每个文件是一个独立工具,这个仓库连 CLAUDE.md 都没有,agent 扫一眼文件树就能领会”仓库精神”。“Compile gifsicle to WASM” 这七个词干了巨量的活:把 C 项目编译成 WebAssembly 要过 Emscripten 工具链,以反复试错著称——而 agent 最擅长的就是试错暴力穷举,人类在第五个天书般的编译报错后就放弃了,它们不会。“拖放上传”这种锦上添花的交互,自己写嫌烦,prompt 一句话几乎免费。压缩参数组合他根本没定义,因为经验告诉他 Claude 在这种事上品味够用,不行再改。他自己也承认”微调参数”那段 prompt 写得很笨拙(毕竟是手机上打的),但意图表达到位就够了。

后续的 follow-up prompts 同样精彩。他盯着 agent 干活时发现它在 WASM 编译上下了血本、甚至给 gifsicle 源码打了补丁,于是追加指令:把构建脚本和针对原版代码的 diff 提交到合适的子目录;构建脚本应该把 gifsicle 仓库克隆到 /tmp、切到固定 commit 再打补丁——这样仓库里不用塞 gifsicle 的拷贝,但保留了完整的复现能力。“合适的子目录”这五个字也有讲究:他记得仓库里有放支撑文件的惯例但忘了具体是什么,这么一说,agent 自己找到了 lib/ 目录。最后一条 prompt 是 “Make sure the HTML page credits gifsicle and links to the repo”——他说这只是出于礼貌:给别人的开源项目做 WASM 封装,就该在页面上给原作者署名。这个习惯,值得所有人抄。

案例二:四行 prompt 改完一个功能

第二个案例展示”短 prompt 办大事”。背景:他用一个叫 blog-to-newsletter 的 HTML 工具把博客内容转成 Substack 邮件,最近博客加了种叫”beats”的新内容类型,他想让它也进邮件。Prompt 一共三句:把 simonw/simonwillisonblog 从 GitHub 克隆到 /tmp 做参考;更新 blog-to-newsletter.html,纳入带描述的 beats——参考博客的 Atom everything feed 的做法;用 python -m http.server 跑起来,用 uvx rodney —help 测试,对比邮件内容和 simonwillison.net 首页。

一把过,PR 改得分毫不差。三个技巧值得划线。**“克隆到 /tmp 做参考”——向 agent 解释复杂问题的最好方式,往往是直接让它看相关代码,放 /tmp 是防止参考代码被误提交;agent 在参考仓库里自己读了 Django ORM 的定义,连 beat 类型到显示名的映射表都推导出来了。“参考 Atom feed 的做法”**——他的博客已经用”是否加了备注”来筛选哪些 beats 进 Atom feed,一句”照那个逻辑来”省掉了所有细节描述。用既有代码指代复杂逻辑,是 prompt 的顶级压缩术。**验证机制永远要给**——让 agent 拿真实线上数据对比验证,它就能自己确认改对了。

十二、附录:他天天在用的 prompt

附录目前收录四个日常 prompt,会持续更新,链接里都有可以直接抄的原文。简单介绍下思路:

Artifacts 自定义指令:他常用 Claude 的 Artifacts 做原型,但模型张口就是 React,而 React 要构建步骤,代码没法直接复制去静态托管。所以他的项目级指令是:永远不用 React,只用纯 HTML + 原生 JavaScript + CSS,依赖最少化,外加一套他习惯的代码风格规范(两空格缩进、box-sizing 全局设置、输入框 16px 字号、标题用 Sentence case 等)。

校对(Proofreader):这一条背后有他的一条铁律,值得单独说——他不让 LLM 替他写博客。任何表达观点、用”我”做主语的文字,必须出自他本人;LLM 可以更新代码文档,但带他名字和人格的东西他自己写。LLM 在他写作流程里的角色只有校对:找错别字和语法错误、揪出重复表达、发现逻辑或事实错误、指出可以加强的弱论证、检查有没有空链接占位符。

Alt text(图片无障碍描述):让模型为贴入的图片写无障碍 alt 文本初稿,要求输出在代码块里、单行呈现方便贴进 Markdown,截图上的文字必须精确收录。他通常配 Opus 用,夸它”alt text 品味极好”,会自己做编辑决策,比如只挑图表里最有意思的数字。但他也提醒:这些决策不一定总是对的,初稿仍需要人来编辑把关。

播客金句提取:每次上完播客,他会把转写稿丢给一个定制项目,让模型找出最能体现主题、最有惊喜感、表达最清晰或最”带劲”的引述,直接输出引文,长一点没关系,然后他基于这些写博客。

十三、笔者读完的几点体会

通读下来,有几条”元模式”反复贯穿全书,值得单独拎出来。

第一,一切围绕验证闭环。 Red/green TDD、first run the tests、curl explore、rodney 截图、showboat exec 防作弊……全书一半以上的技巧本质上是同一件事:给 agent 装上验证自己工作的手段。Simon 反复强调,coding agent 和普通 LLM 的分水岭就是能执行代码,而你的 prompt 水平高低,很大程度上取决于你有没有把”怎么验证”也写进去。

第二,上下文是第一稀缺资源。 子代理保根上下文、git log 开局喂上下文、—help 输出设计成 agent 说明书、克隆参考仓库到 /tmp——这些全是上下文管理技术。模型能力在涨,上下文窗口基本没涨,会管上下文的人和不会管的人,出活质量差距会越来越大。

第三,经验要沉淀成系统资产。 LLM 不长记性,但你的 harness 可以。TIL 笔记、上千个 PoC 仓库、compound step 复盘、CLAUDE.md——本质都是把”只需要搞明白一次”的经验,变成 agent 随时可调用的弹药。你的存货厚度,决定 agent 的杠杆倍数。

第四,人的标准一寸不让。 自己没审过的 PR 不准发,带自己名字的文字不让 AI 写,好代码的清单一条不减。这本书最大的价值或许不是任何具体技巧,而是给”AI 辅助编程”立了一套职业标准:真正的问题从来不是 AI 能不能写代码,而是怎么把 AI 写的代码,变成你敢签名负责的代码。

最后提醒一句,这本书每周还在更新 1～2 章,没有任何一章是”定稿”,建议直接收藏原文,隔段时间回去看会有新东西:

“ https://simonwillison.net/guides/agentic-engineering-patterns/

添加微信，备注”LLM“进入大模型技术交流群

如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢

>/ 作者：ChallengeHub小编

>/ 作者：欢迎转载，标注来源即可

内容效果不满意？点此反馈