14 篇博文 含有标签「developer-tools」

2025 年的一项对照实验让有经验的开发者使用了 AI 编码工具，并测量他们是否变得更快。开发者们预测效率会提升 24%。研究结束后，他们报告自己大约快了 20%。而客观测量显示，他们实际上慢了 19%。

这并不是一个关于 AI 过度炒作的故事。这是一个关于隐性知识的故事——那种存在于每个成熟代码库中、仅靠阅读代码无法恢复的、无文档记录的"为什么"。AI 智能体在全新系统中生产效率出奇地高，正是因为那里几乎没有隐性知识可以违反。它们在成熟代码库中退步，原因完全相同。

AI 编程工具的默认思维模型是 VS Code 内部的一个面板。一个对话框，几个行内建议，或许还有一个“应用差异（apply diff）”按钮。这种构想已经过时两年了。该领域的领先产品并不是 VS Code 扩展；它们是完整的编辑器，只是启动时碰巧看起来像 VS Code。Cursor 是一个分叉版本（fork）。Windsurf 是一个分叉版本。Zed 是一个从零开始构建的原生编辑器。这种模式并非巧合 —— 当智能体（agent）的覆盖面最终超过了宿主编辑器的插件 API 所能支持的范围时，必然会出现这种情况。

如果你正在构建一个编程智能体，并且仍然将“发布一个插件”视为理所当然的分发选择，那么你即将撞上那些领跑者在 2024 年左右遇到并选择翻越的那面墙。这面墙有个名字：插件 API 是为了给人类控制的编辑器添加功能而构建的，而不是为了托管一个想要控制编辑器的自主智能体。

47% 的专业开发者现在使用 AI 代码审查工具——两年前这一比例仅为 22%。然而在同一时期，AI 协作编写的 PR 合并后产生的 Bug 数量是人工编写代码的 1.7 倍，整个行业的变更失败率上升了 30%。团队在部署这些工具时出了问题，而问题并非工具本身。

核心问题在于工程师在没有理解 AI 审查能力边界的情况下就将其引入工作流。这类系统在真实代码库上的效果上限为 50–60%，只擅长一小类表层问题，而恰恰在导致生产事故的错误上静默失败。将 AI 审查视为通用质量关卡的团队，得到的是虚假的信心，而非真正的覆盖。

最迫切需要 AI 编程帮助的团队，通常并不是那些正在构建全新服务（greenfield services）的团队。他们往往正在维护 2012 年产出的 50 万行 Rails 单体应用，或是处理过数十亿笔交易的 COBOL 支付系统，亦或是架构师早在三次收购前就已离职的微服务网格。在这些代码库中，一个位置不当的重构就可能引入隐蔽的数据损坏漏洞，而这些漏洞往往在三周后的生产环境中才会浮现。

而这恰恰是目前的 AI 编程助手（agents）失败得最惨烈的地方。

令人沮丧的是，这种失效模式在爆发前是隐形的。AI 助手生成的代码可以通过编译，通过现有测试，并在审查中看起来非常合理。问题往往出现在预发环境（staging）、深夜的批处理作业，或者是某个客户在月份特定日期才会触发的边缘情况中。

你的 AI 编码智能体刚刚生成了一个拉取请求。代码看起来没问题，编译通过，测试也过了。你合并了它。两天后，预发布环境的 CI 流水线开始抛出 AttributeError: module 'openai' has no attribute 'ChatCompletion'。智能体使用了一年前已被废弃、并在最新主版本中彻底移除的 API 模式。

这就是废弃 API 陷阱，它坑害团队的频率远比那些聚焦 AI 代码质量的会议分享所描述的要高得多。一项对七个前沿 LLM 进行评估、覆盖 145 个 API 映射的实证研究发现，大多数模型在主流 Python 库上的 API 使用合理性（AUP）低于 30%。当被明确给出废弃上下文时，所有被测模型的废弃 API 使用率高达 70–90%。这个问题是结构性的，与特定模型或特定库无关。

大多数采用 AI 编程智能体的团队，都会把第一周花在争论使用哪个模型上。他们用人为设计的例子对 Opus、Sonnet 和 GPT-4o 进行基准测试，痴迷于排行榜，最终选出一个。然后他们花接下来三个月纳闷，为什么智能体一直在重建错误的抽象、忽视他们的测试策略，以及反复询问该用哪个包管理器。

问题不在模型。问题在上下文文件。

