这两年关于程序员未来的讨论越来越极端。一种声音说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 不会等所有人准备好。它会继续把写代码这件事变得更便宜。然后把真正懂工程的人推到更重要的位置。参考资料程序员三大流派Andrej Karpathy 关于 Vibe Coding 的讨论GitHub Spec KitHarness engineering: leveraging Codex in an agent-first world