Vibe Coding不是提示词竞赛：工程规范才是关键

Vibe Coding 这个词最近在AI编程讨论里出现频率非常高。很多人的第一反应是“用自然语言指挥AI写代码”，于是把大量时间花在打磨提示词上：需求描述反复改、角色设定越写越长、语气和格式要求堆了一大段。我一开始也这么干，用了一段时间之后发现一个很别扭的事实——提示词确实能决定AI第一次生成的代码长什么样，但它决定不了这套代码一个星期之后是否还能改得动，决定不了能不能交给另一个同事维护，更决定不了边界输入来的时候会不会直接崩掉。真正影响这些问题的，是用AI编程的方式背后的工程规范。这篇就把我对 Vibe Coding 的重新理解拆开讲：它到底在解决什么问题，为什么提示词不是核心，以及一套能落地的流程长什么样。

1. 先把话说明白：Vibe Coding 不是提示词竞赛

很多教程都在讲“怎么把提示词写得更好”，这容易让人产生一个错觉：Vibe Coding 的成败取决于提示词水平。但如果你真的用它完整做过一个小项目，就会意识到这个结论只对了一半。提示词是入口，不是护栏。

1.1 Vibe Coding 解决的真实问题是什么

Vibe Coding 本质上改变了“编写代码”这个动作的颗粒度。过去是你自己动手把功能一行行写出来，现在是你把一个清晰的需求描述出来，AI 负责生成实现，你再负责审查、运行、验证、修改。

这个模式解决的真实问题，是缩短“脑子里有想法”到“有可执行代码”的距离。尤其是原型验证、脚本工具、内部系统、UI 草稿这类任务，AI 能很快给出一个能跑的版本。这个价值非常实在，不需要否认。

但也正因为起点很低、速度很快，很多人会忽略一个问题：AI 生成代码不是终点，它是需要持续维护的起点。Vibe Coding 真正要解决的不只是“能不能生成”，而是“生成之后能不能长期改、能不能稳定跑、能不能交给别人看懂”。

1.2 为什么提示词替代不了工程规范

提示词解决的是“从自然语言到代码”的翻译问题。你可以用一段提示词让 AI 写一个登录接口，也可以让它把某个页面重构成组件化写法。这个层面的效率确实高。

但代码一旦进入真实项目，它要面对的就不是“生成”这个动作，而是持续的变化。需求会变，数据结构会变，依赖版本会变，别人会接手，AI 会在旧代码基础上继续生成增量代码。这时候起作用的是什么？

是工程规范。

比如：

• 目录结构是否固定，AI 知道新文件往哪里放；
• 接口签名是否提前定义，AI 不会自己乱改参数；
• 命名规则是否统一，AI 不会一套代码里混着 camelCase 和 snake_case；
• 错误处理是否有约定，AI 不会只写 happy path；
• 提交前是否跑测试和 lint，AI 不会把明显坏掉的代码当成完成。

提示词可以描述单次需求，工程规范约束的是每次生成的行为。前者管一次，后者管长期。

1.3 用一条标准判断自己更缺什么

判断自己是不是在“死磕提示词”，有一个很简单的标准：看时间花在哪。

如果你反复修改提示词，是因为 AI 第一次生成的东西结构太乱、命名太随意、接口设计不合理，那问题大概率不是提示词不够好，而是缺少输入输出约定和结构约束。这时候继续调提示词，边际收益会越来越低。

如果你是做一次性脚本、Demo 演示、临时数据分析，AI 生成结果接近目标就够了，那提示词确实值得多花时间。因为代码寿命短，能跑就行。

所以关键不是“提示词重要还是工程规范重要”，而是这条代码未来要活多久。活过一周，提示词够用；活过三个月，必须有工程规范兜底。

2. 死磕提示词的三种典型内耗，我都经历过

我不是一开始就得出这个结论的，是踩过几个很具体的坑之后才反应过来。

2.1 提示词越写越长，上下文越用越乱

最早用 AI 写一个内部工具，我习惯把所有要求都写进提示词：技术栈、目录结构、命名风格、错误处理、日志格式、注释语言、禁止用什么写法……一开始还挺好用，后来问题来了：提示词太长，模型容易记住后面的，忘记前面的；有时候改了中间一段，生成结果反而把之前已经稳定的部分弄坏了。

