每一位使用 AI 工具的开发者都听过同样模糊的承诺：“AI 让你更高效。“几乎没有人解释过这种进步实际上是什么样子——每一步会发生什么变化、如何判断自己处于哪个阶段，以及要晋升到下一级需要具体做些什么不同的事情。结果是，很多开发者"使用 AI"已经两年了，却没有实质性地超越把它当作更快的自动补全工具来用。

Dan Shapiro 引入了一个名为"vibe coding"的框架，将这种进步映射为六个等级的阶梯——从 AI 作为更智能的 Tab 键，到 AI 作为完全自主的构建和发布系统。Nate 结合 StrongDM 和 Anthropic 内部开发实践的真实案例对其进行了扩展。在 Big Hat Group，我们将这一框架应用于企业客户，帮助他们评估团队的真实水平——并补充了缺失的部分：规范层。不只是"这是某个等级”，而是"这是晋升到下一级的具体方法”。

框架：快速概览

这六个等级描述了人类与 AI 委托的一个连续谱。随着你沿阶梯上升，AI 承担更多实现工作——开发者的角色从构建转变为指导，再从指导转变为定义规格，再从定义规格转变为评估结果。

等级名称人类做什么AI 做什么
0智能自动补全一切——AI 只是更快的 Tab 键补全 token
1编程实习生审查所有内容，为每项任务定义范围处理离散的、有范围的任务
2初级开发者阅读每个差异处理多文件更改
3开发者如经理在功能/PR 级别审查完成所有实现
4开发者如产品经理撰写规格，检查测试是否通过代码是黑盒
5暗工厂撰写规格，评估结果一切：构建、测试、发布

大多数阅读本文的开发者处于第 1 级和第 3 级之间。以下是如何判断你的位置，以及下一步该做什么。

第 0 级——智能自动补全

日常体验： 你在使用 GitHub Copilot、Cursor 或 Claude 的内联补全，但交互方式大致是：建议出现，你忽略它，手动输入接近建议的内容。也许 20–30% 的补全会被原样接受。你把每个建议都当作需要编辑后才能信任的初稿。

你在这里的迹象：

  • 你重新输入那些"差不多对"但不完全正确的建议
  • 你关闭补全的速度比阅读它们还快
  • 你曾经关闭过自动补全，因为感觉像"噪音"
  • 你每天使用 AI 的时间以分钟计，而非小时

瓶颈所在： 在第 0 级，AI 带来约 15–20% 的生产力提升——真实的，但有限。模型的质量受限于它接收到的上下文，而在这个等级，你提供的上下文几乎只有当前文件。你留下了 80% 未使用的潜在价值。

如何晋升：

  1. 先接受，后编辑。 训练自己先接受补全，然后修正错误的地方。目标是更快地评估补全，而不是绕过它们来写代码。
  2. 在命名上信任模型。 变量名、函数签名、测试名——模型的建议通常和你的一样好。停止过度质疑它们。
  3. 使用多行补全。 如果你的工具支持（Cursor、Copilot Next Edit Suggestions），练习让模型完成整个函数体，然后再决定是接受还是丢弃。

第 1 级——编程实习生

日常体验： 你已经开始使用聊天界面或 AI 编码工具（Claude、Codex、Cursor agent 模式）来完成离散的编程任务。你给 AI 一个单一的、范围明确的工作——“写一个执行 X 的函数"或"修复这个文件中的这个特定 bug”——然后在接受之前审查每一行。你的纠错率很高。你对待 AI 输出的方式就像对待一个你还不信任的初级开发者的代码一样。

你在这里的迹象：

  • 你将整个文件内容粘贴到提示中，给 AI 提供足够的上下文
  • 你的提示包含详细的逐步指令，因为你不相信 AI 能做出合理的选择
  • 你花在审查输出上的时间与自己编写代码的时间一样多
  • 单文件范围让你感到安全；多文件范围让你不安

瓶颈所在： 你就是瓶颈。每项任务都需要你大量的前期定义工作，然后才能编写任何代码。AI 无法在会话中构建在之前工作的基础上，因为每项任务都被当作孤立的。你在获得真实价值，但受限于你写提示和审查输出的速度。

