6 月 4 日，Simon Willison 转引了 Charity Majors 的一段判断：软件团队里的 AI 拥护者和怀疑者，可能都没错。

这句话有意思的地方在于，它没有把争论写成“先进”和“保守”的冲突。更真实的场景是，同一个团队里，两派人都想把软件做好，只是盯着两种不同的生存风险。

两种风险都是真的

AI 拥护者看到的是时间压力。

一些团队把 AI 编程工具用得很深后，确实可能出现能力跃迁。原文用的是“真实、非想象、非连续”的提升。这个判断不能被轻轻抹掉。对竞争激烈的团队来说，等尘埃落定再动手，可能已经太慢。

AI 怀疑者看到的是熵增压力。

当代码产出速度超过工程师阅读、理解和审查的速度，团队就在透支一笔多年攒下来的信任账户。代码能跑，不等于系统可维护。上线更快，也不等于值班更轻。

可以把两派看到的东西压成一张表：

角色看到的现实害怕的风险合理动作
AI 拥护者AI 工具带来真实能力提升，竞争对手可能加速团队观望太久，错过提效窗口试点工具、改开发流程、训练团队使用方式
AI 怀疑者代码生成可能快过人工审查和理解可靠性下降、知识流失、值班压力加重加强 review、测试、可观测性和责任边界

这也是我更在意的一点：两派的目标并不冲突。拥护者不是天然不要质量，怀疑者也不是天然反对工具。

冲突发生在风险计量方式不同。一个人拿交付速度说话，另一个人拿返工、故障和维护成本说话。指标不接上，争论就会变成各说各话。

真正缺的是共享现实

Charity Majors 提到一个关键句：两派之间没有天然反馈回路。

这句话比“要不要用 AI”更重要。因为工具采购很容易，团队共识很难。买一个 AI 编程工具，只需要预算和权限；让团队知道它到底提高了什么、制造了什么债，则需要工程系统自己给出答案。

软件行业以前也见过类似张力。持续集成、DevOps、云原生都把交付速度往前推过。但成熟做法不是只催发布，而是配套测试、回滚、监控和复盘。

AI 编程的麻烦在于，它直接进入代码生产环节。

GitHub Copilot 2021 年面向开发者推出，ChatGPT 在 2022 年 11 月之后让自然语言生成代码变得日常。近两年，Cursor、Claude Code 这类工具又把模型带进更完整的开发流程。

门槛降了，治理要求反而升了。

AI 生成的代码看起来像完成品，但它不会自动带上上下文、责任人和长期维护知识。一个 pull request 能不能合并，不只看测试是否通过，还要看谁理解设计取舍、谁能排障、半年后谁愿意接手。

限制也要讲清楚：目前不能把“用了 AI”直接等同于“系统一定失控”，也不能把“没用 AI”直接等同于“公司会失败”。原文说的是两类可能的生存威胁，不是已经发生的结论。

工程负责人要把 AI 接进治理系统

这件事最直接影响两类人：工程管理者和软件团队技术负责人。

工程管理者要决定节奏。不是全面禁用，也不是全面放开，而是先划试点范围。比如从低风险模块、内部工具、测试代码、文档生成开始，再逐步进入核心链路。

技术负责人要决定门槛。AI 参与生成的代码，不能因为“效率高”就绕过 review、测试、监控和事故复盘。相反，越是生成得快，越要把可理解性写进合并条件。

更实用的观察项可以很简单：

要观察什么为什么要看可能动作
review 队列是否变长产出变快可能把压力转移给审查者限制 AI 生成代码一次提交规模，要求拆小 PR
线上问题是否集中在 AI 深度参与模块判断速度收益是否带来维护成本给相关模块补测试、监控和代码所有人
关键设计是否有人工确认记录防止“代码有了，但没人理解”要求设计说明、取舍记录和负责人签字
值班压力是否上升可靠性成本常在运维阶段暴露把事故复盘反写进 AI 使用规则

对采购和工具迁移也一样。企业不该只看模型演示和插件热度。更稳妥的做法，是延后大规模铺开，先让一两个团队跑出规则：哪些场景允许用，哪些模块要谨慎，哪些代码必须人工重写或加审查。

开发者个人也会被影响。会用工具当然有价值，但更值钱的是能解释工具产出的代码，能判断哪里要拒绝，哪里要补测试。AI 让写代码变快，也让“读代码、改代码、守系统”的能力更显眼。

接下来要看三件事。

一是团队有没有把 AI 使用纳入工程规范，而不是靠个人习惯。二是组织有没有同时度量速度和维护成本，而不是只报“开发快了”。三是事故和返工能不能反向改变工具使用规则。

回到开头那句话：拥护者和怀疑者可能都没错。错的是让他们在同一个团队里，用两套互不相认的现实工作。

AI 编程真正考验的不是口号，而是组织能不能在加速时保住可信度。