★ FEATURED ARTICLE 最近常有同行在群里聊 Vibe Coding说 AI 已经把活干完了自己只需要在旁边“看着”。我实际用下来的感受完全不是这样。Vibe Coding 确实能省掉很多键盘上的苦力活但你要是不把需求说清楚AI 就按它自己的理解给你“编”一个方案你要是不做严格验收代码跑起来那一刻有多爽后续上线出事时就有多狼狈。说白了Vibe Coding 的核心不在“写”而在两件事上说清楚验收。把这两个环节做到位AI 才是效率引擎否则它就是隐患制造机。这篇文章我把自己的实操经验、踩过的坑和现在固定下来的一套流程写出来希望能帮你把 Vibe Coding 用得更稳。1. 说清楚需求Vibe Coding 的第一步不是“编”而是“翻译”Vibe Coding 之所以经常写出一堆没用的代码大多数时候不是 AI 不行而是你的需求里留了太多空。人类程序员会从模糊需求里“猜”你的意图AI 也会猜但 AI 猜的方向往往不是你的方向。它猜的是训练语料里出现频率最高的那种做法而不是你脑补的那种做法。我一开始也以为描述需求就是“把一句话说完整”比如把“给我写个抓天气的脚本”改成“用 Python 写一个爬天气的脚本”听起来确实完整了但还是不够。AI 会自己选库、选输出格式、选失败处理方式等它跑完你一看——CSV 呢重试呢日志呢这时你才想起来自己心里其实早有完整的预期只是没写出来。1.1 一句话需求为什么会跑偏举个例子。我让 AI “写一个脚本每天定时抓取天气信息保存下来”。AI 很勤快几秒就生成了完整代码用 requests 抓公开接口写进 CSV还加了 cron 配置说明。看起来没毛病可我发现我实际要的是按城市分文件存储它全写在了一个表里我要求失败重试三次并记录日志它只做了简单异常处理失败就退出我期望8 点整准时跑它却在配置里默认了凌晨 3 点我打算长期维护让它把抓取函数单独拆出来它全部堆在一个 main 里这些不是 AI 的智商问题是描述里的信息缺口。AI 只能根据字面信息选择最常规的路径而最常规的路径常常不是你的路径。1.2 我后来固定下来的“需求五要素”现在的描述模板基本固定不写满这五项我不会让它开工目标这个程序/功能是做什么的为谁服务一次完成什么结果输入源数据从哪来什么格式有哪些来源有没有异常输入的可能输出产出什么格式、什么内容、落在哪里、文件名规则约束不能依赖某些库、不能访问某些网络、代码结构要怎样、运行环境是什么验收条件哪些场景跑通算合格哪些失败算合理哪些算 bug比如上面天气脚本我会写成目标每天 8 点抓取北京、上海、广州三个城市的天气数据供本地报表用。 输入城市列表固定写在配置文件中调用公开天气 API无鉴权。 输出每个城市生成一个 CSV 文件文件放在 data/ 目录下文件名包含日期。 约束Python 3.10只可用标准库和 requests抓取函数要独立封装失败不中断主流程敏感信息走环境变量。 验收条件三个城市各生成正确 CSV天气接口关闭时脚本能重试 3 次然后跳过该城市数据重复运行不产生脏数据。这样一段描述喂下去AI 生成的代码基本一次就能用我只需要读一遍关键逻辑改改细节就行。相比以前来回拉扯效率高得多。1.3 给 AI“现场勘查”的机会还有一个很多人忽略的细节AI 没有你的代码库、没有你的运行环境、没有你的历史数据。你给它一段代码片段让它改和让它凭空写效果完全不一样。我现在会在描述里附带这些附加信息帮助 AI 建立上下文现有项目的目录结构依赖文件内容requirements.txt 或 package.json关键接口的定义或数据库表结构目标运行平台、Python 版本、系统类型数据样例尤其是格式复杂的字段比如一次让 AI 帮我改一个数据处理脚本我在描述里直接贴了三行原始输入样例和对应期望输出。AI 立刻理解了格式转换逻辑一次改对连我原本没说清楚的字段切割规则都对应上了。后来我意识到这就是“说清楚”的进阶版把现场材料交给 AI它才能在你的世界里干活而不是活在它自己的想象里。注意描述不是越长越好关键是信息密度高。跑题的信息会引导 AI 往无关方向发散反而浪费时间。2. 验收标准先定义“完成”再开始写“说清楚”之后就该“验收”了。但这里的难点在于——很多人的验收标准就是“能跑”。我从自己实际项目中总结能跑只是最低级的验收指标它只能证明代码没有语法错误证明不了逻辑正确、边界安全、数据准确。2.1 我踩过的“能跑”陷阱有次我让 AI 生成一个解析 Excel 报表的脚本输入文件有几千行它跑得很顺畅十几秒就出结果。数据量看着没问题我草草验了一眼就上线了。结果月底核对时发现某个字段值超过 1000 时AI 用了 int 截断导致数据差了十几个数。报表还能出数字也还在就是不对。这就是典型的“能跑”陷阱主流程跑通了边界、复杂数据、异常路径没验。AI 的代码看着整洁但隐藏错误只有在特定输入下才触发。从那以后我把“能跑”从验收清单里直接删掉了。2.2 验收清单怎么列现在每个任务开工前我都会先写下这么一份验收基准编号验收项判定方法通过标准1正常路径跑核心用例输出与预期一致2空输入传入空文件或空参数不崩溃、有清晰提示3异常数据传入格式错误/超大数据过程不产生脏数据4外部依赖失败断开网络/删除文件有明确的失败日志5重复运行连续执行两次结果一致不污染旧数据6数据正确性抽样比对源数据和结果关键字段无误7代码可读性快速阅读核心函数结构清晰能维护这条清单不是每次都全用但它是个底线。简单脚本至少过 1、2、3、6 项涉及网络请求的必须过 4有状态写入的必须过 5。2.3 自动验证优先于手动看输出能手工验证的尽量写成自动化测试。Vibe Coding 在这一点上有个天然优势AI 生成测试代码的效率和生成业务代码一样高。让它把上面清单转换成 pytest 用例整个过程可能不到一分钟然后你就拥有了可重复执行的验收工具。一个简单示例比如验收天气抓取脚本中的解析函数可以这样要求 AI 同时生成测试# test_parser.py import pytest from weather_parser import parse_weather_payload def test_normal_payload(): payload {city: 北京, temp: 23.5, humidity: 60} result parse_weather_payload(payload) assert result[city] 北京 assert result[temp] 23.5 assert result[humidity] 60 def test_missing_field(): payload {city: 上海} with pytest.raises(KeyError): parse_weather_payload(payload) def test_extra_field(): payload {city: 广州, temp: 28, humidity: 80, wind: 东南风} result parse_weather_payload(payload) assert wind not in result跑完 pytest我才敢说“这个函数通过验收了”。注意测试用例本身也需要审一遍AI 有时候会写出“测试通过但逻辑没覆盖全”的用例你得确保测试真的覆盖了验收点而不是只让数字变绿。2.4 人工复查 AI 最容易埋雷的地方自动化测试不能替代全部人工检查。我的经验是AI 生成的代码里有几类问题很难用测试抓出来必须肉眼扫一遍关键位置异常处理范围过广比如 except Exception 后面直接 pass吞掉所有错误导致失败看起来像成功硬编码危险信息API 密钥、数据库密码直接写在代码里时区和编码撞车尤其在处理跨地域、多语言文本时容易在 date 和 encoding 上出错资源不释放文件、连接、缓存开了不关短跑看不出挂久了就出事代码风格不统一混用多种模式后续改起来非常痛苦我曾经让 AI 写过一个批量文件处理脚本它把整个主流程包在 try 里出了错就打印一句话 continue所有任务全部跳过但整体显示“处理完成”。当时的单元测试全过了因为测试只调用了函数、没断言失败时的行为。后来加了失败文件计数才算把这块堵上。所以我的复查原则是凡是“全流程”级别的代码必须重点看错误处理分支别只看成功路径。3. 在嵌入式场景里 Vibe Coding说清楚硬件约束再让它动手热词里看到“嵌入式vibe coding”这种说法时我第一反应是有点紧张——嵌入式不是网页脚本搞不好是要烧硬件的。但实际试过之后我觉得嵌入式反而是 Vibe Coding 很值得投入的场景只是验收的维度不太一样。3.1 嵌入式 Vibe Coding 适合干什么我给自己的边界是这样逻辑性、重复性的代码很适合让 AI 生成硬件相关的代码必须人工核对。适合的状态机定义和迁移逻辑串口、I2C、SPI 驱动的初始化框架解析协议报文的结构体转换日志、错误码、回调函数模板测试桩和 mcu 端单元测试不适合直接生成的寄存器地址和芯片手册相关的位操作时序敏感代码尤其中断上下文中电源管理和低功耗逻辑安全关键路径具体板卡的引脚复用配置一次尝试中我让 AI 帮我写一个电池充放电状态机它用了非常清晰的状态枚举、迁移表、超时处理整体结构比我手写更快更完整。但我核芯片手册时发现它把某个触发迁移条件的电量阈值写成了 20%而实际硬件触发中断的阈值是 15%。这种错误在逻辑测试里根本发现不了数据一错硬件行为全偏。所以嵌入式场景的验收第一关永远是硬件手册不是代码编译。3.2 嵌入式的验收手段有哪些嵌入式项目我没法像 Web 项目那样随便跑 pytest实操中我的验收顺序是静态编译检查零警告编译。嵌入式里 warning 往往不是小事可能代表类型截断或未定义行为日志调试输出关键分支打印状态跑板子时观察实际执行路径示波器和逻辑分析仪验证时序、波特率、边沿是否符合预期。这一步不能省波形不会撒谎寄存器回读配置写入后读回来确认硬件确实处于预期状态长时间跑机测试尤其看门狗、异常恢复、低电量场景无法用短时测试覆盖比如 AI 生成一个从传感器读取数据的驱动我会要求它输出“读取时的寄存器写入序列”然后用逻辑分析仪抓实际波形对比。只要波形时序对得上我才敢往上层继续堆代码。3.3 嵌入式描述需求时要多说一句“为什么”嵌入式场景里给 AI 描述需求时除了说“要做什么”我还会尽可能把“为什么”带上。硬件工程师面对传感器、总线、中断时如果不明白设计意图改起来特别容易破坏原有功能。AI 也一样。比如让它生成一段初始化代码我会写目标初始化三轴加速度传感器用于低功耗模式下的计步检测。 约束I2C 频率不超过 400kHz初始化后进入低功耗模式睡眠时关闭传感器供电唤醒后重新初始化。 为什么低功耗状态下电流目标在 50uA 以内不能一直打开传感器。 验收读取寄存器确认进入睡眠模式示波器抓 I2C 时序测量整机电流低于目标值。把“为什么”写清楚之后AI 在生成代码时会主动避开频繁读取、长延时、无条件轮询这类高耗电写法。它的全局视野会好很多。4. 把“描述 验收”固化成工作流顺便说说什么情况下别用 Vibe Coding把需求描述和验收标准这两步固定下来后我的 Vibe Coding 项目流程基本稳定成了四步循环。4.1 我的日常操作流程描述按五要素模板写需求附上现场材料代码结构、数据样例、接口定义生成让 AI 按描述写代码同时在描述里附上验收清单要求自动验证跑测试用例、静态检查、性能冒烟人工复查 反馈读关键代码、核对错误分支问题再丢回给 AI 迭代这个循环里有一条很重要的原则每一轮只改一个点。AI 迭代时如果一次塞进五个问题它往往顾此失彼修好一个、弄坏一个。我只挑优先级最高的一个问题反馈给它改完验收再进入下一个。虽然看起来多跑了几轮但总时间通常更短而且结果更可控。4.2 什么时候不要碰 Vibe Coding我自己已经划了一条清晰的边界线遇到这些类型的任务直接手写安全关键路径医疗、电气控制、金融核心人肉审查都难保万无一失AI 生成的代码更不该直接进入强并发、强性能场景AI 对竞态条件、内存序、优化策略的理解不够细容易生成“看起来对但埋雷”的代码模糊表达无法消除的需求有些逻辑你就是说不清需要边写边理。这种项目硬套 Vibe Coding 结果只能是反复返工老代码库维护如果项目本身耦合重、文档缺、结构差AI 没有足够的上下文很容易搞出新问题另外就算是日常任务我也建议把 AI 写在临时分支或副本里确认验收通过后再合入主干。这样既能安心试错也能保留每次迭代前后的对比痕迹。出了问题可以随时回滚不会一团糟。4.3 现在的分工方式用顺手之后我和 AI 的分工大致是这样我负责定义问题、描述边界、定验收标准、看关键实现AI 负责把那些重复性、模板化的代码快速生产出来再用测试帮我一遍遍验证。大量繁琐的体力活被去掉了而我需要动脑子的部分反而更清晰了。说实话最早我接触 Vibe Coding 时心态是“让 AI 帮我干活我在旁边看结果”。现在的心态变成“我把需求跟验收做得越细致AI 替我省的时间就越多”。这个流程跑顺之后我再没出现过“代码跑通但数据不对”那种事故也不再有“AI 改了我这段代码结果别处崩了”的惶恐。如果你刚开始上手我建议不要一上来就拿大项目练先从一个个小型脚本开始把描述和验收的肌肉记忆练出来。熟练之后你会发现 Vibe Coding 本质上不怎么“vibe”——它是一套靠清晰描述和严格验收驱动的高效工作流。
阅读完成 · 觉得有帮助？