更麻烦的是，当提示词变成一个“大杂烩”，你很难定位是哪一句话导致的结果变差。想删没把握，想改没头绪，最后只能整段重写。

后来我换了一个思路：把提示词缩短，把约束从“对话里的文字”搬到“项目里的文件”。比如把命名规范、目录结构、接口定义放到项目文档里，让 AI 基于项目上下文工作，而不是每次在提示词里重新强调一遍。效果反而稳定很多。

2.2 把重试当调优，没有验收标准

另一种内耗是不断让 AI“重写一下”“再优化一下”。如果你没有明确的验收标准，这个循环是没有底的。

比如之前让 AI 写一个数据处理脚本。第一次能跑，但输出格式不对；我在提示词里加说明，让它“把输出改成 JSON”，它改了；再跑发现字段命名又不对；继续提示，它改好了字段，但原文件覆盖逻辑又出问题了。就这样来回折腾，明明是一个很小的脚本，却花了快一个小时。

问题不在 AI，而在我没有提前定义“完成”的标准。如果一开始就明确：输入文件是什么、输出文件是什么、字段列表有哪些、异常情况怎么处理、跑完看哪个日志，整个过程的收敛速度会快很多。

后来我给 AI 编程任务定了五条验收线：

• 输入输出是否符合预期；
• 正常路径是否跑通；
• 异常输入是否有处理；
• 日志和错误信息是否可读；
• 是否执行过真实的验证命令。

没有验收标准，提示词调得再细，也只是在碰运气。

2.3 让 AI 在错误的代码上不断打补丁

还有一种情况最折磨人：你让 AI 基于一段已经写歪的代码继续加功能。由于最开始的接口命名、数据结构、模块划分就是乱的，每加一个功能就要强行绕一个弯。AI 自己也不知道该怎么绕，于是生成一堆补丁式代码，最后整个文件变成“所有逻辑都挤在一起，互相牵制”。

这个问题的根源，往往不是提示词力度不够，而是第一次生成之后缺少代码评审。你没有在前两步纠偏，后面就是在烂地基上盖楼。你再怎么提示“不要乱改”“保持简洁”，AI 也不可能在混乱结构里自己长出规范。

所以我现在坚持一个习惯：每次 AI 生成完，先看整体结构和命名，再决定往下走。结构不对，哪怕功能能跑，也要先重构再继续。这一条省掉了我后面很多补丁时间。

3. 工程规范说白了，是人和 AI 之间的约定

很多人一听到工程规范，就想到几十页的文档、复杂的流程、严格的评审会。其实在 Vibe Coding 场景下，工程规范不一定要很重，但一定要足够明确。它的本质是“人和 AI 之间的一套约定”，让 AI 的生成行为可预期、可约束、可验收。

3.1 需求拆解：先把模糊想法变成任务卡

让 AI 编程最容易翻车的地方，是拿一个模糊的大需求直接让它“做个系统”。AI 不是不能做，而是大概率做出一个“看起来都有一点、但都不对”的东西。

正确做法是先把需求拆成一个一个的小任务。一个任务只做一件事，任务描述里包含：

• 目标：这个任务要完成什么功能；
• 输入：依赖哪些数据、文件、接口或页面；
• 输出：完成后应该产出什么，代码文件、接口、页面还是脚本；
• 约束：技术栈、目录位置、命名规范、是否需要兼容旧逻辑；
• 验收：怎么确认这个任务真的完成了。

比如不要直接说“帮我做一个用户管理后台”。可以拆成：

1. 设计用户表结构，包含字段、索引、状态枚举；
2. 实现用户列表接口，支持分页、按关键字搜索；
3. 实现用户创建和编辑接口，提交时校验邮箱和手机号；
4. 实现前端用户列表页，调用列表接口并展示分页器。

每一个任务都足够小，小到 AI 生成后你能快速检查，小到出错后你能快速定位。

3.2 接口先行：先定输入输出，再让 AI 填实现

任务拆完之后，最容易被忽略的是接口契约。

