被 AI 坑惨的福特，召回 350 名老工程师救场
事件回顾
福特在 2026 年公开复盘了过去几年 AI 转型的代价。公司在生产与设计中"过度依赖自动化系统"，结果是 Explorer、Aviator 等重磅车型暴露出执行层不足，质量评分持续下滑，召回数量一度居行业之首。疫情引发的供应链中断更让局面雪上加霜。
转机来自一次反直觉的决策：在重夺 J.D. Power 主流车企初始质量排名第一的当口，福特把 350 多名已离职或退休的资深工程师召回来，让他们指导年轻工程师、改进数据收集和 AI 训练流程，重新训练那套被他们亲手"喂大"、又在他们离开后开始犯错的自动化系统。
福特硬件工程副总裁 Charles Poon 坦言："我们当时错误地以为，只要引入人工智能，再调整一下已有的设计要求，就能产出高质量产品。"
福特踩了什么坑
坑 1：把"老员工的经验"当成可一次性导入的资产。
Poon 透露，公司最有经验的员工离开前，他们掌握的知识并没有被完整导入自动化系统。等系统开始系统性出错，福特才发现这个缺口——而"几十年积累下来的工程判断力"单靠技术补不回来。
坑 2：质量管理方式碎片化。
首席运营官 Kumar Galhotra 把症结总结为"各部门各自为政，奉行'发现并修复'的被动策略，问题出了再打补丁"。他们正在转向"问题发生前就预防"，关注赋能因素和早期信号，而不是最终结果。
坑 3：把互联网的"快速迭代"思维搬进安全关键场景。
Poon 承认，过去福特常在开发后期才发现软件漏洞，但汽车不是消费电子——"车辆运行在安全关键环境中，软件从一开始就必须正确"，不能照搬"先发布再修补"的模式。为此福特成立了一支 40 人的专项质量保证团队，专职早期验证与缺陷预防。
坑 4：高估了 AI 判断力，低估了人的角色。
Poon 直言，AI 有效性"完全取决于训练数据的质量"，而福特在数据质量上栽了跟头。与此同时，那些老工程师的判断力——"能够在问题进入系统之前发现它们"——才是真正的护城河。
老工程师为什么能救场
这批被召回来的 350 人，并不是单纯"修 bug 的"。他们承担了三件机器做不了的事：
- 判别边界：能识别"AI 方案漂亮但藏着五个原型阶段就会爆雷的隐患"，这种判断不会出现在任何训练数据里。
- 重构流程：改进数据收集和 AI 训练流程本身——也就是让 AI 重新变好用的那条上游管道。
- 传承手艺：直接指导年轻工程师，把"什么是合格、什么是凑合"的口径重新校准回来。
福特的下一步目标，是建立"AI 支持工程师，而非取代工程师"的模式——让系统既承载算力，也沉淀公司数十年的造车经验。
行业启示
福特不是孤例。文章引述了 Menlo Ventures 合伙人 Deedy Das 提出的"阶层分化"框架：
- 一边是缺乏判断力、只会靠 AI 快速拼出结果的"氛围编码者（vibe coder）"；
- 另一边是经验丰富的"手艺人"工程师，不得不在大量糟糕的 AI 代码里艰难跋涉，反复修补别人扔过来的烂摊子。
Das 在长帖里写道："大多数软件工程师正面临一种接近抑郁的身份认同危机。"一个伴生词也随之诞生——workslop，指 AI 制造出来的工作垃圾。它们看起来像完成了任务，甚至身兼数职，能让管理层产生"生产力提升"的错觉，并因此获得奖励。但一旦进入真实协作流程，就要更细致、更有经验的同事花时间返工。
"AI 原本被寄望于减少负担，结果却把负担转移给了那些最有能力识别问题的人。"
更有网友给出了具象佐证：前公司大规模裁掉年龄大、经验丰富的员工，"结果公司迅速垮掉，管理层还一脸困惑。后来几轮分拆和诉讼之后，所有人都在问，当初承诺的'股东价值增长'到底去哪了。"
我的判断
把这事从制造业映射回软件工程，几乎是一一对应。福特踩的每一个坑，我们日常都在踩。
什么时候必须靠人（不能信 AI）：
- 安全关键的判断。汽车软件从一开始就要正确，金融交易、医疗、嵌入式控制同样如此。AI 适合做"加速器"，不适合做"决策器"——尤其是不可逆决策。
- 跨周期的工程判断。Poon 那句"在问题进入系统之前发现它们"，对应到代码评审里就是"看出 5 个原型阶段会爆雷的隐患"。这种东西不会出现在任何训练数据里，只存在于看过 10 次同类事故的人的肌肉记忆里。
- 元工作（meta-work）：决定数据怎么收集、流程怎么设计、"什么算合格"——这些上游决策 AI 做不了，必须人来定。
什么时候可以信 AI（让人放手）：
- 重复性、可验证的工作：福特现在跑的 10 万项 AI 驱动测试就是典型，框架高度自动化、结果可验证，AI 在这块能 10× 提效。
- 产生"草稿"但需要人审：写初版脚手架、写测试用例、生成 CRUD 代码——AI 是合格的初稿机器，但绝不能当发布机器。
- 已知模式的快速复用：你清楚输出应该长什么样，AI 帮你从零敲到 60 分。
可操作的判断框架——三问原则：
- 错了能回滚吗？ 不能回滚的场景（数据库迁移、车辆固件、生产环境配置）→ 强制人 review。
- 判断能写进 prompt 吗？ 写不进去的隐性知识（"这代码哪里别扭"）→ 强制人判断。
- 组织还能承担几个类似事故？ 一次召回可以是教训，十次就是文化问题——AI 不是用来"减少资深工程师"的，是用来"解放资深工程师"去处理只有人能处理的事。
福特花 350 个资深工程师 + 一次公开复盘才学到这件事，我们不必非得亲自踩一遍。