Simon Willison：我是怎么用 LLM 帮我写代码的

很多人抱怨用 LLM 写代码没用，Simon Willison 的观点是：这件事远不如大家想得那么直观，里面藏着大量需要积累的经验和技巧。这篇长文是他自己摸了两年多的完整实战手册，从设定预期到具体的工作流，一条条讲清楚。

下面按原文结构做完整精译导读，关键论点配原句直引，建议结合上方链接读英文全文。

Willison 把 LLM 看作「花哨的自动补全」，本质是在预测 token 序列；该把它当成对你能力的增强，而不是替代。他给的心智模型是：一个过度自信、但快如闪电的结对编程搭档。

它会犯错，有时细微、有时严重，但别像对人那样去拟人化它的失误。重要的是记下它做不到的那些任务，这些会成为有价值的参照点。如果你指望它不靠你出一点力就完美实现项目，很快就会失望。

训练截止日期决定了模型知道哪些库和技术。很多 OpenAI 模型训练数据截到 2023 年 10 月或 2024 年 5 月，截止之后的重大破坏性更新它不会知道。

应对策略：刻意选稳定、流行、训练数据里例子多的库，套用「无聊技术」原则，只在真正独特的地方创新、其余用成熟方案。你仍然可以用更新的库，但要在 prompt 里喂它最新的用法示例。

管理上下文是用好 LLM 的核心手艺。上下文包含当前对话的全部历史（所有提示和回复），开一个新对话就把上下文清零。像 Claude Projects 这类工具可以预先灌入大量上下文，也能直接接 GitHub 导入代码；Cursor、VS Code 则会自动把编辑器里的内容带进上下文。相比之下，ChatGPT、Claude 的网页端能让你更清楚地看到「到底有哪些东西在上下文里」。

一个常用技巧：先让它写一个最简版本，再逐步加复杂度；或者把现有代码丢进去做种子，再让它在此基础上改。他举过一个 JavaScript OCR 的例子，就是先给了几个能跑的示例当灵感。

项目开头先做一轮调研，用「Rust 里有哪些 HTTP 库可选？」这种 prompt 让它列选项、给用法示例、做对比。受训练截止限制，最新的库可能不会出现，这通常可以接受，目标是找到稳定、生态成熟、被充分测试过的方案。

最好的做法是做一个能跑的原型，证明关键需求确实能满足，而用 LLM 几分钟就能搭出这种原型。

写生产代码时切换到「专断模式」：把 LLM 当成一个雇来打字的数字实习生，给它详细规格、甚至精确的函数签名（它对函数签名示例反应很好），并明确指定技术选型。因为它能自动补全很多细节，用英文下指令往往比手敲还快。

可以要求它给出完整实现：异常处理、docstring、类型标注一应俱全。他举例一个异步下载数据库的函数 15 秒就写完，接着追一句「用 pytest 给我写测试」同样好使。这里他态度很硬：代码必须正确。

测试这件事不能外包给 LLM。作为开发者，你有责任在交付前亲眼看到代码跑起来，这要求你强化手动 QA 的习惯。

无论有没有用 LLM，测试都一样关键，是交付里不可省的一环。他的原话很干脆：没看它跑过，就不算一个能用的系统。

LLM 从不会嫌你让它重构。常用的追问比如：把重复代码抽出来、用字符串方法替代正则。第一版结果很少是最终实现，多轮迭代是正常且预期之中的。

一个糟糕的初版是起点，不是失败。迭代式打磨本身就是核心技巧。

他选主力工具的首要标准，就是能否安全地执行代码并快速迭代。安全沙箱类：ChatGPT Code Interpreter（在 Kubernetes 沙箱里跑 Python、不能对外联网）、Claude Artifacts（锁死 iframe 里跑 HTML+JS+CSS）、ChatGPT Canvas（类似 Artifacts 的较新功能）。

风险更高、但能力更强的一类：Cursor 的 Agent 功能、Windsurf、Aider（开源，近期 80% 以上的发布是它自己写的），以及 Anthropic 新出的 Claude Code。

vibe coding 是 Karpathy 大约一个月前造的词：完全拥抱过程、忘掉代码细节，随口说「把内边距减半」、不读 diff 全部接受、报错直接复制粘贴不解释。它适合扔了就忘的周末项目，但同时是极好的学习法，能加速你对模型能力边界的直觉，也很好玩。

他自己的 simonw/tools 仓库就有 77 个 HTML+JS 小应用和 6 个 Python 应用，全用 LLM 提示搭出来，每周做好几个，托管在 tools.simonwillison.net，commit 历史里还存着对话记录。学 LLM 最好的办法，就是去玩它。

他用 Claude Code 给 tools 仓库做了个 colophon（版权说明）页，记录每个工具是怎么造出来的。整个过程花了 0.61 美元、约 17 分钟（API 实际耗时约 5 分半）。他一步步喂提示：先写脚本抽出每个 HTML 文件对应的 commit 链接、输出成 JSON；再修正成抓完整 URL、再加上完整 commit 信息；接着写脚本把 JSON 渲染成移动端友好的 HTML 页面；之后一路修 bug、加时间显示、调排序。

第二个会话处理部署：写 GitHub Actions workflow，在部署前先跑 gather_links.py 和 build_colophon.py。中间踩了个坑：初次部署和默认的 Jekyll 部署撞车，最后把 GitHub Pages 的源从「Deploy from a branch」改成「GitHub Actions」才解决。这一段表明，真实项目里 LLM 帮你跑通主干，但收尾常常需要你懂底层。

没有什么能替代人的直觉和经验。该出手时就出手，有时自己上比继续 prompt 更快。LLM 复制不了你多年积累的领域专长，正因为他懂 GitHub Actions，上面那个部署的坑才能很快手动解决。

知道「什么时候该退出 LLM 工作流、自己接管」，本身就是一项有价值的技能。

colophon 那个项目从想法到上线不到半小时，要不是有 LLM，他根本不会花时间去做。所以 LLM 最大的价值，不只是把活干得更快，而是让你能做那些本来「不值得专门花时间」的项目，从而更有野心、也学得更多（比如顺手学会了 GitHub Actions），形成复利式的学习效应。

但他强调这一切建立在已有专长之上：他有 25 年以上的职业编程经验，那些 prompt 其实并不新奇，只是把他已知的模式口述出来。换个完全不熟的领域（比如 Linux 内核驱动），打法会完全不同。LLM 放大你的能力，放大多少取决于你本来的水平。

这是个低风险用法，错了顶多耽误一会儿，特别适合初次摸一个陌生代码库。他的工作流：把仓库克隆到临时目录，用 files-to-prompt 把所有文件收集起来，管道给 llm 工具，配上「以 markdown 给出架构概览」的系统提示，就能拿到一份描述源码结构和依赖的详细文档，他每周都用好几次。

他举例分析 monolith 工具时，很快搞清它用了 reqwest、html5ever 等库，还摸到一个关键限制：不会执行 JavaScript。他说，这种用法的替代方案往往不是「多花点时间」，而是「干脆放弃满足自己的好奇心」。

作者 · Simon Willison（Django 联合创始人、独立开发者）

原文 · simonwillison.net

本页为 GoodVibe 对原文的中文整理，著作权归原作者所有；建议点击上方链接阅读原文全文。