给予AI值得放大的价值：技术领导者的三个优先事项
大多数机构都在问：人工智能能为开发人员做些什么？但一个更难的问题是：你的开发人员能为人工智能带来什么？
DORA 的《2025 年 AI 能力模型报告》指出，AI 并不会拉平团队水平，反而会放大现有的差距。强大且高绩效的组织能从 AI 中获得更多收益，而表现不佳的组织的弱点则会变得更加明显。
在个人层面似乎也是如此。GitClear 在 2026 年 1 月的一项分析中研究了 2,172 个开发人员周的数据，发现经常使用 AI 的开发者产出的持久代码量比非用户多出约 320%（4.2 倍）。这些用户在 2024 年到 2025 年间的产出也增长了 25%。这是一个显著的提升，但这本身并不能解释全部差距。GitClear 的结论是，AI 拉大了本已存在的绩效差异。经验丰富、高产出的工程师往往是首批采用 AI 的群体。
这一点至关重要，因为 AI 并非在真空中运行。它建立在团队现有的习惯、系统和约束之上。如果基础稳固，AI 可以提供助力；如果基础薄弱，AI 则会使弱点进一步扩散。
其中一些基础很容易观察到。基础设施体现在资产负债表上，而工具则可以进行盘点。本文重点讨论三个更容易被忽视的领域：代码审查、技术债务和开发者的判断力。这些并非新问题，但 AI 让人们更容易忽视它们，同时让后果变得更难规避。
重点 1：加强代码审查
AI 让开发人员能够在更短的时间内编写更多的代码，但这只有在审查流程能够处理额外的工作量时才有意义。如果审查流程本身已不堪重负，AI 并不能解决问题，它只是将更多的代码推向了同一个瓶颈。更大规模的代码变更集接踵而至，责任归属变得模糊，审查工作也退化为仅仅扫描明显的危险信号，而无法全面理解变更内容。
这一点已在数据中有所体现。LinearB 的《2026 年软件工程基准报告》发现，包含 AI 辅助代码的拉取请求（Pull Request）的审查等待时间大约是非 AI 代码的 2.5 倍。当代码由 AI 代理自主编写时，延迟时间则上升到了 5.3 倍。其原因显而易见——开发人员对于处理那些看起来更大、风险更高的审查任务感到犹豫。
因此，问题不仅仅在于工作量，更在于“工作量加不确定性”，且流向了一个尚未更新的流程中。
这就是为什么解决方案应该是流程优化，而非增加人手。
建议采取的后续行动：
- 建立或收紧拉取请求的批量标准。 DORA 将小批量处理视为防止“难以审查的代码转储”的最佳防线之一，而 AI 让这种转储变得更容易实现。
- 将静态分析作为真正的门槛，而非建议。 仅靠审查者的评估，无法可靠地将高质量的拉取请求与劣质的区分开来。一项针对 36,000 个拉取请求中 470 万个代码质量问题的 2019 年研究发现，在代码质量指标上，被接受和被拒绝的拉取请求看起来惊人地相似。2026 年 1 月的一项研究证实了 AI 生成代码中也存在同样的模式。静态分析减少了在“接受”或“拒绝”决策中的主观猜测。
重点 2：保持对技术债务的纪律性
AI 可以帮助减少现有的技术债务、改进文档、增加测试并进行重复性的清理工作。但它也可能让团队以比代码库所能吸收的速度更快地堆积新的债务。三组独立的数据都指向了同一个方向：
- GitClear 对 2.11 亿行代码进行的 2025 年纵向分析发现，代码流转率（Code Churn）在 2020 年到 2024 年间增长了 84%。重构工作大幅下降，从 2021 年占变更行数的 25% 降至 2024 年的 10% 以下。2024 年重复代码块出现的频率是 2022 年的 10 倍以上。GitClear 将这些变化与 2022 年后 AI 辅助编码的兴起联系了起来。
- Faros AI 对 10,000 多名开发人员的遥测数据进行的 2025 年分析发现，从低 AI 采用率转向高 AI 采用率的团队，每位开发人员的 Bug 数量增加了 9%，平均拉取请求规模扩大了 154%，审查时间延长了 91%。个人产出增加了，但组织绩效却没有。
- 一项 2025 年卡内基梅隆大学的研究发现了类似的情况。研究人员追踪了 806 个采用 AI 编码工具的团队，并将其与 1,380 个未采用的团队进行了比较。采用后，静态分析警告增加了约 30% 且持续处于高位。认知复杂度增加了约 41%，即使在研究人员控制了代码库增长因素后，这一数值依然居高不下。代码不仅变得更庞大，而且更难理解了。
这种模式显而易见：产出的增长速度超过了其配套的质量控制体系。
这并不意味着团队需要减少 AI 的使用，而是意味着在时间分配上需要更强的纪律性。
建议采取的后续行动：
- 明确预留冲刺（Sprint）容量用于削减技术债务。 如果 AI 增加了交付压力，那么重构和静态分析就变得更加重要，而非相反。
- 在 AI 使情况恶化之前，先梳理你的知识风险。 询问开发人员，代码库中哪些区域是他们在没有长时间上手准备的情况下不敢修改的。利用这一点来确定重构、文档编写和刻意进行审查者轮换的优先级。
重点 3：为开发者的判断力提供试炼场
更好的代码审查和更强的债务纪律，都依赖于一个更基本的前提：人们必须真正具备识别代码优劣的能力。这种能力不会自动出现，而 AI 让人更容易逃避培养这种能力的必要性。
- Anthropic 2026 年 1 月的一项随机对照试验使这种风险变得具体化。研究人员将学习陌生 Python 库的初级开发人员分为“AI 辅助组”和“手动编码组”。那些将代码生成交给 AI 后就不再深究的开发人员，在随后的理解力评估中仅获得 24% 到 39% 的分数。而在使用 AI 的同时积极构建理解的开发人员，得分在 65% 到 86% 之间。Anthropic 的结论非常直白：“生产力的提升可能以牺牲验证 AI 编写代码所需的必要技能为代价。”
- 微软 Azure 首席技术官兼开发者社区副总裁将其描述为一种“以资历为导向的技术变革”。资深工程师受益匪浅，因为他们已经具备了指导、验证和整合 AI 输出的判断力。而经验不足的工程师往往缺乏这种能力。对于他们来说，同样的工具可能带来的不是杠杆作用，而是阻力。
这产生了一种诱人的短期逻辑：雇佣资深人员，自动化初级工作，然后继续前进。这在这一两个季度内可能行得通，但它也可能掏空你未来所需的人才储备。使 AI 变得有用的判断力，必须在被放大之前先培养出来。
建议采取的后续行动：
- 从业务连续性的角度审视你的初级开发人员招聘计划。 四年后你的资深开发人员将从何而来？2025 年的一项 斯坦福数字经济研究发现，在受 AI 影响的职业中，22-25 岁员工的相对就业率下降了 16%，即使在控制了更广泛的公司层面招聘趋势后，这一结果依然成立。
- 弥补 AI 正在造成的指导缺口。 《LeadDev 2025 年 AI 影响报告》发现，38% 的工程主管认为 AI 工具减少了对初级工程师的直接指导。当双方手头都有 AI 助手时，这种知识传递不会自动发生。
- 筛选并入职那些具备 AI 判断力的人，而不仅仅是 AI 使用熟练度。 现在的问题不再是某人是否使用 AI，而是他们是否知道何时不该使用它。
战术建议：设定方向，而非工具
你如何应用这些优先级至关重要。开发人员会感受到“领导”与“控制”之间的区别。《2025 年 Stack Overflow 开发者调查》发现，“自主权与信任”是驱动开发者工作满意度的最强因素。
这种独立性也体现在 AI 工具的选择上。Harness 的《2025 年软件交付状况报告》发现，52% 的开发人员不使用 IT 部门提供的 AI 工具。这可能不是争取标准化的地方。
不要标准化模型选择，不要标准化助手，要标准化访问层。
为你的团队提供一个适配任何 AI 工具的工作空间
JetBrains IDE 为你的开发人员提供了一个统一的环境，几乎可以与任何大语言模型和兼容 ACP 的编码代理协同工作。这意味着他们可以尝试新工具，而不必在每次市场变动时都重构工作流程。
在这种灵活性之下，是一个更稳定的核心：IDE 对代码库的结构化模型。它不是在猜测代码的含义，而是将代码作为代码来理解。当 AI 生成的内容看起来合理但实际上破坏了其他地方的功能时，IDE 可以在变更进入审查前发出警告。加上 JetBrains Qodana，同样的结构化模型可以扩展到整个代码库的持续静态分析中。
这就是实际意义所在：只标准化那些应该标准化的部分，其余部分保持灵活性。All Products Pack 也支持同样的逻辑。它通过一个订阅涵盖了所有 JetBrains IDE，每个 IDE 都是为当前或未来所需的主要语言量身定制的。当开发人员在技术栈之间切换时，无需许可申请、无需采购延迟、也无需重新审批。
决策已经做出，工具已经就绪。