过去两周我一直在用“自然语言驱动开发”的方式做一个小工具说实话第一次把需求说给 AI 听、它噼里啪啦给我生成一版能跑的代码时那种“哇”的感觉是真的。但等我把这个工具从“能跑”推到“能给别人用”的阶段问题一个接一个文件名边界没处理、平台差异被忽略、测试倒是全绿但测的根本不是需求。这就是当前 vibe coding 最真实的状态它把“写代码”的门槛拉低了却没有把“做软件”的门槛拉低。连搜索平台上都开始出现零基础学习资源、以及 vibe coding 与 spec-driven 的对比讨论说明很多人已经开始意识到光靠“顺着感觉跟 AI 聊”并不能走远。这篇文章我不想评价 vibe coding 好不好只想把自己从自然语言驱动开发到工程化落地这条路径踩过的坑、试过的框架、最后沉淀下来的流程完整拆一遍。内容会更适合已经有基础、想把 AI 生成代码真正放进项目里的工程师零基础读者也不用担心我会先把基础概念讲透再往下走。1. vibe coding 的真实边界它接管的是打字不是判断1.1 “感觉对了”的编码方式是怎么流行起来的vibe coding 这个词最早是 Andrej Karpathy 在 2025 年初提出来的。他的原意不是开玩笑而是描述一种新的写代码状态你不再逐行敲代码而是用自然语言把想法描述给 AI 编程工具AI 把实现细节搞定你只看结果甚至很长一段时间不看代码本身。用大白话说就是“凭感觉编码”。这个方式传播得特别快因为它踩中了两个真实痛点。第一个是样板代码太多第二个是原型验证太慢。过去我从想法到能运行的脚本至少要十几分钟甚至一晚上现在我把行为描述清楚30 秒就能得到初稿。人一旦体验过这种速度就很难再回到“手动查文档、逐行拼配置”的老路上去。但我必须说一句有点不合群的话vibe coding 真正改变的是“代码输入方式”不是“软件生产方式”。自然语言是一种高歧义、高语境的表达而运行时环境需要的恰恰是低歧义、可验证的行为。这中间的落差靠“聊得更开心”是填不上的。1.2 我给它划出的可行性边界经过几个项目之后我现在会把任务分成三类。第一类是适合 vibe coding 的一次性脚本、脚手架搭建、接口骨架生成、把一种语言翻译成另一种语言、用数据生成可视化示例。这类任务容错率高、影响面小、即使第一版不对重来成本也不高。比如我经常让 AI 帮我生成一批 mock 数据或者写一个用于临时分析 CSV 的小函数这完全没问题。第二类是勉强能用但要盯着的业务模块的初版代码、CRUD 接口、表单校验逻辑。这类任务适合让 AI 先铺路但每一段都得有人把需求拆清楚并且靠测试把行为固定下来不能只依赖 AI 的运气。第三类是我不建议用 vibe coding 碰的涉及资金、权限、数据一致性、并发控制、协议解析这些区域。生成式模型很容易给出“看起来合理、实际上经不起边界推敲”的方案。不是说不能用 AI 辅助读代码或写测试而是不该用“我觉得它应该没问题”这种状态来管理高风险代码。一句话总结我的红线vibe coding 可以替你把手从键盘上解放出来但不能替你把脑子从代码逻辑上挪开。2. 自然语言驱动开发绕不开的三层信息损失既然要用自然语言驱动开发就必须先搞清楚为什么这种方式容易“翻车”。我的体会是从意图到可运行程序中间会有三层信息损失任何一层处理不好结果都会偏离预期。2.1 第一层你想的和你说的不是一回事这一层最容易理解却也最容易忽略。人脑里的需求通常带着大量隐性前提但说出口的语言天然是省略的。比如你说“把用户文件里的日期格式改一下”你脑补的前提可能是“有多种日期格式需要统一成 ISO 8601”但 AI 听到的可能只是“把 YYYY/MM/DD 改成 YYYY-MM-DD”。很多 vibe coding 翻车不是因为 AI 能力不行而是因为需求在“说出来”这一步就已经丢信息了。甚至你自己当时都没有意识到原来你对“什么才算改好了”是有标准的。问题的源头从来不是 AI而是我们习惯把需求当成对话不习惯把需求当成可验收的规格。2.2 第二层模型理解的“意图”和它执行的“方案”不匹配大语言模型本质上是在做概率预测——它生成的是“最像正确方案”的文本不是“经你确认正确”的方案。所以在面对一个边界含糊的任务时模型会默认选择一条最平滑的路径而不是最稳妥的路径。我遇到过很多 AI 用隐式规则把我坑了的情况自动选择了当前工作目录、假设文件编码是 UTF-8、把所有失败都吞进一张空列表返回、网络请求失败后不做重试就直接抛异常。这些行为在模型眼里是“合理的默认值”但在真实项目里可能就是线上事故。这一层信息损失没法靠更长的 Prompt 完全消除只能靠“规格 测试 运行检查”三重机制来拉回。2.3 第三层真实运行环境和模型训练语料的错位模型记忆里的“主流做法”总是有点滞后的。比如某些库的新版本已经改了 API模型可能还在按旧签名生成代码某些平台在 Windows 和 Linux 下路径处理不同模型只会给出它在训练语料里见得最多的写法。这一层我称之为“语料与现实时差”。它会出现得毫无规律你甚至可能觉得代码明明生成得无懈可击却在某台干净的机器上跑不起来。所以遇到 vibe coding 结果不能直接运作时先别急着怪模型检查环境依赖和版本差异往往是更高效的动作。理解了这三层损失后vibe coding 就不再是一个“玄学”而变成了一个需要设计输入和反馈的工程问题。3. 把“自然语言需求”当成规范来写而不是当聊天发很多人喜欢用“帮我写一个...”开头剩下全靠 AI 自由发挥。这种用法不是不行但它把工程质量交给了运气。我现在已经形成了一种固定习惯每次让 AI 写代码之前先写一份“小规格”哪怕只有几百字。3.1 我写自然语言需求时必带的四块内容一份合格的“AI 需求说明”我的结构通常是任务背景这个程序要解决什么问题它是给谁用的。行为和约束必须做什么不能做什么。验收标准做成什么样才算完成。边界样例输入是什么期望输出是什么。给你们看一个我真实用过的对比。不推荐的问法帮我写一个 Python 脚本把 data 目录下的所有 jpg 文件重命名成“日期_序号.jpg”运行完了输出日志。这个描述看起来挺清楚但当我拿到结果后实际情况是只处理了顶层目录、没有考虑重名文件、没有检查文件是否损坏、日期信息读的是文件系统修改时间还是拍摄时间AI 只能用猜的。我会改成这样的规格任务背景有一个图片备份目录目录内每天会新增一批 jpg需要按拍摄日期归档命名方便后续按时间检索脚本运行环境是 Windows 10存在中文文件名。 行为与约束只处理 data 目录及其一级子目录文件名格式为 yyyyMMdd_HHmmss_序号.jpg日期读取 EXIF 拍摄时间读取失败则使用文件修改时间重名时序号递增不得修改原文件内容。 验收标准运行一遍后所有 jpg 都符合命名格式且无重名被跳过的文件数量要打印出来。 样例输入文件名 IMG_1234.jpgEXIF 时间为 2025-01-02 08:30:00序号初值为1输出 20250102_083000_1.jpg。这份描述会多花我三分钟但它能让 AI 的初版代码成功率大幅提升。更重要的是它能逼着我把需求想清楚。3.2 “随便聊聊”与“可验收”之间的差异自然语言是分层的。你说“写个脚本处理文件”这是一种表达你说“这个脚本要能处理目录里每天出现的增量文件并且遇到非法格式时要跳过并统计”这是另一种表达。后者本质上已经是一份小型 spec 了。很多人觉得写自然语言需求不需要结构化但实际项目中越是结构化地表达AI 的生成质量越稳定。因为模型在没有足够约束时只能按概率选择一种开发路径而这种路径不一定是你要的。3.3 长上下文项目的维护方法让 AI 先读文件而不是聊天记录里翻vibe coding 做到后期会遇到一个可怕的问题AI 好像“忘了”前面的需求。这往往不是理解能力问题而是上下文窗口里的信息被大量中间对话冲淡了。你越是用一长串对话去修修补补模型对最初目标的理解就越模糊。我的做法是核心约束永远不放在聊天记录里。如果你用 Cursor 这类编辑器就把项目说明写成一个CLAUDE.md或者AGENTS.md文件放到仓库根目录每次让 AI 开始任务前先读它。这样不管对话怎么变“规范”都会稳定地回到上下文里。对 Chat 类工具也一样与其在同一个会话里聊几百条不如把任务拆碎每次携带独立规格重新开始。4. spec-driven 和 harnessvibe coding 缺的那根硬骨架聊到这儿话题自然要接上最近常被拉出来对比的 spec-driven 开发。很多人问 vibe coding 和 spec-driven 有什么区别我的回答是它们本来就不在同一个维度上。4.1 vibe coding 是交互方式spec-driven 是治理方式vibe coding 描述的是“你怎么跟 AI 协作”——用自然语言、维持心流、快速迭代。spec-driven 描述的是“怎么为 AI 设定边界”——先定义规格再让 AI 在规格的轨道上实现并用测试来验证结果。更准确地说spec-driven 是 vibe coding 最容易变成工程化落地的刹车系统。它的核心不是写一份冗长 Word 文档而是把需求转成可执行的验收条件。大家担心的“AI 写代码不靠谱”在 spec-driven 的框架里被翻译成了“如果验收条件覆盖率高模型生成质量差一点也能被测试拦住”。当然这只是理想状态实际落地还需要持续打磨。4.2 harness 到底是什么你要是搜索“harness × SDD 全栈开发实战”会发现这个词越来越常和 spec-driven 一起出现。这里的 harness可以理解成一套用来约束 AI 行为的“脚手架”或者“测试马具”。在设计 harness 时我会尽量先搭好这四层结构固定入口规定 AI 只能实现某个确定签名或 CLI 入口而不是自己定义一个函数结构。输入输出边界输入要符合结构输出类型要明确避免模型的自由发挥破坏外围系统。测试探针用一组真实数据和哑数据构造测试让系统能明确告诉我它对不对。操作脚本提供可以直接运行的 lint、test、build 脚本让 AI 自己也能快速检查工作是否成功。这套 harness 的意图是让自然语言生成的代码落在“轨道”里而不是让 AI 自由发挥设计一个全新的轨道。4.3 用最小 harness 约束生成的实例假设我要生成一个时间差计算模块。我不会直接说“写一个 time_diff 函数”而会在工作目录里放以下骨架# time_diff.py def diff_in_seconds(start: str, end: str, fmt: str %Y-%m-%d %H:%M:%S) - int: Return end - start in seconds. Raise ValueError if parse fails. raise NotImplementedError# test_time_diff.py from time_diff import diff_in_seconds def test_basic_diff(): assert diff_in_seconds(2025-01-01 00:00:00, 2025-01-01 00:01:30) 90 def test_invalid_time(): try: diff_in_seconds(not a time, 2025-01-01 00:00:00) assert False, should raise ValueError except ValueError: pass然后告诉 AI请实现time_diff.py运行python -m pytest -q通过全部测试。模型不需要自己猜边界因为失败的测试会直接反馈给它。同时我还是能保持 vibe coding 那种“先看结果再说话”的协作快感但结果质量已经从“听天由命”变成“被我控制”。这就是 harness 的价值它不是限制创造而是把 AI 的创造力收进了一条可验证的管道。5. 我按这套方法落地项目时的标准流程方法论讲多了容易飘落到具体项目里我的流程是以下六步。这套流程不是完美答案但它是我踩了足够多坑之后稳定下来的一套操作至少每次都能让生成代码在真实环境里立住脚。5.1 先画一张“禁止 vibe”的边界清单开工之前我会先确定哪些内容允许 AI 自由生成哪些内容必须由人类手写或逐字 review。以我之前做的一个数据脚本为例项目部分是否允许 vibe coding理由调研阶段 demo允许速度快便于确认方向数据解析核心逻辑半允许需要我先写样例再让 AI 生成文件写入与格式转换半允许涉及编码、路径等隐藏边界需要重点审查账号鉴权和密钥管理禁止安全相关必须人工复核这块列表会给整个项目定下情绪基调。没有它我很容易陷入“让 AI 把所有事都写完”的爽感里然后把风险集中堆到后期。5.2 标准循环拆任务、写规格、生成、测试、再拆真正的循环过程是这样的把项目拆成能在 2 小时内完成的小任务。对每个小任务写上一小节规格包含验收标准。调用 AI 生成实现。立刻运行测试和 lint不允许把“测试失败”留到晚上统一处理。如果测试不过把报错信息原样丢回给 AI让它迭代。测试通过后进行人工 code review重点不是读每一行而是检查模型是否把隐藏假设写成了硬编码。这个循环本质上跟 TDD 很像但有一个很大的不同TDD 是人类自己写测试和实现这里的做法是测试由人类搭骨架实现交给 AI反馈回路由测试驱动。这比“一次生成一大块代码再找 bug”要省力得多。5.3 交接给维护者之前的工程化动作一个 vibe coding 出来的项目如果永远只有原作者一个人跑那可以随意一点。但一旦要交给别人或者三个月后还要回来改就必须做三件事。第一把依赖锁住。AI 生成的代码通常不会主动帮你锁版本所以要用 Lockfile 把依赖固定下来避免未来某个依赖小版本更新导致脚本直接崩掉。第二把“为什么这么做”写进 README 里。模型不会替你解释设计决策时间一长你连自己当时为什么让 AI 这样做都会变得模糊更别提别的维护者。第三把可以跑起来的命令沉淀成脚本或 Makefile。如果 AI 的 README 里只有一堆“可以执行 python script.py”说明项目还没有真正到工程化状态。我常说一句话vibe coding 负责让代码快点长出来工程化负责让代码活得久。这两件事缺一不可。6. 踩坑实录测试全绿仍然在真实场景翻车的原因按说有了测试和规格生成代码应该很稳了。但我在真实项目中还是不止一次遇到“测试全绿一到真实数据就出问题”的诡异状况。我挑了三个最有代表性的原因都和模型的行为偏好有关系。6.1 模型总在文件名和编码上自行脑补有一次让 AI 生成一个整理目录的脚本我用了一份规格里面只说了“处理 JPG 文件”模型自动把所有“看似是 JPG”的文件名按后缀处理结果一个名为photo.jpg.backup的备份文件也被当成了 JPG最终在处理文件字节流时崩溃。排查过程让我印象很深。第一步是观察报错发现是在某个文件上解不开第二步是打印文件名列表发现混入了.jpg.backup第三步查根因规范只写了“扩展名为 .jpg”没有定义等于号语义。最终预防方法很简单在规格里明确“使用splitext后扩展名全小写等于.jpg”测试中加入.jpg.backup这个反例。模型不是不知道文件后缀可能有多段而是在没有强约束的时候它会优先选一条简单的路。所以审核的时候别只盯着“能跑的路径”还要问它“遇到脏输入时会怎样”。6.2 测试验证了实现但没有验证需求第二个更隐蔽。我让 AI 顺手生成测试它写的测试几乎是照着实现抄的等于自己证明自己。比如实现了一个排序函数测试用的输入是已经完全排序好的数据这种测试当然全绿但它根本测不了排序的逻辑。这种问题叫“测试与实现高度相关与需求弱相关”。现在我的对策是关键路径的测试样例必须由我人工提供并且要刻意加入边界反例、乱序数据、超大输入、空输入。如果你发现 AI 生成的测试用例全是“常规情况”不用怀疑直接自己加几条带有破坏性的用例。6.3 长对话让模型逐渐漂移第三个坑更多发生在 Chat 类工具里。任务做到第 20 轮我让 AI 继续修改某个函数结果它把整个文件里其他早前已经确认过的逻辑也一并改了看起来“更整洁”了实际上破坏了接口约定。我后来花了不少时间才确认这是上下文污染造成的。因为后续消息越来越多模型对初始约束的注意力会被稀释。现在的解决方案有两个核心规范放到/docs/specs里让 AI 随时读取不要在一个会话里做超过三到四个独立改动。每次完成一个小里程碑后我会开一个新会话把当前文件状态和规格重新贴进去避免旧对话不断干扰新判断。6.4 定位问题的通用排查顺序这些坑看起来五花八门但定位的方式是通用的。我通常会按下面这个顺序走一遍确认边界报错是数据问题、逻辑问题、还是环境问题。固定复现找出最小的用例让问题能稳定重现。对比差异比较模型生成的测试数据和真实数据的差异通常这一步就能找出“隐式假设”。改测试再改代码先补上暴露问题的测试然后要求 AI 根据测试修正实现。这套顺序最核心的一点是不要一上来就让 AI 解释它为什么写出 bug。它给出的解释往往只是在顺着你的问题补一个符合语言模型风格的故事。让测试来说话比在 chat 里来回辩论高效得多。7. 从 vibe coding 里真正能学到的长期能力最后聊聊学习方法。很多人担心 vibe coding 用多了技术会退化我的观点恰恰反过来它真正考验的其实是你在更高抽象层次上的工程能力。7.1 拆需求是未来比写代码更值钱的技能过去一个工程师的价值主要在于“怎么写”现在 AI 既然把“怎么写”变得廉价“写什么”和“写对”就变成了分水岭。拆需求不只是把用户的话复述一遍还要把它转成无歧义的行为约束。我会刻意练习这样的表达尽量不用“大概”“适当”“一些”这类玄学词汇把每个形容词都翻译成可检查的条件。“更快”翻译成“耗时小于 3 秒”“好看”翻译成“居中对齐且主色不超过三种”“更稳定”翻译成“连续跑 100 次不崩溃”。这个翻译过程就是 vibe coding 能带给你的最大成长。7.2 学会审查生成代码里的关键路径刚开始我会大段地扫 AI 生成的代码最后一圈看下来什么也没记住。后来我意识到要做的是“关键路径审查”不是通读全文。重点关注有 I/O 的地方有并发的地方有权限变更的地方每一处异常被吞掉的地方以及在数据从一个模块传递到另一个模块时的类型假设。其他样板代码比如变量命名、工具函数封装AI 写得好不好不太重要——因为测试能兜底。真正要你出面的地方永远是边界和风险所在。7.3 让 AI 自己和自己辩论我还有一个技巧算是我持续在用的当我对需求本身有疑惑时会先用自然语言让 AI 列出问题再让 AI 尝试回答。有时候它会问我“空目录需要报错还是跳过”这个问题恰好就是规格里缺少的信息。把这种“自我辩论”当作前置质检能节省很多来回时间。整体来说vibe coding 不是一条通往“不用懂代码”的捷径而是一条通往“更懂系统行为”的新路。它要求你把注意力从语法细节中抽离出来放到用户意图、边界条件、验收标准和长期维护上。这个过程一开始会有点别扭因为它改变了原来的工作节奏需要主动把反馈收窄、把规则明确、把风险边界画好。我现在的项目习惯是先让 AI 快速把代码活蹦乱跳地写出来体验那种高歌猛进的速度感但在按下“合并到主线”的按钮之前规格、测试和边界审查一个都不能少。这份克制才是 vibe coding 从一时兴起真正变成可靠的工程化能力的关键。
从vibe coding到工程化落地：自然语言驱动开发的关键实践
过去两周我一直在用“自然语言驱动开发”的方式做一个小工具说实话第一次把需求说给 AI 听、它噼里啪啦给我生成一版能跑的代码时那种“哇”的感觉是真的。但等我把这个工具从“能跑”推到“能给别人用”的阶段问题一个接一个文件名边界没处理、平台差异被忽略、测试倒是全绿但测的根本不是需求。这就是当前 vibe coding 最真实的状态它把“写代码”的门槛拉低了却没有把“做软件”的门槛拉低。连搜索平台上都开始出现零基础学习资源、以及 vibe coding 与 spec-driven 的对比讨论说明很多人已经开始意识到光靠“顺着感觉跟 AI 聊”并不能走远。这篇文章我不想评价 vibe coding 好不好只想把自己从自然语言驱动开发到工程化落地这条路径踩过的坑、试过的框架、最后沉淀下来的流程完整拆一遍。内容会更适合已经有基础、想把 AI 生成代码真正放进项目里的工程师零基础读者也不用担心我会先把基础概念讲透再往下走。1. vibe coding 的真实边界它接管的是打字不是判断1.1 “感觉对了”的编码方式是怎么流行起来的vibe coding 这个词最早是 Andrej Karpathy 在 2025 年初提出来的。他的原意不是开玩笑而是描述一种新的写代码状态你不再逐行敲代码而是用自然语言把想法描述给 AI 编程工具AI 把实现细节搞定你只看结果甚至很长一段时间不看代码本身。用大白话说就是“凭感觉编码”。这个方式传播得特别快因为它踩中了两个真实痛点。第一个是样板代码太多第二个是原型验证太慢。过去我从想法到能运行的脚本至少要十几分钟甚至一晚上现在我把行为描述清楚30 秒就能得到初稿。人一旦体验过这种速度就很难再回到“手动查文档、逐行拼配置”的老路上去。但我必须说一句有点不合群的话vibe coding 真正改变的是“代码输入方式”不是“软件生产方式”。自然语言是一种高歧义、高语境的表达而运行时环境需要的恰恰是低歧义、可验证的行为。这中间的落差靠“聊得更开心”是填不上的。1.2 我给它划出的可行性边界经过几个项目之后我现在会把任务分成三类。第一类是适合 vibe coding 的一次性脚本、脚手架搭建、接口骨架生成、把一种语言翻译成另一种语言、用数据生成可视化示例。这类任务容错率高、影响面小、即使第一版不对重来成本也不高。比如我经常让 AI 帮我生成一批 mock 数据或者写一个用于临时分析 CSV 的小函数这完全没问题。第二类是勉强能用但要盯着的业务模块的初版代码、CRUD 接口、表单校验逻辑。这类任务适合让 AI 先铺路但每一段都得有人把需求拆清楚并且靠测试把行为固定下来不能只依赖 AI 的运气。第三类是我不建议用 vibe coding 碰的涉及资金、权限、数据一致性、并发控制、协议解析这些区域。生成式模型很容易给出“看起来合理、实际上经不起边界推敲”的方案。不是说不能用 AI 辅助读代码或写测试而是不该用“我觉得它应该没问题”这种状态来管理高风险代码。一句话总结我的红线vibe coding 可以替你把手从键盘上解放出来但不能替你把脑子从代码逻辑上挪开。2. 自然语言驱动开发绕不开的三层信息损失既然要用自然语言驱动开发就必须先搞清楚为什么这种方式容易“翻车”。我的体会是从意图到可运行程序中间会有三层信息损失任何一层处理不好结果都会偏离预期。2.1 第一层你想的和你说的不是一回事这一层最容易理解却也最容易忽略。人脑里的需求通常带着大量隐性前提但说出口的语言天然是省略的。比如你说“把用户文件里的日期格式改一下”你脑补的前提可能是“有多种日期格式需要统一成 ISO 8601”但 AI 听到的可能只是“把 YYYY/MM/DD 改成 YYYY-MM-DD”。很多 vibe coding 翻车不是因为 AI 能力不行而是因为需求在“说出来”这一步就已经丢信息了。甚至你自己当时都没有意识到原来你对“什么才算改好了”是有标准的。问题的源头从来不是 AI而是我们习惯把需求当成对话不习惯把需求当成可验收的规格。2.2 第二层模型理解的“意图”和它执行的“方案”不匹配大语言模型本质上是在做概率预测——它生成的是“最像正确方案”的文本不是“经你确认正确”的方案。所以在面对一个边界含糊的任务时模型会默认选择一条最平滑的路径而不是最稳妥的路径。我遇到过很多 AI 用隐式规则把我坑了的情况自动选择了当前工作目录、假设文件编码是 UTF-8、把所有失败都吞进一张空列表返回、网络请求失败后不做重试就直接抛异常。这些行为在模型眼里是“合理的默认值”但在真实项目里可能就是线上事故。这一层信息损失没法靠更长的 Prompt 完全消除只能靠“规格 测试 运行检查”三重机制来拉回。2.3 第三层真实运行环境和模型训练语料的错位模型记忆里的“主流做法”总是有点滞后的。比如某些库的新版本已经改了 API模型可能还在按旧签名生成代码某些平台在 Windows 和 Linux 下路径处理不同模型只会给出它在训练语料里见得最多的写法。这一层我称之为“语料与现实时差”。它会出现得毫无规律你甚至可能觉得代码明明生成得无懈可击却在某台干净的机器上跑不起来。所以遇到 vibe coding 结果不能直接运作时先别急着怪模型检查环境依赖和版本差异往往是更高效的动作。理解了这三层损失后vibe coding 就不再是一个“玄学”而变成了一个需要设计输入和反馈的工程问题。3. 把“自然语言需求”当成规范来写而不是当聊天发很多人喜欢用“帮我写一个...”开头剩下全靠 AI 自由发挥。这种用法不是不行但它把工程质量交给了运气。我现在已经形成了一种固定习惯每次让 AI 写代码之前先写一份“小规格”哪怕只有几百字。3.1 我写自然语言需求时必带的四块内容一份合格的“AI 需求说明”我的结构通常是任务背景这个程序要解决什么问题它是给谁用的。行为和约束必须做什么不能做什么。验收标准做成什么样才算完成。边界样例输入是什么期望输出是什么。给你们看一个我真实用过的对比。不推荐的问法帮我写一个 Python 脚本把 data 目录下的所有 jpg 文件重命名成“日期_序号.jpg”运行完了输出日志。这个描述看起来挺清楚但当我拿到结果后实际情况是只处理了顶层目录、没有考虑重名文件、没有检查文件是否损坏、日期信息读的是文件系统修改时间还是拍摄时间AI 只能用猜的。我会改成这样的规格任务背景有一个图片备份目录目录内每天会新增一批 jpg需要按拍摄日期归档命名方便后续按时间检索脚本运行环境是 Windows 10存在中文文件名。 行为与约束只处理 data 目录及其一级子目录文件名格式为 yyyyMMdd_HHmmss_序号.jpg日期读取 EXIF 拍摄时间读取失败则使用文件修改时间重名时序号递增不得修改原文件内容。 验收标准运行一遍后所有 jpg 都符合命名格式且无重名被跳过的文件数量要打印出来。 样例输入文件名 IMG_1234.jpgEXIF 时间为 2025-01-02 08:30:00序号初值为1输出 20250102_083000_1.jpg。这份描述会多花我三分钟但它能让 AI 的初版代码成功率大幅提升。更重要的是它能逼着我把需求想清楚。3.2 “随便聊聊”与“可验收”之间的差异自然语言是分层的。你说“写个脚本处理文件”这是一种表达你说“这个脚本要能处理目录里每天出现的增量文件并且遇到非法格式时要跳过并统计”这是另一种表达。后者本质上已经是一份小型 spec 了。很多人觉得写自然语言需求不需要结构化但实际项目中越是结构化地表达AI 的生成质量越稳定。因为模型在没有足够约束时只能按概率选择一种开发路径而这种路径不一定是你要的。3.3 长上下文项目的维护方法让 AI 先读文件而不是聊天记录里翻vibe coding 做到后期会遇到一个可怕的问题AI 好像“忘了”前面的需求。这往往不是理解能力问题而是上下文窗口里的信息被大量中间对话冲淡了。你越是用一长串对话去修修补补模型对最初目标的理解就越模糊。我的做法是核心约束永远不放在聊天记录里。如果你用 Cursor 这类编辑器就把项目说明写成一个CLAUDE.md或者AGENTS.md文件放到仓库根目录每次让 AI 开始任务前先读它。这样不管对话怎么变“规范”都会稳定地回到上下文里。对 Chat 类工具也一样与其在同一个会话里聊几百条不如把任务拆碎每次携带独立规格重新开始。4. spec-driven 和 harnessvibe coding 缺的那根硬骨架聊到这儿话题自然要接上最近常被拉出来对比的 spec-driven 开发。很多人问 vibe coding 和 spec-driven 有什么区别我的回答是它们本来就不在同一个维度上。4.1 vibe coding 是交互方式spec-driven 是治理方式vibe coding 描述的是“你怎么跟 AI 协作”——用自然语言、维持心流、快速迭代。spec-driven 描述的是“怎么为 AI 设定边界”——先定义规格再让 AI 在规格的轨道上实现并用测试来验证结果。更准确地说spec-driven 是 vibe coding 最容易变成工程化落地的刹车系统。它的核心不是写一份冗长 Word 文档而是把需求转成可执行的验收条件。大家担心的“AI 写代码不靠谱”在 spec-driven 的框架里被翻译成了“如果验收条件覆盖率高模型生成质量差一点也能被测试拦住”。当然这只是理想状态实际落地还需要持续打磨。4.2 harness 到底是什么你要是搜索“harness × SDD 全栈开发实战”会发现这个词越来越常和 spec-driven 一起出现。这里的 harness可以理解成一套用来约束 AI 行为的“脚手架”或者“测试马具”。在设计 harness 时我会尽量先搭好这四层结构固定入口规定 AI 只能实现某个确定签名或 CLI 入口而不是自己定义一个函数结构。输入输出边界输入要符合结构输出类型要明确避免模型的自由发挥破坏外围系统。测试探针用一组真实数据和哑数据构造测试让系统能明确告诉我它对不对。操作脚本提供可以直接运行的 lint、test、build 脚本让 AI 自己也能快速检查工作是否成功。这套 harness 的意图是让自然语言生成的代码落在“轨道”里而不是让 AI 自由发挥设计一个全新的轨道。4.3 用最小 harness 约束生成的实例假设我要生成一个时间差计算模块。我不会直接说“写一个 time_diff 函数”而会在工作目录里放以下骨架# time_diff.py def diff_in_seconds(start: str, end: str, fmt: str %Y-%m-%d %H:%M:%S) - int: Return end - start in seconds. Raise ValueError if parse fails. raise NotImplementedError# test_time_diff.py from time_diff import diff_in_seconds def test_basic_diff(): assert diff_in_seconds(2025-01-01 00:00:00, 2025-01-01 00:01:30) 90 def test_invalid_time(): try: diff_in_seconds(not a time, 2025-01-01 00:00:00) assert False, should raise ValueError except ValueError: pass然后告诉 AI请实现time_diff.py运行python -m pytest -q通过全部测试。模型不需要自己猜边界因为失败的测试会直接反馈给它。同时我还是能保持 vibe coding 那种“先看结果再说话”的协作快感但结果质量已经从“听天由命”变成“被我控制”。这就是 harness 的价值它不是限制创造而是把 AI 的创造力收进了一条可验证的管道。5. 我按这套方法落地项目时的标准流程方法论讲多了容易飘落到具体项目里我的流程是以下六步。这套流程不是完美答案但它是我踩了足够多坑之后稳定下来的一套操作至少每次都能让生成代码在真实环境里立住脚。5.1 先画一张“禁止 vibe”的边界清单开工之前我会先确定哪些内容允许 AI 自由生成哪些内容必须由人类手写或逐字 review。以我之前做的一个数据脚本为例项目部分是否允许 vibe coding理由调研阶段 demo允许速度快便于确认方向数据解析核心逻辑半允许需要我先写样例再让 AI 生成文件写入与格式转换半允许涉及编码、路径等隐藏边界需要重点审查账号鉴权和密钥管理禁止安全相关必须人工复核这块列表会给整个项目定下情绪基调。没有它我很容易陷入“让 AI 把所有事都写完”的爽感里然后把风险集中堆到后期。5.2 标准循环拆任务、写规格、生成、测试、再拆真正的循环过程是这样的把项目拆成能在 2 小时内完成的小任务。对每个小任务写上一小节规格包含验收标准。调用 AI 生成实现。立刻运行测试和 lint不允许把“测试失败”留到晚上统一处理。如果测试不过把报错信息原样丢回给 AI让它迭代。测试通过后进行人工 code review重点不是读每一行而是检查模型是否把隐藏假设写成了硬编码。这个循环本质上跟 TDD 很像但有一个很大的不同TDD 是人类自己写测试和实现这里的做法是测试由人类搭骨架实现交给 AI反馈回路由测试驱动。这比“一次生成一大块代码再找 bug”要省力得多。5.3 交接给维护者之前的工程化动作一个 vibe coding 出来的项目如果永远只有原作者一个人跑那可以随意一点。但一旦要交给别人或者三个月后还要回来改就必须做三件事。第一把依赖锁住。AI 生成的代码通常不会主动帮你锁版本所以要用 Lockfile 把依赖固定下来避免未来某个依赖小版本更新导致脚本直接崩掉。第二把“为什么这么做”写进 README 里。模型不会替你解释设计决策时间一长你连自己当时为什么让 AI 这样做都会变得模糊更别提别的维护者。第三把可以跑起来的命令沉淀成脚本或 Makefile。如果 AI 的 README 里只有一堆“可以执行 python script.py”说明项目还没有真正到工程化状态。我常说一句话vibe coding 负责让代码快点长出来工程化负责让代码活得久。这两件事缺一不可。6. 踩坑实录测试全绿仍然在真实场景翻车的原因按说有了测试和规格生成代码应该很稳了。但我在真实项目中还是不止一次遇到“测试全绿一到真实数据就出问题”的诡异状况。我挑了三个最有代表性的原因都和模型的行为偏好有关系。6.1 模型总在文件名和编码上自行脑补有一次让 AI 生成一个整理目录的脚本我用了一份规格里面只说了“处理 JPG 文件”模型自动把所有“看似是 JPG”的文件名按后缀处理结果一个名为photo.jpg.backup的备份文件也被当成了 JPG最终在处理文件字节流时崩溃。排查过程让我印象很深。第一步是观察报错发现是在某个文件上解不开第二步是打印文件名列表发现混入了.jpg.backup第三步查根因规范只写了“扩展名为 .jpg”没有定义等于号语义。最终预防方法很简单在规格里明确“使用splitext后扩展名全小写等于.jpg”测试中加入.jpg.backup这个反例。模型不是不知道文件后缀可能有多段而是在没有强约束的时候它会优先选一条简单的路。所以审核的时候别只盯着“能跑的路径”还要问它“遇到脏输入时会怎样”。6.2 测试验证了实现但没有验证需求第二个更隐蔽。我让 AI 顺手生成测试它写的测试几乎是照着实现抄的等于自己证明自己。比如实现了一个排序函数测试用的输入是已经完全排序好的数据这种测试当然全绿但它根本测不了排序的逻辑。这种问题叫“测试与实现高度相关与需求弱相关”。现在我的对策是关键路径的测试样例必须由我人工提供并且要刻意加入边界反例、乱序数据、超大输入、空输入。如果你发现 AI 生成的测试用例全是“常规情况”不用怀疑直接自己加几条带有破坏性的用例。6.3 长对话让模型逐渐漂移第三个坑更多发生在 Chat 类工具里。任务做到第 20 轮我让 AI 继续修改某个函数结果它把整个文件里其他早前已经确认过的逻辑也一并改了看起来“更整洁”了实际上破坏了接口约定。我后来花了不少时间才确认这是上下文污染造成的。因为后续消息越来越多模型对初始约束的注意力会被稀释。现在的解决方案有两个核心规范放到/docs/specs里让 AI 随时读取不要在一个会话里做超过三到四个独立改动。每次完成一个小里程碑后我会开一个新会话把当前文件状态和规格重新贴进去避免旧对话不断干扰新判断。6.4 定位问题的通用排查顺序这些坑看起来五花八门但定位的方式是通用的。我通常会按下面这个顺序走一遍确认边界报错是数据问题、逻辑问题、还是环境问题。固定复现找出最小的用例让问题能稳定重现。对比差异比较模型生成的测试数据和真实数据的差异通常这一步就能找出“隐式假设”。改测试再改代码先补上暴露问题的测试然后要求 AI 根据测试修正实现。这套顺序最核心的一点是不要一上来就让 AI 解释它为什么写出 bug。它给出的解释往往只是在顺着你的问题补一个符合语言模型风格的故事。让测试来说话比在 chat 里来回辩论高效得多。7. 从 vibe coding 里真正能学到的长期能力最后聊聊学习方法。很多人担心 vibe coding 用多了技术会退化我的观点恰恰反过来它真正考验的其实是你在更高抽象层次上的工程能力。7.1 拆需求是未来比写代码更值钱的技能过去一个工程师的价值主要在于“怎么写”现在 AI 既然把“怎么写”变得廉价“写什么”和“写对”就变成了分水岭。拆需求不只是把用户的话复述一遍还要把它转成无歧义的行为约束。我会刻意练习这样的表达尽量不用“大概”“适当”“一些”这类玄学词汇把每个形容词都翻译成可检查的条件。“更快”翻译成“耗时小于 3 秒”“好看”翻译成“居中对齐且主色不超过三种”“更稳定”翻译成“连续跑 100 次不崩溃”。这个翻译过程就是 vibe coding 能带给你的最大成长。7.2 学会审查生成代码里的关键路径刚开始我会大段地扫 AI 生成的代码最后一圈看下来什么也没记住。后来我意识到要做的是“关键路径审查”不是通读全文。重点关注有 I/O 的地方有并发的地方有权限变更的地方每一处异常被吞掉的地方以及在数据从一个模块传递到另一个模块时的类型假设。其他样板代码比如变量命名、工具函数封装AI 写得好不好不太重要——因为测试能兜底。真正要你出面的地方永远是边界和风险所在。7.3 让 AI 自己和自己辩论我还有一个技巧算是我持续在用的当我对需求本身有疑惑时会先用自然语言让 AI 列出问题再让 AI 尝试回答。有时候它会问我“空目录需要报错还是跳过”这个问题恰好就是规格里缺少的信息。把这种“自我辩论”当作前置质检能节省很多来回时间。整体来说vibe coding 不是一条通往“不用懂代码”的捷径而是一条通往“更懂系统行为”的新路。它要求你把注意力从语法细节中抽离出来放到用户意图、边界条件、验收标准和长期维护上。这个过程一开始会有点别扭因为它改变了原来的工作节奏需要主动把反馈收窄、把规则明确、把风险边界画好。我现在的项目习惯是先让 AI 快速把代码活蹦乱跳地写出来体验那种高歌猛进的速度感但在按下“合并到主线”的按钮之前规格、测试和边界审查一个都不能少。这份克制才是 vibe coding 从一时兴起真正变成可靠的工程化能力的关键。
