历史不站在你以为的那一边 — 技术革命中手艺人的真实命运

今天，"Luddite"在英语世界几乎是一个贬义词，意思约等于"恐惧技术的无知之人"。科技媒体用它嘲笑一切对新技术持谨慎态度的人。但这个标签与历史事实的距离，大到荒谬。

1811 年至 1816 年间，英格兰中部和北部——诺丁汉郡、约克郡、兰开夏郡——爆发了一系列有组织的机器破坏行动。参与者自称"卢德将军"（General Ludd）的追随者，这个名字来自一个可能是虚构的人物 Ned Ludd。他们砸的不是所有机器，而是特定的机器——那些被雇主用来替代熟练工人的机器。

英国历史学家 Eric Hobsbawm 在其 1952 年的经典论文 The Machine Breakers 中指出了一个被后世叙事刻意忽略的事实。他将卢德运动定性为一种 集体谈判的手段 ——他使用了一个著名的短语："collective bargaining by riot"（以暴动为形式的集体谈判）。Hobsbawm 的核心论点是：在工会尚未合法化、工人缺乏制度性谈判渠道的时代，破坏机器是他们向雇主施加经济压力的少数有效工具之一（Hobsbawm, 1952, p. 59）。

这不是一群被技术吓到的糊涂人。恰恰相反——他们是经验丰富的手艺人，清楚地看到了正在发生的事：他们赖以安身立命的不可替代性，正在被一步步拆掉。

要理解卢德运动，你必须先理解 18 世纪末英国纺织业的技能结构。

在动力织布机普及之前，一个合格的手工织布匠（handloom weaver）需要多年学徒训练。他们不仅操作织机，还理解纤维特性、布匹纹路设计、张力控制，能从头到尾独立完成高质量的布匹。这种全流程的掌握——从原材料到成品——给了他们强大的市场议价能力。雇主想要布，就得接受织布匠的价格和工作节奏。

动力织布机改变了这个权力格局。不是因为机器本身有多精妙——事实上，早期的动力织布机生产的布匹质量远不如手工织布，故障率也高得离谱。但真正改变权力格局的是另一件事：操作动力织布机不需要多年学徒训练。一个女人、一个孩子，经过几天培训就能操作。

E.P. Thompson 在其 1963 年的巨著 The Making of the English Working Class 中，用大量一手资料记录了这个过程。Thompson 的分析表明：织布匠们抗议的核心，不是机器取消了他们的工作——至少在运动初期，多数人仍然有工作。他们抗议的是，机器摧毁了使他们的劳动具有尊严和价值的那个东西： 技艺本身的不可替代性 。当任何人都能被训练来操作织布机时，"合格织布匠"就不再是一个有意义的身份（Thompson, 1963, Ch. 9 "The Weavers"）。

这里要引入一个关键概念，后面会反复用到：

卢德工人砸机器，不是因为他们不懂机器，恰恰是因为他们太懂了。他们准确地看到了机器背后的制度安排：雇主不是在追求更好的布匹（事实上早期机器织的更差），而是在追求 不依赖工人技能 的生产方式。在大量历史案例中，技术是手段，去技能化不是副作用——而是管理层主动追求的结果。

如果你把"织布机"替换成"LLM"，把"织布匠"替换成"软件工程师"，卢德运动的叙事结构会让你脊背发凉：

维度	1812 纺织工人	2025 程序员
威胁来源	动力织布机 + 廉价非熟练劳动力	LLM/AI 编码工具 + 低成本"AI 编排员"
核心恐惧	技艺被廉价劳动力+机器取代	编程技能被 AI+低成本操作员取代
早期信号	机器布质量差但雇主仍推广	AI 代码有 bug 但管理层仍推行
雇主话术	"效率" "进步" "不可阻挡"	"10x 效率" "AI native" "适应或淘汰"
实际诉求	不是砸机器，是要公平的工资和技能认可	不是反 AI，是要保留工程判断力和职业尊严
被忽略的关键	问题不在于机器是否更好，在于谁决定了它的用法	问题不在于 AI 是否更强，在于谁定义了"程序员"的新角色

这不是类比游戏。结构上的相似强到了让人发毛的地步。

