Vibecoding这词，最近在开发者圈子里发酵得特别快。用大白话说，就是你把需求讲明白，代码由AI来写，你负责听反馈、把方向——写代码从“动手”变成了“动嘴”和“动脑”。上一篇我已经简单体验过一把Claude Code，属于浅尝辄止，跑通一个Demo就收手了。这篇是系列的第二篇，我决定拿一个真实的小工具需求，让它从头到尾走完：项目初始化、写方案、实现、运行、调试、加功能，全流程都让Claude Code参与，我在旁边负责判断和验收。这篇文章就是这次完整实操的记录，想试Vibecoding但不知道真实效果的人，看完应该能有个底。

1. Vibecoding到底在“比划”什么：先弄明白这个开发范式

1.1 它跟过往的“AI辅助编程”有什么不一样

Vibecoding不是新鲜到无中生有的东西，它是从“代码补全”到“对话式助手”一路进化过来的。早几年我们用IDE里的补全插件，本质是“你写一半，它帮你猜剩下的一半”，模型看的范围很小，很少超过当前文件。后来有了对话式AI助手，我们开始把报错信息复制进去，让AI解释哪里出了问题，或者让它直接写一个小函数，我们再粘回来。这个阶段仍然是人主导、AI打辅助，代码的主体结构都是人脑里先想清楚的。

Vibecoding把这件事倒过来了。它的工作模式更像“发外包需求”：你描述清楚要做什么、边界是什么、期望的输出长什么样，AI端到端地产出代码，甚至会自己运行、自己看报错、自己修。你不需要一步步告诉它“这里写个函数、那里加个循环”，你需要做的是看懂它产出的结果对不对，然后继续提下一轮要求。

我特别喜欢一个类比：早前的AI辅助像是随身带了一本会说话的词典，碰到不会的词查一下；Vibecoding则像是雇了一个手速极快的实习生，你负责布置任务、看它干活、最后验收。注意，实习生意味着它会有自己的想法，也会犯错，你如果不盯着，它能把事情做歪。

1.2 为什么这种体验会让人“上瘾”

有朋友问我，为什么愿意花时间记录这种尝鲜过程，是不是被营销话术裹挟了。我的回答是，Vibecoding带来的体验确实有一种独特的“心流”：需求说出来，几十秒后代码就躺在那儿了，能跑通，再丢一句反馈，它又开始改。这种“需求变成现实”的链路被压到极短，非常容易上头。

更让我触动的是，它把写代码的重心从“记忆”挪到了“审美和判断”。过去写代码，最累的是记住各种API的细节、框架的写法、环境配置的玄学；现在这些杂活被AI接管了，人反而要反复回答几个更根本的问题：我到底要什么？这样做会不会有副作用？这个设计是不是合理的？对于熟悉业务的人来说，这种转变特别舒适，因为你的经验终于可以直接转化为生产力了。

但小白要小心，这个“上瘾”也可能是一个陷阱。如果你根本没有分辨代码好坏的能力，AI产出一坨逻辑混乱的代码，你也会兴高采烈地把它跑起来，然后埋一颗大雷。Vibecoding最好玩的前提，是你至少要有“看得出代码在干嘛”的能力。

2. 工具那么多，我为什么偏偏选了Claude Code

2.1 一篇“（二）”背后的选型思路

第一篇做完基础体验之后，我其实列过一个再往深处试的目标清单：工具能不能主动读写项目文件？能不能自己执行命令并看结果？能不能在一个长对话里保持对项目结构的记忆？简而言之，我想要的不再是“陪聊式编程”，而是“代理式编程”。

市面上的AI编程工具我大概分成了三类。第一类叫“编辑器内置助手”，优势是跟IDE融合度高，但多数时候还是人写一句、它补一段。第二类叫“对话式编程平台”，把AI做成了独立面板或网页，适合解释问题和生成代码块，但它往往不会主动去读你整个项目的文件，除非你手动挂载。第三类就是我这次重点体验的CLI式Agent工具，代表就是Claude Code。

我选Claude Code做“（二）”的对象，原因很直接：它跑在终端里，视角天然就是“整个项目目录”，而不只是“当前打开的这个文件”。它可以直接发起shell命令运行测试，也可以把报错反馈迭代回去。我需要的不是又一个聊天框，而是一个能靠自然语言驱动、完整跑完“需求到交付”闭环的东西。

2.2 Claude Code的几个关键特点

第一个特点是纯粹的终端交互。它没有复杂的面板，打开终端就是个对话界面，适合写在脚本里、适合远程服务器，跟Git操作配合起来也没有割裂感。

第二个特点是它拥有“看整个项目”的视野。启动之后它会生成一份当前目录的上下文描述，后续判断会基于整个代码库。我这次深有体会：它能自己定位到demo目录下的所有Markdown文件，而不是等我告诉它文件路径。

