近两年我最大的编程习惯变化是把大量日常开发从“写代码”变成了“向AI描述我想要的代码”。这个被社区称为 Vibe Coding 的实践方式简单说就是用足够清晰的提示词告诉AI你的目标、输入、约束然后通过一轮轮反馈把结果推向可用状态。它已经成了我做原型、写内部自动化工具、验证技术方案时的首选工作方式。要注意的是Vibe Coding 绝不是把代码扔给AI就完事恰恰相反它对你的代码理解能力、测试意识和工程化习惯提出了更高要求。这篇文章我会拆解我自己的 Vibe Coding 完整流程从概念、工作流设计、实战案例到坑和排查经验按真实可复现的方式写一遍。1. 什么是 Vibe Coding从“写代码”变成“描述代码”1.1 这个词到底在说什么Vibe Coding大意是指一种人机协作式编程开发者不再逐行敲出实现细节而是用自然语言向AI编程工具描述功能、行为、边界由AI生成代码再由人来验证、修正、继续迭代。这个词在近两年逐渐流行带着一点自嘲也带着一点对全新协作范式的概括。我自己的理解更偏中性它就是“把编程的主战场从脑内编译转移到需求表达和结果验证”上。过去我在写一个新函数时大脑里要先走一遍数据流、边界条件、调用方式然后才打开编辑器敲代码。现在这个逻辑链条的前半段很多由AI直接补完我反而把更多精力放在“我怎么描述才能让生成结果更接近需求”。可以把它和一个老概念区分开常见的代码补全工具本质是“单词联想”你写了函数名它补参数Vibe Coding 则更接近“意图到完整模块”的生成。补全工具的代词是“我能帮你少敲几个字”而 Vibe Coding 的潜台词是“你把需求说清楚其余我来打底稿”。1.2 与传统编程、传统AI辅助的核心差异我把三者的区别用一个表列出来方便对号入座。维度传统编程传统代码补全Vibe Coding主要工作重心设计、实现、测试全流程减少键入负担需求表达、结果验证、纠偏错误发现时机编译/运行/测试时键入时运行/测试时居多部分即时对代码理解要求高必须懂每一行中至少懂结构高必须看懂AI输出并判断取舍单位时间产出依赖个人熟练度小幅提升关键场景可数倍提升失控风险较低低高特别是不断叠加需求时第三行值得留意。Vibe Coding 对代码理解的要求没有降低反而转移了。当我让AI生成一个读取配置文件、解析环境变量并返回字典的模块时我如果不懂字典合并顺序、不懂变量优先级就很难发现AI生成的代码在边界场景下返回了错误结果。所以我在团队里经常说Vibe Coding 适合“懂行的人偷懒”不适合“不懂的人省事”。1.3 它到底适合谁能解决什么问题从实际经验看适合 Vibe Coding 的人群主要有三类有经验的开发者想快速验证想法、减少重复业务代码的编写时间。独立开发者和技术写作者需要一次性脚本、演示代码、数据转换工具这类“用完即走”的东西。正在学习编程的人用它当作“带注释的样例生成器”拿AI生成的代码做学习和对照素材。不太适合的是完全没有工程基础、也不打算读代码的人。因为代码最终要以长期可维护的状态存在如果连基本流程图都读不明白后续的调试、扩展、部署都会寸步难行。Vibe Coding 最大的价值不是替代思考而是把你从“重复的语法细节”里捞出来让你集中精力在更高层的目标上。2. 动手之前搭建适合自己的 Vibe Coding 工作流很多人第一次尝试 Vibe Coding 时会犯一个错误直接打开一个AI对话框把想法一次性全倒进去然后指望得到完整可用的项目。实际结果通常是代码刚能跑但结构混乱、依赖隐晦、再改几轮就崩。我后来终于总结出一个比较稳的工作流它包含工具选型、需求拆解和工程兜底三个部分。2.1 工具链选择与搭配思路先说结论不要只依赖一个“聊天框”也不要跟风追求最新锐的满屏工具。一套趁手的组合通常长这样一个支持在项目目录内工作的AI编程助手它能读取当前文件、识别工程结构比单纯把代码粘进聊天框要高效得多。一个可以自由调节上下文长度的对话窗口用来做思路讨论、方案对比和文档生成。一个命令终端配合自动化测试和静态检查用来验证AI生成的代码。我的习惯是分两路用。像“帮我看看这个函数为什么报错”这种需要结合完整上下文的问题我会交给能感知当前工程文件的助手像“对比三种数据库连接方式在并发场景下的区别”这种偏概念讨论的我反而会开一个干净的新对话不让旧项目的上下文污染判断。两路并行的原因是工程上下文和通用知识本来就是两类信息。把它们混在一个会话里模型反而容易取舍失当该看的文件没看不相关的背景却聊了一堆。2.2 需求描述一份“说人话”的提示词应当包含什么提示词质量几乎决定了Vibe Coding的成败。我给AI描述需求时会尽量包含五类信息目标这段代码最终要完成什么输入是什么输出是什么。例如“把指定目录下所有CSV文件合并成一个汇总表”。样本给一个具体的数据样例或参数示例而不是抽象描述。样本能显著降低模型猜偏的概率。行为细节文件找不到怎么办、重复数据怎么处理、是否需要按某个规则排序。这些细节直接决定代码能不能真正用起来。非目标明确“不要做什么”例如“不要联网”“不要自动覆盖已有文件”“不要用正则表达式解析HTML”。验收方式告诉AI你准备怎么验证比如“我会用三条测试命令来验证请确保程序支持这些参数”。还有一个容易被忽略的点你不需要写“请”“谢谢”之类的礼貌用语但一定要写清“如果发生异常请在stderr输出一段人话而不是抛出晦涩的堆栈”。这个对提词中的容错要求很有帮助。2.3 工程化底线把AI生成的内容当作正式代码管理我见过不少朋友让AI生成代码后只在临时目录里试跑一下能出结果就复制走。这种用法对一次性脚本没问题但一旦代码要长期演进就会失控。我的底线有三条所有AI生成代码先进版本控制仓库再谈修改。哪怕只是一个脚本也要能回退。依赖必须固定版本。AI生成的代码可能写了某个库的最新API但你的运行环境装的是旧版本跑不起来时有理说不清。入口函数要有明确边界。AI倾向于把所有逻辑塞进一个又长又臭的main函数我会在提示词里直接要求“把核心逻辑抽成函数方便测试”让结构从一开始就可维护。另外我强烈建议在项目里放一个requirements.md或notes.md把非目标、已知坑、交接信息写在里面。很多Vibe Coding翻车不是AI能力不足而是对话上下文里夹带了大量遗忘的信息回头再改时模型已经不知道你当初为什么排除了某个方案。3. 一次完整的实践从零做一个批量重命名工具理论说了这么多还是用一次真实动手记录来讲清楚。我选择“批量重命名图片文件”这个功能作为演示因为它短小、清晰又能覆盖 Vibe Coding 的大部分关键步骤。3.1 第一步写一条足够具体的初始提示我不建议一上来就写“写一个图片重命名工具”太宽泛。我的第一版提示是这么写的请帮我写一个 Python 脚本用于批量重命名文件夹里的图片。要求接收一个目录路径作为命令行参数只处理jpg、png、gif文件按文件修改时间从早到晚排序后给每个文件加上三位序号前缀序号从 1 开始执行前先打印将要重命名的映射让用户确认支持--dry-run参数做预览不真正修改文件。脚本作为单个文件rename_images.py输出核心逻辑请拆成可测试的函数不要写在全局作用域里。仔细看这个提示它包含了目标、输入、输出、排序规则、安全确认、函数结构要求。AI拿到之后生成的代码通常会比较克制不会放飞自我。3.2 第二步生成的初版代码与我做的事后修正用上面的提示词生成出来的初版代码大概长这样import argparse from pathlib import Path SUPPORTED_SUFFIXES {.jpg, .png, .gif} def build_rename_plan(root: Path, prefix: str img): images [] for path in root.iterdir(): if path.is_file() and path.suffix.lower() in SUPPORTED_SUFFIXES: mtime path.stat().st_mtime images.append((mtime, path)) images.sort(keylambda item: item[0]) plan [] for index, (_, path) in enumerate(images, 1): new_path path.with_name(f{prefix}_{index:03d}{path.suffix}) plan.append((path, new_path)) return plan def rename_files(plan, dry_run: bool True): for old, new in plan: print(f{old.name} - {new.name}) if not dry_run: old.rename(new) def main(): parser argparse.ArgumentParser(description批量重命名图片文件) parser.add_argument(directory, typestr, help目标目录) parser.add_argument(--prefix, typestr, defaultimg) parser.add_argument(--dry-run, actionstore_true, help只预览不执行) args parser.parse_args() root Path(args.directory) if not root.is_dir(): raise SystemExit(f目录不存在: {root}) plan build_rename_plan(root, args.prefix) rename_files(plan, dry_runargs.dry_run) print(f共预览/处理 {len(plan)} 个文件) if __name__ __main__: main()这个代码已经做到了基本可用。它的顺序逻辑很直接读目录、过滤后缀、按mtime排序、生成映射、预览或执行。但仅仅“能跑”不等于合格。我拿到代码后第一件事不是直接使用而是看几个容易出问题的点root.iterdir()是非递归的如果目标目录里有子目录子目录里的图片不会处理。这个是功能限制需要在需求里明确。path.stat()在拿到文件列表之后才调用如果目录里偶发文件被占用会直接抛异常。没有处理重名冲突。如果旧文件img_001.jpg本身已经存在重命名可能出现覆盖。这些判断要求我具备一定的代码阅读能力。我不会直接让AI重写而是把问题一条条回传给它要求它处理。3.3 第三步让AI迭代修复和扩展功能我接下来给AI的提示是上版本基本可用但有几个问题需要修1. 重命名时如果目标文件名已经存在请在执行前跳过并汇总到日志输出2. 文件读取过程如果遇到权限报错捕获异常后继续不要中断整个流程3. 增加--recursive参数开启后扫描子目录4. 保持原有函数接口不变方便测试。这种带明确修改清单的提示词比直接说“帮我优化一下”要有效得多。因为AI不需要猜测哪些地方是你关心的它会精准修改。我举个比较关键的变化递归扫描的改动。AI大概率会把root.iterdir()改成root.rglob(*)或者加一个分支def collect_images(root: Path, recursive: bool False): iterator root.rglob(*) if recursive else root.iterdir() for path in iterator: if path.is_file() and path.suffix.lower() in SUPPORTED_SUFFIXES: yield path这里我关心的不是这个函数本身而是它是否保持了build_rename_plan的接口不变。如果AI为了支持递归把函数签名改成需要传recursive那我前一轮写的测试可能全部需要改动。所以我会特意在提示词里强调“接口不变”或“尽量保持兼容”能省很多返工。3.4 第四步用自动化测试把迭代锁住拿到AI生成的新版本后我不会直接跑而是先要求它生成一组测试。提示词可以很直接为build_rename_plan和rename_files写一组测试覆盖以下情况1. 空目录2. 目录里混有非图片文件3. 图片按修改时间排序4.--dry-run模式不实际重命名5. 目标文件名冲突时跳过且记录日志。测试使用 pytest 风格。这样的提示词得到的结果会是一个典型的 pytest 文件我在本地跑一遍pytest -q test_rename_images.py测试的作用不是证明代码没问题而是锁定行为。后面再做任何迭代只要测试还是绿的我就能快速知道这次修改没有破坏已有功能。老实说这是我在 Vibe Coding 里学到的最重要一课让 AI 生成的代码先用测试钉死行为再谈优化和扩展。4. 实测中遇到的典型问题与排查思路工具再好坑还是存在的。下面这些是我反复踩过的典型问题每个都配了排查思路基本都是可以直接抄作业的。4.1 AI 幻觉编出不存在的函数和参数这是最常见的一类。AI会一本正经地调用某些不存在的模块函数比如imgtool.prepare_rename_batch(...)而你搜遍文档也找不到。它还会虚构“这个参数应该存在”的用法让代码在编译期就报错。我的排查策略分三步把报错信息的第一行单独复制出来不要贴整个堆栈发给AI问“这个函数在目前环境里不存在请确认正确写法。”打开官方文档页面用截图或文字摘要喂给AI让它基于“真实文档”重新生成而不是靠记忆发挥。如果AI坚持要一个并不存在的库直接停止追问换一个实现路径。与其和幻觉较劲不如绕过那个库用手写逻辑替代。这个问题的排查逻辑本质上要求我能识别“真实缺失”和“幻觉错报”的区别。如果我不认识那个API却选择盲目相信AI就会白白浪费时间。4.2 AI 上下文越长反而越“笨”我刚开始时有一个误区为了让AI掌握更多项目信息我把几百行历史代码全部贴进去。结果它经常忘记最开始的需求后面生成的代码开始“漂”甚至自己跟自己矛盾。原因是上下文窗口虽然不断变大但模型对关键信息的注意力会被大量无关文本稀释。现在我的做法很明确长对话只做方案讨论一旦开始写代码就切换成一个新的、干净的对话窗口把真正的需求和约束放在最前面然后把历史代码中直接相关的函数片段贴给AI而不是把整个文件倒进去。这和给新同事交接工作时给他一份精炼文摘而不是几千行代码是同样的道理。我还会在项目根目录维护一个CONTEXT.md只记录关键语法决策、目录结构、非目标和当前功能状态。每次开新对话时把CONTEXT.md的内容作为第一段提示词塞给AI效果惊人地稳定。4.3 反复修改后的“代码雪崩”Vibe Coding 迭代多了会出现一种很伤脑筋的问题改 A 功能时AI顺手破坏了 B 功能的实现而且两个功能在代码里看着还挺像测试没覆盖到就直接上线后面才发现。这种事我中招过不止一次。例如同样是扫描文件AI在支持递归后把常规模式下的排序逻辑也改了导致某次的输出顺序全变了而测试里没有写“非递归模式下的排序”这个断言。排查方法分两层第一层给AI下命令时明确写“本次只改collect_images函数不要动其他函数。”这是防止雪崩的最有效手段。第二层把测试覆盖范围做宽。不要只测输入输出还要针对“模式A保持旧行为、模式B增加新行为”分别写断言。一旦发现AI改坏了不该改的代码最快的解决方式是回滚到上一版然后重新发起一个只针对目标函数的修改请求而不是在坏版基础上继续缝补。4.4 安全与隐私红线输入输出都要设边界AI生成代码时可能会默认添加一些“听起来很合理”的功能比如自动发送诊断信息、尝试连接网络、把文件内容上传到某个服务。这类行为在调试场景下风险极大。我给自己立了几条规矩提示词里明确禁止联网、禁止读取个人目录以外的路径、禁止执行系统命令。除非这个工具本身就需要这些能力。生成代码后第一时间人工扫一遍是否有明显的网络请求、文件写入、shell 调用。涉及密钥、数据库账号、云服务凭据的代码绝对不通过AI工具处理即使只是贴进对话框也不行。在团队协作中会在项目仓库里加一层“AI生成内容”的标注并要求提交前完成密钥扫描。Vibe Coding 不是把安全责任外包给模型而是把安全责任变成检查清单让人来把关。4.5 排查问题时的“大段粘贴式提问”陷阱遇到报错时很多人喜欢把整段堆栈复制给AI。堆栈长不代表信息多里面有大量框架内部调用对模型判断真实原因帮助有限有时反而误导。我用了一个简单有效的方法先自己在本地把堆栈拆解到“第一处报错的业务代码行”然后把那一行、它的前后5行、以及一个最小化复现脚本贴给AI。这样模型需要推理的范围会小很多准确率也明显提高。最小化复现脚本这个概念在Vibe Coding里非常重要——它相当于把复杂问题切成一个十行能跑通的独立样本AI看到它通常几秒就能给出正确思路。5. 我的几条核心体验与进阶建议Vibe Coding 用了这么久它并不是万能钥匙。我的几条心得体会如果给两年前的自己能省掉一大半折腾。5.1 先回答一个问题这段代码可能怎样走向失控用 Vibe Coding 时我每接到一个需求会先问自己如果这段代码被AI写歪了最可能的失控点在哪是边界条件是外部依赖还是性能瓶颈然后把“在这个失控点必须做防御”写进提示词。比如处理用户上传文件的后端接口失控点可能是文件名路径穿越。让AI生成代码时提示词里就要写“必须对文件名做白名单校验禁止包含../”。又比如处理大量数据的批处理任务失控点是内存占用提示词里就要写“使用流式处理不要一次性load全部数据”。这个思路能让AI从一开始就沿着安全边界生成代码而不是在代码写完后再做亡羊补牢。归根结底Vibe Coding 要求你具备判断“哪里会出问题”的能力而这个能力只能靠日常编程经验积累。5.2 别只当“验收员”要当“复读生”我在培养新人的时候会建议他们使用一个技巧让AI生成代码后再追加一个问题“请用500字以内解释这段代码里最难的三行”。这个操作强制人去阅读AI生成的结果。不是每个细节都读懂但至少要让关键路径在脑子里形成图景。这个习惯对我的影响很大。有一次AI为了让排序更快引入了一个我从未见过的数据结构我在追问解释时发现它返回的结果在某种边界下顺序不稳定。这让我避免了一场隐蔽的生产事故。只做验收、不做理解是 Vibe Coding 最大的隐患。5.3 从个人实践走向团队协作时的三点补充当我把 Vibe Coding 引入团队协作后发现还要补三件事建立统一的提示词模板把安全边界、编码风格、禁止事项固化在后缀里省得每个成员各写各的效果天差地别。把AI生成内容的代码评审当成和人工代码一样的对待。不能因为它是“AI生成的”就默认它是中性的反而要更仔细地检查它和现有规范的兼容性。所有重要决策尤其是依赖选型、数据结构设计不要只听AI的建议。要让AI给出理由、列出备选方案再结合架构与运维成本一起判断。这点在多人维护项目里格外重要。我今天可以让AI生成一段风格奇怪的代码但要站在团队其他成员明天还要读它的立场上统一风格反而比“AI生成的炫技代码”更值得保留。最后说一个具体的后续扩展方向把 Vibe Coding 用于自动化测试生成是一个非常实惠的切入点。让AI先把现有函数的行为边界用测试钉死再去做重构会比直接改代码安全得多。我现在的大部分新功能都是先让AI写测试再让AI写实现最后让AI优化实现。这个顺序反过来用踩坑的概率会大很多。希望这篇实操记录能帮你在真正开工前少走几步弯路。