这两年，关于程序员未来的讨论越来越极端。
一种声音说：AI 都能写代码了，程序员快没用了。
另一种声音说：AI 只是工具，真正的程序员反而会更值钱。
我现在越来越觉得，这两句话其实都对，但都只说了一半。
AI 不是简单地消灭程序员，也不是平均地增强所有程序员。
它真正做的事情，是把程序员之间原本不太明显的能力差距，突然放大了。
以前大家都在写代码，差别可能体现在：
- 谁语法更熟
- 谁框架用得更快
- 谁排查 bug 更有经验
- 谁加班更多
但 AI 进来以后，游戏规则变了。
当“写出一段能跑的代码”变得越来越便宜，真正贵的东西就变成了：
你能不能说清楚要什么。
你能不能定义什么叫做对。
你能不能设计一个让 AI 稳定交付的环境。
所以，AI 时代的程序员，正在快速分成三层。
不是初级、中级、高级。
而是三种完全不同的工作方式：
Vibe Coding、Spec Coding、Harness Engineer。
如果翻译得直白一点：
- Vibe Coding（氛围编程）：凭感觉让 AI 写
- Spec Coding（规范编程）：写清规范让 AI 做
- Harness Engineer（驾驭工程师）：搭好系统让 AI 稳定交付
这不是三个流行词，而是程序员能力迁移的三个阶段。
一、第一层：Vibe Coding，会让 AI 快速写出原型的人
Vibe Coding 这几年特别火。
它的工作方式很简单：
你告诉 AI 一个大概想法，AI 生成一堆代码。
你跑一下，能用，就继续让它加功能。
哪里报错，就把报错贴回去，让 AI 修。
比如：
帮我做一个登录功能，支持邮箱和密码，界面好看一点。
AI 很快就能给你生成页面、接口、校验、样式，甚至还能顺手帮你写一点状态管理。
这就是 Vibe Coding 最吸引人的地方：
它让“从 0 到 1 看见东西”的速度变得极快。
以前你想做一个小工具，可能要先建项目、选框架、写页面、接接口、处理样式。
现在你只要描述一个方向，AI 就能给你搭出一个大概能跑的雏形。
这对个人开发者、原型验证、小工具、内部演示非常有价值。
但 Vibe Coding 的问题也非常明显：
它很快，但不一定稳。
它很爽，但容易失控。
它能帮你冲出第一版，却不保证你能维护第二版。
很多人第一次用 AI 写代码，会有一种错觉：
“我好像突然变强了。”
但做着做着就会发现，真正痛苦的不是 AI 写不出代码，而是它写得太多、太快、太随意。
目录结构开始乱。
状态管理开始绕。
异常处理前后不一致。
同一个概念在三个文件里有三种写法。
你让它修一个 bug，它顺手改了另一个逻辑。
你让它优化一下，它把原来能跑的地方改坏了。
这时候你才会意识到：
Vibe Coding 解决的是“有没有代码”的问题，不解决“代码是否可靠”的问题。
它适合探索，不适合托底。
它适合做草图，不适合直接当施工图。
它适合让你快速看到可能性，不适合让你把复杂系统长期交给感觉。
所以，第一层程序员的核心能力不是“会写提示词”，而是：
会把一个模糊想法，快速变成 AI 能理解的任务。
这已经比不会用 AI 的人强很多。
但如果只停在这一层，你会越来越依赖运气。
因为你不是在管理工程，你只是在和 AI 对话。
二、第二层：Spec Coding，会写规范的人
当你被 Vibe Coding 折磨过几次，就会自然进入第二层：Spec Coding。
你会开始明白，不能一上来就让 AI 写代码。
你得先把事情说清楚。
Spec Coding 的核心不是“提示词更长”，而是“约束更明确”。
同样是登录功能，Vibe Coding 可能这样说：
帮我做一个登录功能。
Spec Coding 会这样写：
实现邮箱密码登录。
邮箱必须符合格式。
密码错误时提示“邮箱或密码错误”，不能暴露账号是否存在。
登录成功后跳转到控制台。
后端使用 bcrypt 校验密码。
接口返回统一错误结构。
需要包含正常登录、密码错误、邮箱格式错误三个测试场景。
这两种写法的差别，不只是字数。
前者是在许愿。
后者是在定义工程合同。
Spec Coding 真正改变的是程序员的位置：
你不再只是让 AI “帮你写”。
你开始告诉 AI “什么算写对”。
这一步非常关键。
因为在 AI 时代，代码生成能力会越来越普及。
但需求拆解、边界定义、验收标准、风险判断，这些能力不会自动普及。
很多程序员过去不爱写文档，觉得文档是形式主义。
但 AI 出现以后，文档突然变成了生产资料。
你写得越清楚，AI 越像一个稳定的执行者。
你写得越模糊，AI 越像一个自信但不靠谱的实习生。
Spec Coding 的高手，往往不是最会“调教 AI”的人，而是最会把复杂问题拆成可执行规范的人。
他知道：
- 哪些需求必须先定义边界
- 哪些输入输出不能含糊
- 哪些错误场景必须提前写清
- 哪些安全约束不能交给 AI 自由发挥
- 哪些测试要先出现，否则后面一定会返工
这一层程序员的价值，不再只来自写代码速度，而来自对复杂度的控制。
他们做的是一件过去经常被低估、现在越来越值钱的事情：
把“我想要”翻译成“系统应该如何工作”。
这也是为什么我认为，未来很多程序员的分水岭，不是会不会用 Cursor、Claude Code、Copilot、OpenClaw 或其他 AI 工具。
真正的分水岭是：
你能不能写出一份 AI 和人都看得懂、并且能拿来验收结果的规格说明。
会写代码的人很多。
能把需求写得足够清楚、可验收的人，会越来越稀缺。
三、第三层：Harness Engineer，会搭系统的人
如果说 Vibe Coding 是让 AI 写代码，Spec Coding 是让 AI 按规范写代码，那么 Harness Engineering 更进一步：
它不是直接关心 AI 写什么，而是关心 AI 在什么环境里工作。
Harness 这个词，可以理解成“马具”“约束装置”“测试夹具”。
放到 AI 编程里，它代表的是一整套工作环境：
- AI 能访问哪些文件
- AI 不能碰哪些目录
- 它可以调用哪些工具
- 它执行任务前要读哪些规范
- 它改完代码后必须跑哪些检查
- 它遇到失败时应该如何定位问题
- 它生成的结果由什么质量门禁拦住
这时候，程序员的角色又变了。
你不再只是任务提出者。
也不只是规范撰写者。
你开始变成 AI 工作流的架构师。
这很像从“自己开车”变成“设计赛道”。
Vibe Coding 阶段，你坐在驾驶位上，不断提醒 AI 往左一点、往右一点。
Spec Coding 阶段，你先画好路线图，让 AI 按路线开。
Harness Engineering 阶段，你把赛道、护栏、测速点、维修站、终点规则都设计好，让不同 AI Agent 可以在里面协作。
这也是未来真正稀缺的能力。
因为企业级软件开发最怕的不是“代码生成得不够快”。
企业真正怕的是：
- 代码改坏了没人知道
- 权限泄露了没人拦住
- 测试没跑就合并了
- 上下文丢失导致重复返工
- 多个 AI 同时改代码互相覆盖
- 生成内容看似合理但违反系统约束
这些问题，靠一句“你认真一点”是解决不了的。
也不能指望 AI 每次都自觉。
你需要的是工程化的护栏。
比如：
- 给 AI 明确只读、可写、禁止访问的范围
- 把需求、设计、计划、测试步骤标准化
- 用 lint、test、typecheck 做自动质量门禁
- 用代码评审和变更摘要控制合并风险
- 用小任务拆分减少上下文漂移
- 用可复现命令验证每次修改
到了这一层，程序员关注的已经不是某一次提示词写得漂不漂亮，而是整个 AI 协作系统是否可靠。
这类人可能写的业务代码反而少了。
但他们决定了 AI 生成的代码能不能进入真实工程。
所以，Harness Engineer 不是“不写代码的程序员”。
恰恰相反，他必须更懂工程。
因为只有真正踩过坑的人，才知道护栏应该建在哪里。
四、三层差异的本质：从产出代码，到控制复杂度
很多人讨论 AI 编程时，关注点还停留在：
AI 写代码到底能不能替代程序员？
但这个问题本身就有点过时了。
因为 AI 写代码已经不是未来，而是现在。
真正应该问的是：
当代码越来越容易生成，程序员还剩下什么核心价值？
我的答案是：
控制复杂度。
Vibe Coding 控制的是想法到原型的复杂度。
Spec Coding 控制的是需求到实现的复杂度。
Harness Engineering 控制的是 AI 协作到工程交付的复杂度。
越往后，越不只是“会不会写代码”。
越往后，越接近工程负责人、架构师、技术负责人真正关心的问题。
这也是为什么 AI 不会平均地提升所有程序员。
它会让会表达的人更快。
让会写规范的人更稳。
让会搭系统的人更稀缺。
同时，也会让只会等别人拆好任务、照着需求单写代码的人越来越被动。
过去，一个需求说不清楚，可能大家开几次会、慢慢磨。
现在，需求说不清楚，AI 会立刻把混乱放大成一堆代码。
过去，工程边界不清楚，可能只是开发效率低一点。
现在，边界不清楚，AI 可能会在十分钟内帮你制造出一个更难维护的系统。
AI 不会自动带来工程质量。
它只会放大你原有的工作方式。
你本来就会拆问题，AI 会让你更快。
你本来就重视测试，AI 会让你覆盖更多场景。
你本来就习惯随手改、凭感觉冲，AI 会让混乱来得更猛烈。
这就是三层分化背后的真相：
AI 没有降低工程能力的重要性，它只是降低了写代码本身的稀缺性。
五、普通程序员应该怎么升级？
如果你现在还停留在 Vibe Coding，也不用焦虑。
Vibe Coding 不是低级，它是入口。
每个人都应该先体验那种“想法快速变成代码”的冲击感。
但你不能一直停在那里。
比较现实的升级路径是三步。
1. 先把 AI 当原型工具
不要一开始就把核心系统交给 AI。
先让它做这些事情：
- 写小工具
- 生成页面草稿
- 解释陌生代码
- 补充单元测试
- 重构局部函数
- 根据报错提供排查方向
这个阶段的目标不是追求完美，而是建立直觉：
AI 擅长什么，不擅长什么。
什么任务可以交给它，什么任务必须自己判断。
2. 再训练自己写规格说明
当你发现 AI 产出开始不稳定时，不要急着换模型。
先检查自己有没有把需求说清楚。
每次让 AI 做稍微复杂一点的任务前，先写清五件事：
- 背景：为什么要做
- 目标：最终要得到什么
- 边界：哪些不做
- 约束：技术、安全、性能、风格要求
- 验收：怎么判断完成
这五件事写清楚，AI 的稳定性会立刻提升一个层级。
更重要的是，这个习惯不只对 AI 有用。
它对人也有用。
你会发现，很多所谓“沟通成本高”“需求反复变”“开发返工多”，本质上都是规格说明没有写清楚。
AI 只是让这个问题暴露得更快。
3. 最后开始搭自己的工程护栏
当你开始频繁使用 AI 改真实项目，就必须建立护栏。
最简单的护栏包括：
- 每次只让 AI 改一个明确任务
- 改之前先让它说明计划
- 改之后必须解释变更点
- 关键文件禁止随意修改
- 提交前必须跑测试或静态检查
- 涉及鉴权、支付、隐私、数据删除的代码必须人工复核
这听起来麻烦，但这是 AI 编程从“玩具”进入“工程”的分界线。
没有护栏，AI 越强，你越容易失控。
有了护栏，AI 越强，你的交付能力越高。
六、未来最值钱的程序员，不是最会写提示词的人
很多人把 AI 编程理解成“提示词工程”。
但我觉得，这个理解太浅了。
提示词当然重要。
但提示词只是入口，不是终局。
未来真正值钱的程序员，不是每次都能写出一段神奇 prompt 的人，而是能把 AI 放进稳定工程系统里的人。
他知道什么时候应该让 AI 自由探索，什么时候必须收紧边界。
他知道什么时候可以快速试错，什么时候必须先写测试。
他知道 AI 的输出不能靠感觉验收，而要靠规范、测试、评审和可复现流程验收。
这类程序员反而更不容易被 AI 替代。
因为他们做的事情，正是让 AI 变得可用、可信、可交付。
换句话说：
不会用 AI 的程序员，会被会用 AI 的程序员拉开差距。
只会让 AI 写代码的程序员，会被会写规范的程序员拉开差距。
只会写规范的程序员，又会被会搭 AI 工程系统的程序员拉开差距。
七、写在最后
如果用一句话总结这三类程序员：
Vibe Coding 是草图能力。
它让你快速探索，把想法变成可见的东西。
Spec Coding 是蓝图能力。
它让你定义边界，把需求变成可执行的工程合同。
Harness Engineering 是交付体系能力。
它让你搭建环境，把 AI 的不稳定输出变成可控交付。
AI 时代，程序员当然还重要。
但重要的方式变了。
真正的安全感会来自：
你能不能提出好问题。
你能不能写清楚规格。
你能不能搭好系统。
你能不能让 AI 在你的工程边界里稳定工作。
未来的程序员，不一定都要成为 Harness Engineer。
因为 AI 不会等所有人准备好。
它会继续把写代码这件事变得更便宜。
然后把真正懂工程的人，推到更重要的位置。