最近这一个月我的开发状态有了肉眼可见的变化不再是打开编辑器先空想半天架构而是先打开一个聊天窗口把我的“感觉”描述给AI。这就是大家常说的 vibe-coding——靠氛围、对话和直觉驱动的编程方式。我一边用一边记随手攒下这份AI vibe-coding日志今天把期间的完整过程、踩过的坑、总结出的工作流一次性写清楚。想从“手动写码”切换到“人机结对”的朋友或者已经在用AI但频繁返工的同仁这篇应该能帮你少走不少弯路。1. 为什么我开始用AI vibe-coding1.1 从“写代码”到“描述代码”的转变以前写一个功能我的第一反应是打开IDE找类名、看接口、写模板代码。现在完全不同了我坐在电脑前先不急着敲键盘而是在对话窗口里把需求“讲”给AI听。比如“我想做一个批量重命名图片的小工具要能按拍摄日期自动归类界面简洁一点”然后AI会给我生成一个可以直接运行的Python脚本。这种体验很像跟一个耐心的结对编程伙伴聊天我负责描述目标它负责铺路。这个转变背后有一个真实痛点大量时间消耗在“把想法翻译成代码语法”上而不是消耗在“想清楚要做的东西”上。Vibe-coding把人解放出来让我更关注“做什么、为什么做”而不是“怎么写”。用我自己的话说它把编程从“打字劳动”变成了“表达劳动”——你对问题理解得越清楚说出来的话越准确AI给出的代码就越贴切。这正是这个玩法最吸引人的地方。1.2 vibe-coding适合什么样的项目和人群并不是所有代码都适合让AI来“氛围编程”。我试了一段时间后总结出三类比较合适的场景一次性脚本和工具类程序例如文件批量处理、数据清洗、格式转换这种项目生命周期短、逻辑相对独立AI出活很快。原型和Demo想验证一个想法是否可行搭个最小可用版本出来这时候速度比代码质量更重要。前端界面和配置类代码布局、样式、配置文件AI特别擅长这种有大量模板性质的内容。不适合的场景也很明确。核心算法逻辑、涉及复杂分布式系统设计、对稳定性和性能要求极高的底层模块如果你自己都搞不明白这段代码为什么要这么写那让AI写就是在埋雷。Vibe-coding不是“彻底放手”而是“换一种方式控制”——你依然要能看懂代码、会审查代码、懂得在关键节点做决策。2. 我的AI编程工作流搭建2.1 工具选型IDE插件、CLI、Web端怎么选工欲善其事必先利其器。我在过去一个月里试过好几类AI编程工具最后形成了自己的搭配方案。IDE里装AI插件是最常见的方式比如GitHub Copilot、Continue、还有国内的通义灵码等它们能直接在编辑器里做代码补全和对话适合大多数日常开发。我个人的筛选标准有三条补全速度要快响应超过两三秒就会打断心流。上下文理解能力要强至少能记住当前文件的内容。认得出项目里的框架和目录结构不要动不动就给你一个跟现有代码风格完全不同的方案。CLI类的工具是我后来才加进工作流的比如OpenAI Codex、Google的Gemini CLI。它们的好处是可以在终端里跟AI对话让AI直接读取Git仓库、跑测试命令、改文件。这种工具特别适合做“自动提交”式的任务我给它一条指令它能把一次改动从头跟到尾。Web端工具更像“督察员”角色。当我在IDE或CLI里得不到满意答案时就把关键代码复制到网页版里重新问换一种提问方式往往能获得不同解法。不要只依赖单一工具多AI协作的价值在这里体现得很明显。2.2 提示词工程把需求说清楚Vibe-coding看着随性但想稳定产出提示词就得有章法。我自己把这几个月踩出来的经验总结成了一套“四要素提示法”本来只是随手记在日志里后来发现这套方法几乎适应所有场景。要素一背景。先告诉AI这是一个什么项目、用什么技术栈、在哪个目录下工作。比如“我在做一个基于FastAPI的日志分析服务Python 3.11代码在app/目录下”。没有背景AI就会瞎猜。要素二任务。用“我希望你……”或者“请帮我……”开头明确提出要做什么。不要只说“优化一下代码”要说“把这边的查询改成异步避免阻塞事件循环”。越具体产出越贴边。要素三约束。列清楚不能碰的东西。包括“不要改数据库结构”“不要引入新的第三方库”“保持现有函数命名风格”。这能很大程度上避免AI“自由发挥”。要素四验收标准。告诉AI“代码完成后要用pytest跑通现有测试”“返回结果格式要跟之前保持一致”。这会让AI在生成代码时主动检查自己的结果。举个例子我让AI帮我加一个接口时会直接说“在现有FastAPI应用里新增一个/healthz接口返回系统当前时间和内存占用。不要改其他现有接口不要添加新依赖写完后把代码输出到app/routes/health.py。”这样一次生成基本不用大改。提示词不是越复杂越好关键是信息密度要高能用一句话说清的就不要绕圈子。2.3 上下文管理让AI记住关键信息AI编程最常见的翻车点就是“失忆”。聊到一半它忘了项目结构忘了刚才约定好的变量名甚至忘了自己刚刚说过的话。所以管理上下文是一件很重要的事。我目前的做法是在一个任务开始前先把项目核心信息整理成一份“项目说明书”放在对话开头。这份说明书很短就三五行但每次新开会话就带上。内容大概包括项目简介、技术栈、目录结构、常用命令。刚开始写感觉麻烦但后来发现这比跟AI啰嗦十分钟再让它重新读代码省时太多。还有一个小技巧当一个任务超大时我会把任务切成“一个会话只做一个事”。比如“先写数据模型”“再写接口”“最后写前端页面”每个阶段都是一个新的会话带上同一个项目说明书。这样每个会话的上下文都很轻AI的出错率会明显下降。多AI协作也是我处理上下文的一种方式。有的工具适合从零生成代码有的工具擅长在存量代码里找问题。我经常让A工具生成初版再让B工具审查逻辑漏洞最后自己拍板修改。分工明确效果不错。3. 一次真实的vibe-coding实战从零写一个本地知识库工具3.1 项目背景与需求拆解这部分我想分享过去两周做的完整案例是一个本地Markdown知识库管理工具。起因很简单我电脑里散落着几百个Markdown笔记标签混乱、目录嵌套很深每次想找一条旧笔记都很痛苦。我本来想找现成的工具但试了一圈都不太顺手就决定自己写一个。需求用一句话说把散落的Markdown文件集中索引到一个网页界面里支持按文件名搜索和按标签筛选同时保留本地文件的原样。对就是这样一个小工具技术栈我选定用FastAPI加SQLite做后端前端就用简单HTML加原生JavaScript不搞复杂框架。为什么选这个组合因为我很熟PythonFastAPI出接口快SQLite零配置适合本地工具前端原生三件套跑起来没有任何依赖问题。3.2 分步实操记录我先打开Chat窗口告诉AI我的项目目标和结构“新建一个目录notes-app使用FastAPI开发后端SQLite存储索引需要扫描指定目录下所有.md文件解析front-matter标签提供搜索和标签筛选API。前端做一个单页包含搜索框和标签列表。”AI很快给出一个项目骨架包括main.py、requirements.txt和一个index.html。我看了下目录结构基本符合预期就直接让它在工作区创建文件。这一步非常快从零到能跑起来只用了十几分钟。接着我让它实现核心扫描逻辑遍历目录、读取文件、提取标题和标签。第一版Code AI用了pathlib的glob代码本身很简洁但我发现它没有处理嵌套目录而我需要的扫描范围正好是嵌套的。于是我把这个问题反馈给它“目前只扫描了根目录我需要递归扫描所有子目录并且忽略隐藏文件夹。”AI立刻修改了glob模式改成os.walk或Path.rglob问题解决。第三个环节是搜索接口。我要求它“支持按文件名、正文内容和标签三种方式搜索返回结果要按最近修改时间排序”。AI生成的SQL查询逻辑基本正确但一开始没做SQL注入防护。我直接在提示里加上“所有搜索参数必须使用参数化查询”它随即改掉了拼接字符串的方式。在这个阶段人如果不懂代码根本发现不了这种隐患。这也再次印证AI写代码人可以不会写但必须会看门道。3.3 关键代码与AI生成结果的调整让我把其中一段实际生成的代码简化后展示出来顺便聊聊我做的调整。AI最初写的文件扫描部分大概长这样from pathlib import Path def scan_notes(root_dir: Path) - list[Path]: return list(root_dir.rglob(*.md))这个函数确实能递归扫描但我马上加了两个约束。第一扫描结果要排除备份文件夹里的文件第二文件太多时扫描会很慢所以需要加入缓存机制只有修改时间变化时才重新索引。我让AI按这两点重新设计第一次扫描全量建索引之后每次启动都对比mtime做增量更新。AI给出了带缓存逻辑的版本代码量翻了一倍但运行效率高很多。再比如搜索接口AI最初返回的JSON里每个文件都附带全部正文内容导致响应体非常臃肿。我要求它改成“列表接口只返回元数据详情接口再返回正文”一拆二后配合前端路由逻辑也更清晰了。这种基于真实使用体验的“二次修改”是vibe-coding里最磨人但也最提升代码质量的部分。AI可以负责把骨架搭起来但只有你才知道真正用起来有多顺手。这个工具最后大概花了我两天多零零散散加在一起肯定不到十小时而如果完全手写我估计要一整个周末。省下的时间并没有让我更空闲而是让我把心思花在了真正重要的事情上打磨搜索体验、优化界面排版、补上自己常犯的笔记习惯缺陷。4. 调试、重构、测试AI代码不是终点4.1 让AI自己解释它的代码Vibe-coding里最容易出现的幻觉是AI生成了一段看起来很合理、实际上逻辑乱套的代码尤其是当它把几个不相关的功能揉在一起时。我有段时间频繁遇到这种情况后来总结出一个很好用的补救方法问AI“请一句一句解释这段代码在干什么”。之前写知识库工具时AI生成了一段处理标签分类的代码我看了一眼觉得逻辑不太对但说不清哪里不对。于是我在对话框里贴了那段代码让它解释每一步意图。它解释到一半自己发现了一个边界情况当文件没有front-matter时代码会直接抛异常而不是回到默认标签。我顺势让它修复它马上补了一个try-except分支。这个体验让我学到一条重要经验如果你看不懂AI生成的代码别急着改先让AI解释。解释的过程既是学习也是“让AI自查”的契机。它能发现自己的逻辑漏洞比人眼更快只要你有耐心把它引入到“自我解释”的状态。4.2 单元测试与AI辅助写测试是很多人讨厌的部分但对AI来说却是强项。我现在的习惯是每次AI生成一个新函数或新模块就顺手让它生成一份对应的测试用例。这不是客套话我已经实打实受益了。本地知识库工具里那个搜索函数AI生成的测试代码覆盖了“空目录搜索”“多标签组合筛选”“正文关键词命中”三种情况第一次跑就发现了两个预期之外的报错。其中有个报错很有意思我用一个中文关键词做搜索AI写的测试期望返回两条记录但实际只返回了一条。查了半天原来是SQLite的LIKE子句默认区分大小写中文字符不影响但英文关键词可能大小写不匹配。AI在生成测试时默认用了英文标题暴露了这个坑然后我让它把搜索改成大小写不敏感它用了一个很简单的LOWER()函数就解决了。所以我现在非常建议无论多小的工具都让AI顺手写测试。它不写你的代码就是“看起来能跑”而不是“真能跑”。尤其是AI自己生成的代码让它自己找毛病比自己对着断点翻stack trace省力得多。4.3 代码审查意识AI生成代码后不管运行起来多流畅我都建议做一轮“人工要点审查”重点盯三个地方安全边界有没有SQL注入、命令注入、路径穿越这些常见漏洞。依赖风险有没有偷偷装了你不需要的库或者用了版本很老的API。隐藏逻辑有没有悄悄改变原有行为比如改了配置文件的格式或者覆盖了用户数据。做知识库工具时AI在某个版本里自动给所有扫描到的文件加上了“更新时间已同步”的字段但实际它把文件修改时间固定成了索引建立时间。这会导致用户看到原文件的mtime被篡改。我看到代码后发现这个逻辑完全没必要直接让AI删掉。这个改动很小但如果盯着执行结果而不是代码本身估计很久都不会发现。说白了AI编程时代代码审查不是可选项而是必选项。你可以不理解每一个语法细节但必须知道这段代码最终会被用来做什么、会不会产生副作用以及发生问题时如何定位。5. 常见问题与排查技巧实录5.1 AI重复犯错、上下文丢失怎么办使用AI编程一个月我最常遇到的问题就是它在同一个对话里重复犯同一个错误。比如我让它改了三遍“不要用requests用httpx”它每次都答应结果下一次还是生成requests的代码。原因通常是上下文太长了早期信息被模型“遗忘”。我的解决办法是“及时止损”一旦发现同一个错误连续出现两次就不要再继续对话了而是新建一个会话把之前正确的约定重新写一遍。这时候我会把“项目说明书”再拿出来并增加一句“请特别注意项目统一使用httpx其他HTTP库不要使用”。这个新会话从干净状态出发往往一次就能改对。如果继续在旧会话里纠缠只会越改越乱。工具层面也可以配合。有些IDE插件支持把当前打开的代码文件自动作为上下文带入这样AI不会被长对话带偏。我经常在开新会话时把相关文件手动进来效果比单纯口述好得多。5.2 幻觉代码与安全风险幻觉代码是vibe-coding最大的暗礁。它的表现是AI十分自信地给出一个API看似真实存在实际上根本没有这个函数或者版本对不上。我遇到过最典型的几次包括让我用一个不存在的pandas方法还有一个已经被废弃的CSS属性。解决方案听起来有点“笨”但很有效一旦发现代码运行报错先把报错信息复制回给AI告诉它“这个API不存在请重新搜索文档”而不是自己去改。大多数AI模型都能根据报错信息自我修正。安全风险方面要更谨慎。尤其是当你让AI直接操作文件系统、执行Shell命令或处理外部网络请求时一定要加入明确约束。我的一句固定提示词是“只允许读取current目录下的文件禁止写删除操作禁止执行任意Shell命令。”这能极大降低AI生成破坏性代码的概率。在业务项目里建议再加一条“所有输入的长度做校验所有输出做转义”这样的规则。5.3 独家避坑什么时候不该用AI最后这个部分我觉得比任何操作技巧都值得记住。Vibe-coding不是万能的在下面几种情况里我强烈建议你不要用AI你需要“精确到字节”的输出比如协议解析、加密算法、内存布局。你完全不了解这个问题的领域连代码跑出来的结果是否正确都无法判断。项目的质量门槛很高比如医疗、金融等强监管场景。你只是想让AI“写个大概”但自己根本没时间验证。我用AI编程最舒服的状态是“我懂需求、懂系统边界、能验收让AI去写轮子。”最危险的状态是“我完全不懂让AI来教我全程怎么做。”前者是人用工具后者是被工具牵着走。一定要分清楚。后来我又试过让多个AI agent协作一个负责扫描代码、一个负责写测试、一个负责总结变更感觉像带了一个小队。但哪怕是多个agent最终的验收人还得是我自己。AI能帮你跑得很快但方向盘永远要握在自己的手里。我个人在实际操作中最大的体会是vibe-coding真正改变的不是“写代码”这个动作而是“做软件”的思维方式。以前我在动手前会焦虑生怕漏掉某个细节现在我会先跟AI聊一轮把焦虑变成具体的描述让它先产出第一版再一起头脑风暴。这个过程很上头也很容易让人产生“什么都能做”的错觉。保持清醒、坚守边界才是一个AI时代程序员该有的状态。希望这份日志里的经验和踩坑记录能让你在自己的AI编程路上少一些迷茫多一些笃定。