兆企观察 · 深度
Vibe Coding：门槛降了
但判断力，成了新的门槛
当“写”变得廉价，“判断”就变得昂贵
▲ Vibe Coding：门槛降了，但判断力成了新的门槛
2025 年 2 月，一个叫 Andrej Karpathy 的人在社交平台上随手发了一段话。他是 OpenAI 的联合创始工程师、前特斯拉 AI 负责人，那天他描述了一种新的编程方式：完全跟着感觉走，不看代码，出错了就把报错信息丢回去让 AI 改——他给这种方式起了个名字，叫 “vibe coding”（氛围编程）。
他自己都没料到这条推文会火。后来他在一次演讲里回忆：“我以为它只是一时兴起，但它成了彻底的梗——我想它触动了一根弦，给每个人都在感受、却说不出口的东西起了个名字。”如今这个词已经有了维基百科页面。
一年后，一个在字节跳动干了五年、完全不懂代码、纯文科背景的产品经理，用几句话就让 AI 做出了一个功能完整的微信朋友圈——图文、评论、点赞、发布、可见范围一应俱全。她甚至不知道代码是怎么写的，只知道“有 bug”，然后用大白话告诉 AI，AI 就修好了。
这两件事放在一起，指向同一个问题：编程这件事，是不是真的对普通人打开了一扇门？
我的答案是：Vibe Coding 确实把门槛从“会写语法”降到了“会提需求、会判断好坏”，普通人第一次有了真正参与编程的可能；但门槛降低不等于没有门槛——真正的分水岭变成了“会不会判断好坏”，而这件事，程序员并没有被取代，反而更被需要。
CHAPTER 01
编程的门槛被“自然语言”击穿了：从写语法到说人话
要理解这场变化有多大，得先回到 Karpathy 的一个判断。从 AI 发展的视角看，软件的形态已经变过两次：最早是人手写的代码（Software 1.0），后来是训练出来的神经网络权重（Software 2.0）——后者不是“写”出来的，而是“调”出来的。而他认为，近几年出现了第三种形态（Software 3.0）：用提示词给大语言模型编程。
“你的提示词现在就是给 LLM 编程的程序。而且，这些提示词是用英语写的。”——Karpathy 在演讲里的这句话，分量在于：过去七十年，编程语言是少数人掌握的技能，而现在，编程的“语言”变成了每个人都会说的自然语言。
他由此推出一个结论：突然之间，每个人都是程序员了，因为每个人都会说自然语言；过去你要花五到十年学习才能用软件做点什么，现在不是了。
这不是理论推演，而是正在发生的现场
那位在字节跳动做了五年产品经理、完全不懂代码的从业者，用几句话就让 AI 做出了一个功能完整的微信朋友圈：她先用 ChatGPT 讨论产品方案，把方案稿复制到另一个工具里，说“帮我做一个微信朋友圈”，AI 就做出了完整的功能。
更有意思的是 Karpathy 自己举的例子。他 vibe code 了一个叫 MenuGen 的 App——你在餐厅看不懂菜单，拍张照，它就生成菜品图片。他坦言自己根本不会写 Swift，但
“就一天的工作，当天晚些时候它就在我手机上跑了。”他还讲了一个细节：这个 App 注册就送 5 美元额度，“所以这是我生活里的一个主要成本中心，目前是个负收入 App，我在上面亏了很多钱”——一个不会写代码的人，能做出一个真实上线、真实烧钱的产品，这在两年前是难以想象的。
门槛确实降了。但降到哪里，就停在哪里了吗？并没有。
▲ 编程门槛的变化——过去要学编程语言，现在说自然语言
CHAPTER 02
但“说人话”不等于“随便说”：vibe coding 自带一套方法论
如果 vibe coding 真的只是“对着 AI 说一句我要什么”，那它早就该被证伪了。现实是：真正跑通的人，都在“说人话”之外，悄悄加上了一整套方法论。
先看原始形态有多粗糙
目光短浅
让 AI 改一个 bug，这个 bug 是改好了，却又引入了新的 bug，甚至完全破坏了程序原有的逻辑。
需求不明确
你明明想要一个塞尔达，它却给你做出一个原神——两款风格迥异的游戏，调侃的是 AI 理解不了需求的细微差别。
于是，为了让 AI 真正写出“懂我”的程序，人们发明了一连串沟通技巧：写程序前先和 AI 讨论需求，让它通过不断提问来明确你到底想要什么；开发前先写规范文档，再照着文档开发，这叫 SDD（Spec-Driven Development，规范驱动开发）；写程序前先写测试用例，把开发变成“不断让测试通过”的过程，这叫 TDD（Test-Driven Development，测试驱动开发）。
这一整套“话术”下来，字数都能写一篇高考作文了。为了省事，人们又把这些提示词打包成模板分享——比如 Open Spec 走 SDD 流程，Superpowers 走 TDD 流程。
更完整的做法，是一套被反复验证的五步流程
01 ① 环境搭建先把工程骨架、依赖、运行环境搭好，让 AI 有个能落脚的地方。
02 ② 产品设计把“给谁用、解决什么问题、做成什么样”说清楚，这一步省了，后面全是返工。
03 ③ 技术设计数据怎么存、模块怎么切、接口怎么定——先想清楚，再让 AI 动手。
04 ④ 产品实现交给 AI 写，但要求它每改一次都留下版本快照。
05 ⑤ 人工验证人来做最后一道验收：它到底对不对、能不能用、敢不敢上线。
其中有两个细节特别关键
给 AI 建立“项目说明书”
在项目里创建一个 agents.md 文件，写明两条铁律——每次改动必须创建版本快照，每次改动必须编写或更新测试并确保全部通过才能交付。这样 AI 就不会写完代码直接交差，而是会自己先跑一遍、测一遍，发现问题就继续修。
给 AI 自测的能力
给 AI 一个能够验证的环境非常重要，否则它很容易写出一堆 bug。很多人只是让 AI 写代码，却不给它验证的环境，结果自己沦为了测试员，来来回回帮 AI 找 bug，极其浪费时间。
这套流程还给出了“什么时候可以省步骤”的判断标准——简单且不重要的需求，可以跳过产品设计和技术设计，直接让 AI 实现；复杂且重要的需求，才走完整五步。
这恰恰说明：vibe coding 不是“不用思考”，而是“把思考用在了不同的地方”。
▲ vibe coding 的五步方法论——从环境搭建到人工验证
CHAPTER 03
方法论要落地，得靠“编程智能体平台”
上面这些方法论听起来都对，但一个现实问题是：光有方法论不够，它得有地方落地。
这就是编程智能体平台（比如 OpenAI 的 Codex、Anthropic 的 Claude Code、Cursor 等）出现的原因——它们不是“更聪明的聊天窗口”，而是把 vibe coding 从“纸上谈兵”变成“能干活”的基础设施。
它先解决的是三个死结
01 死结 ① AI 够不着你的电脑最早的 vibe coding 是在聊天窗口里复制粘贴：AI 给你一段代码，你贴到本地运行，报错了再把错误粘回去——写个小程序要来回几十次。根本原因是，大模型和聊天界面都跑在厂商的服务器上，它唯一的能力是“产出内容”，没法直接读你硬盘上的文件、更没法执行程序。编程智能体平台是一个跑在你本机（或云端沙盒）的程序，能直接读写文件、执行终端命令、跑测试、提交代码，把“读代码→改代码→运行验证”连成闭环——相当于给 AI 装上了一双能操作电脑的手。
02 死结 ② 上下文聊天窗口看不到你的整个项目，而平台会主动收集项目结构、你正在编辑的文件、命令行输出等信息一起打包给模型，让它“看到的东西跟你几乎一样”。这也是为什么它能在几十万行的代码库里定位问题，而不是只会在一个孤立文件里打转。
03 死结 ③ 并行与长时运行云端智能体可以并行跑多个任务、后台运行、甚至跨天自动唤醒，把“一个人”的产能放大成“一支小队”。
看清了它解决什么问题，发展方向也就清楚了
从单 Agent 走向多 Agent 协作
由一个“调度者”把任务拆开，分派给架构、编码、测试、审查等专业子 Agent，并行推进再交叉校验。
长时运行与自主执行
让 Agent 在无人值守的情况下连续工作数小时，中途可检查点恢复。
MCP 生态与权限分层
用统一协议把数据库、代码仓库、设计工具接进来，同时把安全从“事后打补丁”变成“架构前置”，高风险操作默认需要人工审批。
具体到人，该怎么用
对程序员来说，角色正在从“写代码”转向“编排写代码的 Agent”。核心职责变成了架构设计、任务分解、质量评估和最终把关。
但“委托”是有边界的：AI 擅长“你已经明确知道该怎么做”的任务，而模糊需求、跨模块的系统判断、安全与权限边界，必须由人兜底。一个被反复验证的经验是——把项目规范写进 agents.md 之类的配置文件，让 AI 每次都读到；把能自动化的检查（测试、格式、静态扫描）交给确定性的工具，而不是指望 AI“记得”。
对普通人来说，门槛确实降了，但不是降为零。你不需要会写代码，但需要三样最小能力：
· 把需求说清楚——用大白话描述“我要什么、给谁用、解决什么问题”。
· 会读报错并原样反馈——把错误信息复制给 AI，而不是只说“它坏了”。
· 知道安全红线——不要把密钥硬编码进去，涉及支付、隐私的功能要请专业人员把关。
还要有心理准备：“最后 20%”往往比想象中难得多——认证、支付、边界情况这些收尾工作，常常比做出一个能跑的 Demo 花的时间还长。
▲ 编程智能体平台——给 AI 装上能操作电脑的手
CHAPTER 04
门槛降低的代价：判断力成了新的分水岭
Vibe Coding 最诱人也最危险的地方在于：它让你“感觉”自己很快，但感觉和现实之间，可能隔着一条鸿沟。
▲ 门槛降低的代价——生成变便宜，判断变昂贵
最硬的证据，来自 Anthropic 的随机对照试验
AI 组的得分比手写组低了 17%（这个差距在统计上显著，Cohen’s d=0.738，p=0.01）。
“认知努力——甚至痛苦地卡住——很可能对培养精通至关重要。”——Anthropic 在结论里写下的这句话，反过来说就是：那些被 AI 替你省掉的“卡住”的时刻，恰恰是能力生长的时刻。
这不是孤例
01 METR · 快了 20% vs 慢了 19%开发者自认为用 AI 后快了 20%，实际测量却慢了 19%——感知与实际的差距接近 40%。研究者把这种状态称为“dark flow”（暗流），说它像老虎机一样，把“损失伪装成胜利”。
02 一句话总结我们自动化了写代码，但没有自动化软件工程。
而最生动的警示，来自一个真实的生产事故
一位开发者用 AI 做了个搜索功能，上线当天一切正常——因为只有 10 个测试用户。两周后的黑色星期五，网站四分钟内崩溃：
AI 生成的代码在每一次按键时都触发一次数据库查询，有人输入 “running shoes”（跑鞋），就是 12 次查询猛砸生产环境。没有防抖、没有缓存、没有限流。公司每分钟损失 1.2 万美元。
当被问及为什么没做防抖时，这位开发者的回答诚实又可怕：测试时是好的，他没意识到这会是个问题。
真正的要害在于：他不是做了个坏决定，他根本没做决定。
连命名者本人也在动摇
Simon Willison 原本坚持“vibe coding（不看代码）”和“agentic engineering（专业工程化使用 AI）”是两回事，但如今他承认，这两者在他自己的工作中已经开始模糊，这让他很不安。他划出了一条底线：
vibe coding 只适合“个人工具，bug 只伤到自己”；如果为他人构建软件，vibe coding 是严重不负责任的，因为那涉及他人的数据。他还提出了一个新难题：AI 能在半小时内造出一个有 100 次提交、漂亮 README、完整测试的仓库，外观和用心打磨的项目一模一样，根本无法从外观分辨——因此他现在更看重的是“作者是否真的用过这个东西”。
BitTorrent 之父 Bram Cohen 说得更直接：纯粹的 vibe coding 是个神话。他讽刺那种“看引擎盖下面就是作弊”的教条，并留下一句值得所有开发者贴在墙上的话——
“烂软件是你做的决定，你得认账。”
把这些放在一起看，结论就清楚了：AI 把“写”这件事的成本压到了接近零，但“判断”这件事的成本没有降，反而因为“写”变得太容易而变得更贵。
当生成代码不再是瓶颈，瓶颈就转移到了“生成之后——你能不能看出它对不对”。
▲ 普通人能参与吗——判断力成了新的分水岭
CHAPTER 05
普通人到底能不能参与？能，但程序员也没有被取代
回到最初的问题：普通人到底能不能参与编程？能，而且门槛确实比过去低得多。但素材同时告诉我们两件事，缺一不可。
第一件：普通人需要的不是“先学会编程”，而是“先动手”和“会判断”
那位字节的产品经理给普通人的建议很直接：直接开干，找一个你想实现的小 idea，不要上来就做微信，在干的过程中学习；了解不同的 AI 工具；多用，用得越多越能找到感觉；建立“不懂就问 AI”的心智。
反过来，你不需要先学一堆概念——学概念的周期太长，等你学完却没有任何实际收获，很可能就失去兴趣了。而一位从零开始做小白教程的实践者说得更朴素：vibe coding 其实非常简单，就是用大白话去告诉 AI 你想要什么；最难的不是这个技术，而是第一次动手的决心。
第二件：“会判断”恰恰是程序员的价值所在
一位作者提出了一个叫“熟练编排者悖论”的说法：
管理 AI 所需的技能，恰恰会被 AI 侵蚀——你越是依赖 AI 生成，就越难判断它生成得好不好。
这解释了为什么 Anthropic 的研究里，高分者的共同点是“用 AI 建立理解”而不是“用 AI 代替思考”：他们追问、要解释、提概念性问题，而不是简单地说“帮我写”。
Karpathy 给了一个更乐观的框架
他借用经济学里的杰文斯悖论——就像 ATM 没有消灭银行柜员，反而因为网点成本下降而让柜员更多——认为软件需求会变得极大：
“软件过去稀缺、太贵，如果门槛降低，需求反而会上升。我对软件工程持谨慎乐观。”他甚至给出了一个关于“人的价值”的判断——
“agent 做不到的事，才是你现在的工作；agent 能做的，它可能很快比你做得更好。所以你应该策略性地思考，你真正把时间花在哪。”
他还讲了一个关于教育的观察，意味深长。他做了个把大语言模型蒸馏到本质的 200 行代码项目 microGPT，以前他会做视频一步步讲解，现在他意识到：
“我不是在向人解释，我是在向 agent 解释。如果你能向 agent 解释，agent 就能当路由器，用你的语言、无限耐心、按你的能力水平讲给人听。”他让 agent 自己写 microGPT，agent 做不到——“它只是不能自己发明出来，但它完全理解为什么这么做。所以我的贡献是这几个比特。”
换句话说，AI 时代真正稀缺的，不是“能生成”的能力，而是“能判断什么值得生成、什么是对的”的能力。
这也正是 WorkMate 这类平台在回答的问题
当一个人要独自面对“提需求—生成—验证—交付”的完整链条时，它把几个关键环节变成了可配置、可治理的机制：
技能（Skill）
把某个领域的专业工作流和提示词打包好，让不懂行的人也能按专业范式拿到稳定结果。
引用知识库
让 AI 的回答严格基于你指定的资料，而不是凭空生成。
执行过程透明
把 AI 的每一步思考和工具调用折叠成可展开的审计面板，让你随时能看清“它为什么这么做”。
人机交互（HITL）
遇到有后果的动作——删除、外发、付款——任务自动暂停，弹出确认卡等你拍板，回应后才从断点继续。
这些机制背后是同一个判断：AI 负责生成，人负责判断，而平台要做的，是让这个“判断”尽可能快、尽可能有据可依。
而对于“一个人做不完”的问题，它用数字员工和协同任务给出了另一种答案。
数字员工是以独立工号登录的 AI 员工，7×24 小时待命，有法务、财务、销售等专业分工，可以像真实同事一样被派活，即使离线，任务也会持久化到队列、等它上线后自动执行；协同任务则把“人→人→人”的工作流建模成一条可追踪的任务链，支持串行接力与并行汇聚。
一个人，也能组织起一支“AI + 人” 的团队。
结尾
回到开头那个问题。Vibe Coding 到底改变了什么？
它没有让程序员消失——恰恰相反，Anthropic 的研究、Willison 的底线、Cohen 的“认账”，都在说同一件事：
当“写”变得廉价，“判断”就变得昂贵。它真正改变的，是把编程的门槛从“会不会写语法”挪到了“会不会提需求、会不会验收结果”。这扇门确实向普通人打开了，但进门之后，你要面对的是一道新的分水岭。
CONCLUSION
AI 可以替你写下一万行代码，却没法替你承担那一行错误带来的后果。
真正值得追问的或许不是“AI 会不会取代程序员”，而是：当生成代码变得像说话一样容易，我们每个人，是否都准备好为自己的“判断”负责了？
你试过 vibe coding 吗？
做出来的东西，你敢直接上线吗——欢迎在留言区说说你踩过的坑。
点赞 · 在看 · 收藏 三连，我们下篇见
