使用 LLM 智能体启动新项目的思考Thoughts on starting new projects with LLM agents

几个月前，我曾撰文介绍过如何使用 LLM 智能体来协助重构我的一个 Python 项目。首先必须承认，无论从哪个合理的标准来看，那次重写都是非常成功的；自那以后，我一直能够顺利地继续维护该项目，没有出现任何问题。

在这篇文章中，我想探讨另一个最近在智能体的大力协助下完成的项目：watgo。在这个项目中，许多情况都有所不同；最明显的是，这是一个从零开始构建的新项目，而非代码重写，并且使用了另一种编程语言（Go）。本文将分享我在开发该项目时的经验，以及在此过程中汲取的一些教训。

开发流程

作为一个全新项目，它需要进行详尽的设计。我先是拿着一份 API 草图，与智能体一起对设计进行了迭代。为此，我建议将设计过程记录在一个 Markdown 文件中，并将其提交到代码仓库里，以备日后参考。

之后，我开始让智能体按照我认为合理的逻辑顺序来编写 CL [1]，并确保这些 CL 体积小巧且易于审查（下一节会详细讨论这一点）。有时候，想要保持 CL 足够小巧并不容易，而且多轮修改可能会让智能体感到困惑；在这种情况下，我会先提交该 CL，然后回过头来让智能体根据需要，通过提交独立的 CL 来修改或重构代码。在最坏的情况下，如果我觉得我们的方向搞错了，可以把整个提交序列全部回滚（对于更复杂的场景，使用分支也能起到很好的作用）。

这一点值得反复强调：有时候，单个 CL 就能带来巨大的飞跃，但为了让它真正可用，需要经过大量的审查、清理和重构。我遇到过好几次这样的情况：智能体在单个 CL 中生成了相当于好几天工作量的代码，但随后我却要花上好几个小时来指导它进行清理和重构。总的来说，这确实提高了生产力，只是并不像某些专家试图让我们相信的那么夸张。

保持人工参与

鉴于目前智能体的能力水平，我认为有必要将项目划分为以下两类：

watgo 项目就是第（2）类的典型例子：我当然打算长期维护这个项目，因此我要求代码必须是我能完全看懂的。除了极少数例外，任何代码都必须经过完整审查，并且通常要经过多轮修改才能合入。

即使编写代码的成本下降了，维护一个项目所需的工作也远不止于此。维护工作包括对 Bug 进行分类和修复，是去思考“需要做什么”而不是“怎么做”，是随着时间推移保持代码的健康状态等等。正如 Brian Kernighan 所说：

大家都知道，调试代码的难度是编写代码的两倍。因此，如果你在写代码时已经聪明到了极点，又怎么可能还有能力去调试它呢？

也许在未来的某个时刻，智能体会变得足够强大，能够完全自主地开发和维护第（2）类项目。也许吧。但我们目前显然还没达到那种水平。我的直觉是，要实现这一目标，就必须跨过 AGI 的门槛 [2]，而一旦跨过那道坎，我们这个世界上就几乎没有什么是确定无疑的了。

实际工作流

如果你让 agent 直接提交真实的 PR，而自己只负责审查 PR，这就很难保持自律去进行真正彻底的代码审查。我发现以下方法更加可靠：

我会在本地代码仓库中运行一个 CLI agent，并让它在本地直接修改代码。同时，我会在同一个项目中打开一个 VSCode 窗口，以便：

一旦对修改感到满意，我就会手动创建一个 commit。

保持 CL（变更列表）精简

如前所述，我们必须不断地小步快跑，保持 CL 足够小，确保人类审查者能够单次完整理解。每天狂飙突进提交数千行代码的做法极具诱惑力，但必须克制这种冲动。使用 agent 编程就像快速阅读：没错，你的进度确实变快了，但速度越快，对代码的理解力就越容易受损。

特别是在重构时，agent 往往倾向于采取最直接的“捷径”来达成目标。因此，引导它们时刻保持“全局观”至关重要——要找出所有适合将 X 优化为 Y 的地方，而不仅仅是代码审查时偶然注意到的一处。正因如此，有时即便你还没完全认可所有细节，也可以先提交一个 CL，之后再回过头来进行多轮重构。在与 agent 结对编程时，版本控制系统的作用堪称完美。

测试策略

几乎每篇探讨“如何利用 AI 取得成功”的文章都会强调这一点，但由于它实在太过关键，有必要在此再次重申：一套坚实的测试策略对于项目的成功绝对至关重要。当拥有完善的测试套件来验证代码时，agent 毫无疑问能发挥出最佳效果。

在重写 pycparser 时，我已经有了一套庞大的现有测试套件。而在开发 watgo 时，我做的第一件事就是构思如何将 WASM 规范和 wabt 项目的测试套件改造为我所用。

如果你的项目没有现成的测试用例可供依赖，那么当务之急就是寻找或者从零开始构建一套。不过，务必当心“自我强化循环”的陷阱：将测试代码和业务实现统统交给 agent 去编写，是非常危险的。

编程语言选择——为 agent 编程项目首选 Go

Go 是一门非常适合让 agent 来编写的语言，因为它在设计之初就高度重视人类的可读性。Go 语言最大的优势，恰恰也是让审查 agent 生成的代码成为一种愉悦体验的原因：

既然人类在使用 agent 时，绝大部分时间都花在阅读而非编写代码上，上述这些优势叠加在一起，便带来了极其出色的开发体验。还记得关于编程语言设计初衷的讨论吗？有些语言针对“易写性”进行了优化（如 Perl），而另一些则针对“易读性”进行了优化（如 Go）。在借助 agent 进行开发时，我们的工作模式变成了 99% 的时间在读代码，只有 1% 的时间在写代码，因此语言的可读性就显得尤为关键。

鉴于本文早先提出的观点，我认为这一点至关重要——即通过理解和审查智能体所有的设计选择与代码，保持人类的监督与介入。

结语

如果你正在研究一个对你来说完全陌生的领域，我强烈建议不要采用本文介绍的方法。要想真正学到东西，你必须自己从零开始，亲自去阅读、设计和编写代码。智能体并没有改变这一基本事实；甚至在智能体出现之前，如果你想学习某项技术，直接从 Stack Overflow 或其他项目里复制代码显然也不是正道。同理，虽然智能体可以作为学习的辅助工具，但它们无法代替你学习。

由此推论，初级工程师在依赖大语言模型（LLM）时应格外谨慎。任何东西都无法替代来之不易的经验，也无法替代在学习充满挑战的新知识时付出的汗水与心血。学习本来就是一件辛苦的事；如果觉得太轻松，那你大概率并没有真正学到什么。

对于高级工程师而言，智能体是一大福音。它是一个极佳的工具，能够提高生产力、免除枯燥的工作，并帮你摆脱拖延状态；但前提是必须审慎地加以使用。