AI 研发成熟度模型：你在哪一级，决定了你该用什么

Fen9Pi2026/6/8大约 7 分钟

AI 研发成熟度模型

不是谁都需要全套。
你在哪一级，决定了你该用什么。
从裸奔的 Vibe Coding 到多 Agent 自动协作，
五个级别，每个级别都有自己的工具和方法。
关键是：认清自己的级别，用对工具。

Level 1：裸奔的 Vibe Coding

Level 1

场景：

跟 Agent 聊天写代码。

你：帮我写个登录页
AI：[生成代码]
你：看一眼，不对，蓝色
AI：[修改代码]
你：再看，还不太对，字体大一点
AI：[再修改代码]

特点：

快
代码质量全凭运气
三轮需求之后 Agent 开始忘第一轮说了什么

定义： " 第 1 章定义过 Vibe Coding："完全用自然语言描述需求，AI 生成代码，人工验证"。

定位：

是起点，不是终点。

问题：

没有规格
没有验收标准
没有版本控制
没有测试
没有文档
全凭聊天记录

适合：

快速原型
一次性脚本
学习探索

不适合：

生产代码
团队协作
长期维护

Level 2：用一个 Skill

Level 2

场景：

装了测试 Skill 或 Git Skill。

特点：

单个场景有保障了。

例子：

每次提交前自动跑测试
测试不过不提交
Git hook 检查代码规范

流程：

流程还是散的，什么时候用哪个 Skill 靠自己判断。

价值：

至少有一个场景不再靠运气。

相关工具：

第 2 章的 Matt Pocock Skills（grill-with-docs, tdd）
第 6 章的 Superpowers（20 个超能力）

问题：

技能是孤立的
没有串联起来
没有完整链路
还是要靠人工判断什么时候用哪个

适合：

个人开发者
单点优化
特定场景保障

不适合：

完整项目开发
团队协作
端到端流程

Level 3：Skill 串起来了

Level 3

场景：

有了一条完整的链路。

例子：

Goal Workflow：

PRD → Issue → /goal 实现

OpenSpec：

propose → apply → archive

第 3 章的 SDD：

Spec → 实现 → 验证

第 4 章的 Ralph Loop：

PRD → 设计 → 实现 → 审查 → 交付

特点：

不只是用一个工具，是用一条规则串起多个步骤。

价值：

规格写好了自动进实现
实现完成了自动进审查
有形状了，还没全链路

问题：

链路有了，但不够完整
有些环节还是人工
质量标准不统一
数据追踪不完整

适合：

小团队
MVP 开发
快速迭代

不适合：

大型项目
复杂系统
高质量要求

Level 4：完整的 Spec-Driven 闭环

Level 4

场景：

七条路至少用了三条以上，从需求到交付全覆盖。

每个阶段有：

输入
输出
质量标准

特点：

不靠感觉，靠可验证的东西说话。

完整例子：做一个支付模块

第 1 步：/prd

产出一份 PRD：
- 四个 User Story
- 每个带 checkbox 验收标准

第 2 步：/prd-to-spec

产出一份 SPEC：
- API 端点
- 数据库 schema
- 错误码表

第 3 步：/to-issues

拆成十个 Issue：
- 标注依赖
- 定义优先级

第 4 步：/goal

逐个实现：
- Agent 对照 checkbox 逐条实现
- 每勾上一个你知道进度往前走了

第 5 步：/review-it

扫一遍：
- 自动化审查
- 标记问题

第 6 步：gstack

全维度再扫一遍：
- 23 个维度
- 安全、性能、可维护性...

第 7 步：/ship-it

合入：
- 自动创建 PR
- 自动合并
- 自动关闭 Issue

第 8 步：/note-it

记录设计决策：
- 为什么这么做
- 有哪些权衡
- 有哪些限制

三个月后的价值：

审计来了，从 PRD 到 Note 一条线拉到底。

不是： "我记得当时好像是这样想的"

是：文档里有。

现实情况：

多数个人开发者在 Level 2-3
多数团队在 3 往 4 过渡

Level 5：多 Agent 自动协作 + 持续改进

Level 5

场景：

第 7 章的 autoresearch 是这个级别的雏形。

特点：

五个 Agent 交叉审查
评分达标自动合入
完全自动化

但 Level 5 真正的门槛不是自动化。

是你看数据了。

数据驱动的问题：

哪些 Issue 一次过审查？
哪些反复返工？
哪类 bug 多 Agent 也抓不住？

持续改进的反馈环：

第 7 章提到 autoresearch 有一个持续改进的反馈环。

机制：

审查中发现的问题模式被反馈到生成和审查 prompt 里。

结果：

下次同类 Issue 的首次通过率就会提高。

更进一步的场景：

项目跑了三个月，积累了上百条 Issue 的审查数据。

发现：

"并发处理"类 Issue 的平均返工次数是其他类型的三倍。

分析：

不是 Agent 不行，是你的并发 Issue 写得太抽象，Agent 理解偏了。

改进：

下次写并发相关的 PRD，自动增加"并发场景覆盖率"检查项。

结果：

数据喂回去，流程自己变好。

现实情况：

Level 5 现在还是稀罕东西。

autoresearch 的"一觉醒来一排 merged"通常只发生在 Issue 明确的中小功能上。

但方向很清楚。

五个级别对比

级别	名称	特点	工具	适合
Level 1	裸奔的 Vibe Coding	跟 Agent 聊天写代码	无	快速原型、一次性脚本
Level 2	用一个 Skill	单个场景有保障	Matt Pocock、Superpowers	个人开发者、单点优化
Level 3	Skill 串起来	有完整链路	Goal Workflow、SDD	小团队、MVP 开发
Level 4	Spec-Driven 闭环	全覆盖、可验证	Goal Workflow + gstack + autoresearch	团队协作、端到端流程
Level 5	多 Agent 自动协作	数据驱动、持续改进	autoresearch	大型项目、复杂系统