但历史不会简单重复。要理解"这次有什么不同"，我们需要看一个更细致的案例——一个技术路径选择如何决定了一整个职业命运的案例。

1984 年，MIT 出身的科技史学者 David Noble 出版了 Forces of Production: A Social History of Industrial Automation 。这本书讲了一个让人坐立不安的故事：美国机床行业在 1950 年代面临自动化时，明明有两条可行的技术路径——但最终胜出的那条，不是技术上更好的那条，也不是更便宜的那条。

先说背景。二战后，美国航空工业面临大量复杂零件的加工需求。传统的金属切削全靠熟练机械师（machinist）——这些人经过多年学徒训练，能阅读工程图纸、选择刀具、调整进给速度、控制公差，独立完成复杂零件的加工。他们是工厂的顶梁柱，也是管理层最头疼的群体：技术好的机械师有强大的议价能力，控制着生产节奏，而且经常在车间层面自行决定如何加工零件——不需要工程师的指令。

两条自动化路径同时出现了：

第一条：录制-回放（Record-Playback）

原理非常直观：熟练机械师加工一个零件，机器记录下他的每一个操作——刀具轨迹、进给速度、切削深度。之后，机器就可以精确重放这些操作，批量加工相同零件。

关键特征：熟练机械师仍然是核心——他"教"机器怎么做。他的技能不但没有被消除，反而被放大了：一个好机械师的操作，通过录制回放，可以产出成百上千个零件。这条路径的技术在 1950 年代初就已相当成熟，造价可控，实际车间测试效果良好。

第二条：数值控制/APT 编程（Numerical Control）

由 MIT 伺服机构实验室在美国空军资助下开发。原理完全不同：工程师在办公室里用一种叫 APT（Automatically Programmed Tool）的编程语言编写加工指令，这些指令被编码到穿孔纸带上，由机床直接执行。

关键特征：编程由工程师和程序员在办公室完成，车间工人只负责装卸工件和更换纸带。机械师的多年技能变得多余——你只需要一个会"按按钮"的人。

Noble 对两种技术的比较分析得出了一个核心结论：录制-回放技术在经济性、可靠性和实用性上并不逊于数值控制，在某些方面甚至更优。然而，它从未被认真地纳入发展轨道。原因不在于技术——而在于它 保留了机械师对生产过程的控制权 ，而这正是管理层和军方试图消除的（Noble, 1984, Ch. 6–8）。

需要指出的是，Noble 的论述在学术界并非没有争议——一些技术史学者认为他低估了 NC 在加工复杂曲面零件方面的技术优势。但他关于"技术路径选择受权力关系影响"的核心论点，已经成为科技社会学的经典命题。

Noble 的研究揭开了技术决定论刻意遮掩的东西：自动化从来不是沿着"唯一最优路径"自然演进的。每一步都是人的选择——而这些选择背后是权力博弈，不是纯技术逻辑。

美国空军为什么大力资助 MIT 的数值控制方案？Noble 找到了当时的内部文件。理由并不隐晦：空军需要在战时快速扩大军工生产，而这个目标的最大瓶颈是 对熟练机械师的依赖 。如果每条产线都需要老师傅，产能就被老师傅的数量卡住了。数值控制的承诺是：只要有程序员和工程师，就能驱动任意多条产线——工人的技能不再是瓶颈。

管理层的逻辑如出一辙。当时的工厂管理者对车间有一种根深蒂固的焦虑：熟练机械师知道得太多。他们知道零件该怎么做，知道哪些工序可以省、哪些不能省，知道管理层定的工时标准是否合理。这种知识是权力的来源——而管理层想把这种权力从车间收回到办公室。

Noble 在采访和档案中发现了大量类似的管理层表态。其中，他转述的一个核心观点是：管理层对于数值控制最大的热情，来自于它" 把技能从车间转移到规划办公室 "的承诺（Noble, 1984, Ch. 9）。

录制-回放被放弃了。不是因为不好用——当时的测试表明它运转良好。原因只有一个：它把权力留给了工人。

工人的体验是什么？Noble 在书中记录了大量机械师的口述（Noble, 1984, Ch. 11）。综合他们的描述，一个典型的心声是这样的：以前我是一个 craftsman（匠人），我理解整个零件——材料、公差、刀具磨损、热变形。现在我是一个 button-pusher（按按钮的人）。纸带告诉机器该做什么。我只负责装卸工件。如果程序有错，我不被允许修改——我得打电话给办公室的程序员。