每款 AI 编程工具——Claude Code、Cursor、GitHub Copilot、Windsurf——都会在每次会话开始时读取一个项目专属的 Markdown 文件。这些文件有不同的名字：CLAUDE.md、.cursor/rules/、.github/copilot-instructions.md、AGENTS.md。但它们的目的相同：告诉智能体那些无法通过阅读代码推断出来的信息。这个文件的质量如今比背后的模型更可靠地预测输出质量。然而大多数团队只写一次、写得很糟，然后再也不碰。

大多数团队对待 CLAUDE.md 的方式和对待 README 一样：写一次，然后忘掉它的存在，最后疑惑为什么什么都不好使。但 CLAUDE.md 不是文档。它是你的代码库和每一个接触它的 AI agent 之间的 API 契约。写对了，每一次 AI 辅助的提交都遵循你的架构。写错了——或者更糟，让它腐化——你实际上是在每次会话中让你的 agent 变得更笨。

AGENTbench 研究在 12 个代码库中测试了 138 个真实编码任务，发现自动生成的上下文文件实际上降低了 agent 的成功率，甚至不如完全没有上下文文件。三个月积累的指令，其中一半描述的代码库已经面目全非，不会指导 agent——它们会误导 agent。

当今生产环境中最有效的 AI 智能体看起来与框架演示完全不同。它们不是拥有十七种节点类型的有向无环图，也不是通过消息总线协调的多智能体集群。它们是一个提示词、一个工具列表和一个 while 循环——它们比框架重型的对手交付更快、故障更少、维护成本更低。

这不是为了标新立异。这是一个又一个团队在花费数周时间进行框架迁移、抽象调试和 DSL 考古之后得出的结论。这种模式如此一致，值得给它一个名字：后框架时代。

你的公司花了六个月构建了一个内部 AI 聊天机器人。演示非常令人印象深刻——高管们频频点头，试点团队赞不绝口，甚至有人在 Slack 的一条消息中称之为"变革性的"。上线三个月后，你查看了分析数据：12% 的周活跃用户，而且其中大多数还是最初试点的那五个人。

这就是内部 AI 工具陷阱，几乎每家企业都会掉进去。工具本身没问题，技术是可靠的。但没人用它，因为你建了一个目的地，而你本应建一个交汇点。

一套联络中心 AI 系统在验证基准上的准确率超过 90%，但主管们仍然要求客服人员手动录入笔记。18 个月后，该产品以"采用率低"为由被砍掉。这种模式在企业 AI 部署中反复上演——技术上无可挑剔却无人使用的系统，被一套根本看不见失败的指标所衡量。

问题在于，团队所度量的内容与预测产品成败的内容之间存在系统性错配。工程组织从经典 ML 那里继承了度量本能：准确率、精确率/召回率、BLEU 分、延迟百分位、评估通过率。这些指标描述的是孤立的模型行为，几乎无法告诉你 AI 是否真正有用。

你的 AI 编程助手不记得昨天发生了什么。每个会话都是冷启动的 —— 它不知道你使用的是 yarn 而不是 npm，不知道你禁用 any 类型，也不知道 src/generated/ 目录是神圣不可侵犯的，永远不应该手动编辑。因此，它会使用错误的包管理器生成代码，在你禁止的地方引入 any，偶尔还会覆盖掉那些需要你花一小时才能恢复的生成文件。你纠正了它。明天它又犯同样的错误。你再次纠正它。

这不是模型质量问题。这是一个配置问题 —— 解决方案就是一个纯 Markdown 文件。

CLAUDE.md、AGENTS.md 及其针对特定工具的同类文件，是 AI 编程助手在每个会话开始前阅读的简报。它们编码了助手原本需要重新发现或被纠正的内容：运行哪些命令、避免哪些模式、团队的工作流如何构建，以及哪些目录是禁区。它们相当于一份详尽的工程入职文档，被压缩成了一种优化过的、适合机器阅读的形式。

一个团队在采用 AI 编程智能体（AI coding agents）后，交付的拉取请求（PR）增加了 98%。这听起来像是一个成功的故事——直到你注意到评审时间增长了 91%，PR 的规模膨胀了 154%。代码交付的速度超过了任何人的验证能力。

这就是 80% 问题。AI 编程智能体非常擅长生成看起来似懂非懂（plausible-looking）的代码。当剩下的 20% 需要架构判断、边缘情况意识或任何比“编译通过了吗？”更复杂的反馈循环时，它们就会陷入停滞或悄然失败。在编程智能体上取得成功的团队，并不是那些提示词（prompt）写得最激进的团队，而是那些构建了更好的反馈循环、更短的上下文窗口（context windows）和更严谨的工作流的团队。