2026 年 LLM 编程：2 倍而非 10 倍
2x, not 10x: coding with LLMs in 2026
过去半年，我逐渐意识到 LLM 虽然已跨过实用门槛，但离彻底取代软件工程师还差得远。2026 年，LLM 的普及主要得益于它们能可靠地运行在自动化反馈循环中，而非模型性能的单纯提升。这就好比爬楼梯，只要能迈上一步就足够，能一次迈三步反而没那么重要。目前，LLM 擅长生成符合明确验收标准的代码，但在代码结构可维护性和文档撰写上仍显笨拙。我现在的做法是让 LLM 生成草稿，然后由我进行大量迭代，甚至明确指令让其不要写文档。未来的生产力提升不会仅靠模型变强，而取决于我们如何围绕现有能力重构工作流。所谓的 10 倍效率提升，或许需要绕过 LLM 的固有弱点，而非等待技术奇迹。
能够爬上高高的楼梯，并不意味着你就能游泳。
HN 评论区
27- lazopm
在我看来，你应该根据自己对特定领域的熟悉程度，以及是否由你负责/理解该领域，来调整使用 LLM 的工作方式。以下是我的感受：
* 学习阶段：0.5 倍 - 1 倍。我会把系统提示词改成“教师模式”，虽然牺牲了当下的生产力，但真正学会这个系统/工具后，后期会有丰厚回报。随着我越来越自信，我会慢慢放宽这个提示词。
* 具备工作知识：2 倍 - 3 倍。一旦我上手熟练了，就能感受到不错的生产力提升。大部分时间花在了规划阶段。这是我处理那些我不完全负责或不怎么关心、只需把活干完的领域时的模式。
* 精通：10 倍以上。我做 Web 前端已经 12 年多了，我可以快速审查计划和实现方案，对于我的初始提示词，我已经清楚大部分想要构建的内容。
1 倍 == 我使用 AI 之前的速度
- gashad
这让我想起了最近在《Harness Engineering is not Enough: Why Software Factories Fail》(https://www.youtube.com/watch?v=Ib5GBkD555M) 中看到的主题（警告：最后 3 张幻灯片看起来像是广告）。我喜欢的一个点是，Dex 展示了一个他匆匆带过的小图表，显示软件开发由以下部分组成：
- 25% 规划及与其他团队对齐
- 25% 编码
- 25% 测试/验证
- 25% 代码审查/返工
其中一个论点是，代理式编码（agentic coding）能大幅加快编码部分的速度。所以也许编码速度能提升 2 倍。但这对于软件工程师所做的一切工作总量来说，提升幅度很小。
- watso
你仍然需要知道自己在做什么。这来自于多年亲手操作的经验。对于当前和未来的初级开发者来说，这种必要的经验将从何而来？