如果你让 AI 直接写一个“查询订单”的功能，它可能返回一个很大的对象，也可能拆成多个小对象；字段名可能是order_id，也可能是orderId；错误码可能用数字，也可能用字符串。单看一次生成没问题，但如果你有多个任务，分别让 AI 实现，最后拼在一起时就会发现对不上。

解决办法是接口先行。先定义好输入输出格式，再让 AI 去实现。

比如在任务卡里写清楚：

GET /api/v1/orders?page=1&page_size=20&keyword=xxx Response: { "code": 0, "message": "ok", "data": { "list": [ { "id": 1, "order_no": "ORD20250101001", "status": "paid", "amount": 99.5, "created_at": "2025-01-01 10:00:00" } ], "total": 1, "page": 1, "page_size": 20 } }

这样 AI 在生成实现时，不会自己去发明一个接口格式。它只需要保证代码行为符合这个契约。你后续验收也更容易，因为预期结果已经写死了。

3.3 目录、命名、格式约定：让 AI 生成的代码有固定落点

项目里最让人头疼的，不是 AI 写不出代码，而是它把代码放在你找不到的地方。命名也没有固定规则，今天生成UserService，明天生成user_service，后天生成userManager。单看都能跑，混在一起就凌乱。

通用做法是先把目录规范和命名规范写进项目说明，然后在每次任务描述里引用。

比如：

• 业务逻辑放src/services，工具函数放src/utils，类型定义放src/types；
• 文件名使用小驼峰或短横线，按项目现有风格统一；
• 接口返回统一使用{ code, message, data }结构；
• 数据库表名使用复数蛇形命名；
• 新增功能不允许直接修改公共工具函数，优先新建独立模块。

这些规范不需要很宏大，只要与项目实际一致就行。关键是让 AI 每次生成时都遵守同一套规则。时间长了，整个项目的代码风格会趋向一致，后面维护、排查、交接都会轻松很多。

3.4 错误路径和安全边界：不能只让 AI 写正常流程

AI 生成代码时，天然倾向于写正常路径“一条路走到底”。输入正常、权限正常、数据库正常，一切都按预期运行。但真实系统恰恰是在异常场景下最容易出问题。

工程规范要补的，就是让 AI 必须考虑非正常路径：

• 入参校验：字段缺失、类型不对、长度超限，返回什么；
• 资源不存在：根据 ID 查询没有记录，是返回空还是返回错误；
• 外部依赖失败：数据库超时、第三方接口报错，怎么记录日志；
• 权限不足：普通用户访问管理员接口，返回什么状态码；
• 数据边界：批量处理时，空列表、超长列表、包含空值怎么办。

这些要求在每次任务描述里都写，会显得啰嗦。更合适的做法是放在项目规范文档里，在任务卡中直接引用对应章节，让 AI 查规范而不是每次重新发挥。

另外，凡是涉及密钥、Token、密码、用户隐私数据，都要有明确边界。不要理所当然地要求 AI 生成一个包含完整密钥的配置放到仓库里。这类内容应该走本地的环境变量、密钥管理服务，AI 只需要负责调用方式，不应该负责生成敏感信息，更不应该让敏感信息出现在代码提交记录里。

4. 一套能落地的 Vibe Coding 工作流

聊完理念和规范，下面是一套实际可用的流程。我拿它跑过不少小项目，也用在一部分模块开发里。它不一定适合所有团队，但至少能帮你把“用 AI 编程”从碰运气变成有节奏地推进。

4.1 启动准备：仓库、分支、目录、任务清单

在让 AI 写任何代码之前，先把项目骨架搭好。这一步很基础，但很关键。它解决两个问题：代码往哪里放、AI 怎么知道全貌。

具体准备内容：

• 创建一个干净的代码仓库，初始化 Git；
• 建立一个符合项目需求的基础目录结构；
• 把项目描述、技术栈、运行方式、目录规范、命名规范写进 README 或独立规范文档；
• 把需求拆成任务清单，每个任务写清楚目标、输入、输出、约束、验收标准；
• 如果是多人协作，建议每个任务单独一个分支，避免 AI 生成的代码和别人的改动互相覆盖。

