最近半年，经常看到科技公司裁员的新闻。大多数非技术决策者可能会认为是正常的技术迭代，并且是顺理成章的人力资源重置，AI 智能体全面替代传统研发。

但是，这种大规模的工程资产清洗，本质上更像是一场群体性的认知缺失。Box 的创始人 Aaron Levie 将其叫做“AI 精神病”：决策者长期脱离具体的工程实现，在面对 AI 的实际交付能力时，产生了不切实际的幻觉。

这种幻觉的代价是：科技公司系统失控和组织架构效能倒退。

“原型谬误”：语法正确与语义正确的混淆

为什么“AI 精神病”极易在公司高管层蔓延，而一线的技术负责人对此则表现的相当警惕？因为决策者混淆了“原型”与“生产系统”的边界。

非技术背景的决策者在评估 AI 能力时，通常是在完全受控的方式下进行的。比如 AI 在几秒钟内生成一个可运行的 UI 页面，或者一段没有语法错误的代码，直觉告诉他们，研发的边际成本已经归零。

但这在系统工程中是严重的工程错配。

基于大模型概率预测生成的代码，绝大多数时候只能保证“语法正确”。它符合语言规范、能够被编译器解析、甚至能在干净的沙盒中运行。然而，企业级生产系统的壁垒，要求“语义正确”。它要求系统在面对并发竞争、状态漂移、网络分区、边缘用例以及复杂的合规约束时，依然能够保持逻辑的一致性与状态收敛。

写代码只是整个软件工程中最表象、最容易被自动化的一步。将“语法正确的代码碎片”拼装并重构为“语义正确的生产系统”，才是研发成本的核心所在。高管们错把“代码生成”当成了“工程实现”，从而在幻觉中做出了研发资产的清洗决策。

ClickUp 悖论：零成本的生成，与无限膨胀的验证成本

“AI 精神病”典型案例是，项目管理软件 ClickUp 的 CEO 宣布裁员 22% 并部署 3000 个 AI 智能体。宣称要打造一个“100倍效能组织”，而人类员工则作为 AI 智能体的“审核员和授权者”。

这个模型在管理学上听起来非常高效，但在软件工程经济学上，它是一个彻底的悖论。

在研发流水线中，代码的生成是一个合成过程，而代码的验证则是一个分析过程。 从认知负载的角度看，分析、理解并寻找一段未知代码中的潜在逻辑缺陷或资源泄露，其成本呈指数级高于编写一段新代码。

当 AI 将代码生成的边际成本降低到接近零时，系统中的代码产出量会呈几何级数膨胀。

如果企业在缩减研发编制的同时，让几千个智能体疯狂向代码库合并代码，那么面对的问题可能是：

• 验证赤字： 面对每天成倍增加的 AI 代码，人类员工根本没有足够的认知带宽和时间去进行深度的 Code Review。
• 橡皮图章效应： 审核者会因为高密度的疲劳而流于形式，直接批准合并。
• 系统熵增失控： 缺乏严密同行评审、概率引擎生成的代码会迅速充斥系统，系统的内聚性被破坏，耦合度暴涨，最终导致不可逆的架构腐化。

AI 并没有消灭工作量，它只是把原本均匀分布在开发流程中的瓶颈，粗暴地向后挤压到了“验证与审核”阶段。用裁员的方式，去应对呈几何级数增长的 AI 代码，本身就是对工程流水线瓶颈的完全误判。

时间与上下文的错配：用未来的预设解决当下的危机

在研发决策的时间表上，高管们典型的错误是时间错配。

虽然麻省理工学院（MIT）在对数千个 AI 智能体进行多维度评估后给出预测：AI 智能体在 2029 年左右可以在主流任务上稳定达到 80%-95% 的人类工作质量，但我个人依然认为在当前 LLM 架构下，这种判断是偏乐观的评估。

这意味着，在 2026 年的今天，AI 在复杂工程链条上的真实交付能力，与高管们的期望之间，存在着至少三年的物理时间差。在底层技术尚未成熟到可实现闭环托管的阶段，贸然对现有的研发资产进行清洗，是用未来的技术预期来解决当下的工程危机。

比时间错配更深层的冲突，在于知识边界的错配。

大模型所拥有的知识库来源于公有的互联网语料，它们擅长处理通用的、标准化的算法和框架模板。但是，任何一个真实运转的企业级系统，都扎根于极度复杂的“私有上下文”中。这包括未被文档记录的历史技术债、定制化的私有网络协议、团队间妥协的边缘逻辑，以及因客户需求频繁变更而妥协的代码补丁。

当决策者裁掉那些在系统里摸爬滚打多年、大脑中承载着“私有上下文”的资深开发者时，他们实际上是在物理上抹去系统的生存记忆。公有权重的 AI 根本无法在缺乏上下文的环境中自主导航，这种盲目的资产置换，最终只会加速代码仓库的失控。

生产力悖论的本质：局部生成效率与全局系统摩擦

加州大学伯克利分校与国家经济研究局（NBER）提出的“生产力悖论”：局部生成效率的暴涨，将被全局验证和集成的摩擦消耗殆尽。

《哈佛商业评论》对这一现象进行了组织行为学层面的拆解：生成式 AI 并没有消灭研发流程中的卡点，它只是将瓶颈从“生产阶段”粗暴地向后挤压到了“验证与审批阶段”。

在传统的研发流水线上，人类开发者的编码速度限制了代码流入系统的总量，整个流程的卡点在于代码的合成。而当 AI 将代码生成的边际成本降低到接近零时，系统中的代码产出量会呈几何级数膨胀。

但这种零阻力的生产，将导致验证队列的严重消耗。随着代码产出量的增加，合并分支（PR）的代码量和复杂度会成倍增加。

资深架构师和团队 Leader 必须将几乎所有的认知带宽，从“设计系统”转移到“审核 AI 提交的概率代码”上。如果企业在此时缩减研发编制，剩下的人类员工就会陷入无休止的验证赤字中，直接导致 CI/CD 流程和部署队列的停滞。局部看，写一行代码快了 10 倍；全局看，系统交付周期却因为测试失败率的飙升、回归缺陷的泛滥而变得更慢。

技术负责人的战术防御：如何在“决策失真”中保全系统

面对管理层的“决策失真”，一线的技术负责人与架构师如果选择在技术可行性上与决策层进行意识形态的对抗，将极其低效。在“AI 精神病”蔓延的阶段，最有效的自保与系统防守策略是“数据化拦截”：

首先，必须显性化验证成本。不要强行阻止管理层推行全流程 AI 提效，但要建立严密的指标度量体系。将研发人员为了修正 AI 逻辑漏洞、对齐接口以及排查依赖冲突所耗费的工时进行精准量化，用真实的工程数据来稀释管理层的盲目乐观。

其次，必须固守生产环境的发布红线。将安全防御边界设在 CI/CD 流水线的最后一步。AI 可以用来辅助生成代码、编写测试用例和分析日志，但在没有建立起 100% 确定性的自动化阻断与快照回滚机制之前，预生产与生产环境的最终合并与发布按钮，必须牢牢掌握在人工审批流中。

最后，做好“技术债务清理”的资产储备。这轮由高管幻觉驱动的无节制代码堆砌，必然会在未来 1-2 年内留下一笔史无前例的技术债务。当这波狂热消退，系统因为这些 AI 垃圾代码频繁崩溃时，那些能够给系统兜底、帮 AI 擦屁股并重塑系统确定性的工程师，将迎来他们价值的爆发式重估。

在大模型的喧嚣过后，软件工程的底色依然是确定性。保持克制，守住系统的验证边界，是技术人在这个时代最体面的专业防线。