AI融入开发两年：我们学到的经验与启示本文总结了AI融入开发两年的经验，指出AI并非提升代码速度，而是通过减少上下文切换

本文总结了AI融入开发两年的经验，指出AI并非提升代码速度，而是通过减少上下文切换、加速陌生技术与遗留代码理解等方式，提升工程师综合能力。深度仓库集成是关键。文章探讨了AI在技术采用、测试及服务脚手架上的持续价值，也强调了其在业务意图、安全和架构决策上的局限性，并提出了有效的实践策略。

译自：Lessons from 2 Years of Integrating AI into Development Workflows

作者：Nishant Ghan

两年前，我开始尝试使用AI辅助开发工具。如今，它们已融入我们整个工程组织的日常工作流程中。实现这一目标并非仅仅是采用最新模型，而是要区分哪些能够有意义地改善工程成果，哪些只是徒增噪音。

在一家大型云基础设施公司将AI集成到生产开发中后，我认识到，成功与否更多取决于你将这些工具应用到何处，而非工具本身。

真正重要的摩擦

问题从来都不是更快地编写代码。高级工程师不会为语法而烦恼。真正的摩擦来自上下文切换、不熟悉的堆栈以及融入了多年隐性决策的遗留系统。

学习新框架会带来认知负担。理解一个你没有编写过的大型代码库需要时间。即使对于经验丰富的工程师来说，跨多种语言和生态系统工作也会减慢他们的进度。

这些正是AI辅助能提供真正价值的领域。通过降低在不熟悉领域快速入门的成本，它改变了你跨多样化堆栈的生产效率。

加速不熟悉技术的采用。 在实施超出我 immediate 专长的系统时，AI在理解核心概念、审查常见模式和生成初始脚手架方面已被证明非常有用。其输出并非生产就绪，但提供了足够的依据以高效地查阅官方文档。从几天到几小时，即可获得工作原型。
跨框架的测试脚手架。 每个项目都使用不同的测试工具。我不是从头开始重建设置模式，而是描述需求并审查生成的脚手架。这使得精力从框架机制转向有意义的测试逻辑。生成的代码是一个起点，而不是最终产物。
理解遗留代码。 AI在解释控制流、揭示隐藏假设以及建议保持行为不变的重构方面非常有效。它加速了构建你没有编写的代码的心智模型，尽管所有更改仍需要仔细的人工审查。
服务脚手架。 新服务通常需要重复的样板代码：路由、日志记录、配置、错误处理。AI可以根据规范生成初始结构。真正的任务是将其调整为组织标准，但初始设置时间显著缩短。

早期的AI工具在没有上下文的情况下运行。每个提示都需要重新说明架构、约定和依赖项。

理解你的仓库的工具改变了这种动态。它们在提出更改建议时会考虑现有模式、文件结构和依赖项。这种上下文允许它们提出真正适合你的系统的修改，而不是通用示例。

在调试时，这些工具可以一起分析构建错误、配置和代码。正是这种上下文感知能力将AI从新奇事物变成了工作流程加速器。

这些提升并非来自AI“编写代码”。

它们来自于：

最大的转变是信心的提升。以前需要大量准备的任务现在变得易于接近，这扩展了单个工程师可以承担的工作范围。

在团队中全面推广并非一蹴而就。

许多工程师尝试过AI工具，但由于效果不佳而弃用。在大多数情况下，问题在于提示质量，而非工具能力。提出精确、有上下文的问题是一项通过实践才能提高的技能。

此外，对于过度依赖也存在合理的担忧。高级工程师担心技能退化。初级工程师担心学习捷径而非基础知识。这两种担忧都是合理的。

有效的方法是避免一概而论的全面采用，而是展示有边界的使用案例。“用它来理解一个不熟悉的测试框架”是可操作的。“AI让你更快”则不然。

AI难以理解业务意图。它可以解释代码的作用，但不知道该行为是否正确。

对安全性敏感的代码需要格外谨慎。看似合理的建议可能隐藏着微妙的漏洞。认证、授权和加密必须牢牢掌握在人类手中。

架构决策也仍然是人类的领域。AI可以提供选项，但它不了解团队的优势、运营实际情况或组织限制。这些因素通常比技术上的优雅更为重要。

两年后，最大的变化并非代码输出量的增加，而是能力的扩展。

工程师在不同堆栈之间切换变得更加容易。学习新框架从几天缩短到几小时。大型、不熟悉的代码库能更快地被理解。上下文切换的认知成本显著下降。

AI不会取代工程判断力。它能减少开发过程中的摩擦，并降低在核心专业领域之外进行有效工作的门槛。

如果你正在为工程团队评估AI，请首先确定你真正的工作流程瓶颈。然后问问AI是否能有意义地减少这种摩擦。答案取决于具体上下文，但评估框架保持不变。