AI 拥护者与怀疑者：一场时间与熵的赛跑，以及组织最缺失的反馈回路

Simon Willison 近期推荐了 Charity Majors 的一个观点，用两个精妙的比喻把 AI 时代软件团队的内在冲突剖开：AI 拥护者是在「与时间赛跑」，AI 怀疑者则是在「与熵赛跑」。

两个真实的生存威胁

拥护者的逻辑很直观。我们已经看到一些团队凭借 AI 辅助开发实现了跳跃式的能力提升，这种提升不是渐进式的，而是带有断层性质的。如果等待技术稳定、等待工具成熟、等待最佳实践出现，竞争对手可能已经用 AI 生成的方案拿下了市场。这不是舆论恐慌，而是真实的生存威胁——赛道可能在尘埃落定之前就关闭了。

怀疑者的恐惧同样具体。当代码以超过人类审阅能力的速度被生成出来，当系统中越来越多的模块没有人能完全掌握上下文时，你其实是在透支团队多年建立起来的信任账户。系统可靠性下降、隐性知识蒸发、故障响应变成一场噩梦。最终你会得到一个无人理解的产品，以及一群疲惫不堪的值班工程师。这也是真实的生存威胁。

速度与质量的非零和博弈

表面看这是速度与质量的经典矛盾，但 Charity 的点睛之笔在于：两种观点「都没错」。这意味着问题的本质不是争论谁对谁错，而是两个正确世界之间的沟通断裂。

一个团队里，拥护者体验到的收益是真实具体的：一个需求从描述到可运行原型只需要几分钟；怀疑者看到的代价也同样真实：AI 生成的代码带着微妙的错误，错误处理一塌糊涂，抽象混乱，但已经进入了主分支。双方在各自的事实世界里制定决策，却缺少一个双向的信息通道。

缺失的反馈回路

这就是 Charity 提出的核心诊断：「不存在连接拥护者与怀疑者的自然反馈回路」。在传统软件工程中，代码评审、测试、上线监控等机制天然构成了一套反馈系统，但它们的节奏是以人类开发速度设计的。当 AI 将生产速度提升几个数量级时，原有的反馈机制就被淹没了。

这不是一个技术问题，而是一个组织设计问题。你需要刻意构建新的反馈回路，让「速度带来的教训」能够流入「质量保障的流程」，也让「稳定性方面的发现」能够反过来影响「如何更好地利用 AI」。比如，将 AI 生成代码的 bug 模式定期回馈给提示词设计；或者创建专门的「AI 产出复盘」环节，让拥护者和怀疑者坐在一起，基于真实数据而不是印象来讨论。

趋势与启示

这件事揭示了一个更大的趋势：软件工程正在从「制造」范式转向「管理」范式。过去工程师的主要工作是编写代码，现在越来越多的工作变成了管理 AI 的输入、验证 AI 的输出、维护系统整体的可理解性。这种转变要求组织能力的一次升级——不再是单纯的工程能力或管理能力，而是两者在更高层面的融合。

对于技术领导者和一线工程师来说，这提醒我们不要陷入「选边站」的思维。真正有价值的工作是主动建造那缺失的反馈回路。它可能是一个轻量的数据面板，追踪 AI 贡献代码的缺陷率、回滚率；也可能是一个定期的交流会，让双方分享实际案例。无论形式如何，它的目标是修复两个群体之间日益扩大的「现实认知差距」。

AI 时代的竞争优势，可能不仅取决于你用多快的时间交付了多少功能，更取决于你是否能比对手更快地建立这种内部反馈循环——既拥抱速度，也驯服熵增，让两个赛跑的人最终朝同一个方向前进。

原文地址: AI enthusiasts are in a race against time, AI skeptics are in a race against entropy