如何晋升：

  1. 为你的项目创建 CLAUDE.md 或 agents.md。 这是一个上下文文档，一次性编码你的约定、模式和约束——这样你就不必在每个提示中重复它们。有了这个上下文，AI 在你代码库上的准确性会显著提升。
  2. 练习任务分解。 将一个功能分解为 3–4 个顺序任务，逐一移交，然后审查开始和结束状态之间的差异——而不是每个中间步骤。
  3. 将审查转向差异。 不要从头到尾阅读输出文件，而是看什么发生了变化。这更快，也能捕捉到真正重要的东西。

第 2 级——初级开发者

日常体验： 你在移交多文件更改。你给 AI 一个跨越多个文件的功能或 bug 修复，它生成一个 PR。你在合并之前逐行审查该 PR。你的 AI 使用量已经越过了一个门槛——你产出的代码比自己能写的多——但审查正在成为新的瓶颈。

你在这里的迹象：

  • 你经常给 AI 涉及 5–10 个文件的任务
  • 你在接受 PR 之前仍然逐行阅读每个差异
  • 你发现自己在纠正那些并不错误、只是与你的做法不同的东西
  • 你的产量提升了，但审查负担也同步增加

瓶颈所在： 审查时间随产量扩展。AI 比你快，你的瓶颈已从编写转向了审查。逐行审查 AI 输出通常是多余的——模型的错误是结构性和架构性的，而不是语法性的。逐行阅读成本高昂，却在捕捉错误的错误类型。

如何晋升：

  1. 转向语义审查。 问"这个 PR 是否完成了规格中说的内容？“而不是"每一行都正确吗？“结构和架构上的差距才是重要的；模型能可靠地处理语法。
  2. 添加 AI 代码审查步骤。 使用 Claude 的 /code-review 命令或 PR 审查 agent。让 AI 审查 AI 的输出——在不需要自己逐行阅读的情况下捕捉结构性问题。
  3. 现在就投资测试覆盖率。 晋升到第 3 级需要信任测试作为你的主要安全网。如果你的覆盖率太薄，无法捕捉回归，那就是你在晋升之前需要修复的先决条件。

第 3 级——开发者如经理

日常体验： 你在功能级别而不是代码行级别进行审查。你编写的规格足够清晰，让 AI 可以在没有你监督的情况下执行。你是架构师；AI 是实现者。你的大部分时间花在规格撰写、架构决策和高级代码审查上——而不是实现。

你在这里的迹象：

  • 你在实现过程中很少查看单个文件内容——你等待 PR 摘要
  • 你的提示描述结果，而不是步骤
  • 你开始更关心测试覆盖率，而不是具体的实现方式
  • 当出现问题时，你的本能是修复规格，而不是手动纠正代码

瓶颈所在： 质量现在直接取决于规格质量。模糊或不完整的规格导致返工。你仍然是主要审查者，这在规模化时限制了产量。瓶颈再次转移：不再是阅读代码，而是评估交付的功能是否真正符合意图。

如何晋升：

  1. 构建规格模板，强制你在移交任务之前定义验收标准、边缘情况和测试要求。模板的纪律性使 AI 的输出保持一致。
  2. 将自动化代码审查 agent 集成到 CI 中。 在每个 PR 上运行的第二个审查者在你审查之前捕捉结构性问题——并捕捉你在快速移动时可能错过的内容。
  3. 在规格中定义测试要求。 “当[特定测试场景]通过时，此功能完成"将质量门从你的判断转移到客观、可审计的标准。

第 4 级——开发者如产品经理

日常体验： 代码是黑盒。规格和测试是你与它的接口。你撰写需求和验收标准；AI 构建功能并根据它们进行验证。你检查测试是否通过，而不是代码看起来是否正确。你的主要产物是规格和测试计划。

你在这里的迹象：

  • 你在任务执行过程中很少（或从不）打开实现文件
  • 你的规格读起来更像产品需求，而不是技术设计
  • 你对"完成"的定义是"测试通过且需求满足”，而不是"我审查了 PR”
  • 你通过功能验收标准衡量 AI 输出，而不是代码质量指标

瓶颈所在： 在第 4 级，测试覆盖率就是一切。你在测试中的盲点成为你发布功能中的盲点。没有全面的覆盖——包括边缘情况、集成场景和性能基准——质量是无法衡量的，而不是高的。第二个风险：架构漂移。AI 做出局部正确的决定，这些决定积累成你看不到的系统性问题，因为你没有在阅读代码。