从匠人到按钮操作者。同一个人，同一份工作，但工作的内涵已经被掏空了。

如果你是一个程序员，读到这里应该已经感到了不适。因为 AI 编码工具的部署，同样面临两条路径：

维度	增强路径	替代路径
类比	录制-回放（Record-Playback）	APT 编程（Numerical Control）
AI 的角色	辅助编写+审查，人掌握架构和设计决策	生成全部代码，人只做需求描述和验收
工程师角色	技术决策者——用 AI 放大自己的判断力	"按按钮"的审批员——接收 AI 输出，点击部署
技能要求	需要深度理解才能有效引导和审计 AI	只需要会写 prompt 和做基本验收
谁获益	有经验的工程师——AI 放大他们的产出	管理层——降低对资深工程师的依赖
对组织的风险	较低——人保留了理解和纠错能力	极高——一旦 AI 出错，无人有能力诊断

哪条路径正在赢？

看看企业的行为，而不是他们说了什么。当一个公司宣布"AI 让我们的工程团队效率提升了 3 倍"，然后紧接着裁掉 30% 的工程师——他们在走哪条路径？

当招聘信息从"需要 5 年系统编程经验"变成"需要 AI 工具使用经验，能有效 prompt engineering"——这是在增强工程师，还是在替换工程师的定义？

Noble 的研究在四十年后给我们的最大警告是：

如果读到这里你的结论是"自动化必然导致去技能化"，那你也犯了一种简单化的错误。

Noble 的故事有其局限性。并非所有组织都选择了"替代路径"。事实上，在 Noble 自己研究的机床行业中，后来出现了一个有趣的逆转：当 CNC 机床变得更灵活、操作界面更友好之后，一些高端制造企业重新赋予了机械师更多的车间自主权——因为管理层发现，完全剥离工人的判断力会导致昂贵的错误和低效的刚性流程。

社会学家 Andrew Friedman 在 1977 年就指出：管理层并非始终追求去技能化。面对核心员工，他们有时会采取"负责任自治"（responsible autonomy）策略——用更大的自主权换取更高的产出和忠心。去技能化的 Braverman 模型是一种 重要的默认趋势 ，但不是不可抗拒的命运。

甚至在 AI 领域，我们已经可以看到分化：一些顶级技术公司把 AI 当作资深工程师的放大器（force multiplier），要求工程师先吃透 AI 的输出才能用好它；另一些公司则直接拿 AI 当"工程师替代品"，用 prompt engineer 顶掉传统开发者。两种模式并存，最终走哪条路，要看组织的利益导向、行业竞争态势，以及工程师群体有没有足够的话语权。

所以，Noble 的警告不是宿命论——而是提醒我们注意 默认方向 。如果没人干预，在劳资权力悬殊的地方，去技能化往往是阻力最小的选择。但它不是唯一的选择。

如果只看卢德运动和数控机床，你可能会陷入悲观。但编程有一段独特的历史，它自身经历的自动化浪潮比任何行业都多——而且每次的结果都出乎意料。

先看全景：

时期	"自动化"的内容	当时的恐慌话术	实际结果
1950s	机器码 → FORTRAN/COBOL	"真正的程序员写机器码。编译器生成的代码又慢又臃肿。"	程序员数量从数百增长到数万——十倍级暴增
1970s	手动内存管理 → 结构化编程	"封装会毁掉性能。goto 才是真正的控制流。"	软件成为独立产业，程序员跨入十万量级
1990s	C/C++ → Java/Python + GC	"不懂指针不配叫程序员。GC 是给不会写代码的人用的。"	Web 开发爆发，全球程序员突破百万
2010s	手写全栈 → 低代码/No-Code	"5 年内不需要程序员了。"	低代码使用者 ≠ 程序员减少，总量继续增长
2020s	手写代码 → AI 生成代码	"编程已死。"	？

这张表看起来是一剂强效安慰剂：每次都有人喊"完了"，每次结果都是程序员更多了。那这次也不用担心，对吧？