第三个特点是权限控制。它执行命令和修改文件之前，会主动跟你要授权。这一点对我来说是刚需。AI写代码最可怕的地方不是它写错，而是它自作主张乱改一气、把所有文件都碰一遍。Claude Code在关键操作前能停下来让你确认，这个交互模型值得所有做AI编程工具的人参考。

你可以把这个体验类比为“点外卖”：骑手接单、取餐、配送，每一步都有状态更新，你有事随时可以取消；而不是把一袋食材直接丢给你，连炒都没炒。

2.3 我列了一张工具选型的心智表

这张表不是绝对的，不同工具之间差距每天都在缩小。但就“Vibecoding尝鲜”这件事来说，我想要的是最接近“一个人把活干完”的体验，所以Claude Code成了这次的实验对象。

3. 上手准备：半小时把Claude Code拉起来

3.1 安装与授权环节

安装这个环节没什么玄学。前提是你机器上有Node.js环境，然后执行全局安装：

npm install -g @anthropic-ai/claude-code

装完之后确认版本：

claude --version

第一次输入claude启动，它会引导你做登录授权。这里提醒一句，Claude Code本身是收费服务，按API调用量计费，具体费用和你的账号套餐绑定。我的建议是，正式动手之前先搞清楚自己的配额或账户余额，不要像我上一篇那样，一口气聊到一半弹出一条额度不足的提示，那个感觉真的非常扫兴。

授权完成之后进到对话界面，可以先敲/help看看有哪些斜杠命令。版本更新很快，不同版本能用的命令不完全一样，见机行事。整体界面就是一个终端里的交互行，跟在终端里用Git的感觉差不多。

3.2 一个值得养成的习惯：给AI一个独立工作区

我上一篇的教训是：不要把Claude Code直接开在一个堆满无关文件的目录里。它的视野是整个目录，目录越乱，它越容易抓错重点。这次我单独建了一个临时目录，叫vibe-demo，里面放了一个demo-md文件夹，塞了大概七八个风格各异的Markdown文件，有的标题乱跳，有的列表缩进不齐，有的空行多到离谱，还有两个文件里嵌了代码块。

CLAUDE.md这个文件是Claude Code特别认的项目说明文件，相当于给AI看的“入职手册”。我这次在目录里简单写了一句：本项目的目标是为了测试AI辅助工具，重点关注demo-md目录下的Markdown文件格式统一。这个动作在后来的对话里非常关键，AI不会因为偶然翻到别的文件而跑偏。

3.3 第一次交互：让AI先复述它看到的世界

启动之后，我没有急着提需求，而是先让它“侦察”：

请阅读当前目录的结构，列出它的主要文件类型，然后分析demo-md目录下所有Markdown文件的格式差异，不要修改任何文件。

这一步很重要。Vibecoding最容易犯的错是“需求你自己还没想清楚，AI已经开始动手了”。让AI先把现状复述一遍，既是帮我确认它理解正确，也是在正式改动前建立共识。它很快输出了一串分析：标题层级不统一、列表缩进有的用4空格有的用2空格、连续空行数量不一致、部分文件开头有YAML Front Matter需要保留。我听完第一反应是：好家伙，它真的把文件都看完了。

4. 实战：用自然语言指挥Claude Code写一个Markdown格式化工具

4.1 需求描述：越具体越省事

这一轮我给自己定的任务非常明确：写一个批量整理Markdown格式的小工具，输入是demo-md目录，输出是处理好的文件和一份整理报告。我把规则压缩成三条：第一，标题层级调整时只在必要处补空格，标题内容本身不能动；第二，无序列表的缩进统一为两个空格；第三，连续空行压缩成一个，但代码块内部空行不能动。我用来描述需求的Prompt大概长这样：

请开发一个Python脚本，放在项目根目录，它需要处理demo-md目录下的所有Markdown文件。规则如下：

