“这代码是你自己写的吗”一位从来看不上AI写代码的资深同事指着我前一天提交的一段代码问。我如实坦白函数主流程是我设计的初稿由AI编程助手生成中间那几个边界条件我改了三轮。他愣了一下又把代码从头看了一遍。那一刻我知道他对Vibe Coding的看法开始松动了。这算是我一年半以来最常见的场景。所谓Vibe Coding说穿了一点不玄乎开发者不逐行手敲代码而是用自然语言把需求、约束、验收标准讲清楚让AI编程助手先产出实现再由你以技术负责人的身份去审查、纠偏、验收、整合。它跟早年那种只会补if和for的代码补全工具是两种东西。这一年半里我一边用它交付了几个能上线的系统模块一边经历了不止一次深夜翻车现场。这篇文章我不打算唱赞歌也不打算劝退只想把自己从怀疑、入坑到稳定使用这套工作流的真实经历包括那些边缘场景和踩坑细节完整拆开给你看。如果你正在观望要不要用AI编程或者已经用了但经常觉得“它写的不敢上线”这篇应该值得你泡杯茶慢慢读。1. 从“玩具”到“队友”我心态转变的三个阶段1.1 被历史经验误导的第一印象我最早接触的AI辅助编程体验并不好。当时那类工具更像“智能输入法”你敲半个函数名它帮你补剩下的半行。碰到复杂业务逻辑它给出的代码经常看着对放到真实环境里一跑就露馅。那会儿我给它的定位很明确闲聊可以写生产代码免谈。这种印象维持了相当长一段时间直到某次架构升级时我需要在一片老代码里找出所有硬编码的参数并统一收敛逐行搜索加手工修改花了一整个下午。事后我开玩笑说这种体力活如果有个实习生能干一天我也不心疼。这个念头本身已经在为后续接受AI做铺垫了——当你遇到的劳动量大但确定性也高时你就会开始寻找批量解决的方案。1.2 一次内部数据处理任务带来的转折真正让我改变态度的是一个看起来特别不起眼的内部数据处理任务。那天我需要合并两个来源的订单明细文件字段对不上、时间格式混乱、金额单位还不一致按老办法写清洗脚本加手工对账怎么也得两个小时起步。我抱着试一试的心态把文件样例、字段含义、想要的输出格式和几条明显规则写进对话框让AI生成一个Python清洗脚本。它给出的初稿居然能跑通大部分逻辑我只需要修改其中三处一个列名映射写错了、时区处理用的固定偏移量不够通用、异常分类太粗糙。我修正完一跑干净利落出了结果。整个过程连描述带审查带修补不到40分钟。这次经历让我意识到一个问题AI的价值不在于“替你思考”而在于“把你的思考快速翻译成代码”。只要我描述得足够具体它产出的代码就足够接近可用。我后来复盘时给自己定了一条原则以后凡是能写清楚输入、输出和规则的重复性工作都可以先让它干一版出来人只做审查和兜底。1.3 一年半后我才敢承认的真相现在已经过去一年半我必须诚实地总结Vibe Coding的效率确实高高到让我把大量样板代码、数据转换、接口胶水这些体力活全交给了AI但它离“无人驾驶”还远得很。它在我输入模糊时会下意识补全一个“最像那么回事”的答案而这种答案往往隐藏着我最不想要的假设。我会在使用中持续确认当前模块的错误代价有多大我能不能在几分钟内发现它的错如果答案是“不能”无论AI多高效我都不放心。这种边用边警惕的状态才是Vibe Coding的常态。那些“AI一小时写完整个项目”的故事要么项目过于简单要么讲的人还没体会到生产环境里维护代码的痛。2. Vibe Coding的生死边界哪些项目能吃肉哪些项目会要命2.1 绝对不能交给AI的三类核心代码这半年里我吃过大亏最终总结出三类代码我坚持自己写绝对不进任何AI会话。第一类是涉及资金逻辑的代码比如优惠计算、退款、对账、计费分摊。这类逻辑表面看很简单一个折扣率、一个取整规则、一个状态流转。可一旦边界算错损失是真金白银而且用户发现时往往已不可逆。AI只能学到“通常怎么实现”学不到你们业务的财务规则到底是什么。我在让AI输出这类代码的时候光为了验证它对“部分退款后剩余金额保留几位小数”的理解就来回改了好几轮最后还是决定自己手写核心计算函数。第二类是权限与安全相关代码例如认证、授权、密钥管理、敏感数据过滤。这类代码的威胁模型非常依赖上下文AI写的“平均水准”恰好是这个行业最危险的基准线。它可能把密钥硬编码进配置文件可能在日志里打印隐私字段可能把越权判断放在前端而不是后端。我曾收到过它生成的一段“看起来没什么问题”的用户角色校验代码仔细一追才发现它用前端传入的角色字段做后端信任依据这在安全上等同于把门锁交给访客自己配置。第三类是状态与并发相关的核心逻辑包括数据库事务边界、幂等控制、分布式锁、消息按序消费。AI写代码时是“无状态思考”它看不到你的系统里有哪些并发入口很容易生成一份在单线程下正确、一上生产就偶发异常的乐观锁代码。这种问题的排查成本远高于自己动手的成本。2.2 AI真正擅长的高杠杆任务上面说了一堆不能碰的并不代表AI一无是处。恰恰相反有一类任务它做得又快又好低状态、高重复、规则明确的“翻译型代码”。我把它总结为四个字搬、转、套、填。“搬”指的是把一个逻辑从A语言搬到B语言比如把一段Python数据清理函数翻译成SQL存储过程。“转”指的是格式转换JSON结构重排、CSV字段合并、DTO与VO互转这类代码没有行业逻辑只有喂进去一个结构、吐出来另一个结构。“套”指的是按既有项目的模板套新的页面、接口、测试桩和配置文件。“填”则是把已经设计好的函数签名、表结构、接口契约填成完整实现。我最近接手的某报表模块先生成好数据模型和接口规范剩下的查询、分页、字段映射全部交给AI填充代码审查成本比手写低很多。有一个体会可以分享让AI写“骨架已定、只缺血肉”的模块时它的完成质量会让你惊喜让AI写“边界混乱、需求模糊”的模块时它会用流畅的代码掩盖你所有没有想清楚的地方——这才是最危险的。2.3 一个简单的四问检查表我现在每接到一个需求会先拿四个问题过一遍决定哪些部分可以交给AI这个需求能不能写成机器可验证的规格例如“金额必须大于0”“时间字段必须为ISO8601”这种描述越多越好。连你自己都说不清成功标准时别指望AI替你定义。出错之后我能多快发现如果可以立即用测试或界面反馈兜住容错空间就比较大如果错误要等几天后用户投诉才暴露这块代码就得谨慎。我有没有能力审查它的输出这里的审查能力包括能不能看懂逻辑、会不会设计异常用例、知不知道这个模块的常见坑。没有审查能力的Vibe Coding等于裸奔。这个模块属于“高代价低容错”吗简单说就是错了会扣钱吗会泄露数据吗会危及用户吗只要有一项是“会”就自己写核心把AI限制在辅助位置。下面这张表是我自己贴在项目文档里的一张速查表供参考维度适合交给AI必须人工主导错误代价低可快速发现并修复高金钱、安全、不可逆操作状态复杂度单函数、无状态、纯计算多并发入口、事务、时序依赖需求清晰度输入输出规则明确业务边界模糊需要人为决策审查能力你能读懂并验证你对该领域经验不足典型场景DTO转换、脚本、页面骨架、测试桩计费、权限、架构、核心算法3. 把AI从“实习生”调教成“高级开发”的五个基本功3.1 用“实现说明书”替代“一句话需求”我见过最多人踩的坑就是像人一样对AI说话“帮我写一个订单导入功能。”这句话的模糊程度和跟同事说“你看着办”一样AI当然会给出看着很全、其实哪都不搭的实现。我的做法是写一份“实现说明书”把需求压缩成结构化的字段再丢给AI。下面是一个实际用过的模板【任务】编写Python函数解析外部系统同步来的订单文件。 【输入】filepathCSV文件路径UTF-8编码字段依次为 order_id, amount, received_at, customer_code 【输出】返回对象success_count、failure_count、errors列表 每条错误记录形如{line: 行号, reason: 错误原因} 【规则】 1. amount必须大于0否则该行校验失败 2. received_at使用ISO8601格式时区统一转成UTC 3. order_id长度不超过32超过则失败 4. customer_code为空时允许重试但不能静默跳过。 【错误处理】校验失败的任意行记录到errors并跳过该行 全部处理完成后返回结果不抛异常。 【约束】只使用Python标准库禁止引入第三方依赖。按这种格式写清楚AI的输出几乎不用返工最多调整行号偏移和异常类型。这份说明书的额外价值是它逼迫你在问AI之前先把需求想透。很多时候写着写着我自己就发现问题了根本不需要AI回答。3.2 把任务拆到一屏能看完的粒度AI的长期问题不是不够强而是会“忘记”早期约束。你让它一口气实现一个完整系统它开头还记得你要求“不要引入新依赖”写到后面就把这个约束忘光了。我现在的做法是单个任务尽量收窄到一个函数、一个接口、一个文件能表达的粒度整个需求描述控制在几句规则之内。拿“实现博客文章管理”来举例我不会说“帮我写个博客后端”而是拆成四轮对话第一轮生成文章的模型定义与建表语句第二轮实现创建和更新接口第三轮实现带分页的列表查询第四轮实现标签筛选。每一轮交付后我审查确认再开启下一轮。这样做的另一个好处是当你发现AI某一轮思路跑偏时只需要丢弃这一小段对话重新开始不会连带整个项目都废掉。3.3 上下文投喂决定了答案的下限AI没有你的项目记忆它不知道你的代码风格、依赖版本、已有表结构也不知道昨天刚踩过的坑如果你不说的话它就只能靠猜。与其让它猜不如下点功夫喂上下文。我习惯在每次开启新任务时把这几样东西贴进对话框当前项目的目录结构节选涉及的文件源码片段最好包含接口签名和注释相关表结构或JSON样例报错信息的完整堆栈如果是修bug的话一份项目约定文档的摘要。这里特别提一下“幻觉API”问题。AI会一本正经地调用一个看起来合理、实际上不存在的库接口。为了对付它我会在任务开头明确写一句“仅使用以下依赖清单内已有库禁止引入记忆中的API如不确定某个接口是否存在先执行help()或查看本地文档再回答。”这一条能显著减少“看起来很真但跑不起来”的代码。3.4 测试是Vibe Coding的保险丝如果只让我选一条最重要的经验我会选这个让AI写代码之前或同时让它写测试。测试不是可有可无的仪式它是你在没有读遍每一行代码的情况下唯一能快速验证AI输出正确性的保险丝。我的通用做法是任务描述里同时包含“请一并生成覆盖正常与异常场景的pytest测试”验收时会重点看异常用例有没有覆盖到。比如实现那个订单解析函数时可以要求测试覆盖这四种场景金额为负、时间格式错误、order_id超长、customer_code为空。下面是我实际用过的测试代码片段# tests/test_order_parser.py from order_parser import parse_orders def test_negative_amount_is_rejected(tmp_path): csv_file tmp_path / orders.csv csv_file.write_text( order_id,amount,received_at,customer_code\nA001,-10,2025-01-01T00:00:00Z,C001\n, encodingutf-8 ) result parse_orders(str(csv_file)) assert result.success_count 0 assert any(amount in e[reason] for e in result.errors)让AI先想清楚“什么情况算错误”再让它写实现顺序很重要。我先让它写测试等于先逼它定义问题的边界。反过来如果先给实现再补测试它很容易写出“永远通过”的测试那种测试在Vibe Coding里是最大的幻觉。3.5 高频提交、严格审查自己的diffAI每交付一小段能运行的代码我会立刻单独提交一次版本控制并在提交前认真看一遍diff。这个过程等价于每天给AI做代码审查。我看diff时会刻意问三个问题它有没有偷偷引入新依赖有没有改动我原本没有要求的命名或结构有没有把错误处理“优化”掉有一次我让AI修复一个导入工具的空白字符问题提交前看diff时发现它不仅修了空白字符还顺手把好几处报错从主动抛出改成了日志输出。这种行为在代码评审里叫“夹带私货”放在AI身上同样要警惕。你越沉默它越会自作主张。保持每次变更小而清晰我才能准确评估它到底做了什么。4. 一年半里最惨的三次翻车现场4.1 静默吞掉异常的那个“好心”修复第一次严重翻车发生在一个内部数据导入工具上。当时系统反馈一批订单文件“导入完成0条无任何报错”可文件里明明有数据。我排查了很久才发现问题出在我让AI“增强健壮性”的时候它给处理流程加了一层巨大的try/except把所有错误都捕获后存进了内存里的一个数组既没有写入日志也没有展示给用户。导入失败就这样被静默吞掉了表面上风平浪静数据却一条没进库。这次事故让我明白对AI说“处理异常”等于给了它一把自由发挥的铲子它会按自己的理解挖坑。后来我处理错误时会显式指定三件事异常发生后是继续还是中止状态信息写到哪里失败记录怎么暴露给调用方。没有这三条描述我就不让AI碰异常逻辑。4.2 看起来很真的幻觉API第二次翻车尤为隐蔽。当时我让AI实现一段基于某个标准库的文本解析逻辑它生成了一段调用该库“某个更优雅方法”的代码方法名、参数列表、返回类型风格跟那个库的方向完全一致看起来没有一丝违和。我审查时没发现因为那方法的命名风格太像真实接口了我一眼扫过去就直接跳过。直到联调运行解释器打出AttributeError我才去查官方文档——原来那个方法根本不存在是AI把另一个语义相近的库接口缝补过来的。追查根因时我总结出一条模型对接口的记忆是“概率性组合”它觉得这里应该有这样一个接口于是造了一个。防御办法就是我前面提到的限定依赖清单要求AI引用的接口必须能在本地环境中查到具体定义。从那以后凡是在代码里看到我没印象的库接口我都会先查文档再审查而不是凭感觉点头。4.3 自动膨胀出来的“微服务架构”第三次翻车不是运行时报错而是设计层面的失控。某次我想快速搭建一个内部工具的后端就给了AI一个比较宽泛的任务描述。它干劲十足一口气生成了仓库对象、事件监听器、服务定位器、抽象工厂甚至还有一套消息总线。单看每个文件都写得有模有样组合在一起却把我吓到了——我们只需要一个不到十个接口的内部系统它却造了一个面向未来十倍规模的技术骨架。我花了两天才把这些抽象层拆干净回到一组简单直接的模块。这次教训很贵架构是权衡之后的决策不是“生成”出来的副产品。AI可以把单个函数写得无可挑剔但它不会为你承担整个架构的技术债务判断。从那以后系统骨架、模块划分、关键数据流向全部由我先定AI只能在骨架内部填细节。4.4 从三次翻车里提炼的一条铁律把三段经历放在一起看共同点非常明显越是看起来合理、结构越完整的AI输出越具有欺骗性。静默吞异常是结构完整的“安全优化”幻觉API是结构完整的“优雅调用”自动膨胀架构是结构完整的“健壮设计”。面对这种输出光是“测试跑通了”“肉眼读着顺”还不够你得带着一个逆向问题去审它为什么这么做这个结构是为了解决什么问题如果追问三遍没有清晰答案大概率是模型自己在脑补。5. 我现在的工作流人定契约AI写细节5.1 我会先写哪些“骨架”经过一年半的磨合我的工作流稳定成一种很像“结对编程”的模式我出契约AI出实现。动手时我会先写接口定义、数据结构定义、核心状态流转规则再在实现位置留好TODO注释。做完这些准备工作之后我会把任务喂给AI并要求它“严格按上述接口与约定实现不要改变函数签名与数据字段命名”。因为接口和数据结构是明牌的约束AI再怎么天马行空也只能在这份图纸内施工。完成之后我做两件事跑测试看diff里有没有违反约定的地方。大部分情况下这种“骨架先行”的做法可以把AI的自由度控制在安全范围内让它的效率为我所用又不会越权改写边界。5.2 我的“永不委托”清单长久下来我给自己列了一张“永不委托清单”凡命中这些内容的代码坚决自己写架构与模块边界、数据库表结构设计、金额与状态计算、权限与安全策略、幂等与并发控制、对外接口协议。这些内容有一个共同特征它们都是系统的“契约层”错误会向所有下游扩散审错一片等于把整个项目的地基交给概率模型。AI可以对这些内容提供建议也可以帮我起草初稿但最终版本的每一行我都必须亲手敲过、想透。5.3 Vibe Coding如何改变了我的学习方式副作用也有惊喜。以前我刚接手不熟悉的语言框架时习惯先找教程、搭环境、跑Hello World节奏慢还容易卡壳。现在我会反过来先让AI生成一个小项目样例读它的代码顺便熟悉目录结构和惯用法再自己动手改造一版最后请比我熟悉这个技术栈的人做一次review。这个过程让我上手新东西的速度快了很多。但我必须补一句AI生成的代码用来起步可以用来当唯一学习素材是有毒的。它会把一些“好像合理”的写法混进去你如果照单全收等于把流利的幻觉当成了最佳实践。学东西时一定要有真人参与审查这点无论如何不能省。这一年半走下来我变化最大的不是写代码的速度而是对“定义问题”这件事越来越有耐心。Vibe Coding把我从键盘敲击里解放出来同时也用各种翻车提醒我表达不清的代价从来不会因为AI而消失只会被它更丝滑地放大。它最值钱的不是那一段段代码而是逼着我把模糊的念头翻译成清晰的指令和可验证的断言。最后分享一个小技巧如果你的AI在同一个问题上连续三轮都没有修出正确结果别再一股脑换提示词了停下来自己把那块代码看一遍。多数时候问题不在它愚蠢而在你最初给的说明或者上下文里藏着自相矛盾的前提。调整输入的方向比硬撩AI有效得多。
