最近圈子里的朋友都在聊 vibe coding我自己的感觉是这个词几乎一夜之间就成了 AI 编程的代名词。但我翻了一圈中文资料发现大部分内容都停在概念科普和 Demo 展示真正能告诉我“怎么用自然语言把一个完整项目从零到一落地”的实战细节很少。我前阵子刚好用纯自然语言驱动的方式完整做了一个可用于日常的小工具项目——一个基于 Python 的自然语言意图识别与槽位提取命令行程序。整个过程中我几乎没有手写代码所有功能都通过对话式描述让 AI 完成包括项目骨架搭建、核心算法、命令行交互、单元测试和 README 文档。这篇文章就把我完整跑通的流程、每个环节踩过的坑、以及背后的原理讲清楚。无论你是刚接触 AI 编程的新手还是想系统化使用 vibe coding 的老手本文都会有用。1. vibe coding 到底是什么从“敲代码”到“描述需求”的范式变化1.1 这个词怎么来的以及它和普通“AI 辅助编程”的区别vibe coding 这个词最初来自 Andrej Karpathy 的公开分享大意是你不再逐行编写代码而是用自然语言把需求描述出来让 AI 生成代码你只负责理解、审阅、修正方向整个过程更像“跟着感觉走”。很多人会把 vibe coding 和传统的 AI 辅助编程混淆但两者的体验差异非常大。我用 GitHub Copilot 做传统辅助编程时AI 是“补全我的思路”——我写了一个函数它帮我续写我定义了一个类它帮我填充方法。本质上我还是编码的主导者AI 是超强版的自动补全。而 vibe coding 是全反过来的AI 是主导者我要做的只是“准确描述我想要什么”并不断在对话中校正方向。举个例子。传统方式下我想给一个文本文件做分类工具我需要先写def load_file(path)再写def preprocess(text)再写def classify(text)……然后再让 AI 帮我补全每个函数内部逻辑。而 vibe coding 的方式我只需要在对话框里输入帮我写一个 Python 脚本读取指定文件夹下的所有 txt 文件基于关键词规则对每行文本进行分类统计每个类别的行数把结果输出为 CSV 文件支持命令行参数指定文件夹路径和输出路径。就是这么一段自然语言AI 会在几秒内生成一个完整可运行的单文件程序。我再根据运行结果继续反馈“分类规则太粗粒了请把‘支付’、‘退款’、‘订单’这些词归类为交易类把‘登录’、‘验证码’归类为账号类。”然后 AI 会自动修改规则字典和相关逻辑。这个差异是本质性的传统 AI 辅助编程是把 AI 嵌进“你的代码流程”vibe coding 是把“你的意图”作为整套开发流程的唯一输入。也正因为如此vibe coding 的门槛不在写代码而在于表达的准确度和结构感。1.2 它的适用边界能做什么不适合做什么用了这段时间我总结出了 vibe coding 比较靠谱的适用边界给你做个参考。先说适合的场景。第一是原型验证这是 vibe coding 体验最好的领域。你想验证一个想法能否用代码实现完全可以用自然语言让 AI 快速生成一个粗糙但可运行的版本。第二是内部工具和小脚本比如数据处理脚本、文件批量重命名、PDF 合并、日志分析这类一次性或低频使用的工具。第三是小产品的 MVP一个功能边界清晰的单人或小团队项目vibe coding 能极大缩短开发周期。第四是学习和探索想了解某个库怎么用、某个算法怎么实现可以通过自然语言让 AI 写示例代码比翻文档效率高得多。而不适合的场景也很明显。第一是高并发底层系统。这类系统的每个细节都可能影响性能和稳定性靠自然语言驱动 AI 来写几乎不可控。第二是安全敏感型项目。涉及资金、隐私、复杂权限控制的逻辑AI 生成的代码可能带着隐蔽的逻辑漏洞人工审阅成本极高。第三是维护期长、需要严格架构约束的复杂企业项目。这类项目需要严格的模块划分、规范约定和代码评审vibe coding 那种“改了这里崩了那里”的随意性会成为灾难。我的判断标准很简单项目能接受“先跑起来再慢慢修”的节奏就可以 vibe coding项目必须“一次就写对”或“可长期演进化维护”就要降低对 AI 生成代码的依赖让 AI 作为辅助而不是主导。2. 自然语言为什么能“翻译”成项目意图识别、槽位提取与上下文机制2.1 LLM 理解编程任务的基本链路很多新手会好奇我随便说一句话AI 是怎么知道要写什么代码的这条链路从自然语言处理的角度看其实并不神秘底层就是传统 NLU 领域里的两个核心概念——意图识别Intent Detection和槽位提取Slot Filling。意图识别是判断用户这句话“想干什么”比如“帮我把文件重命名”背后是“文件操作”意图“帮我统计一下数据”背后是“数据分析”意图。槽位提取是从这句话里抽出完成这个意图所需的关键实体还是以刚才那句为例槽位可能是“文件路径”“新文件名”“文件格式”等。在大模型出现之前做这类系统非常痛苦。我早年间做智能客服项目时意图识别要准备几千条标注语料去训练分类模型槽位提取要设计 CRF 或 BERT 序列标注模型开发周期以“月”为单位。而大模型把这两步操作内化成了自己的一项基础能力——它先在语义层面理解你这句话的意图再从句子中抽取实体和约束最后映射到它掌握的编程知识上生成对应代码。这个过程对用户是不可见的但这意味着你能不能说清楚意图、能不能把关键槽位喂给模型会直接决定 AI 生成的代码质量。2.2 意图识别和槽位提取在 vibe coding 中的实际角色现在我们把同一个视角套到 vibe coding 上。当你对 AI 说“帮我用 Python 写个 Web 服务接收 POST 请求返回 JSON 数据”这句话里实际包含了一次完整的意图识别和槽位提取过程。意图是开发一个 Web 服务端程序。槽位是编程语言Python、请求方式POST、返回格式JSON、程序类型Web 服务。AI 识别出意图后会把它映射到“FastAPI 或 Flask 项目实现”这个知识领域再结合槽位信息确定用app.post路由、返回一个dict并自动转 JSON 等细节。高阶的 vibe coding 用户会刻意在描述中增加关键槽位的密度。比如不光说“写个 Web 服务”还会说用 FastAPI 写一个 Web 服务支持 POST /api/v1/predict 接口接收 JSON 格式的输入{text: ...}返回{intent: ..., slots: {...}}在本地 8000 端口运行依赖统一放在 requirements.txt 里。这句话里的槽位密度明显更高框架是 FastAPI路由是/api/v1/predict输入输出结构明确端口是 8000依赖管理方式是 requirements.txt。AI 提取这些槽位后生成的代码几乎不需要二次修改就能直接运行。理解了这一点你就会明白 vibe coding 的“黑魔法”本质它其实是把“人类语言 → 意图 槽位 → 代码”这条翻译链路交给大模型自动完成。所以你要修炼的核心能力有两个第一把意图表达清楚第二让关键槽位一个不缺。前者决定大方向不错后者决定细节不崩。2.3 上下文管理为什么多轮对话中的记忆是成败关键除了单次需求理解vibe coding 的另一个关键机制是上下文管理。说白了就是 AI 在多轮对话中的“记忆力”。大模型的记忆机制可以类比一个记性有限的实习生你第一天告诉他要关注“代码风格保持类型注解”他记住了并且在前几天做得很好但 50 轮对话之后他逐渐忘了这个约定开始生成没有类型注解的代码。这时候你说“怎么又没写类型注解”他会道歉并重新改好但再过几十轮同样的错误还会复发。这就是 vib coding 中最常见的“上下文漂移”问题。AI 不是真的忘了而是在大量新的代码片段和对话内容中早期指令的注意力权重被稀释了。解决方式我在后面专门的章节里详细讲这里先给一个最直接的思路把那些“绝对不可违反的约定”写在项目根目录的说明文件里每次对话都把文件内容作为系统级上下文交给 AI而不是指望它一直记住对话开始时的偏好。上下文管理的另一个维度是 token 预算。AI 对话有上下文窗口限制常见的模型有 128K 或 200K token。看起来很大但其实几轮代码生成下来几千行代码就把窗口填得差不多了。所以给 AI 完整项目开发需求时尽量不要把所有文件的代码一次性塞进上下文让它分析而是按模块分批次沟通或者使用支持项目目录索引的工具让 AI 按需检索文件。理解了意图识别、槽位提取和上下文管理这三个机制你就掌握了 vibe coding 的理论骨架。接下来要看的是实操层的工具选择。3. 工具选型Web 对话、IDE 插件与终端 Agent 到底怎么选3.1 三类 vibe coding 工具的定位差异现在支持自然语言驱动开发的工具非常多大体可以分成三类Web 对话工具、IDE 插件、终端 Agent。三者对“驱动项目开发”这件事的介入深度完全不同。Web 对话工具大家都很熟悉像 ChatGPT、Claude、Gemini 这类产品。它们的特点是不需要配置环境打开网页就能用适合需求探索、技术方案讨论、代码片段生成。但它们的弱点是无法直接操作你本地的项目文件——你获得代码后需要自己复制到文件里再手动执行、测试。也就是说它们能写代码但无法“完成项目开发”的闭环。IDE 插件类是大多数人接触 AI 编程的第一站代表产品有 Cursor、GitHub Copilot、Continue、Windsurf 等。它们的优势是直接嵌在编辑器里AI 能读取你当前打开的文件和项目目录索引生成的代码可以直接应用到文件里。这类工具适合有明确代码库、但想用 AI 加速具体编码工作的开发者。终端 Agent 是近半年增长最猛的方向代表产品包括 OpenAI Codex CLI、Anthropic Claude Code、Google Jules、开源的 OpenHands 和 Aider 等。它们运行在终端里通过自然语言指令直接操作整个项目——读取文件、修改代码、执行命令、安装依赖、运行测试、提交 Git 提交记录几乎把完整开发流程全包了。这正好落到那个热搜词的场景上在终端使用自然语言的 Agent。3.2 三类工具对比我试过这三类工具后把它们的核心差异整理成了一个表格方便你快速决策维度Web 对话工具IDE 插件终端 Agent环境配置难度零配置需安装 IDE 和插件需命令行基础安装 CLI 工具对项目的介入深度仅生成代码片段可读写当前项目文件可执行命令、跑测试、建 Git 提交上下文获取方式手动粘贴项目信息自动索引当前文件/目录自动读取项目结构并按需检索文件开发生命周期覆盖仅编码环节编码 部分调试从骨架生成到测试运行全覆盖适合人群新手、需求探索期习惯 IDE 的开发者愿意接受终端工作流的进阶用户项目规模上限小片段、单文件中小型项目中小型项目可支撑完整 MVP单看表可能不够直观我用自己的体验补一个判断维度你想让 AI 帮你“完成一个项目”而不只是“写一段代码”那么你需要的其实是终端 Agent。原因很简单——项目开发的完整闭环包含代码编写、运行、调试、测试、依赖管理等环节Web 工具只能覆盖代码编写这一个环节IDE 插件覆盖到调试终端 Agent 才能把整个生命周期串起来。3.3 我的选型建议如果你是完全没写过代码的新手我的建议是从 Web 对话工具开始因为零成本、反馈直观。先用它理解“如何把需求说清楚”再决定要不要上更重的工具。如果你有基本的编程基础想正经用 vibe coding 完成一个项目建议直接选终端 Agent。我目前的主力工作流是终端 Agent 负责执行和改代码Web 对话工具负责前期方案讨论和复杂逻辑推演。两者搭配项目推进速度非常快。关于具体工具的选择我的建议是“谁文档全、谁迭代勤就选谁”。终端 Agent 这个领域目前发展极快各家的能力和定价每个月都在变。OpenAI 的 Codex CLI 胜在 OpenAI 模型理解力强Claude Code 在处理长上下文和复杂重构上表现突出开源方案 OpenHands 胜在可自托管。我的原则是不要迷信单一工具主要看它能否处理你项目中常见的文件类型和命令操作。选好工具之后下一个问题是实战中到底怎么一步步用自然语言驱动出一个完整项目我用一个真实案例来拆解。4. 实战用一句话驱动出一个可运行的“自然语言意图识别与槽位提取”工具4.1 需求侧我给 AI 的第一段自然语言完整示例为了让案例尽量贴近真实场景我设计了一个小项目做一个命令行版本的意图识别与槽位提取工具。输入一句自然语言比如“明天下午三点提醒我开会”程序输出意图“设置提醒”以及槽位{时间: 明天下午三点, 事件: 开会}。这个项目既覆盖算法逻辑又覆盖命令行交互、输入输出设计、测试编写非常适合演示 vibe coding 的完整流程。我在终端 Agent 里输入的第一段自然语言是这样的帮我开发一个 Python 命令行项目名字叫 intent-slot-parser。核心功能是用户输入一句自然语言程序自动识别它的意图并提取出关键槽位。意图包括设置提醒、创建日程、添加待办、查询天气这四类。输入示例“明天下午三点提醒我开会”输出应该是意图设置提醒槽位{时间: 明天下午三点, 事件: 开会}。程序要有命令行交互模式用户输入 exit 时退出。需要为四类意图各准备至少 10 条测试样本测试程序能正确识别意图和提取槽位。项目结构要清晰核心逻辑和命令行入口分离。依赖尽量少只用 Python 标准库。最后把测试跑通的结果发给我。注意我在这个描述里放入了大量“槽位”信息项目名称、编程语言、核心功能、意图类型列表、输入输出示例、交互方式、测试样本数量、项目结构约束、依赖约束、验收标准。这比随口说一句“帮我做个意图识别的程序”要有效得多因为 AI 提取到的槽位密度足够高生成结果会非常接近我预期的样子。4.2 AI 的第一次输出项目骨架与核心实现终端 Agent 收到这个指令后会自动创建项目目录写入文件并逐条执行测试。整个过程的输出大致是下面这样的这是简化后的展示实际输出更长agent$ mkdir -p intent-slot-parser agent$ cat intent_slot_parser/parser.py EOF ... agent$ cat intent_slot_parser/cli.py EOF ... agent$ python -m pytest tests/核心的逻辑文件parser.py看起来像这样我省略了部分细节# intent_slot_parser/parser.py from dataclasses import dataclass from datetime import datetime import re INTENT_RULES { 设置提醒: [提醒, 记住, 别忘了, 到时叫我], 创建日程: [安排, 会议, 预约, 日程, 参加], 添加待办: [添加, 待办, 要做, todo, 完成], 查询天气: [天气, 气温, 会不会下雨, 多少度], } TIME_PATTERNS [ r(明天|后天|今天|周日|周一|周二|周三|周四|周五|周六), r(\d{1,2}[:]\d{2}), r(上午|下午|晚上|中午|凌晨)?\s*(\d{1,2})[点时], ] dataclass class ParseResult: intent: str slots: dict def parse_intent(text: str) - str: for intent, keywords in INTENT_RULES.items(): for kw in keywords: if kw in text: return intent return 未知 def extract_time_slot(text: str) - str | None: for pattern in TIME_PATTERNS: match re.search(pattern, text) if match: return match.group(0) return None ...这里最重要的一点不是代码本身多优秀而是我作为项目主导者需要在 AI 生成后做一次“人工审阅”。我看了它的实现逻辑发现它用的是基于关键词的意图匹配而不是基于模型的语义匹配——这个实现方式很朴素但对于项目要求来说是够用的。第一次生成就能有一个结构清晰、可以运行的版本已经达成了初版目标。我没有让它一上来就实现最复杂的 AI 意图识别而是明确限定在关键词规则上。这是一个非常有用的 vibe coding 策略先让项目以最简单的形态跑通再逐步增加复杂度。4.3 多轮迭代从“能跑”到“好用”项目能跑通之后真正的 vibe coding 之旅才刚刚开始。接下来每一步优化我都是通过自然语言告诉 AI 来完成的。第一轮迭代增强泛化能力。我发现它只处理了“明天下午三点”这种规则匹配但用户可能会说“十分钟后”“今晚八点”。于是我输入现在的时间槽位提取规则太僵硬只能识别固定词。请增加相对时间支持识别“X分钟后”“X小时后”“今晚”“明天早上”这类描述并把相对时间转换为具体的日期时间。转换后的时间格式用 ISO 格式输出。AI 修改了extract_time_slot函数增加了相对时间的解析逻辑并接入datetime做相对计算。第二轮迭代改进意图冲突处理。当句子同时包含“提醒”和“会议”时程序会返回第一个匹配到的意图“设置提醒”但用户可能是“创建日程”。我输入现在的意图识别按关键词先后顺序匹配当多个意图都命中时结果不稳定。请增加一个优先级机制如果句子中同时命中“提醒”和“日程”优先判定为“创建日程”同时命中“天气”和“日程”时优先判定为“查询天气”。把优先级写成一个显式的配置结构。第三轮迭代补充命令行交互体验。我输入命令行模式目前交互感太弱。请加一个欢迎语显示支持的四类意图每次解析后显示分隔线当用户输入无法识别为任何意图时提示“抱歉我没能识别您的意图请重新描述”并保持程序不退出。第四轮迭代写测试。我输入请为 parser.py 写完整的单元测试要求覆盖每类意图至少 10 个正向用例相对时间槽位提取的 5 个用例多意图冲突时的优先级用例。测试数据写在一个单独的测试数据文件里用 pytest 参数化方式运行。这几轮迭代全是自然语言驱动我没有写过一行代码但项目复杂度肉眼可见地提升了。4.4 这个案例揭示的 vibe coding 工作流回顾这个实战过程我发现它真正有效的核心是一个可复制的工作流共五步第一段描述里塞满关键槽位——项目名、语言、功能、约束、验收标准尽量一次给全。让 AI 先给出最小可运行版本——不要一开始追求高复杂度先让骨架跑通。运行测试用现象反馈修正——每次迭代都以“我刚才运行后发现……”开头让 AI 基于实际现象调整而不是凭空加需求。一次只改一个维度——不要让 AI 同时做意图识别优化和命令行界面优化逐项推进方便定位回归问题。最后一轮做工程化收尾——补测试、写 README、整理依赖、补充类型注解。这套流程我如今几乎每天在用。下面我再把自然语言表达层面的核心技巧单独拎出来讲因为这是 vibe coding 里最软也最关键的技能。5. 把需求说清楚的五步法决定 vibe coding 成败的表达技巧很多人用 vibe coding 效果不好最常见的原因不是 AI 不行而是需求说不清楚。下面这套五步法是我在大量实践中总结出来的每一步都会用一个项目开发中的真实例子来说明。5.1 第一步先定义输入和输出再谈功能细节新手最容易犯的错误是花大量篇幅描述“这个系统能做什么、背景是什么”却没说清楚“喂进去什么、吐出来什么”。而 AI 生成代码时最需要的锚点就是输入输出结构。反面例子“我想做一个工具帮我整理日常安排让我不会忘记重要的事最好还支持提醒功能。”正面例子“我输入一句话例如‘明天下午三点提醒我开会’程序输出意图类别和关键槽位。输出格式是 JSON{intent: 设置提醒, slots: {time: ..., event: 开会}}。”输入输出描述清楚了AI 就能立刻确定函数签名、数据结构、模块边界。这是整个项目的地基。5.2 第二步给示例比给规则更有效大模型的少样本学习能力非常强与其给它提十条抽象规则不如给它三五个具体的“输入 → 期望输出”示例。例如在改进意图冲突时我给的规则是“同时命中‘提醒’和‘日程’时优先判定为日程”但 AI 执行时可能理解有偏差。如果我在描述里加上具体示例——示例1“明天上午十点开会提醒我” → 意图应为“创建日程”即使出现了“提醒”两个字示例2“周末提醒我交房租” → 意图应为“设置提醒”没有日程动词。——AI 会更准确地把握优先级规则的实际语义。示例就是给 AI 的坐标比笼统描述精确得多。5.3 第三步把约束条件单独列出项目开发中总有一些“红线”比如不能引入某些依赖、性能必须达到某个量级、代码必须在 Python 3.9 下运行、不允许使用某些第三方库等。如果你把这些约束混在需求描述中间AI 很容易忽略。我的做法是在描述末尾单独拉一个“约束”区块约束1. 只能使用 Python 标准库不允许安装第三方包2. 兼容 Python 3.93. 函数必须带类型注解4. 不要在代码中写死文件路径。这个区块最好用“约束”这样的显式标记开头AI 会把它当作高优先级指令。5.4 第四步主动指定技术栈和边界如果你对技术栈没有特殊要求AI 会按自己的偏好选择可能生成 Flask 项目、也可能生成 FastAPI可能用 TensorFlow、也可能用 scikit-learn。当你更希望项目可维护性强、生态熟悉时最好主动指定。比如“Web 框架用 FastAPI不用 Flask数据存储用本地 JSON 文件不用数据库意图识别先基于规则字典实现暂不引入模型。”主动指定技术栈还有一个额外好处AI 会按同一技术栈的重构逻辑生成所有代码保持风格一致性。否则每次生成一段代码它都可能切换到另一个库项目最终会变成一堆风格混乱的杂烩。5.5 第五步分阶段提交需求不要一次性倒出所有需求这个是我踩坑最多的一条。我一开始用 vibe coding 时恨不得一句话把整个系统的所有功能都描述完帮我做一个项目管理工具要能创建任务、设置优先级、跟踪进度、生成报表、发送邮件通知、支持多人协作、带用户登录……结果 AI 给出的代码要么是大量未实现接口的“骨架空壳”要么就是各功能都沾一点但都不完整的“半成品”。正确的做法是分阶段提交第一轮只做核心主流程跑通第二轮补齐一个最常用的扩展功能第三轮增加边缘场景处理和异常分支第四轮工程化收尾测试、文档、构建。每次只提一个阶段的需求AI 的注意力会非常集中生成的代码质量明显更高。当你掌握了这五步表达技巧之后vibe coding 的基本功就齐了。但真到了跑项目的环节你大概率会碰到各种诡异问题。下一章我专门讲我在实战中踩过的坑以及一个完整的排查链路。6. 自然语言驱动项目中容易踩的坑以及一条完整的排查链路6.1 坑一AI“自信地”生成不存在的 API 或库这是 vibe coding 中名气最大的坑因为 AI 会出现“幻觉”——它不是故意撒谎而是在训练数据里见过类似 API但记混了于是“自信”地生成了并不存在的函数签名或模块。我在一次自然语言驱动中遇到过这种情况。我对 AI 说“用 standard library 里的 argparse 模块解析命令行参数”AI 生成的代码看起来完全合理但当我运行python cli.py --help时却报了一个AttributeError: ArgumentParser object has no attribute add_argument。这不可能argparse 明明有这个功能。后来我发现AI 在处理某个边缘场景时用了一个不存在的parser.add_argument_group_ex()方法——这个 API 根本不存在是它幻觉出来的。识别这种坑的方法很直接当错误提示指向“模块里没有某个属性/方法”时不要急着信任 AI 的第一次修复因为它可能只是换个地方继续幻觉。正确的做法是让 AI 把 API 文档原文或标准库源码中的真实签名列出来或者你自己快速查一下官方文档。6.2 坑二上下文漂移导致项目越改越乱这个坑我在讲上下文管理时就提过。具体表现是项目前 20 轮对话里AI 严格遵守了某项规范比如“所有函数的返回类型都带Optional标注”。但到了第 40 轮AI 开始在某些新函数里省略Optional再往后它甚至给旧函数也做了“重构”把类型标注抹掉了。我的应对习惯分三步。第一步把所有“不可违背的约定”写进项目根目录的一个说明文件里内容类似# PROJECT_CONVENTIONS.md - 所有公共函数必须带完整类型注解 - 所有模块必须包含模块级 docstring - 异常处理禁止使用裸 except - 禁止在业务代码中 print()必须使用 logging第二步在新一轮对话开始时先在消息里对 AI 说“请先阅读项目根目录下的 PROJECT_CONVENTIONS.md后续所有修改都遵守其中约定”。第三步一旦发现 AI 违反约定不要说“你怎么又忘了”而是直接把违规代码片段和约定条款同时贴给它强制它对照修正。6.3 坑三项目能跑但没人看懂代码vibe coding 最常见的成功幻觉是“程序跑通了太好了”但过两周再看代码你完全没有勇气去改——函数名语义不明、模块之间互相依赖、逻辑分散在各处。我在做上面那个意图槽位项目时就遇到过。第一版 AI 生成的代码把parse_intent和extract_time_slot全放在一个文件里函数名还算清楚但它内部有十几个未注释的正则表达式每个表达式是干什么的完全看不出来。后来我强制要求 AI 做了一次“代码可读性重构”并给了它三条具体指令每个正则表达式前面加注释说明匹配规则公共函数写 docstring 说明输入输出拆分过长的函数。经过这一轮代码质量提升非常明显。vibe coding 的项目越到后期智能体对“当前代码到底写了什么”的理解就越依赖代码本身的质量。代码可读性差AI 后续的修改也会跟着变差。所以不要因为“AI 写的代码”就跳过工程化收尾那部分要花的精力一分都不能省。6.4 从报错到根因一个完整的排查链路实例下面分享一次完整的排错经历你能看到在 vibe coding 工作流中AI 和人是如何协作完成问题定位的。现象项目要读取一个包含一万行的数据集文件AI 用json.load加载后程序抛出了JSONDecodeError: Extra data。第一轮我直接把完整报错贴给 AI请求修复。AI 给出的修改是“改用json.loads并按行分隔解析”也就是把它改成了逐行解析。我运行后程序不报错了但解析结果错乱——数据集本身就是合法的 JSON 数组逐行解析反而把数组里的每个元素误当成独立 JSON。第二轮我意识到问题不在解析方式而在于文件本身。我让 AI 先输出文件前 200 字节的原始内容发现文件首尾有不可见的 BOM 字符和多余的换行符。原来 AI 在生成数据文件时写入了一个带 BOM 的编码格式而json.load默认按 UTF-8 无 BOM 解析导致首位解析失败。第三轮修复方案就清晰了读文件时指定encodingutf-8-sig自动剥离 BOM。这个案例里最有价值的教训是AI 第一次给出的修复建议换解析方式是完全错误的因为它在没有查看数据文件本身的情况下直接从“报错信息”跳到“修复方案”跳过了“根因分析”这一步。而我作为项目主导者最重要的动作是要求 AI 先输出用于定位的原始数据信息这本质上是一种“用调试思维对抗 AI 幻觉”的策略。类似的排查链路我可以总结成一个操作顺序把报错原样贴给 AI → 要求 AI 先输出排查所需的原始信息文件内容、环境版本、实际输出 → 要求 AI 提出一个“最小实验”来验证根因 → 验证通过后再让 AI 修改。这套链路能帮你绕开 AI 最激进、最不可靠的那类修复。7. 从“能跑”到“能维护”vibe coding 产物的工程化收尾7.1 第一次逼 AI 补测试很多 vibe coding 教程不会强调测试但实际项目开发中没有测试几乎寸步难行。项目改到第五轮之后每一次自然语言的修改指令都可能引入回归问题。如果没有测试兜底你根本分不清是 AI 改坏了还是新需求和旧逻辑冲突。所以我在项目功能基本稳定后给 AI 下达的第一条“硬指令”是必须为核心逻辑补充完整的单元测试。我用的自然语言描述大致是为当前项目写一套 pytest 单元测试。要求覆盖所有意图类型的正向识别用例、时间槽位的规则用例、意图优先级冲突用例、未知输入的兜底用例。测试数据要参数化每个用例都带可读的注释。运行全部测试并把结果发给我。AI 生成的测试规模相当可观而且我在它运行通过后还会做一件额外的事故意改坏一个函数逻辑再跑测试验证测试真的能捕获错误。这是规避“AI 生成测试跟着 AI 生成代码一起错”的重要手段——如果测试本身就是错的它就会“正确”地通过。7.2 README 和架构说明让未来的人包括 AI读得懂项目要维护文档是刚需。但这里的文档有两种完全不同的读者人以及下一轮对话中的 AI 自己。给 AI 看的文档我通常会要求它生成一份名为ARCHITECTURE.md的文件内容包含项目的模块划分、每个模块的职责、模块之间的依赖方向、核心数据流的输入输出格式。这么做的原因是当你开始新一轮 vibe coding 对话让 AI 修改项目时它能通过这份文档快速理解整个项目的结构而不是靠现场读代码猜。这样既节省 token也避免“AI 误解模块边界、改错地方”的问题。给人类看的 README我要求它包含安装步骤、使用示例、命令说明、测试方式、常见问题。这部分相对标准但一定要按“从一个完全陌生的人视角”来写不要假设读者已经了解项目背景。7.3 给 AI 写“项目宪法”约定文件的作用在上文讲到上下文漂移时我提到了把约定写进说明文件。这一步在大型 vibe coding 项目中效果尤其显著相当于给 AI 立了一部“项目宪法”。我目前的约定文件通常包含代码风格约定类型注解、docstring、命名规范技术栈约定框架、依赖管理工具、Python 版本架构约定模块分层、数据流方向、不允许的循环依赖测试约定每个核心函数必须单测、测试数据文件位置验收约定提交代码前必须跑通哪几条命令文件放在项目根目录每轮对话开始时我都提醒 AI 阅读它。这样可以最大程度缓解上下文漂移问题让 AI 在 40 轮、50 轮对话之后依然遵守第一轮就定下的整体架构约定。7.4 后续扩展思路做完了工程化收尾这个项目就算真正“竣工”了。后续还可以沿着几个方向扩展。一个方向是引入更高级的意图识别算法。比如把基于关键词的规则匹配替换成基于 TF-IDF 或向量相似度的语义匹配甚至接一个本地小模型跑 intent classification。另一个方向是把它改造成 FastAPI Web 服务对外提供 HTTP 接口。还有方向是扩展意图类型把它从“提醒 / 日程 / 待办 / 天气”扩展到更多场景也可以加入多轮对话状态记忆让它成为一个小型对话系统的核心模块。这些扩展的方向都可以继续用 vibe coding 的方式推进只需要在新的对话中把ARCHITECTURE.md和PROJECT_CONVENTIONS.md作为上下文传给 AI然后按那五步法描述新需求AI 就能像一位熟悉项目的老队员一样开始干活。我自己在这轮完整实践里最大的体会是vibe coding 并不是“什么都交给 AI我躺平”而是把工作的重心从“如何写代码”转移到了“如何准确描述、如何审阅结果、如何掌控方向”。AI 负责把自然语言翻译成可运行的程序我负责保证这段自然语言足够精确、足够完整。这套分工方式让很多原本需要几天才能搞定的内部工具现在几个小时就能交付。最后再分享一个小技巧每次开始新项目时先花 10 分钟把目标项目的输入输出、约束、技术栈、验收标准写成一页纸的“需求简报”然后再把这页纸直接作为第一轮对话的内容。你会发现这 10 分钟投入带来的项目质量提升远超你后面多花两小时返工。