1. 代码块内部的任何内容都不修改，用```围栏判断是否在代码块内；
2. 非代码块里，连续两个及以上的空行压缩为一个空行；
3. 非代码块里，无序列表的缩进全部统一为两个空格；
4. 跳过文件名在忽略名单里的文件，比如README.md。 处理完成后，生成一份report.txt，统计每个文件修改了多少行、各标题的数量。

我说得越具体，它返工的概率就越低。很多人用AI编程喜欢“帮我整理一下”这种一句话需求，但AI不是读心术，它只能根据概率猜。把规则一条条列出，效果天差地别。

4.2 让它先给方案，我再“找茬”

Claude Code没有直接开写，而是先给了一个技术方案：尝试用Python标准库实现，不引入第三方Markdown解析器，逐行处理。我问它为什么不直接用现成解析库，它解释说，那些库更擅长把Markdown渲染成HTML，但对“保留内容、只格式化”这种需求，逐行处理反而更可控。这个解释我认可，于是回复了一句“按这个方案继续”。

这里有个值得注意的细节：Vibecoding不是“AI说啥就是啥”，而是你也要对方案有自己的判断。AI给出方案之后，你可以追问、质疑、让它对比取舍，这个过程跟真实开发里的设计评审很像。当然，前提是你自己要有基本的技术判断力。

4.3 看着它写代码、跑测试、改Bug、加功能

确定方案后，它开始创建脚本文件。在动手之前，它先列了一个待写入文件的清单，并发来询问是否允许创建format_md.py和后续可能产生的report.txt。我确认后，它一口气生成了脚本，紧接着主动提出“我可以先运行一遍，看看是否报错”。我允许它执行命令，于是它跑了python3 format_md.py，很快返回一个报错信息：某个文件的缩进计算方式不对，把非列表行的前导空格也顺手改了。

这一下就体现出Agent式工具的价值了。它没用“报错你自己看”应付我，而是自己读了traceback，定位到出错行，然后提出修改方案：增加一个in_code状态变量，并且在处理列表行之前先判断“这行是不是在代码块里以及这行本身是不是真的列表行”。我同意后它改了代码，又主动跑了一遍。这一轮“写代码、运行、报错、修复、再运行”的循环，它完全没有我的干预。

修完基础规则之后，我追加了一个需求：统计每个一级标题和二级标题各有多少个。它把这个功能也装进了脚本，整合到最终的报告输出里。你能明显感觉到，它不会因为你中途加需求而抱怨“需求变来变去”，它只会默默把新逻辑融进去。

4.4 展示一下它最终生成的脚本核心

下面这段是经过它自己迭代、修复过一遍之后的最终版代码片段，我把无关的主函数封装省去了，只贴核心的格式化逻辑：

import re from pathlib import Path SRC_DIR = Path("demo-md") IGNORE = {"README.md", "CLAUDE.md"} def clean_markdown(text: str) -> str: lines = text.splitlines() output = [] in_code = False prev_blank = False for line in lines: # 遇到围栏就切换代码块状态，代码块内部原样保留 if line.startswith("```"): in_code = not in_code output.append(line) continue if in_code: output.append(line) continue # 非代码块：连续空行压缩成一个 if not line.strip(): if not prev_blank and output: output.append("") prev_blank = True continue prev_blank = False stripped = line.lstrip() # 统一无序列表缩进为两个空格 if stripped.startswith("-") or stripped.startswith("*"): line = " " * (len(line) - len(stripped)) + stripped output.append(line) return "\n".join(output)

这段代码不算复杂，胜在逻辑通顺、边界情况处理到位。你注意那个prev_blank的布尔标记，它就是用简单状态机的方式把“连续空行”这个问题解决的，比我预想中的正则方案更稳。代码块和列表缩进的处理也完全对得上我提的需求。实事求地说，如果让我从头写，速度未必比它快，但逻辑上它能做到这个程度，已经超过很多初级开发者的第一版实现质量了。

4.5 全过程复盘：人与AI的协作节奏

我整个过程用了大概一个半小时，其中真正由我手写的内容只有需求描述、方案确认、验收这几步。它运行脚本、看报错、改逻辑、补齐测试报告的时间占绝大部分。最值钱的体验是“循环反馈”：AI跑完，我看一眼输出，有不对的地方就补一句，它立刻继续改。整个节奏像在打乒乓球，但球速特别快。

我的感受是，Claude Code的核心竞争力不在于单次生成的质量有多惊人，而在于它把“生成-执行-反馈-修改”的闭环做得很顺滑。单次生成再惊艳，如果报错后需要人手动复制粘贴、手动改文件、手动重跑，体验也会大打折扣。

5. 翻车记录：那些“理想很丰满”的时刻

5.1 翻车一：它想修改的比我想象的多

第一次让它跑完整流程的时候，我回复“可以”，它差点同时改掉根目录下与本次任务无关的一个配置文件。幸好权限确认弹了出来，我看到改动文件清单不对劲，立刻拒绝了，然后补了一句“这次只允许修改脚本文件和demo-md下的Markdown，其他文件都不要动”。

这个坑我犯过一次之后学乖了：重要的项目，我会在需求描述的最后加一句“任何不在预期范围内的文件修改，请先征得我同意”。对付AI，划清边界比反复纠正它更重要。

5.2 翻车二：上下文变长，AI开始“忘事”

到后半程，我连续提了四五个增量需求，包括“统计一级二级标题”“报告里加时间戳”“把输出格式换成表格”。提完时间戳之后，它突然把前面“代码块内部不修改”的规则给忘了，差点把代码块里的缩进也动了一遍。