不对。如果你把它当安慰剂，你就犯了一个幸存者偏差级别的错误。

把其中两轮放大来看——关键差异都藏在细节里。

先承认那个确实存在的历史规律。

经济学家 James Bessen 在其 2015 年的著作 Learning by Doing: The Real Connection Between Innovation, Wages, and Wealth 中，通过大量历史数据论证了一个反直觉的结论：在大多数历史案例中，自动化一项任务并没有消除对工人的需求——反而增加了需求。Bessen 的解释是：自动化降低了成本，降低了成本则扩大了市场，扩大了市场则需要更多工人。他以 19 世纪自动纺纱机和 20 世纪 ATM 为例——两者最终都增加了相关领域的就业（Bessen, 2015, Ch. 3–4）。

这就是经典的 Jevons 悖论（Jevons Paradox）在劳动市场的表现：效率提升 → 成本下降 → 需求暴增 → 总就业增加。编程领域的版本：FORTRAN 让编程脱离机器码 → 编程门槛下降 → 能用软件解决的问题暴增 → 需要更多程序员。

美国劳工统计局（BLS）的数据支持这个模式。根据 BLS /Occupational Employment and Wage Statistics/（SOC 15-1252, Software Developers），美国"软件开发人员"岗位从 2012 年的约 103 万增长到 2024 年的约 191 万。即便在 AI 编码工具广泛普及的 2023-2025 年，虽然增速放缓，总量并未下降。

但 Bessen 自己也在书中加了一个关键的但书——一个经常被引用者跳过的但书。用他的话概括：总量增加并不意味着对 同一批工人 的需求增加。被自动化改变的工人——那些拥有旧技能的人——往往经历了漫长的工资停滞、地位下降和痛苦的转型期。 总量统计掩盖了分配上的残酷 （Bessen, 2015, Ch. 7）。

每一轮之后——

旧技能贬值了。写汇编不再稀缺。手动管理内存不再是必备能力。手写 SQL 不再是核心竞争力。手动编写 CRUD API 不再有任何智力含量。

新技能升值了。系统设计能力。分布式架构判断力。可观测性工程。安全审计。

这些转换不是温和的。被贬值的那批人，不会自动变成拥有新技能的人。中间是一段充满痛苦的失重期。

每次都说"这次不一样"的人最终都被打脸了——但"每次都没有不同"同样是一种思维懒惰。

前四轮自动化有一个共同特征：它们自动化的都是编程过程中的某个 局部翻译层 。

• FORTRAN 自动化了 "人类可读的数学公式 → 机器码" 的翻译
• 结构化编程自动化了 "程序逻辑 → 具体控制流" 的组织
• GC 自动化了 "内存分配策略 → 具体的 malloc/free 调用" 的决策
• 低代码自动化了 "业务流程 → 具体的 UI 和 API 代码" 的生成

每一轮都让程序员从一个低层次的翻译工作中解放出来，转而去做更高层次的决策。但"理解问题并做出设计决策"这个核心能力一直留在人的手中。

AI 正在尝试自动化的，是一个本质不同的层面：不是从一种表示到另一种表示的翻译，而是 "从模糊的人类意图到完整可运行方案"的直接跳跃 。这不是另一个翻译层——这是整个编程行为的核心。

Daron Acemoglu 和 Simon Johnson 在他们 2023 年的著作 Power and Progress: Our Thousand-Year Struggle Over Technology and Prosperity 中，提供了一个超越 Jevons 悖论的分析框架。他们的核心论点可以概括为：技术进步是否惠及大多数劳动者，取决于新技术创造的价值如何分配。历史表明，如果没有制度性约束—— 工会、监管、社会规范 ——技术带来的生产力收益绝大部分会被资本所有者获取。劳动者的处境是改善还是恶化，取决于制度设计，不取决于技术本身的特性（Acemoglu & Johnson, 2023, Part III）。

不要急于下结论。先看看历史上"降级"到底长什么样。

这是本文最核心的论点，也是公众讨论中最容易被忽略的一个：在过去 200 年的技术革命中， 大多数受冲击的手艺人并没有失业 。他们经历的是一个更隐蔽但更具破坏性的过程——去技能化与降级。

