开发者宣布弃用LLM编程：一场关于代码自主性的讨论

当一位开发者说“我不再用LLM写代码”

在Hacker News上，一篇题为《I will not be using LLMs in my coding》的帖子引发了关注。尽管原文只有标题和极少的信息量（5分、0评论），但标题本身已经触及了当前开发者社区中一个持续升温的议题：AI编程助手到底该在多大程度上介入我们的工作流。

这不是一个孤立的声音。随着LLM驱动的代码补全、对话式编程工具快速普及，一部分开发者开始主动划清边界。他们并非否认工具的效率价值，而是对“默认使用”的行业惯性提出质疑。

拒绝的理由可能是什么

虽然原帖没有展开论述，但从开发者社区的常见讨论来看，弃用LLM编程的动机通常集中在几个方向。

代码理解与所有权

当代码由模型生成或大幅补全时，开发者对它的理解深度会打折扣。读懂一段自己没写过的逻辑，和亲手推导出这段逻辑，在调试和维护阶段的体验完全不同。部分开发者担心长期依赖会让“读懂代码”的能力退化。

对输出质量的审慎态度

LLM生成的代码可能看似合理却暗藏错误，尤其是在边界条件和领域特定逻辑上。对于追求确定性的系统级开发，逐行验证模型输出的成本，有时并不低于自己动手写。

工作流与心智负担

引入LLM意味着引入新的交互环节：写提示词、审查建议、判断是否采纳。对习惯沉浸式编码的开发者来说，这种频繁的上下文切换本身就是一种负担。

LLM（Large Language Model，大语言模型） 是当前AI编程工具的核心技术基础，指在海量文本语料上训练、具备自然语言理解与生成能力的深度神经网络模型，参数量通常在数十亿至数万亿级别。在编程场景中，LLM通过代码语料训练获得根据上下文补全或生成代码的能力。与传统IDE的基于语法规则的自动补全不同，LLM输出具有概率性——同一提示可能产生不同结果，且模型可能生成语法正确但语义错误的代码（即“幻觉”）。理解这一点，有助于解释为何开发者会对模型输出保持审慎：LLM本质上是基于统计规律预测下一个token，而非真正“理解”代码逻辑。

上下文切换成本（context switching cost） 是认知心理学中的一个概念，指人在不同任务或思维模式之间切换时产生的认知损耗。在编程中，沉浸式编码依赖开发者维持一个完整的“心智模型”——对当前问题、代码结构和设计意图的连贯理解。引入LLM交互会打断这一状态：写提示词要求从“实现逻辑”切换到“描述需求”，审查建议又要求从“生成”切换到“批判性评估”。研究表明，频繁的上下文切换会显著降低深度工作效率。这正是部分开发者认为LLM反而增加心智负担的原因——审查模型输出所需的认知资源，可能并不亚于自己动手编写。

这不是反AI，而是选择权

需要区分的是，“不使用LLM编程”和“反对AI工具”是两回事。前者是一种个人工作流选择，后者才是立场表态。

开发者社区对这类选择的态度正在变得更为包容。工具的价值不在于所有人都用，而在于需要的人能用到、不需要的人不被强制。一个健康的生态应该同时容纳“全流程AI辅助”和“纯手写代码”两种实践。

对AI编程工具的一点启示

这类声音对工具开发者同样有价值。它提醒产品团队：效率提升不是唯一维度，信任感、可控性和对开发者习惯的尊重同样影响采纳意愿。

如果LLM编程工具希望覆盖更广泛的开发者群体，降低“审查成本”和“心智切换成本”可能比单纯提升生成速度更重要。让开发者能精确控制介入范围，比如只在特定文件、特定任务中启用辅助，或许是更务实的方向。

可控性（controllability） 在人机交互与AI工具设计中，指用户对系统行为、介入范围和输出结果的可预期与可调节程度。对于AI编程工具而言，可控性体现在多个层面：能否只在特定文件或函数中启用补全、能否设置建议的触发阈值、能否明确区分AI生成与人工编写的代码段。可控性不足会直接侵蚀信任感——开发者若无法预判工具何时介入、介入多深，就倾向于整体关闭而非精细管理。这与自动驾驶的分级理念类似：用户需要的是可逐步信任的渐进式授权，而非非此即彼的开关。降低审查成本与心智切换成本，本质上都是提升可控性的具体路径。

小结

一条只有标题的Hacker News帖子，折射出的是开发者对AI编程工具边界的持续思考。选择不用LLM写代码，不是技术保守，而是对自身工作方式的清醒认知。在AI工具高速演进的当下，保留“不使用”的权利，本身就是生态成熟的标志。