上周有个朋友跟我说：”我用Cursor写代码已经很溜了，Copilot补全也用得飞起，怎么感觉效率到了天花板？该试的都试了，提升不上去了。”

我问他：”你写Prompt的时候，是不是每次都在想怎么把需求描述得更清楚？”

他说：”对啊，这不是基本功吗？”

我说：”这就是你的天花板。”

他一脸问号。

一个残酷的事实：80%的人卡在第一层

AI编程这个技能树，不是一条直线往上点的。它更像格斗游戏的段位系统——青铜、白银、黄金，每个段位的玩法完全不一样。你在青铜段位把操作练到极致，也打不过白银段位随便玩玩的人。

问题是，大多数人不知道自己在哪个段位，甚至不知道段位这个东西存在。

他们以为AI编程就是”写Prompt → 拿代码 → 复制粘贴”，区别只是Prompt写得好不好。就像以为打篮球只有投篮一个动作，区别只是准不准——完全忽略了传球、跑位、战术配合这些维度。

我把AI编程分成三个段位。不是为了制造焦虑，是因为不同段位需要完全不同的思维方式和工具链。你在错误的段位里死磕，就像拿着青铜的装备打黄金的副本——不是你不够努力，是你的打法不对。

第一段位：氛围编程——跟着感觉走

这个段位有个很潮的名字叫”Vibe Coding”，翻译成人话就是”凭感觉写代码”。

典型画像是这样的：打开Cursor或者Copilot，脑子里有个模糊的想法，开始跟AI对话。AI给了一段代码，看着差不多，复制过去。跑不通？再问一轮。跑通了？完事。

这个阶段的特征是反馈循环极短——写Prompt、看结果、调整Prompt，整个过程就像在跟AI玩乒乓球。节奏很快，感觉很爽。你甚至会觉得自己效率已经很高了，毕竟一个下午能”写”好几百行代码。

但问题藏在你看不见的地方。

第一个问题：代码质量是随机的。 同一个功能，你今天问和明天问，AI给的实现可能完全不同。你没有标准，也没有约束，最终的代码质量完全取决于AI那一刻的”心情”。

第二个问题：上下文会爆炸。 你跟AI聊了二十轮，它已经忘了第一轮你说的约束条件。于是你发现它又开始用你明确禁止的那个库了。你只好重新提醒一遍，然后它又把之前改好的另一个文件搞乱了。这不是在编程，这是在玩打地鼠。

第三个问题：你没有积累。 每次开始新项目，一切从零开始。上一个项目里AI犯过的错误，这个项目里还会再犯一遍。因为你的”经验”全存在聊天记录里——而聊天记录是不会自动变成系统化知识的。

氛围编程的毕业考试很简单：你能不能独立把AI生成的代码改对？ 如果AI给了一段有bug的代码，你完全看不出来问题在哪——那你不是在编程，你只是在碰运气。

第二段位：结构化编程——用规则控制输出

升到这个段位的人，通常经历过一次痛彻心扉的翻车：AI写的代码上了线，炸了。从此以后，他们开始认真对待”怎么让AI输出稳定、可控的代码”。

结构化编程的核心思维转变是：你不再只是提需求，而是在设计约束。

具体来说，这个段位的人会做三件事。

第一，写系统级Prompt。 不是每次聊天时临时想一个Prompt，而是提前写好一份”规则手册”。比如CLAUDE.md或者.cursorrules文件，告诉AI：我的项目用TypeScript strict模式，测试用Vitest，命名用camelCase，错误处理必须用Result类型而不是try-catch。

这就像给新员工一本入职手册——你不需要每次都口头交代”我们公司的代码风格”，写一次，AI每次开工前都会自动读取。

第二，拆任务。 不再把一个大需求甩给AI让它一口气写完，而是拆成多个小任务，每个任务有明确的输入、输出和验证标准。”帮我实现用户登录”变成”先帮我写一个validateEmail函数，输入是string，输出是boolean，要处理空字符串和格式不合法的情况，给我写三个测试用例”。

第三，建反馈机制。 让AI写完代码之后跑测试、跑lint、跑类型检查。不是你自己去检查，而是让自动化工具替你把关。AI的输出不再是”看着差不多就行”，而是”必须通过所有检查才算完成”。

这个段位的效率比氛围编程高出一大截，因为你减少了返工。代码质量从”随机”变成了”稳定”。你开始有了积累——那些规则文件和Prompt模板是可以复用的，项目越做越顺。

但这个段位也有天花板。

天花板在哪？你还是在手动操盘。 每个任务还是需要你亲自拆解、亲自下达、亲自验收。你就像一个很优秀的项目经理，每个需求都安排得井井有条——但你一天只有24小时，你的吞吐量受限于你自己的带宽。

结构化编程的毕业考试是：你能不能把你的工作方式教给另一个人，让他用同样的规则和流程达到差不多的效果？ 如果可以——恭喜，你已经把个人经验变成了可复制的系统。但同时这也意味着，你该往下一个段位走了。