纺织业：卢德运动之后，英国手工织布匠并没有在一夜之间消失。他们中的一部分确实失业了，但更大的一部分"转型"了——转成了动力织布机的操作员。工资呢？根据 Thompson 的研究，1800 年前后，一个熟练手工织布匠的周薪可以维持一个体面的中产生活。到 1830 年代，同一个区域的织布机操作员的工资只有前者的大约三分之一（Thompson, 1963, Ch. 9）。人还在，工作还在，但从"匠人"变成了"操作工"。

机床行业：Noble 记录的数控革命之后，多数机械师没有失业。CNC 机床仍然需要人来装卸工件、监控运行、处理简单故障。但原本那个"阅读图纸→选择工艺→控制精度→独立完成零件"的完整技能链条，被拆解成了几个低技能的操作步骤。一个需要 10 年经验的工种，变成了一个培训 3 个月的工种。

Harry Braverman 在其 1974 年的里程碑式著作 Labor and Monopoly Capital: The Degradation of Work in the Twentieth Century 中，将这种模式提升为一个一般性理论。Braverman 的核心概括是：资本主义管理的核心原则，从 Frederick Taylor 开始就没有变过——将 *构思*（conception）从 *执行*（execution）中分离出来，将思考的工作集中到管理层和规划部门，将车间工人简化为预定步骤的执行者。在 Braverman 看来，每一轮技术变革都不过是这个原则的新实现形式——这不仅仅是技术进步的"副作用"，而是被管理系统积极追求的结果（Braverman, 1974, Part I）。

Braverman 的框架启发了后来数十年的劳动社会学研究，虽然细节上有许多学者提出了修正和批评（例如 Andrew Friedman 指出管理层并非始终追求去技能化，有时也采取"负责任自治"策略），但核心洞见经受住了时间的考验：去技能化是自动化的默认趋势，除非有足够强的反向力量。

这些历史案例有几个共同点：

1. 你还有工作 ——但工作的内涵被掏空了
2. 你的技能不再稀缺 ——因为机器承担了需要判断力的部分
3. 你的自主权消失了 ——决策权从你的手中转移到了机器（或写机器程序的人）的手中
4. 这个过程是渐进的 ——不是某一天突然发生的，而是一步步地推进，每一步看起来都"合理"

把这个模式套到程序员身上，可以画出一条降级光谱：

Level 4：工匠

理解问题 → 设计方案 → 选择技术栈 → 实现核心逻辑 → 调试 → 性能优化 → 维护演进。全流程掌控。如同手工织布匠了解从纤维到成品的每个环节，如同老机械师理解从图纸到零件的每个决策。

Level 3：高级操作员

用 AI 生成代码框架 → 审查关键逻辑 → 微调细节 → 部署。仍然有技术判断力，能识别 AI 的错误，能在 AI 失败时接管。但正在逐渐丧失从零构建的能力。

Level 2：操作员

接收 AI 输出 → 做基本验收 → 点击部署 → 出问题叫人。类似数控机床旁的工人：会装卸"工件"（需求），会启动"机器"（AI），但不理解中间发生了什么。

Level 1：被替代

多数程序员不会到达 Level 1。但如果当前趋势持续，相当数量的程序员可能会从 Level 4 滑落到 Level 3，然后从 Level 3 滑落到 Level 2。而且——这是最关键的——他们中的很多人 不会察觉到 这个滑落正在发生。

失业是一个清晰的信号。你丢了工作，你知道出了问题，你会愤怒、会焦虑、会开始寻找出路。社会也有机制来应对失业：失业保险、再就业培训、舆论关注。

降级没有任何一个信号。它是这样发生的：

第一阶段 ："AI 帮你写 boilerplate 代码，省了很多时间。"你觉得这很棒。效率提升了。

第二阶段 ："AI 帮你写大部分业务逻辑，你只需要审查。"你觉得这也挺好的。可以把精力放在更"重要"的事情上。

第三阶段 ："AI 生成的方案你越来越少地修改，因为'大部分时候是对的'。"你开始跳过一些审查步骤。回忆一下，你有多久没有从头写过一个模块了？

第四阶段 ：有一天，AI 生成了一个有微妙竞态条件的并发模块，或者一个在边界情况下会导致数据损坏的数据库查询。你看了一眼——看起来对。因为你识别这类问题的能力，已经因为长期不练习而 萎缩 了。

