停止生成，开始思考
Source: Hacker News
by Sophie Koonin
8 February 2026
Tags: ai, engineering
在我的职业生涯中，我觉得自己在跟进行业新动态方面做得相当不错：参加会议，关注（后来还结交了！）一些编写规范的非常聪明的人，成为在 Slack 上向同事分享 CSS 或 JS 新特性新闻的那个人。在内部工具上工作，只需要关注最新的 Chrome，并在生产应用中玩转仍在实验阶段的锚点定位，这种感觉真的很棒！
因此，当我发现自己好像有被甩在后面的危险——好像错过了什么——时，我感到非常不安。尽管我不喜欢这种感觉，但越来越多的人对 LLM 生成的代码投入了巨大的热情，我实在是想不通。
我已经使用 Copilot——以及最近的 Claude——把它们当作一种“辣味自动补全”和偶尔的调试助手，但每当我尝试让它们做一些稍微聪明的事时，它们就会彻底崩溃。别误会，我知道很大一部分原因是我使用方式不对，但我很难为花大量时间去完善向机器提问的技巧辩护——这本可以在更短的时间内由我自己完美完成。
你必须提供足够的上下文——但不能太多，否则它会超负荷。你需要编写冗长的提示，像在安抚一个脆弱的自尊心一样对 AI 助手说“你是分布式系统专家”，仿佛它是一个不安全、平庸的软件开发者。
或者我可以直接写代码，所花的时间比整个过程都要少。
随着越来越多的人生成代码而不是自己编写，我不禁想，为什么工程师们如此乐意放弃工作中最有价值的部分（编码），而只留下枯燥的部分（代码审查）。
也许人们喜欢为计算机写角色扮演式的指令；我不知道。但我觉得人们愿意且自豪地把生成的代码塞满自己的产品，这很危险。
下面分享几条我在表达对此担忧时遇到的论点。
Reference: “Spicy autocomplete” – The Guardian
“这是我们时代的工业革命！它就像机械化的再现。”
与工业革命的类比
工业革命对气候变化贡献巨大——参见 OER Project analysis。
如今，AI 数据中心的能源消耗惊人；IEA 关于 AI 驱动需求的报告 突出了其规模。
- 并非所有电力都来自化石燃料，这比19世纪的模式有所改进。
- 然而，我们仍在大量浪费资源用于琐碎的产出——例如，病毒式传播的 “虾耶稣” 图像很快被 Meta 禁止。参见 Business Insider 报道。
快时尚类比
机械化让商品更便宜、更易获取，但也导致质量的“向下竞争”。现代例子包括：
- SHEIN —— 你可以用不到一杯咖啡的价格买到一条极易燃的裤子。
- 将工厂外包到欠发达经济体，在那里低工资和薄弱的劳动权利提升了利润。
生成的代码行为类似快时尚：
- 初看可能还算可接受，但在细致审查下常常崩溃。
- 经常抄袭已有设计，正如 Sunday Post 对高街抄袭者的报道 所述。
- 环境影响显著。
关键区别：确定性 vs. 非确定性
- 机械化 用机器取代人力，机器能够可靠地执行相同的任务。一个生成模板代码的 codemod 或脚本就是很好的例子——如果出现问题，人类可以检查机器并诊断原因。
- 大语言模型（LLM）输出 是 非确定性的，其内部工作机制不透明。一个每次产生不同结果、且常伴随幻觉的机械化过程，几乎没有实用价值。
简而言之，虽然 AI 的崛起在规模和资源需求上与工业革命相似，但其非确定性特征和环境足迹带来了必须应对的独特挑战。
“LLM 只是一层新的抽象，就像高级编程语言相对于汇编语言的关系。”
的确，写 Java 或 Go 意味着我再也不必去学习汇编。我能接触到的最接近汇编的东西，莫过于编织图案。
我们编写软件的方式已经在需要思考的内容上发生了演变（取决于你选择的语言）：
- 我不必考虑垃圾回收或内存分配，因为运行时会为我处理这些。
- 我仍然必须考虑编写在我们现有系统更大背景下具有架构意义的高效代码。
- 我必须考虑我构建的软件会如何影响关键路径，并在可维护性与交付速度之间进行权衡。
- 在构建 Web 应用时，我们必须考虑浏览器兼容性、可访问性、安全性和性能。
LLM 造成最大破坏的地方
我见过的最大问题是工程师把本该投入软件开发的思考外包给了 LLM。LLM 无法对系统架构进行推理，因为 它们不会思考——它们不具备思考能力。如果我们停止思考，而模型也不思考，那么 就没有人思考。没有人经过深思熟虑设计的软件，永远不可能产生好结果。
在地平线丑闻之后——无辜的邮局员工因邮局软件的漏洞被误判为盗窃而入狱——我们比以往任何时候都更需要对自己的软件进行思考。我们需要软件的可追责性。
有十三人因邮局系统的这些漏洞而自杀。
我们糟糕的代码才是根本问题
“但现在的人类开发者写的代码不可访问、性能差、充斥着 JavaScript！这有什么不同？”
正是如此。LLM 在（往往未经我们明确同意的情况下）被训练在我们所有的烂代码上，而我们已经教会它们这就是应该输出的内容。因此，它们：
- 重复人类的错误。
- 随后在同样有缺陷的输出上再次训练，形成一种有时被称为人类蜈蚣认知论的反馈循环（参见 Maggie Appleton 关于 AI Dark Forest 的文章）。
我们人类写的代码本身就不够好，何况去期待一个写得更快却同样糟糕的工具。
如果你以为我们已经做得够好了，那其实并没有：
- 辅助技术的使用者经常因为不可访问的界面而受挫。
- 在网络状况极差的地区（或在英国任何城市依赖移动数据的用户）会遭遇性能问题。
- 种族歧视仍然存在于人脸识别软件，甚至在普通的手干手机等设备中也能看到。
- 邮局员工正是因软件缺陷而付出了代价。
我们没有在学习、改进、构建更好的软件，而是把我们的错误外包给了一个不具思考能力的算法。
四只眼好，两只眼坏
Jessica Rose 和 Eda Eren 在 FFConf 2024 上做了精彩的演讲，主题是 AI 编码助手让我们失去技能的危险。下面这张幻灯片尤为突出：
要点
- 审核由人编写的 PR 时会有一定的信任度，因为同事已经对代码进行过推理。
- 开源维护者已经开始收到大量由 LLM 生成的低质量 PR。
- 即使代码是由 LLM 生成，贡献者仍需对其提交负责。
- 审核者同样承担责任，因此仍然有两对眼睛在审查变更。
“单眼”工作流的风险
一些公司展示了像 Claude 这样的工具，它们可以从 Slack 对话中直接生成 PR。工作流大致如下：
- 开发者让 Claude 做一次修改。
- Claude 自动生成代码并打开一个 PR。
- 审核者…
roves the PR.
如果审阅者是唯一查看此更改的人，我们就 失去了一双眼睛，并且降低了团队内部的共享上下文。
审查 PR 不仅仅是为了捕获错误；它还在于 共享对代码及其更改背后理由的理解。
完全跳过 PR、直接提交到主分支的团队，只有在工程师 持续结对、保持共享上下文的情况下，才能在大规模时实现运作。
要点
- LLMs 是工具，而不是取代人类推理的手段。
- 问责制 必须由编写、审查和发布代码的人承担。
- 保持 多层审查（“四眼”原则）以维护共享理解。
- 现在就投资 更好的编码实践；否则，我们只会加速当前错误的传播。
我并非反进步，我只反对炒作
我想明确说明，我 并不是 “反 LLM”。我的反对点在于把它标榜为 人工智能——它并不具备智能，它只是一种机器学习的形式。“生成式 AI”本质上是一个非常复杂的马尔可夫链，而人们对它的期待却远远超出实际能力。
我并不反感在快速原型制作中使用生成式 AI。如果你需要快速拼凑一个线框图或交互式演示，它确实非常有用。我的担忧在于人们以为可以通过“随意编码”来完成可投入生产的软件，或者把代码背后的真正思考交给它。
Mikayla Maki 对使用代理有 特别好的见解：让人保持在循环中，像对待一个不可信的外部贡献者一样对待它们。只在你已经知道如何完成的任务上使用代理，因为理解它们至关重要。
— On Programming with Agents (Zed.dev)
我会继续使用我那辣味的自动补全，但近期不会把我的思考外包。
- 停止生成。
- 开始理解。
- 记住我们最初为何热爱这件事。