上个月我让一个 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 7CI 强制执行规格这是目前 AI 编程体系中最高阶段。规格不再只是文档。而变成机器可以检查的规则。当 Pull Request 创建时CI 不只是运行测试。AI 校验器还会检查代码是否符合规格接口是否违反约定是否修改了禁止修改的模块如果违反规则直接阻止合并。它解决了软件开发里一个长期存在的问题文档越来越旧。很多团队都有 Wiki。但两年后里面写的内容可能早已和真实系统不一致。而规格进入 CI 后代码偏离规格就会失败。规格和代码之间不允许出现长期分裂。那到底应该用哪个等级答案不是越高越好。不同任务需要不同方式。临时脚本Level 1 足够。日常修改Level 2 很舒服。重要功能Level 4 更可靠。复杂系统才考虑多 Agent 和 CI 自动约束。真正重要的能力不是不断升级等级。而是知道当前任务需要哪一种工作方式。如果你现在所有事情都直接让 AI 写代码。那么本周只做一个改变先看计划再让 AI 开始。几十秒的检查可能帮你避免几小时返工。结尾很多人的 AI 编程方式其实是在 2023 年无意间形成的。然后一直没有重新思考。真正的问题不是缺少一个新工具。而是你有没有意识到自己现在在哪个阶段。未来 AI 编程可能并不是“AI 自动写完所有代码。”而更像“人类定义边界AI 在边界内完成更多工作。”你的规则越清晰。AI 输出的问题越少。最终你花在修改错误代码上的时间也会越来越少。最后我们整理出这套 AI 大模型 突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2025 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要 《 AI大模型 入门进阶学习资源包》下方扫码获取~资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。需要这份AI大模型资料清单的话在评论区回复「清单」即可我会根据大家的问题继续补充对应的实战内容。