事情是这样的。

上个月我看到一项研究，差点把咖啡喷在键盘上。

研究说的是 2025 年，有人找了 16 个资深开源开发者，让他们完成 246 个真实任务。这些老哥平均在项目上干了五年，闭着眼睛都知道代码库里哪个模块有坑。他们用的 AI 工具也不差，Cursor Pro 配 Claude 3.5/3.7 Sonnet。

任务开始前，研究员问他们：“你用 AI 的话，能干多快？”

开发者们估了一下，觉得能快 24%。

实际结果：慢了 19%。

METR 研究论文截图：资深开源开发者使用 AI 反而变慢的随机对照实验

对，你没看错。不是快 19%，是慢 19%。

注意，这不是什么野鸡测试。METR 是一个严肃评估 AI 系统能力的机构，用的是随机对照实验——一部分任务能用 AI，一部分不能用，然后比实际耗时。

开发者们直到实验结束，都还觉得自己被 AI 帮到了。

他们感觉自己更快了。实际更慢了。

这事儿让我想了很久。因为我就是那种每天都在用 AI 写代码的人，Typing 的时候确实觉得爽，一行注释下去咔咔几十行代码就出来了。

但我突然意识到一个问题：我到底在用什么标准判断“快”？ 是代码出现在屏幕上的速度，还是从“理解一个需求”到“代码真正上线且不出事”的时间？

这两件事，差远了。

你把一个新人扔进没有地图的城市，然后说“帮我办事”

这两年 AI 编程工具多到什么程度呢，我随便列几个：Claude Code、GitHub Copilot、Cursor、Windsurf、Gemini CLI、OpenAI Codex、Devin。每个都在说“我能读你的代码库、改文件、跑测试、提 PR”。

乍一看，大同小异。

但你实际用起来，感觉完全不一样。差别在哪？

Anthropic 最近发了一篇讲 Claude Code 在大代码库里的文章，标题看着很干，但里面有一句话，我觉得说穿了现在所有 AI 编程工具的底裤：

“模型的能力重要，但围绕模型的生态（harness）同样重要，有时候更决定结果。”

Claude Code 在大代码库中的最佳实践

Harness，你可以先粗暴地理解成“工程脚手架”。它不是模型本身，而是在模型外面你搭的那一套东西：上下文文件、工具调用、权限边界、测试命令、代码索引、团队约定、审查流程。

Claude Code 文档截图：产品定位是 agentic coding tool

我换个说法你就懂了。

你把一个最强的 AI 模型丢进一个百万代码行的仓库，让它“帮我优化一下登录模块”。

它会怎么样？

它不知道这个仓库的登录逻辑散落在哪三个服务里。不知道哪个 User 类型是主表的，哪个是缓存的。不知道 build/ 下面全是生成文件，不应该读。不知道那条看起来人畜无害的 deploy.sh 会直接推到生产环境。不知道你们团队在半年前做过一次重构迁移，有些目录名字看着对，其实是废弃代码。

它在猜。

一个在猜的 AI，不管多聪明，都是在赌。

这就是 Anthropic 说的 harness 的意义。你不是在“调教模型”，你是在给模型提供一张能用的地图。

CLAUDE.md、MCP、LSP：这帮人在下一盘什么棋

Anthropic 在文章里提了几个做法，我挑关键的讲。

第一件事是写 CLAUDE.md。这玩意儿说白了就是给 AI 看的项目说明书。项目结构是什么、编码规范是什么、哪条命令绝对不能碰、PR 要满足什么条件。

但重点来了——Anthropic 特别强调：这个文件要瘦，而且要分层。 根目录只放全局地图和关键坑点。子目录放局部规则。每 3 到 6 个月审查一次，删掉过时的。

为什么？因为上下文不是越多越好。

你把几百行过期规则、无关命令、三年前的技术决策全塞进上下文，模型看似知道更多，实际更容易被噪音拖垮。大代码库的上下文管理，本质不是塞满，是减负。

第二件事是用 LSP。LSP 是 Language Server Protocol，简单说就是让 AI 按“符号”理解代码，而不是像 grep 一样搜字符串。一个 User 类型，grep 可能返回几千行结果；LSP 能告诉你，这个 User 指的是 src/auth/models/user.ts 里那个，不是 tests/fixtures/user.json 里那个。

