干预率是新的构建时间
还记得 CI/CD 团队曾经痴迷于构建时间吗？那个单一指标涵盖了一切：代码质量、基础设施效率、流程瓶颈。系统地衡量和改进构建时间的团队最终改变了他们交付软件的方式。
我的职业生涯始于修复一个令人抓狂的构建时间问题。当时我们正在处理一个基于 StrongARM 芯片的嵌入式分布式系统，代码量达数百万行。在嵌入式平台上进行原生构建非常痛苦——一次完整的构建竟然需要一整天。当时的软件包仓库里并没有现成的交叉编译器。
有一天，我在启动构建后几个小时才意识到自己犯了一个小错误，那一刻我彻底爆发了。我出去买了一本 GCC 书，学会了为我们的项目构建交叉编译工具链，并将我们的构建时间从一天缩短到了 10 分钟。后来，我又加入了 distcc 和 ccache，让构建速度变得更快。这种改善构建基础设施的系统化方法彻底改变了我们团队的工作方式。
现在，我们在 AI 辅助开发方面也正处于类似的时刻。在最近的一条 推文中，Chip Huyen 指出了一个至关重要的指标：干预率（Intervention Rates）。
她的数据揭示了一个引人注目的事实。在分析了 Claude Code（Anthropic 的命令行 AI 工具）的 1,746 条命令后，她发现自己有 24.5% 的时间需要中断或纠正 AI 的操作。但她没有简单地将其归咎为“AI 就是这样”，而是像早期的 CI 团队对待构建时间那样，将其视为一个需要测量、分析和系统性改进的关键指标。
数据说明了一切
正如构建时间成为 CI/CD 的“北极星指标”一样，干预率可以衡量你整个 AI 辅助工作流程的有效性。当你测量需要中断 AI 助手的频率时，你实际上是在同时测量提示词质量、代码组织结构、任务分解逻辑以及工具选择的优劣。
Chip 对 1,746 条命令的分析揭示了明显的模式。35% 的错误属于“内容未找到”（Content Not Found）——即 AI 无法定位它所需的特定文件或函数。
这不仅仅是一个有趣的观察，更是一条可操作的情报。她重构了自己的代码库以提高 AI 的可发现性。结果：每个任务的平均步骤从 8 步下降到 7 步，通过解决一个系统性瓶颈，效率提升了 12.5%。
她的干预率在 15% 到 60% 之间波动，具体取决于任务类型。
这种差异揭示了重要的一点：AI 的有效性在很大程度上取决于上下文和工作流程的设计。如果不进行测量，这些模式就会被隐藏起来。但通过系统化的跟踪，你可以识别出有效的方法并进行复制。
这正是早期 CI 团队进行构建优化的方法——测量、识别瓶颈、系统性修复、重复循环。大多数开发人员在使用 AI 工具时仍处于“祈祷它能正常工作”的阶段，但像 Chip 这样的人已经开始将这种严谨的方法论应用于他们的 AI 工作流中。
开始你自己的测量
你不需要复杂的分析工具即可开始。从基础做起：
确定基准：记录你纠正或重定向 AI 工具的时刻。在不同任务类型中，你的干预率是多少？
找到最大的瓶颈：Chip 的“内容未找到”错误指向了代码组织问题。在你的工作流中，是什么导致了 AI 的频繁失败？
进行系统性改进：寻找能解决根本原因而非仅仅解决症状的方案。
测量影响：你的干预率是否有所改善？任务完成所需的步骤是否减少了？
目标不是立即实现完美的自动化，而是建立能够促进持续改进的测量习惯。
自己尝试
想要探索你自己的 AI 开发模式吗？Chip 开发了 Sniffly，这是一个用于分析 Claude Code 日志的开源工具。如果你使用的是其他 AI 编码工具，Continue 提供了更广泛的开发数据分析功能。
安装 Continue 并开始跟踪你的干预率。你可能会对数据所揭示的关于 AI 辅助工作流模式和瓶颈的信息感到惊讶。
真正的机遇
Chip 的工作中最宝贵的见解并非那个具体的 24.5% 的数值，甚至也不是她所做的特定改进。而是一种思维方式的转变：将 AI 工具视为可度量的基础设施，而不是不可预测的魔法。
随着 AI 成为软件开发的核心，这种系统化的方法将把那些能够建立持久优势的团队，与那些仍停留在祈祷工具明天能更好用的团队区分开来。
现在就开始测量干预率的团队，很可能会在 AI 工具日益成为开发流程核心的过程中占据优势。问题不在于系统化测量是否会变得普及，而在于你是会尽早养成这些习惯，还是会在日后被迫追赶。
参考资料
本分析基于 Chip Huyen 使用 Sniffly（她用于分析 Claude Code 日志的开源工具）对其 AI 开发工作流进行的详细解读。
所有数据可视化和见解均归功于 Chip Huyen 的原始分析。