夜雨聆风你是不是把 AI 编程当成"更快的打字方式"？
装上AI编程工具，让 AI 补全代码，然后得出结论："还行，省了点敲键盘的时间。"接着继续手动写那 80% 的代码，把 AI 当高级自动补全用。
这就像你买了一辆汽车，只用来推着走。
不是汽车不够好，是你根本没坐上去。
更扎心的是——你推着车走了两年，觉得自己效率提升了 30%，还沾沾自喜。而旁边有人一脚油门，已经到了你十倍远的地方。
AI 编程有四个层次，你在哪一层？
接触过 AI 编程的人里，大约 80% 停在"偶尔用 AI 搜一下代码"的阶段。真正在用 Agent 做事的，可能不到 5%。
差距在哪里？我把它分成四层：
第一层：AI 当搜索引擎。
遇到不会的代码，打开 ChatGPT 问一下，复制粘贴到项目里。用的最多，产出最少。本质上和百度没区别，只是答案质量高了一点。
"帮我写一个 Python 读取 Excel 的脚本"——这类问题是 ChatGPT 上被问得最多的。得到答案后呢？复制到项目里，跑一下，报错了，再问一次。改了改，能跑了。
然后呢？没有然后了。
你解决了一个具体问题，但什么能力都没有沉淀下来。下次遇到类似的问题，你还得再问一次。每次对话都是一次性的，每次都从零开始。就像你每次需要一把锤子，都去五金店买一把新的，用完就扔。
第二层：AI 当自动补全：
用AI在编辑器里补全函数、写单元测试、写注释。
用户最喜欢说的一句话是："有了它，我写代码快了 30%。"30% 听起来不错。但你每天写代码的时间，占工作时间多少？大多数开发者大概是 30%-40%。也就是说，Copilot 帮你省下来的时间，是你整个工作时间的 9%-12%。
一天省 40 分钟。一周省 3 小时。一个月省 13 小时。这些时间用来干什么？大部分人的答案是：用来做更多同样的工作。
跑得快了一点，但方向没变。
第三层：AI 当代码生成器：
描述需求让 AI 生成代码，然后人工审查和调试。
很多人到了这一层有一种"终于解放了"的感觉。但很快就发现一个问题：审查 AI 生成的代码，比自己写代码更累。
你自己写的代码，你理解每一行在干什么、为什么这样写、有什么 trade-off。但 AI 生成的 500 行代码，你得从零开始理解。一个函数，AI 用了递归，你想用循环。一个数据结构，AI 选了 HashMap，你觉得该用 TreeMap。
审查别人的代码本来就难，审查 AI 的代码更难——因为你连"这个人的编码习惯"都没有可参考的。来来回回十几轮，花了比手写还长的时间。然后得出结论："AI 写的代码不行。"
这里有个关键转折：问题出在你没有给 AI 足够好的输入。第三层的关键能力是"定义需求"——你得能说清楚：我要什么、不想要什么、什么算做好了、什么情况下算错了。
第四层：AI 当自主执行者：
描述目标和约束，Agent 自己规划、编码、测试、迭代、交付。
前三层，不管 AI 做了多少，规划都是你做的。你决定先写哪个模块、后写哪个模块、用什么技术栈。AI 只是执行你的规划。第四层，Agent 自己做规划。
你给的目标是"帮我做一个用户管理模块"。Agent 会自己规划文件结构、选择技术方案、编写代码、运行测试、发现 bug 自动修复。你不需要参与任何一个步骤，只需要在最后看一眼结果。
这四层之间的核心差异，不在"谁在写代码"，在"谁在规划"。
前两层是"人干活，AI 帮忙"。第三层是"AI 干活，人监督"。第四层是"AI 干活，人负责"。
"不需要写代码"不等于"不需要懂技术"
说到这里，有人会反驳："AI 写的代码经常是错的，你不看怎么行？"
说得对。但你要看清这里面的逻辑。
当你审查 AI 生成的代码时，你在审查什么？不是语法——AI 不会犯语法错误。你审查的是：
业务逻辑有没有理解对？
边界条件有没有覆盖？
和现有系统的集成会不会出问题？
安全性、性能、可维护性是否达标？
这些是工程判断力，不是编码能力。
一个工作了十年的架构师，哪怕手写代码的速度不如应届生，他审查代码的能力也远超应届生。判断力来自经验，来自对业务、系统、风险的理解。这些东西目前没有任何 AI 能替代。
AI 编程时代，判断力比编码能力值钱十倍。
如果 AI 能写代码，那"会不会写代码"就不再是竞争优势。但"知不知道该写什么"，永远是。
这也是为什么我写完"程序员的判断力"系列之后，要写这个专栏。判断力告诉你"该做什么决策"，这个专栏告诉你"怎么用 AI 把决策变成现实"。
为什么大多数人停在第一层或第二层？
我接触了大量使用 AI 编程的人，大致分两类：
第一类：AI 辅助写代码。用AI写函数、生成模块，修改bug。效率提升了 30%-50%，但天花板很明显——他们还在代码的泥潭里，只是走得快了一点。
第二类：用 Agent 做产品。描述需求，Agent 规划实现，自动写代码、跑测试、修 bug，交付可用软件。他们中有工作二十年的架构师，也有完全没碰过代码的产品经理。他们有一个共同点：不亲自写代码，只负责定义和判断。
我属于第二类。不是因为我多聪明，是因为我花了大量时间去理解 Agent 的运作方式，理解怎么把需求描述清楚，理解怎么判断 AI 的输出质量。
工具从来不是瓶颈。认知才是。
但认知锁定是一个真实的问题。你已经写了十年的代码，思维模式是"遇到问题→想方案→写代码→测试"。AI 编程要求你换成"遇到问题→描述需求→验证结果"。这个切换不是装个工具就能完成的。
我见过太多人把 80% 的精力花在"选哪个 AI 工具"上，只有 20% 花在"怎么用好"上。但工具之间的差距远没有"会不会用"的差距大。一个会用 Agent 的人，用 Claude Code 和用 Cursor 的差距，远小于一个只会搜索式 AI 的人用最强模型和最弱模型的差距。
一个自测
想知道自己在哪一层？问自己四个问题：
你用 AI 时，是每次从零开始描述，还是有一套固定的上下文和流程？你交付一个功能时，代码是你写的还是 AI 写的？AI 写完代码后，你是逐行审查还是只看结果？你花在"定义需求"上的时间，比花在"调试代码"上的时间多还是少？
四个问题想完，你大概知道自己的位置了。
如果你发现自己停在第一或第二层，别急。这个专栏的认知篇会帮你建立完整的认知地图，原理篇会拆开 Agent 的黑箱，实战篇会手把手带你走到第三层和第四层。
但第一步永远是：承认自己停在第一层，然后决定走出去。
下一篇，我用一年的真实经历告诉你：为什么"不写代码也能做软件"不是噱头，是已经发生的事实。