第三段位：系统化编程——让AI自己闭环

这个段位的画风突变。

你不再是”使用AI工具的程序员”，而是”设计AI工作流的架构师”。你的工作重心从”写代码”变成了”设计系统”——一个让AI能自主完成端到端开发任务的系统。

听着很玄？举个实际的例子。

在第二段位，你给AI的指令是：”帮我实现这个API接口，要求是……”然后等它写完，你review，提修改意见，它再改，你再review。

在第三段位，你设计的是一条流水线：AI读取需求文档 → 自动拆解任务 → 在独立的git分支上开发 → 自己写测试 → 自己跑测试 → 测试不通过就自己修 → 全部通过后提交PR → 另一个AI角色做code review → review通过后自动合并。

你从棋手变成了棋局设计者。

这个段位需要的核心技能完全不同：

第一，工作流设计。 你得想清楚整个开发流程应该怎么自动化，哪些环节需要人工介入，哪些可以全自动。这不是Prompt工程，这是系统工程。

第二，Agent编排。 一个AI做所有事情效果很差，就像一个人又当产品经理又当开发又当测试。你需要让不同的Agent扮演不同角色，各司其职。写代码的Agent专注写代码，review的Agent专注找问题，测试的Agent专注搞破坏。

第三，上下文管理。 大项目不可能把所有代码塞进一个上下文窗口。你需要设计信息流——哪些信息在什么时候传递给哪个Agent。CLAUDE.md、AGENTS.md、项目文档，这些不是”可选的配置文件”，而是你的AI团队的信息中枢。

第四，质量门禁。 自动化最怕的不是慢，是失控。你得在关键节点设置检查点：类型检查必须通过、测试覆盖率不能低于某个值、安全扫描不能有高危漏洞。这些门禁就是你的安全网——AI可以自由发挥，但不能突破底线。

一个反直觉的发现

你可能注意到了一个奇怪的现象：从第二段位到第三段位，Prompt写作能力的重要性反而下降了。

这很反直觉。大多数人以为AI编程的终极形态是”写出完美的Prompt”，所以他们花大量时间研究Prompt技巧——怎么用few-shot、怎么用chain-of-thought、怎么让AI角色扮演。

这些技巧有用吗？有用。但它们解决的是局部最优问题——怎么让AI在单次对话中给出更好的回答。

而真正的效率瓶颈在全局——怎么让整个开发流程更顺畅。

打个比方：你在高速公路上开车，车技再好，每个收费站都要停下来排队缴费。提高车技（Prompt技巧）能让你在两个收费站之间开得更快，但真正改变游戏规则的是ETC（自动化工作流）——直接把收费站消灭掉。

系统化思维比Prompt技巧重要100倍，就是这个道理。

你的30天升级路线

说了这么多，落到行动上该怎么做？每个段位给一个具体的30天计划。

如果你在第一段位（氛围编程），目标是升到第二段位：

  • 第1周：给你最常用的项目写一份CLAUDE.md或.cursorrules，把代码风格、技术栈、测试框架、命名约定全写进去。
  • 第2周：练习任务拆解。每次给AI提需求之前，先在纸上把任务拆成3-5个步骤，每个步骤有明确的验收标准。
  • 第3周：把AI的输出接入自动化检查——配置好lint、类型检查、测试，AI写完代码必须通过所有检查。
  • 第4周：回顾整个月的开发记录，把反复出现的问题沉淀成规则，更新你的规则文件。

如果你在第二段位（结构化编程），目标是升到第三段位：

  • 第1周：试用Claude Code或类似的Agent工具，体验”给一个任务让AI自己完成全流程”的感觉。
  • 第2周：设计你的第一个自动化工作流——不需要很复杂，比如”AI写代码 → 自动跑测试 → 测试不过就自动修”这样的小循环。
  • 第3周：尝试多Agent协作。让一个Agent写代码，另一个Agent做review，感受”分角色协作”和”单Agent包办”的差异。
  • 第4周：在一个真实项目里落地你设计的工作流，记录哪些环节需要人工干预，哪些可以全自动，持续优化。

AI不会替代程序员，但会替代”只会Vibe Coding的程序员”

最后说一句可能得罪人的话。

AI编程工具发展到今天，”会用AI”已经不是竞争力了——就像”会用搜索引擎”在2025年不是竞争力一样。真正的竞争力在于你处于哪个段位。

第一段位的人把AI当搜索引擎用：有问题就问，拿到答案就走。

第二段位的人把AI当初级员工用：给规则、给约束、给明确的任务，验收结果。

第三段位的人把AI当团队用：设计工作流、分配角色、建立质量门禁，让整个系统自己跑起来。

同样是”用AI写代码”，三个段位的人产出差距可能有10倍。不是因为他们用的工具不一样——很可能用的是同一个模型。差距在于他们驾驭AI的方式。

关键不是AI有多强，而是你能调度多少AI的能力。

你现在在哪个段位？你打算怎么升级？

这个问题，值得认真想想。