Greptile——一款被 2000 多家公司采用的 AI 代码审查智能体——发布了其 AI 辅助编程年度报告。该报告基于 每月由 AI 审核的 10 亿行代码 数据，描绘了一幅生产力显著提升的图景。然而，在开发者社区的讨论中——尤其是在 Y Combinator 论坛——不少工程师却表示，真实体验远没有报告所呈现的那样简单。
有一个核心结论几乎无法忽视：在 AI 的支持下，工程师正在提交更多代码。
根据 Greptile 的数据，开发者 每月提交的代码行数 从 4450 行 提升至 7839 行，增长幅度达到 76%。对于 6–15 人的中型团队，增幅更为夸张——人均提交量几乎翻倍，提升 89%。换句话说，AI 编程工具正越来越多地扮演着 “效率放大器” 的角色。
报告还指出，代码变化不仅更快，而且 单次迭代的规模也更大。
在一次提交中，每个文件的代码变更行数中位数 提升了 20%，从 18 行增加到 22 行。这一变化意味着，开发者在每次修改中覆盖的范围更广，也可能表明 AI 工具正在被用于更复杂的改动和不断演进的需求，而不再只是简单的自动补全。
尽管如此，许多程序员的反应依然谨慎，甚至带着怀疑。
在 Y Combinator 论坛上，一个常见的观点是：AI 生成的代码往往需要花大量时间进行调试、修改和清理，而这些真实投入并未被“提交行数”这样的指标捕捉到。边界情况、系统集成问题、隐蔽的 Bug——这些摩擦成本几乎不会出现在宏观统计图表中。
最核心的质疑其实很直接：代码行数增加，并不必然等于生产力提升。
一个初级开发者可能需要几十行代码才能实现的功能，资深工程师用几行就能完成。与此同时，如果 AI 让代码总量变多了，那么 后续被删除、重写或重构掉的代码 又该如何计算？这些数据并不容易统计，但往往正是生产力真正提升或下降最明显的地方。
还有一种观点，直接挑战了“用行数衡量效率”的前提假设。
如果所有工程师能力相同、任务复杂度也一致，那么产出更多代码或许能代表效率更高。但现实中的工程工作并不均质。有些任务非常困难，需要深厚经验，却只产生很少的代码；有些任务很简单，却天生冗长。只看提交量，本质上是把所有任务都当成“中等难度”来衡量，必然失真。
代码质量，是另一个被忽略的关键维度。
这份报告强调数量，却并未直接评估新增代码是否 更好、更安全、更易维护。从另一个角度看，每一行额外的代码都是一种负担，而不是资产——它需要被测试、审查、维护，并在未来被调试。最终，团队仍然需要领域专家来判断：到底应该存在多少代码。
一位评论者用一个生动的比喻点出了问题的本质。
你可以通过“每小时搬运多少件物品”来衡量仓库员工的效率。但如果有人开始 随意扔箱子，或者搬运本来不需要移动的货物，他们就能最大化这个指标，却反而损害了整体运营。
AI 的确能帮助开发者生成更多代码，但真正的问题在于：这些代码是否真的有必要，才能完成目标？
如果组织只奖励更高的提交量，可能会无意中鼓励重复劳动、过度设计和代码膨胀。仅仅衡量“提交的行数”，很容易从结果指标变成被刻意优化的目标。
从这个角度看，也许 “编辑的代码行数” 比 “新增的代码行数” 更合理。
这样一来，通过重构来缩小代码库规模，仍然可以被视为高生产力行为。一个简单的思路是：删除一行代码得 1 分，新增一行代码也得 1 分——鼓励有意义的改变，而不是单纯的扩张。
OpenAI 仍然领先，但差距正在缩小
在生产力提升的叙事背后，是整个 AI 工具栈的重塑。报告还使用 SDK 下载量 作为采用度的代理指标，来观察生态系统的变化。
在 AI 记忆组件 中，mem0 以 59% 的市占率 一骑绝尘。而在 向量数据库 领域，竞争要激烈得多：Weaviate 以 25% 领先，Chroma、Pinecone、Qdrant 等紧随其后。
在 LLMOps 层，报告强调了基础设施的高速增长。
LiteLLM 的下载量据称 增长了 4 倍，达到 4100 万次；LangSmith 则借助与 LangChain 生态的深度绑定迅速上位。一个明确的趋势正在形成：模型调度、监控、降级和可靠性控制，正从“可选项”变成 基础设施标配，就像当年的 Kubernetes 之于微服务。
报告还对 2022 年 1 月至 2025 年 11 月 期间主要模型厂商的 SDK 下载量进行了比较，重点关注 OpenAI、Anthropic 和 Google GenAI。
OpenAI 依然是绝对领导者，其下载量从 2022 年初几乎为零，增长到 2025 年 11 月的 约 1.3 亿次。Anthropic 的增长则被形容为“火箭式”：自 2023 年下半年开始陡增，到 2025 年 11 月达到 约 4300 万次，报告称这是 自 2023 年 4 月以来 1547 倍的增长。相比之下，谷歌的曲线更为平缓，2025 年 11 月约为 1360 万次。
报告认为，这反映出开发者正在用脚投票，越来越偏好 更可控、更可编程、更开放的接口，尽管 OpenAI 依然保持着最大的市场规模。
模型特性决定最适合的编程场景
Greptile 还分享了 五种主流模型 作为编程智能体后端的基准测试结果，对比了 首 token 等待时间、吞吐量和成本 等指标。
在 交互式编程 场景中，“首 token 时间”尤为关键。报告指出，Claude Sonnet 4.5 和 Opus 4.5 在 2.5 秒以内 就能返回首个 token，明显快于 GPT-5 系列（超过 5 秒）。在实际体验中，报告认为 约 2 秒 往往是进入心流与被打断注意力之间的临界点。
但在 批量生成 场景下，结论则发生了反转。
报告认为，GPT-5-Codex 和 GPT-5.1 在吞吐量上断崖式领先，更适合用于 CI/CD 流水线中的大规模代码生成或测试用例填充。而 Gemini 3 Pro 的响应明显更慢，往往需要 10 秒以上 才返回首个 token，每秒输出的 token 数也较少，因此并不适合交互式编程。
研究前沿正在指向哪里
在最后一部分，报告列出了 2025 年 若干关键论文，暗示下一波突破方向。
例如 Self-MoA 表明，通过 单模型多次采样并聚合，可以超越传统的多模型混合方案，这意味着关注点可能从“模型多样性”转向“推理路径多样性”。Search-R1 使用强化学习，让模型 自主决定何时进行搜索，将搜索引擎从静态工具调用，变成可学习的环境动作。RetroLM 则尝试在 KV 层面直接检索，绕过原始文本，可能改变大模型组织和调用记忆的方式。
即便 AI 无处不在，人工审查仍不可或缺
无论 AI 辅助编程多么先进，代码在真正落地之前，人类审查依然不可替代。使用数据和自动化审计，很难完整反映开发者在验证、修正和做判断时投入的时间与精力。
如果一种 AI 编程工具能够证明：它帮助团队 更快、更有信心地交付功能，而不仅仅是让更多代码行通过审查，那么它的价值，才会真正变得 对工程师和业务方都清晰可证。
