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

大多数构建 AI 编程助手的团队都会采用与文档检索相同的现成 RAG 流水线：根据 token 数量对源文件进行分块（chunking），对块进行嵌入（embedding），将其存储在向量数据库中，并通过语义相似性进行查询。这种流水线在处理散文（prose）时表现良好。但在处理代码时，它会悄无声息地失败——而且这些失败很难在聚合指标中显现，因为检索到的代码块看起来似乎合情合理，直到模型生成了错误返回类型的代码、调用了签名错误的函数，或者遗漏了调用图中三层之后才存在的依赖项。

问题不在于嵌入模型或向量数据库，而在于分块策略。代码不是散文。它具有结构属性——依赖图、调用链、类型签名、作用域层级——而基于 token 的分块在检索器看到它们之前就破坏了这些属性。修复这个问题需要重新思考在进入嵌入步骤之前如何分解代码。

有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标，却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是：60% 被接受的建议随后被立即重写，参与度最高的用户正是那些点击 AI 输出、全选，然后自己重新输入的人；这个功能对下游任务完成率零可测影响。

这就是"安静放弃"模式：用户系统性地绕过 AI 功能，同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中，他们与最佳 AI 用户看起来完全相同。

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 是否真正有用。