第三件事是一整套扩展机制：Hooks 在关键事件触发脚本（比如每次编辑后自动格式化）。Skills 是团队统一的任务模板（比如 PR review 标准）。Plugins 是把这些东西打包，给整个组织分发。Subagents 是独立分身，一个负责只读探索代码结构，另一个负责编辑。

你看出来了吗？这些功能单独看都很琐碎。但合在一起，他们在干一件事：

把一次性的 prompt，变成可维护的工程制度。

这才是真正的分水岭。

五个物种：谁坐在你的交付链哪一环

如果你去看这些 AI 编程工具的宣传页，话术高度重合：“读代码、改文件、跑测试、理解项目”。

但真正把它们用起来，你会发现它们根本不是同一个物种。差异不在“能不能写代码”，而在它们坐在你软件交付链的哪个位置上。

IDE 内同步协作——Cursor、Copilot agent mode、Windsurf Cascade。它们贴着你的键盘，适合你正在写代码，大方向清楚，但希望 AI 帮你跨文件改、补测试、处理局部错误。像一个反应很快的结对工程师。

Windsurf Cascade 文档截图：IDE 内 agentic assistant

终端本地 agent——Claude Code CLI、Gemini CLI、Codex CLI。把 AI 放进终端，因为它本来就在你的开发环境里：跑测试、看日志、查 git diff、启动服务。Google 的 Gemini CLI 还打了一张开源牌，意思是你可以检查代码、理解安全边界、甚至自己改。

Gemini CLI 发布页截图：开源终端 AI agent

OpenAI Codex GitHub 仓库截图：终端与本地 coding agent 生态

云端异步 agent——OpenAI Codex 和 GitHub Copilot coding agent。这类工具不是“帮我补下一行”，而是“帮我完成这个任务”。它们在云端沙箱里工作，最后带着 diff、终端日志和测试结果回来。你把 issue 丢过去，等着它开 PR。

GitHub Copilot agent mode 与 coding agent 解释文章

企业 backlog agent——Devin。这玩意儿直接接入你的 Linear 或 Jira，从 backlog 里领任务。官方给了一个经验规则：如果人类能在三小时内完成，Devin 大概率也能。野心最大，坑也最深。

Devin 文档截图：autonomous AI software engineer

开源可扩展生态——Gemini CLI、OpenHands、Cline、Roo。更开放、更可改造，也更依赖你自己搭环境、配权限、接模型。适合个人 hacker 和平台工程团队。

所以别再问“哪个 AI 工具最强”了。

你应该问的是：它在编辑器里，在终端里，在 GitHub issue 里，在云端沙箱里，还是在你的 backlog 里？它拿到的上下文，来自当前文件、整个 repo、issue 描述，还是内部文档？它的权限边界画在哪？它怎么证明自己做过什么？

Codex 配置文档截图

越熟越慢：一个反直觉的真相

回到开头那个研究。

为什么资深开发者用 AI 反而慢了？

答案其实不神秘。一个在项目上干了五年的工程师，脑子里有一张高质量的内部索引。他知道哪个模块有坑，哪个测试不稳定，哪个函数名字虽然相同但绝对不能混用，半年前哪个架构决策不能轻易推翻。

AI 进入这种环境的时候，它能快速吐代码。但它也能快速吐错。

你本来三十分钟能改完的东西，现在 AI 十秒生成了一版。然后你花二十分钟审它的 diff，发现它把抽象边界搞混了。再花十分钟补它没覆盖的边界情况。再花十分钟跑测试，发现它引入了一个你没注意到的副作用。

AI 让代码出现得更快，但没有让正确性自动出现。

Stack Overflow 2025 年的调查也能印证这件事。52% 的开发者觉得 AI 工具提高了个人任务效率。约 70% 的 agent 用户认为 AI 减少了特定任务的时间。但只有 17% 的人觉得它改善了团队协作。

Stack Overflow 2025 AI 调查截图：个人效率与团队协作之间的落差

个人的“写快了”，和团队的“交付快了”，是两笔账。

你写代码的速度翻倍，但 reviewer 的压力翻了三倍，测试维护翻了两倍，安全审查翻了两倍——从 issue 到 merge 的总时长，可能根本没变，甚至更长了。

