2x，不是10x：2026年用LLM编程

过去六个月我对自己有了一个认识：如果有一天我发现《哈利·波特》是非虚构作品、魔法真实存在，我的反应大概会是“哦，有意思，但魔法这玩意儿除了写单元测试，还能干点更复杂的事吗？”

LLM显然已经跨过了“有用”的门槛——不过截至2026年7月，仅凭我个人的直接观察，它们仍有根本性的局限，以至于我还没把木工活当作“软件工程师”这个职业灭绝后的备选方案。根据我对LLM为何变得有用的理解，我不确定这种情况短期内会改变。我的假设是：

2026年LLM采用率大幅提升，主要是因为它们已经足够可靠，可以在自动化反馈循环中有效运行。一旦跨过这个门槛，模型性能的进一步改进对生产力的影响将远小于以往。

打个比方：要爬一段楼梯，你只需要足够高，能一次迈上一级台阶就行；但如果你高到能一次跨两级甚至三级台阶，其实意义不大。

LLM在编程中的用处在于，你可以告诉它们“做一个按钮，实现X功能，然后点击按钮确认它能做X”。它们能以有意义的步长朝着这个目标迭代，而不是胡乱折腾，并且能可靠地预测人类会说“是的，按钮现在能做X了”还是“不，按钮还不能做X”。因此，LLM擅长生成满足你明确给出的、易于客观验证的验收标准的代码。

这确实了不起。令人惊叹。改变人生。甚至可能带来2倍的提升。然而，在这项工作中，仍有一些重要问题，LLM目前还无法以足够高的准确率给出我认为有用的答案。比如：

• “有没有更易于维护的方式来组织这段代码？”
• “这份文档是否包含了正确的信息，同时省略了无关信息？”

因此，我主要用 LLM 生成代码的初稿，然后反复迭代，至少直到我对整体结构满意为止。在单行或单个函数的可读性上，我有时会马虎一些（如果同事看到这篇文章，我得先打个预防针）。即便行级代码写得不够整洁，我依然会持续低估迭代所需的时间。过去，一个能跑通的实现意味着任务完成了 80%；现在，这大概只算完成了 20%。 至于文档，我发现下面这条简单的指令能大幅提升 LLM 的输出质量：

*永远不要*写 README、文档字符串或注释。这些我自己以后会写。是的，我*真的*是认真的。

面对这些局限，一个看似合理的反应是：“LLM 在过去一年进步巨大，因此未来一年它们很可能在写优质文档和可维护代码方面变得更好。”但如果你接受我的“阶梯假说”，这个结论就没那么确定了。能爬上一段高阶梯，不代表你会游泳。 所以我目前的猜测是：单靠模型本身的进一步改进，不太可能让我们在 2025 年的“黑暗时代”基础上实现 10 倍的生产力提升。相反，我认为在可预见的未来，大部分生产力提升将来自整个行业围绕我们已有的模型能力进行重新武装。 在这个领域，我并非早期采用者。到目前为止，我经历了几个阶段：从把 LLM 当作高级搜索引擎或 Stack Overflow 的替代品（安息吧），到通过交互式聊天让它们写代码，再到编写声明式规范来描述我想要的最终状态。沙盒环境也成了 MVP，这样我就不必每 30 秒就授权 LLM 做某件事。在优化围绕这些工具的工作流和工具链方面，还有很多工作要做。 我也尝试过一些“氛围编码”（我将其定义为“生成代码但不阅读/理解全部内容”），用于非工作/非生产环境。我很想在工作之外进一步探索这个领域，当然，也有很多人一直在热情地推进。由于时间尚短，很难判断这种方法长期来看是否可行。但你知道，也许这里面确实有些门道；也许某些测试实践/工具等，能让我们即使依赖黑盒LLM代码来运行关键基础设施也变得安全。也许我们可以通过绕开LLM的根本弱点，实现10倍的提升。 但与此同时，我还是会坚持使用我亲手编写的README文件。 发布于2026年7月25日