停止生成，开始思考
2026年2月8日
标签：AI、工程
在我的职业生涯中，我一直自认为能紧跟行业的最新发展：参加各种会议、关注并结识那些撰写技术规范的聪明人、在Slack上第一个向同事分享CSS或JS新特性的消息。能在只需兼容最新版Chrome的内部工具上工作、在生产环境中尝试仍属实验阶段的“锚点定位”功能——那种乐趣无与伦比。
因此，当我发现自己开始觉得“被时代甩在后面”、好像“错过了什么”时，这种感觉相当不安。尽管我不愿承认，但越来越多的人疯狂依赖由大语言模型（LLM）生成的代码，而我却无法理解其中的逻辑。
我一直在用Copilot——最近也用Claude——把它们当作“加辣版自动补全”或偶尔的调试助手。但每次我尝试让它做一点稍微复杂的事，它就完全崩溃。别误会，我知道很大一部分问题在于我使用方式不对，但我很难说服自己花大量时间去琢磨如何让一台机器写出我自己在更短时间内就能完成的代码。
你得给它足够的上下文——但又不能太多，否则它会“过载”。你得写出一大段提示词来安抚AI那脆弱的自尊心，比如“你是一位分布式系统专家”，仿佛它是一个不自信的平庸程序员。
可我何不直接写那段代码，反而更快？
看到越来越多工程师选择“生成代码”而不是“写代码”，我开始纳闷：为什么大家愿意放弃工作中最有趣的部分（写代码），而只留下最无聊的部分（代码审查）？
也许有人真的喜欢给计算机写角色扮演剧本吧。我不知道。但我觉得危险的是，人们正心甘情愿——甚至自豪地——让生成代码充斥他们的产品。
我听过的几种辩解
“这就是我们的工业革命！就像机械化一样。”
在很多方面，这话确实没错。
首先，想想工业革命对气候变化的贡献，再看看支撑AI软件的数据中心的能源消耗，这种相似性很明显。诚然，如今并非所有电力都来自化石燃料，这算是点进步，但我们仍在浪费惊人的资源，用来生成“虾仁耶稣”的图片。
机械化让商品更便宜、更普及，但质量却下降：自19世纪末以来就是一场“向下竞赛”。如今你能在SHEIN上花比一杯咖啡更少的钱买到一条“易燃”的裤子。机械化导致技能劳动的衰退，公司把工厂外包到欠发达国家，剥削低薪工人赚更多钱。
生成代码就像快时尚：乍看之下还行，但经不起时间考验，仔细一看漏洞百出。而且，就像快时尚一样，它常常抄袭别人的设计，对环境造成负担。
但有个关键区别。机械化是用机器取代了制造流程中的人力，让机器完成同样的工作。就像用脚本或代码生成工具写模板代码。这类过程的关键在于可重复——每次输出一致。如果出错，人类能打开机器，找到问题。
而LLM的输出是非确定性的，内部机制又不透明。一个每次结果都不同、还充满“幻觉”的机械化过程——根本没用。
“LLM只是另一层抽象，就像高级语言取代汇编一样。”
确实，写Java或Go时我不必了解汇编。我最接近“汇编”的，大概就是编织图案说明书吧。
编程语言的演变，让我们逐渐不必操心底层细节：我不用管理内存回收或分配——运行时会自动处理。但我仍需思考代码结构、性能、系统架构、可维护性与交付速度之间的平衡。做Web开发时，我们得考虑浏览器兼容性、可访问性、安全性与性能。
我见过LLM造成的最大问题是：工程师把原本该自己思考的部分外包给机器。LLM不能推理系统架构该如何设计——因为它不会思考。如果我们不思考，而它也不思考，那就没人思考。没人思考的软件，绝不会有好结果。
以英国“邮局丑闻（Horizon scandal）”为例：因为软件漏洞导致员工被错误指控挪用公款，许多无辜职员入狱。我们比以往任何时候都更需要对软件负责。
十三个人因为那个系统的错误而失去了生命。
问题在于我们自己糟糕的代码
你也许会说：现在的人类开发者写的代码也一样糟糕——不可访问、性能低下、臃肿的JavaScript。那又有什么区别？
没错。这正是问题所在。LLM是在未经我们明确许可的情况下，从这些糟糕代码中学习的。我们教会了它输出同样糟糕的东西。它注定会重复人类的错误——再加上别的LLM生成的错误——这正是有人戏称的“人类蜈蚣式知识链”。我们自己代码都不够好，哪来资格要一台机器更快地写出同样糟糕的东西？
如果你觉得“到目前为止还行”，那就去问问使用辅助技术的人；问问网络连接差的国家；问问在英国城市里靠移动数据上网的人；问问被人脸识别或甚至自动干手机系统歧视的人；再问问那些邮局职员。
我们没有学习、没有改进，反而把错误交给了不懂思考的算法。
“四只眼睛好，两只眼睛坏”
去年在FFConf上，Jessica Rose和Eda Eren做了一场精彩的演讲，讲述AI编程助手如何让我们逐渐失去技能。其中有一张幻灯片让我印象深刻：
“你没有亲手写的代码，你就无法理解。你无法维护你不理解的代码。”
当我审查同事提交的PR时，会有一种信任感——因为那是一个经过思考的人写的代码。虽然也有例外，但若某人总提交糟糕的PR，经理自然会介入。
而开源维护者如今面对大量低质量的AI生成PR。作为贡献者，无论代码是否由LLM生成，你都要为自己提交的代码负责。审查者也有部分责任，但至少有两双眼睛在看。
现在有公司在社交媒体上炫耀他们让Claude在Slack里生成代码并直接创建PR。Claude自动写完代码，再自动发起PR。这时责任全落在审查者身上。如果规则不够严格，一个人就能让Claude生成并自己批准——于是我们失去了一双“人眼”，团队的知识共享也随之减少。
代码审查不仅仅是查漏洞，更是分享理解。虽然有公司完全不做PR、直接提交到主分支，但我见过唯一可行的做法是工程师持续配对编程——这样才能保持对改动的共同理解。
我不是反对进步，我是反对炒作
我必须强调：我并不“反对LLM”。我反对的是把它们包装成“人工智能”——因为它根本不智能。它只是机器学习的一种形式。“生成式AI”不过是一个非常强大的马尔可夫链，人们对它的期望远远超过现实。
我也不反对用生成式AI快速制作原型——比如线框或交互演示，这很合理。我的担忧在于：有些人以为可以靠“感觉提示”（vibe code）直接生成可上线的软件，或者把编程中最重要的“思考过程”完全交给机器。
Mikayla Maki提出了一个非常好的观点：始终让人类参与其中，把AI代理当作一个你不完全信任的外部协作者。 只让它执行你自己已经掌握的任务——因为理解才是关键。
我会继续使用我的“加辣自动补全”，但我绝不会把思考外包。
停止生成，开始理解——也别忘了我们当初为什么热爱这份工作。