思想领袖
为什么即装AI代码会让开发人员感到沮丧 —— 以及如何解决这个问题

大多数技术的使用时间越长,人们就会越来越平静地依赖它们。然而,AI工具的情况却恰恰相反:在其年度调查中,超过49,000名开发人员的使用率从40%上升到84%,但对这些工具的准确性的信任却从40%下降到29%。
这种现象我也曾经历过。我们第一次使用AI工具时,开发人员对其产生的代码感到失望:代码质量一般,需要花费大量时间来审查,最终还需要重写。团队原本期望AI能够节省时间,但最终却得到了额外的工作。因此,不久之后,团队就放弃了使用AI工具,恢复了传统的工作方式。
如今,这些工具已经能够加快我们的开发人员编写和审查代码的速度——这并不是因为我们找到了更好的模型,而是因为我们改变了使用它们的方式。以下是我们做出的改变。
为什么AI生成的代码会让开发人员感到沮丧
AI工具依赖于互联网上大量的公共代码,这些代码的质量往往一般。因此,AI工具生成的代码也只是平均水平。
但是,“平均”并不是最高的标准——它只是模型在不知道项目细节的情况下产生的结果。在一项对600多名开发人员的调查中,Qodo 发现,44%的开发人员对AI代码质量不满意,主要原因是缺乏上下文。这就是为什么AI工具生成的代码质量停留在一般水平的原因。
好消息是,AI工具接收到的上下文是唯一可以完全控制的变量。工具对项目的理解程度取决于输入的质量,而不是模型本身。
第二个原因是心理上的:工作的性质发生了变化。当AI生成大部分代码时,开发人员的主要工作不再是编写代码,而是审查生成的代码:阅读别人的解决方案,权衡选择,决定什么可以发布。这需要不同的技能,而对于那些喜欢编写代码的人来说,这并不容易。
在其2025年Octoverse报告中,GitHub 描述了这种转变:那些最远地使用AI的开发人员不再自称为“代码作者”,而是成为“创意总监”,其中的关键技能是引导和验证。但是,走到这一步的路上充满了错误和沮丧,直到他们在自己的工作中看到成效。
什么让AI从沮丧的源头变成可用的工具
当我们的团队第一次开始使用AI工具时,一些开发人员使用的是Claude Code,其他人尝试的是OpenAI Codex、GitHub Copilot或Gemini CLI,每个工具都产生了不同的结果。因此,当我们开始整理团队使用AI的方式时,第一步就是选择一个统一的工具。
这不仅仅是我们的做法。以Linear团队的故事为例:直到2026年初,他们遵循“让每个人按照自己的方式工作”的原则,但是在2026年1月,领导层放弃了这种方法,要求所有开发人员使用两种AI工具来编写代码,而不是手动编写。根据公司的说法,平均生产率在接下来的一个月内提高了30%,合并的PR数量增加了33%。
然而,仅仅拥有统一的工具是不够的——还需要配置:设置规则,例如rules.md,来规定如何编写代码;然后是为项目中的典型任务设置自定义技能,以避免重复解释。最后,值得将工具指向现有的代码库:它分析项目的编写方式,并以相同的风格生成新代码,而不是通用的风格。工具接收到的上下文越多,需要手动重写的代码就越少。
但最难的部分不是技术问题——从代码作者转变为代码评估者需要帮助。最直接的方法是培训和认证。例如,我们的十名开发人员正在参加工具提供商的合作伙伴计划,同时有一名负责采用的工作人员解释工具为什么产生了某个结果以及如何修复它。
一旦团队开始协调工作,仍然存在一个瓶颈——审查。值得用AI来加强审查:工具首先检查每个拉取请求,处理明显的问题:常见错误、风格、重复、安全漏洞。人类审查者不再检查所有内容,而是专注于架构和关键决策。这种效果在构建这些工具的公司内部也很明显:在Anthropic引入此类工具后,接受实质性审查的拉取请求比例从16%上升到54%,工程师们对其评论的异议不到1%。
对于我们来说,这缩短了之前需要两三天、多轮审查的周期,并且减轻了高级工程师的负担,让他们专注于真正困难的部分。最后,当工具开始产生不需要重写的结果时,信任也随之产生。
在哪里信任AI工具会带来回报
首先也是最重要的——编写代码:当工具了解项目,代理处理第一次审查时,团队在相同的时间内编写更多、更好的代码。在我们的例子中,AI工具加快了工作速度大约30-40%。
此外,AI使得入职更加容易。当新人加入项目时,通常需要有人有经验的人回答关于项目代码结构的许多问题。现在,代理可以承担这一角色:如果项目文档良好,新人可以将95%的问题直接问代理,而不是问同事。
文档也是如此:以前需要花费数小时的粗略架构草稿,现在基本上都是由代理自己编写的——我们估计,如果提供足够的上下文,代理可以编写大约80%的草稿。人类的任务是处理不在仓库中的内容:决策、权衡、专业知识。
同样重要的是,要对AI的能力保持诚实,因为过高的期望会导致最初的失望。AI不会处理合规性——人类会对医疗或财务数据进行签署,公司而不是模型对泄密负责。AI也不会加快与合作伙伴的集成,在那里,数十个小时的通话和协调是必要的。
即装AI确实令人沮丧——但仅当它被用作最终解决方案时。沮丧和回报之间的全部差异在于你围绕它建立了什么:一个共享的标准、项目的上下文和开发人员的新角色。












