LLM 会写代码之后，软件行业更容易把黄铁矿当黄金

今天最反常的地方，不是 LLM 会写代码。反常的是，几乎任何人都能用提示词生成一段能跑、甚至看起来不错的软件，但判断它到底好不好，仍然需要专业能力。

原文作者用了一个很准的比喻：没经验的淘金者，容易把黄铁矿当黄金。它会发光，但不是金子。软件里的“能跑”，也经常只是会发光。

这不是反抽象，也不是反 AI。软件史本来就是一部不断把复杂性藏起来的历史。真正麻烦的是，复杂性被藏起来以后，很多团队开始假装它已经不存在。

抽象降低门槛，也稀释判断

早期计算资源昂贵。内存、算力、运行时间都不便宜，程序员必须理解机器：CPU、内存、指令、性能边界。不是那代人更高尚，是犯错成本直接摆在桌面上。

后来资源变便宜了，库和框架成熟了。开发者不必从零造轮子，也不必天天抠几个字节。软件产量上去了，交付速度也上去了。

代价是理解开始变浅。很多人会调用库，却不清楚库的边界；会搭框架，却不知道框架替自己做了什么。系统慢、脆、难维护，往往不是某一行代码的错，而是长期把黑箱当免费午餐。

LLM 是这条路的最新加速器。

这里要留一个现实口子：不够好的软件，有时确实够用。

Wonder Bread 不是手工酸面包，但便宜、能填饱肚子。很多内部工具、一次性脚本、原型验证，也不需要工程洁癖。Claude、Copilot 这类工具能帮人更快做 PoC，更快拼界面，更快验证想法，这些收益是真的。

问题在边界。便宜钢材可以搭临时棚，不能拿去盖摩天楼。软件行业最容易犯的错，就是把这两类场景混在一起。

被外包的不是代码，是“好坏判断”

我更在意的不是 LLM 写不写代码，而是团队会不会因此降低对“好”的敏感度。

代码生成把产出放大了。可它没有自动放大审查能力、架构判断、安全意识和维护经验。技术扩张解决供给，不自动解决质量。

这很像报业当年印刷和分发能力提升。报纸可以印得更多、更快，但判断新闻真伪的人不会凭空增加。不完全一样，但结构相似：供给变便宜之后，质量把关反而更容易被当成成本项。

“天下熙熙，皆为利来。”今天的软件生产也一样。只要激励指向更快上线、更低成本、更漂亮的 demo，质量债就会被推迟。推到维护者那里，推到用户那里，推到下一次故障那里。

这对几类人影响很直接。

软件工程师最该调整的不是“用不用 AI”，而是别让 AI 替你决定什么叫合格。能跑只是第一层。可维护、可扩展、可回滚、可解释，才是生产系统的门槛。

技术管理者更该警惕“演示成功”的幻觉。PoC 看起来顺滑，不代表系统能承受真实数据、真实用户、真实故障。采购和上线决策应该延后到审查之后，而不是被一个漂亮 demo 推着走。

关注开发者就业的人，也别急着把所有压力都归因于 LLM。原文作者提到，自己受伤后难以从事体力劳动，从 2025 年 7 月起失业，靠简历投递、用 Claude 做 PoC、冷邮件寻找机会，仍然没有结果。这是一个艰难处境，也说明行业压力真实存在。

但它不能直接证明“LLM 导致失业”。更稳妥的判断是：LLM 正在改变专业能力被市场识别的方式。会产出的人变多了，会判断的人未必更容易被看见。

这才是资深工程师最尴尬的地方。价值没有消失，反而更重要。只是这种价值经常表现为“没有出事”：没有宕机，没有数据错乱，没有安全事故，没有半年后没人敢碰的代码库。

市场喜欢看得见的产出，不喜欢给避免灾难付费。

接下来盯三件事：场景、责任、定价

判断 LLM 编程是不是健康发展，不用看宣传语。看三件事就够了。

第一，看团队有没有区分场景。原型、一次性脚本、内部低风险工具，可以更激进地用 LLM。支付、医疗、基础设施、安全相关系统，就不能只靠“能跑”放行。

第二，看责任有没有前移。谁审查生成代码？谁理解依赖？谁负责线上故障？如果答案总是“出了事再找资深工程师”，那就是把成本藏起来，不是提高效率。

第三，看专业判断能不能被定价。真正懂底层的人，应该进入设计、评审、上线门槛，而不是只在火烧起来后被叫去救场。否则行业会得到一堆便宜产出，再用昂贵维护慢慢还债。

抽象本身是进步。没有库、框架、云服务和 LLM，今天的软件世界不会这么丰富。问题是每一层抽象都在问同一个问题：你还知道下面发生了什么吗？

如果不知道，至少团队里得有人知道。

否则繁荣会很像繁荣，直到某天账单递上来。