上个月，我让一个 AI Agent 做一件非常普通的事情：
"给用户列表增加分页功能。"
结果它返回了一份 900 行的代码改动，涉及 14 个文件。
它不仅修改了 API 层，还重构了两个组件，甚至加入了一个没人要求的缓存系统。
最后，我真正合并的代码只有大约 60 行。
那一刻我意识到：问题可能并不在 AI，而在于------我们到底是如何向 AI 提需求的。
很多开发者以为 AI 编程的差距，只来自模型能力。
但实际上，从一个模糊想法，到最终稳定运行的软件，中间存在不同成熟阶段。
经过多年全栈项目开发，我发现 AI 编程大致可以分成 7 个层级。
它们不是官方标准，也不是必须一步步升级的等级体系，而更像是一条成熟度路线。
一个临时脚本，也许 Level 1 就足够；但一个可能影响生产环境的核心功能，则需要更高等级的方法。
下面看看，你现在处在哪一级。
Level 1：凭感觉写代码（Vibe Coding）
这是大多数人接触 AI 编程时的第一阶段。
打开聊天窗口，输入：
"帮我做一个带 JWT 登录的页面。"
AI 给结果。
不满意？
继续回复：
"不对，修一下跳转。"
然后等待下一次输出。
整个过程没有明确计划，没有需求文档，也没有设计记录。
唯一保存下来的东西，就是那段很快会被遗忘的聊天记录。
对于 Demo、小工具、一次性脚本来说，这完全没问题。
我自己也经常这样做。
比如临时写一个批量修改文件名的小脚本，几分钟就能完成。
但问题出现在真正的项目中。
因为随着对话越来越长，AI 会逐渐偏离最初目标。
二十分钟前制定的规则，它可能已经忘记。
半年以后，团队成员看到某段代码，也没人知道：
"为什么这里要这样设计？"
这就是 Vibe Coding 最大的问题。
代码可能没有错。
但代码背后的原因消失了。
如果你的"需求文档"只是聊天记录，那么你基本还停留在这个阶段。
发现一个低成本 AI 平台：GPT-5.6 倍率0.08(限时)， Claude Opus5,Fable 5 都能用，倍率 0.25，首字请求速度5s内，还支持 image-2 生图。关注公众号后，后台回复 aihub 即可获取体验额度。
Level 2：先规划，再执行
解决上一阶段问题的方法很简单：
不要让 AI 立即写代码。
先让它告诉你计划。
现在很多工具，例如 Claude Code、Cursor，都支持类似流程。
你描述任务。
AI 先分析：
- 哪些文件需要修改？
- 准备采用什么方案？
- 会不会影响现有逻辑？
你检查计划。
确认没有问题以后，再允许它开始编码。
之前那个分页需求，如果提前进入规划模式，我可能会看到：
"第三步：重构 API 层。"
然后直接拒绝。
问题甚至不会产生。
实际使用时，不应该直接说：
"增加用户列表分页。"
更好的方式是：
"先检查用户列表、接口以及项目已有分页方案，不要修改代码，先给我执行计划。"
AI 可能会返回：
- API 增加 page 和 limit 参数；
- 返回分页信息；
- 修改用户数据 Hook；
- 增加分页组件；
- 补充边界测试。
这样，你可以提前发现错误方向。
也许项目已经有分页能力，只是前端没有调用。
计划模式最大的价值，就是让错误发生在写代码之前。
Level 3：测试驱动 AI
这一阶段，重点发生变化：
不是告诉 AI "我要什么代码"。
而是告诉它：
"什么结果必须满足。"
先写测试。
然后让 AI 编写代码，直到所有测试通过。
对于 AI 来说，这非常有效。
因为它拥有明确目标：
测试失败 → 分析原因 → 修改代码 → 再测试。
不过，需要注意一点：
AI 也可能"作弊"。
比如为了通过测试，直接写死返回值。
测试变绿了，但功能完全错误。
所以测试可以约束行为，却无法完全表达业务目的。
测试告诉 AI：
"应该发生什么。"
但无法告诉它：
"为什么必须这样。"
Level 4：规格驱动开发（Spec-Driven Development）
真正进入大型项目后，很多团队开始关注这一阶段。
核心理念只有一句话：
先写规格，再写代码。
规格文件描述：
- 你正在构建什么；
- 为什么构建；
- 如何判断它完成。
并且，这份规格应该和代码一起进入 Git。
未来需求变化时，不是直接修改代码，而是先修改规格，再重新生成对应部分。
规格，成为项目真正的来源。
例如开发一个午餐投票应用。
规格只描述：
- 成员可以提交餐厅；
- 每天只能投一次；
- 11:30 截止投票；
- 平票进入下一轮。
不会提前规定 React、数据库或者技术实现。
因为规格关注的是：
做什么。
而不是：
怎么做。
这一阶段还有一个重要概念：
Constitution 文件。
它保存团队长期规则：
例如：
"所有时间必须使用 UTC。"
"未经开关控制，不允许修改支付模块。"
AI 每次工作都会读取这些规则。
你不用重复提醒。
刚开始写规格，会感觉浪费时间。
但真正遇到需求变化时，你会发现：
修改几行规格，再重新生成代码，比重新检查几十个文件轻松得多。
如果你的需求已经成为版本管理文件，而代码只是它的产物，那么你已经进入这个阶段。
Level 5：多 Agent 协作
到了这里，一个 AI 已经不够。
你开始管理多个 AI。
一个负责产品需求。
一个负责架构设计。
几个负责开发。
还有一个负责测试。
它们像流水线一样协作。
听起来非常高级。
但现实并没有那么简单。
多个 Agent 最大的问题，不是数量，而是沟通。
如果产品 Agent 的信息没有传递给架构 Agent；
架构 Agent 的决定没有同步给开发 Agent；
最终可能出现：
四个 AI 非常努力地完成一个错误目标。
增加 Agent 数量，并不会自动提升智能。
协调本身，就是新的工程问题。
你需要：
清晰输入；
清晰输出；
共享文档；
明确权限。
有时候，一个上下文完整的 Agent，比五个互相不了解的 Agent 更有效。
Level 6：后台 Agent
这是变化非常明显的一步。
你不再一直陪着 AI 写代码。
你只需要创建任务。
然后 AI 在隔离环境中：
创建分支；
修改代码；
运行测试；
修复问题；
提交 Pull Request。
几个小时后，你回来审核结果。
这时候，你管理的不再是每一行代码。
而是整个任务包。
例如：
任务：
给 POST /api/login 增加限流。
要求：
- 限制 IP 失败次数；
- 保持成功登录逻辑；
- 保留原错误格式；
- 增加测试；
- 不修改认证流程。
这样的任务，AI 更容易正确完成。
相比：
"让登录更安全。"
前者给了边界。
后者给了一片无限空间。
Level 7：CI 强制执行规格
这是目前 AI 编程体系中最高阶段。
规格不再只是文档。
而变成机器可以检查的规则。
当 Pull Request 创建时：
CI 不只是运行测试。
AI 校验器还会检查：
代码是否符合规格？
接口是否违反约定？
是否修改了禁止修改的模块？
如果违反规则：
直接阻止合并。
它解决了软件开发里一个长期存在的问题：
文档越来越旧。
很多团队都有 Wiki。
但两年后，里面写的内容可能早已和真实系统不一致。
而规格进入 CI 后：
代码偏离规格，就会失败。
规格和代码之间，不允许出现长期分裂。
那到底应该用哪个等级？
答案不是：
越高越好。
不同任务，需要不同方式。
临时脚本：
Level 1 足够。
日常修改：
Level 2 很舒服。
重要功能：
Level 4 更可靠。
复杂系统：
才考虑多 Agent 和 CI 自动约束。
真正重要的能力，不是不断升级等级。
而是知道：
当前任务，需要哪一种工作方式。
如果你现在所有事情都直接让 AI 写代码。
那么本周只做一个改变：
先看计划，再让 AI 开始。
几十秒的检查，可能帮你避免几小时返工。
结尾
很多人的 AI 编程方式，其实是在 2023 年无意间形成的。
然后一直没有重新思考。
真正的问题，不是缺少一个新工具。
而是：
你有没有意识到自己现在在哪个阶段。
未来 AI 编程可能并不是：
"AI 自动写完所有代码。"
而更像：
"人类定义边界，AI 在边界内完成更多工作。"
你的规则越清晰。
AI 输出的问题越少。
最终，你花在修改错误代码上的时间，也会越来越少。