一支软件团队里，最难处理的 AI 编程分歧，往往不是“用不用”。

更麻烦的问题是：有人觉得不加速就会被甩开，有人觉得再加速系统就没人看得懂。两边坐在同一个会议室里，目标也差不多——都想把软件做好。

Simon Willison 转引 Charity Majors 的文章时，把这组矛盾说得很准：AI 拥护者在和时间赛跑，AI 怀疑者在和熵增赛跑。

我更在意的不是哪一派赢，而是那句关键判断：没有自然反馈回路连接拥护者与怀疑者。

这句话才是工程团队要面对的现实问题。

两种焦虑都是真的

Charity Majors 没有把争论写成“先进派”和“保守派”的对立。她的判断是：AI 拥护者并没有错，怀疑者也没有错。

拥护者看到的是能力跃迁。深度使用 AI 的团队，确实可能在写原型、补测试、迁移代码、处理样板逻辑上跑得更快。对竞争压力大的团队来说，完全观望不是中性选择，可能就是把窗口让给别人。

怀疑者看到的是另一种成本。代码生成得越快，工程师未必读得越快。系统一旦超过团队的理解能力，问题不会马上出现在漂亮的交付看板里，而会沉到代码库、报警、回滚和事故复盘里。

这两种风险都不像短期指标那么好看见。

角色盯着什么风险合理之处容易漏掉什么
AI 拥护者错过工具带来的能力跃迁竞争窗口不会等团队慢慢统一意见生成代码的长期维护成本
AI 怀疑者系统变得不可理解、不可排障可靠性和团队知识需要多年积累过度保守会拖慢试错
技术负责人两派各说各话需要把争论变成流程和边界不能只靠态度压一边
on-call 工程师凌晨要读懂白天合进去的代码最先承受系统失控成本往往没有参与前面的工具决策

这里的反常点在于：双方都在保护团队，只是保护的对象不同。

拥护者保护的是速度和机会。怀疑者保护的是理解和可靠性。软件团队的问题，恰恰出在这两件事没有被放到同一个反馈系统里。

真正缺的是反馈回路

AI 编程工具容易制造一个误会：个人写代码更快，团队交付就一定更好。

但软件交付不是把更多代码塞进仓库。交付还包括评审、测试、上线、监控、回滚、值班和事后学习。任何一个环节接不住，前面的速度都会变成后面的债。

这也是 Charity Majors 说它既是领导力问题，也是工程问题的原因。

领导力问题在于，团队要决定边界：哪些任务可以放心交给 AI 辅助，哪些核心模块必须有人能讲清设计，哪些变更不能只看“能跑”。

工程问题更具体：AI 参与的代码是否走同样严格的 review？是否补了测试？监控能不能覆盖新逻辑？事故复盘时，能不能追到当时为什么接受这段生成结果？

这些问题不解决，拥护者和怀疑者就会各自拿着一部分事实说话。

DevOps 的历史可以做一个小参照。云和自动化发布把软件交付速度推高后，成熟团队后来补上了 CI/CD、灰度发布、SLO、可观测性和事故复盘。不是速度天然有罪，而是速度必须被约束在可验证、可回滚、可学习的机制里。

AI 编程现在也在走到这个关口。

不同规模团队的约束还不一样。小团队可能先要避免“没人知道这段代码怎么来的”。大团队更要防止 AI 生成改动穿过多个服务后，责任边界被冲淡。

团队状态更现实的动作目的
刚开始引入 AI 编程工具先限定使用场景，比如测试、脚本、样板代码降低试错成本，避免一上来碰核心链路
已经大量使用 AI 辅助开发在 PR 中标记 AI 参与范围，补设计说明和测试要求让评审者知道该重点看哪里
on-call 压力已经上升在事故复盘里记录 AI 工具参与情况和失效原因把模糊争论变成可追踪事实
核心系统复杂度高对关键模块设置人工理解门槛确保有人能解释、能回滚、能排障

这不是给 AI 编程设路障。

这是给速度装刹车和仪表盘。没有刹车，快就是风险；没有仪表盘，慢也未必安全。

最该动手的是技术负责人和 on-call 体系

对工程团队负责人来说，最现实的动作不是再开一轮“支持还是反对 AI”的会。

更有用的是把规则写进流程：

  • 哪些仓库、模块、任务允许 AI 深度参与；
  • 哪些核心代码必须有人工设计说明；
  • AI 辅助生成的改动，是否需要额外测试或更严格 review；
  • 事故复盘是否记录 AI 工具参与情况；
  • on-call 工程师是否能看到足够上下文，而不是只接到报警。

这些动作不华丽，但能减少互相消耗。

对 on-call 工程师来说，这件事更贴身。白天被 AI 加速合并的代码，凌晨可能就是他们要读懂的报警。团队如果没有共享上下文，所谓交付效率会变成值班人员的认知负债。

现实约束也要说清楚：不是每个团队都有余力做完整治理。创业团队可能更看重速度，大型团队更看重稳定性。不同选择都可以成立，但不能假装没有代价。

接下来最该看的，不是某个工具又提升了多少补全能力。

更该看三件事：代码评审有没有跟上，系统可观测性有没有覆盖 AI 带来的改动，事故复盘能不能把“当时为什么信这段代码”讲明白。

如果这些答案长期缺席，团队里会出现一种很尴尬的局面：拥护者继续正确，怀疑者也继续正确。只是系统越来越难被共同理解。

这才是 AI 编程争议里最危险的部分。