这就是为什么 Anthropic 在文章里反复提“组织所有权”。成功的企业部署不是“大家自由探索一下 AI 工具哈”，而是先有人把基础设施接好：上下文文件、MCP、插件、权限、审查流程、标准命令。很多团队甚至出现了一个新角色：agent manager，负责管理 agent 生态——哪些 skill 能用，哪些插件被批准，CLAUDE.md 怎么写，AI 代码要过什么 review。

如果你团队里没有人干这件事，AI 的底层热情会很高，但知识会碎成一堆部落经验。张三有一套私房 prompt，李四有另一套，最后 agent 在不同人手里表现天差地别。

未来工程师的核心技能，不是写 prompt

写到这里，我估计有人会问：那到底怎么用才不亏？

我的答案可能会让你失望：不是学一套“超级 prompt”，而是学会——把任务切成 agent 能做、人类能验的形状。

举一个真实的对比。

烂的需求是：“优化登录模块。”

好的需求是：“在 auth/session 里新增 refresh token 过期测试；不改 public API；覆盖 token 过期、token 缺失、重复刷新三种情况；跑该目录单测并报告结果。”

区别在哪？有边界，有禁止项，有测试，有验收。

这听起来像是在写需求文档。对，本质上就是。甚至更进一步——你是在为 agent 设计一个“工作面”。

如果你每次都要跟 AI 说“呃你先跑这个目录的测试，命令是 npm test 加一个什么参数来着”，说明你的项目根本没为 agent 准备好。你应该把这些东西写进 AGENTS.md 或者 CLAUDE.md 里，一次性解决，而不是每次重复对话。

还有一个容易被忽略的点：规则会老化。

Claude Code 那篇文章里提了一嘴，很多人跳过去了。过去为了约束弱模型写的规则，现在可能限制了新模型。比如旧规则写“每次只能改一个文件”，曾经有用；但今天模型已经能处理跨文件的一致性，这个规则反而让它干不出好活。

Anthropic 建议每 3 到 6 个月做一次配置审查。模型大版本更新后，重新看一遍 rules、skills、hooks、permissions。

过期规则不是严谨，是技术债。

开发者不会消失。但只会写代码的开发方式会消失。

Claude Code 这篇文章，表面上是一篇产品实践指南。但我觉得它真正的信号是：AI 编程工具的竞争，已经从“谁的模型会写代码”，转向了“谁能把模型放进一个可控、可验证、可维护的工程系统里”。

这会深刻改变工程师的价值结构。

会写样板代码？这个能力在贬值。会搬 API、查文档、生成重复测试？也在贬值。

但另外一些能力在疯狂升值：你能不能把模糊需求澄清成可验收的任务？能不能判断一个 AI 生成的 diff 有没有破坏架构？能不能设计一个让 agent 少猜、让 review 轻松的上下文体系？能不能知道什么时候让 agent 做，什么时候必须自己上？

不会用 AI 的工程师，会慢。

只会让 AI 写代码的工程师，会危险。因为你把最关键的质量判断也交出去了。

能把 AI 当成工程系统的一个可管理节点的人，才会变强。

Claude Code、Codex、Copilot、Cursor、Windsurf、Gemini CLI、Devin，表面的竞争是产品，底层的竞争是工作方式。

未来开发者的核心资产，不是键盘敲得有多快，也不是记住了多少 API。

而是你能不能搭起一个体系：让 agent 找得到上下文，做得了小步任务，跑得出证据，过得了审查，进得了交付链。

到那时候，会写代码依然重要。

但只会写代码，真的不够了。

---

参考资料：

• • Anthropic, “How Claude Code works in large codebases: Best practices and where to start”, 2026-05-14

• • OpenAI, “Introducing Codex”, 2025-05-16; “Introducing the Codex app”, 2026

• • GitHub Blog, “The difference between coding agent and agent mode in GitHub Copilot”, 2025-06

• • Google Blog, “Gemini CLI: your open-source AI agent”, 2025-06-25

• • Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, arXiv 2507.09089

• • Galster et al., “Configuring Agentic AI Coding Tools: An Exploratory Study”, arXiv 2602.14690

• • Stack Overflow Developer Survey 2025, AI section

•