这一步做完之后，AI 手里的上下文就从一个模糊的“帮我做个东西”变成了一整套完整工程信息。后面的提示词只需要聚焦“当前任务”，不需要反复描述项目背景。

4.2 单任务循环：描述、生成、查看、改错、提交

每个任务采用同一个循环，我会拆成五步。

第一步，描述任务。提示词里只包含当前任务的信息，不需要重复项目背景。如果项目模型支持链接项目规范文档，就引用那份文档；如果不支持，就把相关约束复制进去。

第二步，生成代码。让 AI 只修改指定文件或只创建指定文件。不建议让它“顺便重构一下相关逻辑”，避免范围失控。

第三步，查看代码。这一条不能跳过。哪怕 AI 生成的代码看起来能跑，也要从头读一遍。重点看：命名是否规范、是否直接改了公共逻辑、有没有处理异常、有没有在代码里写死不该出现的内容。

第四步，运行验证。执行启动命令、测试用例或手动检查。只要验证失败，就带着错误信息回喂给 AI，让它修改。不要直接手动改掉，因为 AI 需要从错误里学到这次任务的边界。

第五步，提交。运行 lint、格式化、测试，确认通过后提交到当前分支，写明这个任务完成了什么。

每一步之间不要贪多。一个任务没跑通，不进入下一个任务。这是整个工作流里最重要的一条纪律。

4.3 多文件修改：怎么让 AI 不破坏已有功能

一个任务可能涉及多个文件，比如新增接口要改路由、控制器、服务层和数据模型。这时候如果一次性把整段提示词丢给 AI，它大概率会“自由发挥”。

更稳妥的做法是先告诉 AI 整体目标，再明确列出需要修改的文件清单，并且强调“只改清单内的文件”。如果涉及接口契约，先把接口定义写出来；如果涉及数据结构变更，先把变更后的结构说明写清楚。

AI 生成完成后，还有一个必做动作：对比变更范围。你可以用 Git 查看改动文件列表，逐个确认 AI 有没有动过清单之外的文件。没有权限意识的 AI 可能会去改配置文件、公共组件，这些改动不及时发现，后面会很难排查。

批量任务也是这样。不要一次性丢一堆任务让 AI 全做完。先让 AI 做一个，检查通过后，再把同样模式复制到第二个、第三个。模式稳定了，效率自然上来。

4.4 验证标准：没有测试和检查，等于没有完成

AI 编程很容易让人产生“进度很快”的错觉，因为代码生成速度太快了。但“生成完毕”不等于“任务完成”。我会用一套检查列表来判断：

• 代码能否正常启动；
• 关键接口能否用真实数据跑通；
• 异常输入是否被处理，不会导致整个程序崩溃；
• 日志和错误信息是否清楚，排查时能看懂；
• 是否执行过lint、test、build等质量检查；
• Git 变更范围是否只包括本次任务涉及的文件。

没有这些验证，AI 生成的代码就只是一个半成品。你把半成品当成完成品提交，代价会在后期不断放大。

如果项目没有测试体系，我建议也不要跳过验证。至少要有启动检查、接口冒烟、边界数据手动测试这几步。验证可能花几分钟，但能避免很多隐藏问题。

5. 比提示词更值得抠细节的几个地方

真正让 Vibe Coding 变得可靠，靠的不是某一条“万能提示词”，而是几个很容易被忽略的细节。

5.1 任务粒度：一次让 AI 改多少代码才合适

任务粒度是 Vibe Coding 里最直接影响成功率的因素。任务太大，AI 一次考虑因素太多，容易顾此失彼；任务太小，又会让交互次数暴增，整体效率反而下降。

一个比较合适的颗粒度标准是“这个任务如果人工做，大概需要 10 到 40 分钟”。小于 10 分钟的大多是模板代码，可以直接让 AI 批量做；大于 40 分钟的，说明里面可能包含多个职责，建议再拆分。

颗粒度合适时，你检查代码的压力会小很多。AI 出错时，你能一眼看到问题，也能更准确地告诉 AI 改哪里。对大项目来说，小步推进不只是稳妥，也是排查问题成本最低的路径。

5.2 上下文策略：不要把整个项目全塞进对话