解决办法有两个。一个是把对话历史压缩一下，Claude Code里有/compact之类的命令可以精简上下文；另一个是开新会话，然后把关键要求写进CLAUDE.md，让新会话重新读取。我这次为了省事，直接在新会话里打开，CLAUDE.md里记录着“代码块内不改、忽略名单不能动”，新会话一上来就门儿清。这种“把规则沉淀到文件里而不是只放在对话里”的做法，我强烈推荐。

5.3 翻车三：同一个Bug修了三轮

列表缩进的判断在第一次运行后报错，它修了一次，结果出现新问题：某些非列表行的前导空格也被改成了两个空格。它又修，第二次修完报告里的统计数字又不对了。来回三次，我开始烦躁，于是换了个策略：让它先写一条针对性的测试用例，把这个场景固定下来，然后再改实现。

它有测试用例做基准之后，明显收敛了。我的体会是，AI与人一样，光靠肉眼找问题容易顾此失彼，需要一条“红灯-绿灯”的约束来防止回归。这也是我后来跟Vibecoding协作最重要的心法之一：宁可多花两分钟让它写用例，也不要让它凭感觉修第五次。

5.4 费用和额度观察

这次整个项目大概消耗了几十万token左右，对不同价位、不同套餐的人来说体感不一样。我不在这里报具体数字，但两句话必须说：第一，Agent式工具因为要读文件、跑命令、多次迭代，消耗量明显高于普通对话；第二，如果你打算在一台机器上让AI连续干大半天活，中间随时看一眼额度消耗是个好习惯，别等它跑到一半停摆了才后悔。

6. 这批经验能复用什么：Vibecoding的边界与工作方法

6.1 真正适合交给AI的任务特征

经过这次实验，我的结论是Vibecoding最适合那些边界清晰、验证容易、涉及面窄的任务。典型例子：一次性脚本、数据格式转换、小型Web接口、单元测试补充、批量重命名与整理。这类任务的特点是，目标可以用三句话讲清楚，做完好不好可以用一个命令验证，出问题的影响范围也有限。

你跟它配合得越久，越能感觉到它的“舒适区”：它喜欢的是“有标准答案”的任务，而不是“到处是拉扯”的任务。格式整理就是一个典型，规则明确，输出可校验，遍历目录跑一遍，脚本成功与否一望即知。

6.2 现阶段我不太敢交给它的任务

反过来，有几类任务我目前不太放心完全交给它。第一类是核心架构决策，比如某个系统的模块怎么划分、数据库怎么设计、哪些服务该拆开，这些需要考虑很多隐性约束和历史原因，它很容易把方案做得“看起来合理但落地很痛”。第二类是安全敏感代码，比如认证授权、支付、权限校验相关的逻辑，这类代码出错代价太大，我至少要自己逐行过。第三类是依赖大量业务背景的代码，比如某个领域只有老员工才懂的特殊规则，AI再怎么读代码也读不出那些“没写在文档里的约定”。

我的结论是：Vibecoding是编程“外骨骼”，不是“外脑”。它能让你跑得更快、举得更重，但它不会替你判断方向。真正的大脑还是得长在你自己的脖子上。

6.3 我总结的五条协作经验

1. 先讲结论和验收标准，再讲背景。AI越早知道“什么算成功”，产出的东西越不容易走偏。
2. 一次只做一件事。别在一条需求里塞三四个目标，拆开会省很多返工成本。
3. 让它先给方案、你确认后再动手。这个步骤往往只花两分钟，但能避免它一头扎进错误方向。
4. 遇到反复出错时，不要继续对话，直接让它写测试用例。有了红灯绿灯的约束，它才能收敛。
5. 把长期规则沉淀到CLAUDE.md里。会话会清空、上下文会压缩，但项目说明文件不会丢。

6.4 给准备尝鲜的人一句实话

Vibecoding是一个很好玩的开发新姿势，但请不要把它理解成“不用学编程了”。它更像是把“写代码”这个体力活大幅自动化，把人类的注意力转移到“要什么、对不对、合不合理”上。对于有开发经验的人，它是效率放大器；对于纯小白，它是一台危险但诱惑力极强的跑车，油门很猛，方向盘还是要自己握。

最后说点个人体会吧。这一趟走下来，我觉得Vibecoding对我最大的改变，不是“少敲了代码”，而是把注意力从键盘上挪开，挪到了更接近本质的地方：需求怎么拆、边界怎么定、验收标准是什么。写代码的时间被压缩成等AI输出的几分钟，剩下的大把时间，我反而花在“向它解释清楚”和“检查它的成果”上。这种体验很微妙，像带新人，也像自己给自己做产品评审。下一篇我大概率会把它带到存量旧项目里试试水，毕竟现在最痛的还是老代码改造，到时候再来写（三）。