为什么 AI 越强大，规范能力越值钱
备选标题（供你挑）：
AI 帮你写代码只需 10 秒，但你可能要花 10 小时搞懂它写了什么
38 万款「裸奔」应用背后：Vibe Coding 繁荣的真正代价
当写代码变得免费，「把话说清楚」成了编程界最贵的技能
AI 消除的不是写代码的门槛，而是想清楚需求的纪律。
2025 年，安全公司 RedAccess 干了一件让整个开发者社区冒冷汗的事：他们扫描了互联网上约 38 万个疑似由"Vibe Coding"生成的应用。结果触目惊心——至少 5000 款没有任何安全防护，没有身份验证，没有访问控制，没有权限隔离，像一扇扇敞开的门挂在公网上。更离谱的是，其中约 40% 已经跑在生产环境里，处理着医疗记录、金融数据、企业内部文档。
你的第一反应大概是把锅甩给 AI："这帮 AI 写的代码也太不靠谱了。"
但等一下。真正的问题不是 AI 写了不安全的代码，而是从来没有人告诉 AI"这个应用需要安全措施"。
需求只存在于某个深夜的对话框里，随口一句"帮我做一个能存用户数据的 Web 应用"，AI 保质保量地执行了——它确实做了一个能存数据的应用。只是没人在"保质保量"前面加上一句"要加密、要鉴权、要防注入"。
这句话看似简单，但它指向一个被整个 AI 编程狂欢刻意回避的真相。这篇文章要聊的就是这个真相，以及它对每一个正在用（或准备用）AI 写代码的人意味着什么。
一、连发明者都在踩坑：Vibe Coding 的「裸奔」不是意外
先把时间线拉回 2025 年 2 月。OpenAI 联合创始人、前特斯拉 AI 负责人 Andrej Karpathy 在 X 上发了一条推文，提出了一个后来被《柯林斯词典》选为 2025 年度词汇的概念——Vibe Coding（氛围编程）。他描述了一种全新的编码方式：开发者"完全顺应感觉，拥抱指数级增长，忘记代码的存在"。原话是——"这不完全是编码，我只是看到东西，说出东西，运行东西，然后复制粘贴东西，它基本上能用。"
多潇洒。多自由。多危险。
Karpathy 自己在提出这个概念后，很快发现了一个尴尬的事实：AI 生成的代码缺乏可维护性，调试时根本搞不清底层逻辑。连"氛围编程之父"本人都踩了坑。这不是个例，这是 Vibe Coding 的结构性缺陷——当需求只活在聊天记录里，没有沉淀成任何可追溯的规范文档，代码就成了一座没有图纸的大楼。你觉得它"能用"，但你不知道承重墙在哪，改一根管线会不会整栋塌掉。
回到 RedAccess 那组数据。38 万个应用，5000 款裸奔，40% 在生产环境。很多人把它解读为"AI 代码不安全"。但我认为这是误读。
真正危险的从来不是 AI 写了烂代码，而是人放弃了「定义什么是好代码」的责任。
Vibe Coding 的问题不在 AI 的执行能力——执行能力恰恰是它最强的部分。问题在于输入端：一个模糊的自然语言指令，经过一个能力超群的执行引擎，被高效地放大成了一个结构完整的、可运行的、但方向可能完全错误的产品。AI 越强，这个"高效地跑偏"的破坏力就越大。
这就是为什么我说，5000 款裸奔应用不是 AI 的失误，而是"规范缺位"的必然结果。当没有人定义"这个系统必须有身份验证"这条约束时，AI 没有义务、也没有动机替你补上这个判断——它只负责把你说的东西做出来。
二、一个等式，戳破了「工具决定论」
聊到这里，你可能会想：那是不是换个更强的工具就好了？Claude Code 听说很强，Cursor 也不错，再不行上 Codex？
这是当下最流行的思维路径，也是最大的注意力陷阱。
来看一个来自企业实战中被反复验证的核心等式：
AI 输出质量 = 上下文质量 × 任务清晰度
这个等式冷酷而精确。模型能力是乘数之外的常数——在你选定工具的那一刻，它就固定了。真正决定产出质量的两个变量——上下文质量和任务清晰度——百分之百掌握在你手里。
这意味着什么？意味着"Claude Code 还是 Codex 更好"这个争论，在大多数场景下是个伪命题。
文档里有一组对比写得很好：Claude Code 像"坐你旁边的资深工程师"，每一步都跟你汇报，适合复杂重构；Codex 像"云端雇佣的自动化小队"，任务丢进去自主跑完，适合快速原型。两种范式各有战场。但请注意——这个对比描述的全部是执行层的差异。而上面那个等式告诉你，执行层的能力，在大多数日常场景中早就溢出了。
打个比方。你纠结该请一个八级瓦工还是一个九级瓦工来砌墙，但你连图纸都没画。八级和九级的差距，在"没有图纸"面前，约等于零。它们都会忠实地砌出一堵你没想要的墙。
一个来自真实团队的实践更能说明问题。有个团队总结了"三层约束法"——任务层告诉 AI"干什么"（优化订单排序，支持多字段排序、升降序、分页），约束层告诉 AI"不干什么"（不能破坏现有缓存、查询不超过 200ms、测试覆盖率大于 80%），规范层通过CLAUDE.md告诉 AI"按什么风格干"（遵循阿里巴巴 Java 开发手册，用 MyBatis-Plus 的 QueryWrapper）。三层写下来，AI 生成的代码基本就是想要的样子。
模型没有变，变的是你给它的约束。一个不到 100 行的
CLAUDE.md文件，能让同一个模型的输出产生天壤之别。
这就是那个等式在现实中的投影。工具是杠杆，但杠杆的支点是你喂给它的上下文。支点不稳，杠杆越长，翻车越惨。
三、约束杠杆：AI 时代的能力重估
如果上面那个等式成立，它会推导出一个对每个开发者都至关重要的判断。我把它叫做"约束杠杆"理论。
传统编程时代，能力栈大概是这样的：想清楚需求（30%）→ 设计架构（20%）→ 写代码（50%）。写代码占了半壁江山，所以"编码能力"是核心竞争力。面试考算法、考手写代码，逻辑就在这里。
AI 编程时代，这张表被重写了：想清楚需求并表达为规范（60%）→ 设计架构（25%）→ 审查和验证 AI 产出的代码（15%）。写代码这个动作本身，正在被压缩到近乎消失——AI 用 10 秒就能生成你过去要写一下午的东西。
在 AI 时代，写代码的能力在贬值，写规范的能力在升值。
这不是一个模糊的趋势判断，而是一个正在被工程实践证实的事实。OpenSpec 这个开源框架的存在本身就是证据——它由 Fission-AI 开发，专门解决一个问题：让你和 AI 在写代码之前，先在"要做什么"上达成一致。它支持 Claude Code、Cursor、Windsurf 等 25+ 工具，不换工具就能接入。
OpenSpec 最巧妙的设计叫 Delta Specs（增量规范）——只记录"变化的内容"，用ADDED/MODIFIED/REMOVED标记变更类型，不用每次重写整个规范文档。比如给系统加双因素认证，只需要在增量规范里标注新增的认证需求，归档时再自动合并进项目主规范。这个设计的本质是什么？是把"需求"从易消散的对话变成了可版本控制的工程资产。
一个完整的 OpenSpec 工作流长这样：/opsx:propose（提案，AI 自动生成 proposal.md、design.md、tasks.md 和增量规范）→/opsx:apply（按任务清单逐项实现代码）→/opsx:archive（合并规范、归档留痕）。整个过程没有跟 AI 反复扯皮需求，没有手动整理文档——但这套流程真正在解决的问题，不是"怎么让 AI 写得更快"，而是"怎么让人想得更清楚"。OpenSpec 官网 GitHub 仓库
到这里，有人一定会反驳：AI 越来越强，未来它自己就能理解需求、自己做架构、自己写规范，人还需要操心这些吗？
我的判断恰恰相反。AI 越强，规范越重要。
AI 越强，一个模糊指令的破坏力就越大——就像给一个实习生和一台挖掘机同样的权力，能力越强，翻车越狠。
原因很简单：AI 的执行能力越强，它执行一个错误或模糊指令的效率和完成度就越高。一个能力平庸的 AI 收到模糊指令，顶多写一段跑不起来的烂代码；一个能力超群的 AI 收到同样的模糊指令，会用最优雅的架构、最规范的语法，高效地构建出一个完全偏离你意图的系统——而且它看起来太"好"了，以至于你懒得审查，直到上线后出事。
这不是假设。RedAccess 那 5000 款裸奔应用就是活生生的例子——它们大概率不是 AI 拒绝加安全措施，而是从来没有人想过要提这个要求，AI 又快又好地把一个"不安全的需求"变成了一个"不安全的现实"。
所以规范层的价值，不是随着 AI 变强而衰减，而是随着 AI 变强而飙升。执行变得廉价，决策和约束就变得昂贵。这条规律不只适用于编程。
四、从 Vibe 到 Spec：一张实战判断地图
说完判断，给你一张可以立刻用的地图。不是所有项目都该上规范驱动那套重武器，但你需要知道什么时候该切换。
用 Vibe Coding 的场景——快速原型、个人项目、探索性验证、一次性脚本。这些场景的核心诉求是"快"和"试错成本极低"。你赌的是灵感，不是工程。一个周末 hackathon 的 demo，用 Vibe Coding 完全没问题，甚至是最优解。
必须上规范层的场景——核心业务逻辑、涉及敏感数据的功能、需要长期维护的生产代码、多人协作的团队项目。这些场景的核心诉求是"可控"和"可追溯"。你赌的是工程，不是灵感。
怎么判断你站在哪一边？问自己一个问题：如果三个月后这段代码出了 bug，有人（可能是未来的你）能看懂它当初为什么这么写吗？如果答案是"不能"，但这个项目又必须长期活着——你需要规范层。
三个可以今天就做的动作：
第一，给你的项目写一个最小信息集的CLAUDE.md或AGENTS.md——只回答三个问题：这项目是做什么的、技术栈是什么、项目结构长什么样。就这三条，已经能过滤掉一大半 AI 的胡乱发挥。Claude Code 甚至提供/init命令自动扫描项目结构生成草稿，你删掉废话、补上项目特有约定就行。
第二，把约束写得像法律条文，别写得像新年愿望。"写好代码、注意安全"是新年愿望；"类型标注必须、数据库操作用 ORM 不用裸 SQL、密码用 bcrypt 哈希"是法律条文。AI 听不懂愿望，但能执行条文。
第三，养成"上下文卫生"的习惯。开始实现前，清除无关的上下文，别让上一个任务的残留信息污染当前任务。这是 OpenSpec 官方反复强调的习惯——听起来微不足道，但它是区分"用 AI 写出好代码的人"和"被 AI 带着跑的人"的分水岭。
文章开头那 5000 款裸奔应用，现在还在互联网上跑着。它们的"创作者"大概还在享受 Vibe Coding 带来的快感——说一句话，应用就跑起来了，多酷。
但他们没意识到的是，自己省下的不是"写代码"的时间，而是"想清楚"的时间。而后者，正在以一种他们看不见的方式，变成技术债、安全漏洞和凌晨三点的线上事故，连本带利地讨回来。
写代码这件事正在变得免费。但「把一件事想清楚、说明白、变成别人（包括 AI）能精确执行的规范」——这项能力，正变成这个时代最贵的技能之一。
这不是某个工具的胜负，也不是某个框架的兴衰。这是编程这件事本身的重心迁移：从手，移到了脑。
所以与其花一整天研究"哪个 AI 编程工具最强"，不如花一小时想清楚"我要做的这个东西，到底该满足哪些约束"。
📌 互动问题：你最近一次用 AI 写代码，是花更多时间在"想清楚要什么"上，还是花更多时间在"让 AI 重写"上？你觉得这个比例健康吗？
如果你觉得这篇文章有价值，欢迎转发给需要的朋友。