很多 AI 编程工具支持把整个项目目录加入上下文。这看起来很酷，但实际使用要小心。全量上下文会带来几个问题：

• 上下文太长，模型容易忽略关键信息；
• 无关文件的内容会干扰生成方向；
• 每次请求可能消耗更多资源，响应变慢；
• 当项目很大时，模型根本看不完全部代码。

我的做法是手动或利用工具标注“本次任务需要的上下文范围”。比如这次只涉及用户模块，就只提供用户模块的目录、接口定义、相关数据模型；不要一股脑把订单模块、支付模块、营销模块全部喂进去。

上下文不是越多越好，而是越相关越好。给 AI 太多无关信息，等于要求它在噪声里找重点，效果只会更差。

5.3 第一次跑不通：先看错误信息，再带着错误信息回喂

AI 生成的代码第一次跑不通是很正常的事。关键在于你的处理顺序。

不要直接让 AI“重新写一遍”。那样大概率会生成一个风格不同、问题也不同的新版本，反而打乱整体一致性。正确顺序是：

1. 先看日志和报错信息；
2. 定位是第一层（运行环境）还是第二层（代码逻辑）；
3. 如果是环境类问题，先把环境问题解决了再让 AI 继续；
4. 如果是逻辑类问题，把完整的报错信息和相关代码片段喂回给 AI，指出哪个文件哪一行，期望它怎么改；
5. 修改后重新运行验证。

如果你发现 AI 反复改不对同一个问题，先停止修改。重新检查任务描述是不是不够清楚、边界条件是不是没有写明白、上下文里是不是给了错误示例。

5.4 让 AI 解释代码：评审比生成更重要

“让 AI 写代码”只是 Vibe Coding 的一半，另一半是评审代码。

初学者经常忽略这一点。AI 写完，自己拿来跑一下，能跑就万事大吉。但能跑和能不能长期维护，是两个完全不同的标准。

我会在 AI 完成生成后，让它用几句话解释一下：

• 核心逻辑是怎么组织的；
• 为什么选择这种写法；
• 哪些函数是新增的，哪些是修改的；
• 有没有已知的边界情况没有处理；
• 如果后续要加某个功能，应该在哪个位置改。

这个动作能逼着 AI 把设计意图说出来，你也能借此判断它是不是真的“理解”了需求，还是只是在拼装一个“看起来像”的实现。

5.5 工具选择：编辑器插件、命令行工具、网页对话，各有边界

Vibe Coding 可以发生在不同工具里：代码编辑器内嵌 AI、命令行 AI 编程助手、网页对话窗口。不同工具的边界差异很大。

编辑器内嵌 AI 最适合做局部代码修改，因为它能感知当前文件但容易忽略项目整体。命令行 AI 编程助手适合多文件、跨模块任务，因为它能感知仓库结构，但操作门槛更高。网页对话窗口适合讨论方案技术选型、复杂逻辑拆分，不适合把它当成代码仓库的“唯一真源”，因为文件同步容易出错。

我的建议是根据任务类型选工具：架构讨论放在对话窗口，多文件实现放在能感知仓库的工具里，单文件微调用编辑器内置 AI。没有哪个工具适合所有场景，清楚边界比追求功能大全更重要。

6. Vibe Coding 翻车现场排查清单

遇到问题先保持冷静。多数问题不是“AI 能力不行”，而是任务描述、上下文、规范或验证链路出了偏差。下面是一份我常用的排查顺序，供参考。

6.1 代码能跑但改不动

表现：新代码能跑，但每次加功能都觉得很别扭，改动一个地方会牵连另外几个地方。新增需求越来越难缝进去。

排查顺序：

1. 先看模块划分，是不是所有逻辑都被塞进了同一个文件；
2. 再看函数职责，是不是一个函数干了好几种完全不同的事；
3. 再查命名，是不是变量名和实际含义已经对不上；
4. 然后看接口边界，是不是每次改都要改调用方；
5. 最后决定：是继续打补丁，还是花时间拆模块。

如果底层结构有问题，不要心疼这次重构的十几分钟。继续打补丁，后面会更疼。

6.2 AI 越改越糊涂，上下文开始自相矛盾

