你的 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）和更严谨的工作流的团队。
这是一个在采用 AI 编程智能体的团队中不断上演的模式：一位开发者发现 Claude 违反了某条规则，于是他们在 CLAUDE.md 中添加了一个更清晰的版本。Claude 违反了另一条不同的规则，于是他们也把那条加上。几周后，这个文件达到了 400 行，而 Claude 忽略的规则比以往任何时候都多。解决方案反而让问题变得更糟。
发生这种情况是因为指令文件的一个基本属性，而大多数开发者从未将其内化：超过一定规模后，添加更多指令会导致模型遵循的指令变少。 正确编写指令文件与其说是追求完整性，不如说是进行无情的筛选 —— 知道该包含什么、该删除什么，以及如何构建其余部分。
第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。
AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
