关于使用LLM代理启动新项目的思考

# 关于使用 LLM 代理启动新项目的思考 来源：https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents 几个月前，我写过关于使用 LLM 代理帮助重构我的一个 Python 项目的文章（https://eli.thegreenplace.net/2026/rewriting-pycparser-with-the-help-of-an-llm/）。首先需要说明的是，这次重构从任何合理标准来看都是成功的；此后我一直能够毫无问题地维护那个项目。 在这篇文章中，我想讨论我最近在代理的显著帮助下完成的另一个项目：watgo（https://eli.thegreenplace.net/2026/watgo-a-webassembly-toolkit-for-go/）。这个项目有很多不同之处；最值得注意的是，它是一个从零开始的项目，而不是重构，并且使用了不同的编程语言（Go）。这篇文章描述了我在这个项目中的经验，以及一路走来学到的一些教训。 ## 过程 这是一个新项目，所以需要大量的设计。我首先与代理一起迭代设计，并草拟了 API。为此，我建议使用一个提交到仓库中的 Markdown 文件（https://github.com/eliben/watgo/blob/main/doc/notes.md）供将来参考。 之后，我开始要求代理按照我认为合理的逻辑顺序编写 CL[\[1\]](https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents#footnote-1)，保持它们小而可审查（更多内容见下一节）。有时很难保持 CL 很小，多轮修订可能会让代理感到困惑；在这种情况下，我会提交 CL，然后回头要求代理根据需要进行修改或重构，用单独的 CL 来完成。在最坏的情况下，如果我觉得方向错误，可以完全回退整个序列（对于更复杂的场景，分支也可能很有帮助）。 这一点值得重申：有时一个单独的 CL 是一个巨大的进步，但需要大量的审查、清理和重构才能变得可行。我遇到过多次代理在一个 CL 中生成了相当于几天工作量的代码，但我随后花了数小时指导它进行清理和重构。总的来说，这仍然是生产力的提升，只是没有一些专家让我们相信的那么多。 ## 让人保持在循环中 鉴于当前代理能力的状态，我认为值得将项目分为两类： 1. 低重要性 / 原型 / 可丢弃的项目，不需要深入理解代码。这些可以"氛围编码"（提交代理代码甚至不审查）。 2. 高重要性的项目，我实际上想要维护；在这里，不建议进行氛围编码，我坚持在提交之前审查并指导代理编写的所有代码（或者提交后不久，如上所述）。 watgo 项目显然是第（2）类的例子：我当然打算长期维护这个项目，所以我坚持要理解代码。除了极少数例外，没有代码能在未经全面审查和往往多轮修订的情况下进入项目。 即使编写代码的成本降低了，维护项目远不止于此。它包括分诊和修复 bug，思考需要做什么而不是如何做，保持代码长期健康，等等。正如 Brian Kernighan 所说（https://www.goodreads.com/quotes/273375-everyone-knows-that-debugging-is-twice-as-hard-as-writing）： > 每个人都知道调试比最初编写程序要难两倍。所以如果你在编写时尽可能地聪明，你将来该如何调试它？ 也许在某个时候，代理会变得足够好，使得第（2）类项目可以完全自主地实现和维护。也许吧。但我们肯定还没有到那一步。我的直觉是，要达到那一步需要跨越 AGI 线[\[2\]](https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents#footnote-2)，在那之后，我们世界中的很多事情就不再确定了。 ### 实用的工作流程 如果你使用代理发送一个实际的 PR 并且只审查那个 PR，那么很难有足够的纪律性来进行彻底的审查。我发现以下方法更可靠： 我使用在本地仓库中运行的 CLI 代理，并要求它在那里更新代码。与此同时，我在同一个项目中打开一个 VSCode 窗口，在那里我可以： 1. 使用 VSCode 的差异视图审查代理的更改 2. 如果需要，自己进行一些调整和代码更改 一旦我对更改满意，我手动创建一个提交。 ## 保持 CL 的小型化 如上所述，以小块的方式逐步推进至关重要，CL 要足够小，以便人类在一次审查中完全理解。每天提交数千行代码快速前进非常诱人，但这种诱惑必须避免。使用代理编码就像快速阅读；是的，你取得了更多进展，但理解力会随着速度加快而下降。 特别是在重构方面，代理仍然会选择通往目的地的最短路径。重要的是要始终引导它们思考"大局"，找到所有应该将 X 改为 Y 的实例，而不仅仅是审查中注意到的单一地方。这就是为什么有时在完全同意所有内容之前提交一个 CL 是可以的，之后再回过头来进行几轮重构。当与代理结对编程时，源代码控制效果惊人地好。 ## 测试策略 这是每一篇"如何成功使用 AI"文章中都讨论的关键点，但仍然重要到需要在此重申：扎实的测试策略对于成功绝对至关重要。当代理有一个可靠的测试套件来测试它们的代码时，它们会产生——到目前为止——最好的结果。 对于 pycparser（https://github.com/eliben/pycparser）的重构，我有一个庞大的现有测试套件。对于 watgo（https://github.com/eliben/watgo），我做的第一件事就是思考如何根据我的需要调整 WASM 规范（https://github.com/WebAssembly/spec/）和 wabt 项目（https://github.com/WebAssembly/wabt）的测试套件。 如果你的项目没有这样的测试可以依赖，这应该是你的首要任务——找到一个，或者从头开始构建一个。但要小心自我强化循环；信任代理同时用于测试和被测试的实现是危险的。 ## 语言选择——Go 用于代理编写的项目 Go 是一种非常适合代理编写的语言，因为它的设计目标是人类易读。Go 最大的优势恰恰是使得审查代理代码的体验如此积极的原因： - Go 变化非常不频繁，所以你不需要像其他语言（比如 Python 和 TypeScript）那样经常疑惑"我们是否在使用最现代/惯用的方法"或"这到底是什么构造"。 - 在 Go 中，完成同一件事的方式相对较少，进一步降低了脑力负担。 - 标准库丰富，不需要时刻关注当下大家都在用的包。 - 总的来说，Go 是为可读性设计的，具有温和但依然强大的类型系统、统一的格式、显式的错误传播和已经为你做好的有主见的选择。 由于人类在使用代理时花费的大部分时间是*阅读*而不是*编写*代码，这些效果叠加起来产生了出色的体验。回想一下关于某些语言优化了可写性（Perl）而其他语言优化了可读性（Go）的讨论？好吧，当与代理一起进行项目时，我们生活在一个 99% 阅读 vs. 1% 编写的世界里，所以这真的很重要。 鉴于本文前面提出的观点——即通过理解和审查代理的所有设计选择和代码来让人保持在循环中——我发现这一方面至关重要。 ## 最后思考 如果你正在处理一个对你来说完全陌生的主题，我强烈*不*推荐本文描述的方法。要真正学习一些东西，你必须自己从头做起，阅读、设计、编写代码。代理并不会改变这个基本事实；即使在代理出现之前，如果你想学习 X，从 Stack Overflow 或其他项目复制显然不是正确的方法。同样，虽然代理可以作为一种学习辅助工具，但它们不能*替你*学习。 作为推论，初级工程师在依赖 LLM 时应该*极度谨慎*。没有什么可以取代来之不易的经验以及学习新的、有挑战性主题时的汗水和泪水。学习本来就应该很难；如果太容易，你很可能并没有真正学到东西。 对于高级工程师来说，代理是一种福音；这是一个提高生产力、避免无聊工作、摆脱拖延的好工具；但只有在明智地使用时才如此。 --- [\[1\]](https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents#footnote-reference-1) CL 代表 Changelist，也称为"补丁"或"差异"——基本上是一个独立的提交，涉及一个或多个文件。这个词源于源代码控制系统 Perforce 和 Subversion。 [\[2\]](https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents#footnote-reference-2) 编程是思想的最终实现；如果机器可以比人类更好地设计、生产、维护和理解代码，那就意味着它们可以开始自我改进，这就是奇点（https://en.wikipedia.org/wiki/Technological_singularity）的定义。