如何晋升：

  1. 投资全面的自动化测试套件——单元测试、集成测试和端到端测试。变异测试在这里很有价值：它发现覆盖质量的差距，而不仅仅是覆盖数量。
  2. 为功能定义结果指标——错误率、性能基准、面向用户的成功率。这些为第 5 级的结果评估模型做好准备。
  3. 添加架构审查检查点。 即使在第 4 级，也要定期审查系统的架构状态，在漂移积累之前捕捉它。

第 5 级——暗工厂

日常体验： 你撰写一个规格，另一端输出一个经过验证的、可部署的产物。人类不在正常操作的实现或审查循环中。系统根据自动化质量门构建、测试和发布。你评估结果并调整系统；你不在构建过程中与单个功能交互。

何时适合——何时不适合： 暗工厂在具有深度现有测试覆盖率和清晰、可衡量结果指标的狭窄、定义明确的领域中有效。它不适合验收标准不明确的新功能、没有自动合规验证的受监管环境，或任何失败在到达生产环境之前无法被测试捕捉的领域。配置不当的第 5 级系统的失败模式不是慢速交付——而是快速交付错误的东西。

不可妥协的要求：

  • 可观测性。 如果你看不到系统构建了什么以及它的性能如何，你就完全失去了反馈循环。日志、追踪和告警是前提条件，而不是附加功能。
  • 自动回滚。 没有自动回滚的自动化部署是负债，而不是效率提升。
  • 结果衡量。 在第 5 级，规格到结果的循环是你唯一的质量信号。如果没有对其进行仪表化，系统就是在盲目飞行。

大多数企业团队应以第 3–4 级为目标。第 5 级是具有重大基础设施要求的特定领域投资。在先决条件就位之前晋升到它，比留在第 3 级更糟糕。

这对工程领导者意味着什么

团队结构在每个等级都会发生变化。 在第 0–1 级，团队组织方式变化不大——开发者拥有实现，AI 辅助。在第 2 级，你需要投资测试基础设施和审查工具。在第 3 级，能力组合开始改变：你需要能够撰写清晰、完整规格的开发者，就像需要能够编写干净代码的开发者一样。在第 4 级，你在招聘产品思维技能——验收标准撰写、测试架构、结果定义。在第 5 级，你在运营一个系统。

招聘影响是真实的。 随着团队从第 2 级向第 4 级推进，需要较少的纯实现者，更多在规格和架构方面强的开发者。在 AI 原生组织中，能够撰写 AI 可以完美执行的规格的开发者，比能够手动实现该规格的开发者更有价值。这不是关于裁员——而是关于能力组合和招聘方向。

没有测试基础设施的第 4–5 级是负债，而不是效率提升。 在没有相应测试覆盖率投资的情况下将人类工作流推进到第 4 级的团队，是在没有添加替代质量门的情况下将审查者从循环中移除。结果是产量更快，但质量无法衡量。这比第 1 级更差，而不是更好。

复合生产力差距是真实的。 今天处于第 1 级的组织面临相对于第 3 级 AI 原生团队的复合劣势。这个差距不是线性的——它会复合，因为更高级别的团队以更快的速度承担更大的任务，投资更好的基础设施，并进一步推进。每个季度差距都在扩大。现在是缩小差距的时候了。

你的 30 天晋升计划

  1. 诚实地评估你当前的等级。 使用上面的"你在这里的迹象"描述，而不是自我报告的估计。这些迹象是行为性和可观测的；使用它们。
  2. 从当前等级的"如何晋升"部分选择一个习惯，坚持练习两周。一个执行良好的习惯胜过三个半途而废的习惯。
  3. 对你的审查流程进行仪表化。 跟踪每个 PR 花费的时间，以及其中多少百分比是代码行级别与功能级别的审查。数据将清楚地显示你卡在哪里。
  4. 找出你的测试覆盖率差距。 这是阻止大多数团队从第 2 级晋升到第 3 级的隐藏瓶颈。在覆盖率真实之前，你无法信任测试作为安全网。
  5. 获取路线图。 Big Hat Group 帮助企业工程团队评估其当前的 AI 开发水平，找出阻止晋升的原因，并构建使过渡可持续的工具、测试基础设施和治理框架。

获取企业 AI 开发咨询

Big Hat Group 与企业工程团队合作，推进他们的 AI 开发实践——从评估团队的当前水平，到实施使晋升持久的 AI 编码工具、规格模板和测试基础设施。

联系我们，开始你的 AI 开发评估 →

相关文章： Claude Code vs Codex vs Gemini CLI：企业指南 · 企业 AI 编程的 agents.md 标准