表现：之前生成的代码好好的，你让 AI 改一个小功能，结果它把不相关的地方也改了；有时候它会说“已经改好了”，但你检查后发现根本没有改。

排查顺序：

1. 先看上下文长度，是不是已经塞了太多历史对话；
2. 再确认是不是任务描述里同时带了多个目的，让模型混淆了优先级；
3. 然后检查你是否明确限定了“只修改指定文件”，没有范围限制，模型很容易放大改动；
4. 最后考虑新开一个对话，带着最新代码和独立任务描述继续，而不是依赖旧对话。

新开对话不是坏事。很多团队用 AI 编程的常态是“每换一个任务，就开一个新的对话上下文”。这样反而干净。

6.3 生成的代码风格不统一

表现：有的文件是类名大驼峰，有的是下划线；有的模块用 Promise，有的用回调；常量命名一会儿大写一会儿小写。风格差异大，会导致 review 成本增加。

排查顺序：

1. 先确认项目规范文档是否存在；
2. 再确认这次任务描述里是否引用了规范；
3. 然后检查模型是否能读取项目级别文档；
4. 最后考虑用代码格式化工具统一风格。

风格问题靠提示词一遍遍强调，不如靠 lint 和格式化工具。机器能自动处理的，就不应该靠人每次口头叮嘱 AI。

6.4 数据边界一进来，系统就崩

表现：空数据、大字段、并发请求、特殊字符，只要输入一超过“正常范围”，程序就会出现各种奇怪问题。

排查顺序：

1. 先看有没有统一的入参校验，是不是所有接口都默认数据一定是好的；
2. 再查错误处理，是不是异常被吞掉，或者没有被日志记录；
3. 然后看外部依赖，是不是数据库、缓存、第三方接口的异常没有兜底；
4. 最后补齐边界用例，手工跑一遍空列表、超大列表、错误格式。

这类问题不是 AI 单次能解决的，它需要你持续在规范文档里补充异常路径要求。你补得越多，AI 后续生成的代码越重视边界。

6.5 如何建立自己的复盘清单

每个人踩过的坑不一样，适合自己的排查清单也不同。我建议你维护一个自己的复盘文档，只要出现一次下面情况，就记录一条：

• 同一类问题反复出现；
• AI 生成结果和预期偏差较大；
• 提示词写了很多但效果变差；
• 代码进入维护期后很难改。

记录格式可以很简单：

现象：AI 在新增接口时顺手改了公共配置。 原因：没有明确限制修改范围。 对策：任务描述里新增一句“只允许修改 xxx 文件，禁止修改公共配置”。 状态：已加入任务卡模板。

复盘清单最终会沉淀成你个人的工程规范。它不是一开始就完整，而是一边用 AI、一边踩坑、一边补全。

7. 我的建议：把提示词当成工程规范的一部分，而不是全部

如果你问我 Vibe Coding 最值得花时间研究的是什么，我的答案是“让你和 AI 之间的协作关系变得可预期”。

提示词仍然重要，但它的重要性体现在“把当前任务讲清楚”，而不是“用魔法公式逼 AI 写出好代码”。真正让项目稳定推进的，是你怎么拆需求、怎么定接口、怎么限制改动范围、怎么验证结果。这些动作加起来，才是 Vibe Coding 的核心能力。

如果你的项目是一次性脚本，多琢磨提示词没问题，性价比高。如果项目要活过三个月，请把一部分时间从提示词里挪出来，放到规范上。先在项目根目录写一个简短的项目说明和任务模板，拆一张任务卡，定义一次接口返回结构，坚持一个小步验证习惯。这是启动成本最低又最有长期价值的一条路。

我自己现在每次开始一个新任务，都会先问三个问题：这个任务真的足够小吗？我知不知道它做没做完？如果 AI 出了错，我能第一时间定位到哪个文件吗？三个问题都能回答，我再打开 AI 编程工具。

Vibe Coding 是个新玩法，但底层逻辑还是老一套：代码是要长期维护的资产，越早建立秩序，后面越省力。别把所有赌注都押在提示词上。规范和流程，才是让 AI 编程真正进入生产环境的那个支点。