这就是 Braverman 所说的"构思与执行的分离"——搬到了软件工程里。你还在工作。你甚至可能比以前更忙——因为 AI 让你能"处理"更多任务。但你处理这些任务的方式，已经从"思考和判断"变成了"审批和转发"。

回到第一章：卢德运动中的织布匠，恐惧的不是没饭吃。他们恐惧的是，当任何人都能操作织布机时，"织布匠"这个身份就不再有意义了。他们将不再是匠人——只是操作员。

回到第二章：Noble 告诉我们，这种降级不是不可避免的。录制-回放方案明明存在——一个保留工人技能、同时实现自动化效率的方案。它被放弃了，不是因为技术，而是因为权力选择。

对程序员来说也是一样。"增强路径"——AI 放大人的判断力——和"替代路径"——AI 消除对人的判断力的需求——同时存在。走哪条路，取决于谁在做选择。

卢德工人面对的动力织布机不是唯一可能的技术路径，Noble 研究的数控机床也不是。但这两个案例里，一旦工人丧失了独立干活的能力，谈判筹码就没了——不管技术路线怎么走。

试着列一个清单：你当前工作中的核心任务，有哪些你可以完全不借助 AI 独立完成？这份清单有多长、多深，就代表你有多少真正的底气。如果清单在过去一年里越来越短，这不是"效率提升"——这是你的技能在向 AI 搬家。

上一次你从零写一个完整模块——不借助任何 AI 辅助——是什么时候？如果答案是"好几个月了"，你可能已经在温水里了。

每一轮编程自动化之后，程序员总量确实增加了。但 Bessen 提醒我们：总量增加 不是 对现有从业者的保护伞。FORTRAN 时代的 coder、Java 时代的 CRUD 开发者——每一轮都有一批人成为了新技能体系下的"操作员"。

BLS 数据告诉你程序员总量没有减少。它没告诉你的是：薪资分布的形状正在变化。近年来的开发者调查数据（包括 Stack Overflow 年度调查）显示出一个趋势：高于中位数薪资的岗位中，"系统架构"和"AI/ML 工程"类角色的占比在上升，而传统"全栈开发"和"前端开发"的薪资溢价在收窄。总量没变，但 结构 在变。

你能分清"我看懂了 AI 的输出，改掉了其中的问题"和"我看了 AI 的输出，没发现毛病"吗？前者是判断力，后者是依赖——但从外面看，两者毫无区别。

Noble 告诉我们最重要的一件事：技术路径是被选择的。录制-回放和数值控制并存时，胜出的不是更好的技术，而是更符合管理层利益的技术。

当你的公司宣布"AI 让我们的工程团队效率提升了 3 倍"，然后紧接着裁掉 30% 的工程师——他们在走哪条路径？当招聘信息从"需要 5 年系统编程经验"变成"需要 AI 工具使用经验"——这是在增强，还是在替换？

这个问题不只跟你一个人有关，还牵涉整个组织的长期能力——一旦去技能化深入到组织层面，当 AI 出错时，将没有人有能力诊断问题。这不是科幻——这正是 Noble 记录的数控机床工厂后来遇到的困境。

—

我不会告诉你"所以要停止使用 AI"——那和砸织布机一样愚蠢。我也不会告诉你"所以只要持续学习就没事"——卢德工人也在持续学习，他们学会了操作新机器，然后发现那份工作不再需要他们真正的技能。

这篇文章不是药方——它是体检报告。上面三个问题就是检测指标。如果你的答案让你不安，那很好——不安是清醒的前提。后续文章会进入更具体的领域：AI 辅助编程如何改变我们的认知模式，技能蜕化的心理学机制是什么，以及在结构性变革面前，什么样的能力建设是真实有效的，什么只是自我安慰。

但在那之前，这篇文章只想让你记住一件事：

1812 年的诺丁汉，一个手工织布匠看着工厂里新装的动力织布机，心里想的不是"这机器比我強吗？"——他想的是"我还是我吗？"

2026 年的你，打开 IDE，看着 AI 自动补全了一整个函数，心里可能也在想同样的问题。

历史不会告诉你答案。但它会告诉你，这个问题值得认真对待。