系列说明：这是我打算长期更新的一个连载，记录自己用 Claude Code 做 vibe coding 的全过程。不抄官方文档，只写我真正操作过、真正踩过坑的东西。这是第一篇，写得比较细，希望你看完就能动手。

一、先聊清楚：vibe coding 到底什么

Vibe Coding（氛围编程）这个词，是 Andrej Karpathy 在 2025 年 2 月提出来的。他的原话大意是：你完全沉浸在氛围里，接受指数级的加速，甚至渐渐忘记代码的存在。说得直白一点，就是你负责描述想要什么，AI 负责把代码写出来。

说实话，我一开始听到这个概念是有些抵触的。写代码不看代码，这怎么听都不太靠谱呀。但用了一段时间 Claude Code 之后，我的想法慢慢变了：vibe coding 改变的，是你"管代码"的层级。以前你盯着每一行怎么写，现在你关心需求清不清楚、结构合不合理、结果对不对。体力活交给 AI，判断力留给自己。

不过在正式开始之前，我想先明确几点，免得后面的内容误导你：

• 如果期待"说一句需求，AI 直接交出生产级代码"，大概率会失望。AI 写的代码常常看起来很专业，细看却藏着 bug。

• 社区里现在慢慢形成了一个共识：随手做着玩的原型可以纯 vibe，但要长期维护的项目，你至少得能向别人讲清楚每一段代码在做什么。讲不清楚的代码，就别往线上发。

• 我自己很喜欢的一句话是：vibe coding 让你把已经想清楚的东西，更快地变成代码。前提是，你得先想清楚。

二、工具这么多，为什么偏偏是 Claude Code

2026 年做 vibe coding 的工具真的一抓一大把：Cursor、Trae、Kiro、Codex……我几乎都试过一圈。很多人会告诉你，Claude Code 强在有 Plan Mode、强在有 CLAUDE.md 记忆。我一开始也是这么以为的，用得久了才发现，这些理由站不住脚——Cursor 也有 Plan Mode，记忆文件现在几乎每个 agent 工具都有了。这些只是"功能清单"上的东西，别人抄起来很快。

真正让 Claude Code 难以被追平的，是它的 harness 做得好。

"Harness" 这个词，直译是"马具"。官方文档里有一句话我很喜欢的说法：Claude Code 是围绕 Claude 模型的 agentic harness——模型之外的那一整套运行时设施，包括工具怎么调度、上下文怎么管理、权限怎么约束、出错怎么兜底。现在行业里有个共识：Agent = 模型 + Harness。模型各家都在追，差距越来越小，真正拉开体验差距的，恰恰是模型外面这层工程。

讲几个细节。

第一，模型和 harness 是一起长大的。 这一点最容易被忽略。Anthropic 自己训练模型，也自己做 Claude Code，模型在训练阶段就"知道"自己会跑在这套 harness 里。什么时候该列待办、什么时候该压缩上下文、命令跑失败了该怎么读报错继续想——这些行为是模型和 harness 长期磨合出来的默契，并非拿 prompt 临时拼出来的。第三方的工具就算接入了同一个 Claude 模型，也很难复现这种感觉；反过来，把别的模型塞进 Claude Code 里用，效果同样会打折扣。这种协同本身，就是壁垒。

第二，它把上下文当作一种需要精心打理的稀缺资源。 这一点我太有感触了。用 AI 写代码最怕什么？聊到后面它开始"失忆"，前面定好的约定全忘了，幻觉也越来越多——这在 agent 系统里有个专门的名字，叫上下文崩塌。Claude Code 为这个问题修了一整套防御工事：上下文用到一半左右会自动做摘要压缩，把关键决策留下来、把冗余丢掉；重的探索任务会派给独立的子 agent 去做，子 agent 花掉多少 token 都不污染主对话的上下文，做完只交一份摘要回来；甚至连 prompt 缓存都有精细的经济学设计，因为缓存一失效，花的可都是真金白银。我自己实测过一次大型重构，跑了两百多轮工具调用，换别的工具上下文早就撑爆了，它稳稳跑完，还记得我最初提的需求。

第三，工具设计得很克制。 它内置的工具只有十几个，数量上远不如很多竞品，但每一个都打磨得很深，组合起来几乎什么都能做。少而精这件事，说起来容易，做起来是需要工程洁癖的。

第四，它对"模型会犯错"这件事始终保持敬畏。 权限模式、操作前确认、Hooks 自动化约束——这些机制的底层都承认同一个事实：AI 一定会犯错，所以系统必须兜底。我特别喜欢这种诚实的设计哲学。一个工具对你越坦白"我可能会错"，你反而越敢用。

所以我的结论是这样：Plan Mode、记忆文件这些功能，别人很快就能有；但上下文管理的深度、模型与 harness 的协同、对失败场景的层层兜底，是需要很多年工程积累才能追上的。这大概就是很多人用了一圈工具、最后还是回到 Claude Code 的原因。

当然，也要公平地说一句：它的门槛是真实存在的。要用命令行，要付费（订阅或者 API 按量计费），网络环境也需要自己解决。如果你平时几乎不碰终端，上手的第一周会有点辛苦，熬过去就好了。

三、安装：五分钟就好

装之前确认电脑里有 Node.js（建议 18 以上的版本），然后一行命令：

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

装好之后，进入你的项目目录，启动：

cd my-project
claude

第一次启动会引导你登录授权。完成之后，就能看到一个对话界面，可以开始说话了。

如果中途遇到什么问题，先跑一下诊断命令：

claude doctor

我自己的经验是，新手碰到的问题大多逃不出两类：Node 版本太旧，或者全局安装权限装坏了。前者升级 Node 就好，后者干脆卸载重装，比重装系统快多了。

四、第一次完整体验：做一个待办事项 App

光说不练总觉得差点意思。下面带你走一遍我第一次用 Claude Code 完整做东西的过程——一个待办事项 Web App。整个过程中，我一行代码都没写。

第 1 步：描述需求

启动 claude 之后，我直接输入：

帮我创建一个待办事项 Web App，要求：
1. 使用 React + TypeScript + Tailwind CSS，用 Vite 构建
2. 支持添加、完成、删除待办事项
3. 支持按优先级（高/中/低）分类，不同优先级不同颜色
4. 数据保存在 localStorage，刷新不丢失
5. 深色主题，手机上也要能用

你可以留意一下这个写法。我没有只说"做个待办事项 App"，而是把技术栈、功能点、边界条件都列清楚了。这是我在 vibe coding 里学到的最重要的一件事：AI 输出的上限，往往就是你需求描述的质量。你说得含糊，它就只能自由发挥，而自由发挥的结果，通常和你想要的相去甚远。

第 2 步：安静地看着它干活

接下来 Claude Code 开始自主执行。我能看到它：

• 检查环境里有没有 Node.js

• 跑 npm create vite@latest todo-app -- --template react-ts 初始化项目

• 安装 Tailwind 等依赖

• 创建 TodoList.tsx、TodoItem.tsx、AddTodo.tsx 这些组件

• 写状态管理和 localStorage 持久化逻辑

• 最后启动开发服务器

每做一个需要权限的操作（比如写文件、跑命令），它都会先问我同不同意。这一点对新手特别温柔，你可以清楚地看到它每一步要做什么，觉得不对劲随时喊停。

第 3 步：用自然语言慢慢打磨

初版跑起来之后，界面能用，但比较素。我继续对它说：

不错，做几个改进：
1. 完成待办时加一个划线动画
2. 顶部加一个统计栏，显示"已完成 X/Y 项"
3. 支持拖拽排序

它理解完就接着改了。改拖拽排序的时候出了个小 bug：拖完的顺序没有保存下来，刷新页面就还原了。我没有自己去翻代码，而是直接把看到的现象告诉它："拖拽排序之后刷新页面，顺序会还原，帮我看看。"它自己定位到是拖拽回调里漏了持久化调用，顺手修好了。

这个小插曲让我明白了一件事：给 AI 报 bug 的时候，描述你看到的现象，比猜测原因更有用。你说"刷新后顺序还原"，它就很好查；你说"是不是状态管理有问题"，反而可能把它带偏。这和我们给同事报 bug 的道理，其实是一样的。

第 4 步：收尾

帮我给核心逻辑写几个单元测试，然后把代码规整一下，多余的注释删掉

从打开终端，到一个能跑、带测试的 App，全程大概二十来分钟。第一次体验完，我的感受有点复杂：一边觉得上头，一边又隐隐不安——这么多代码出自我之外的地方，我真的"拥有"它吗？这个心态问题很值得聊，后面我会专门写一篇。

五、第一周踩过的坑

这部分都是我自己付过学费的，希望你能绕开。

坑 1：需求一句话，返工两小时。 我一开始图省事，只说"帮我做个记账页面"，结果它自己定了技术栈、配色和数据结构，做完和我想要的完全是两码事。后来改成列清单式的描述，一次到位率明显高了很多。

坑 2：没有 commit，就让 AI 继续改。 有一次它改了十几个文件，把项目改崩了，我想回退，才发现上一个能跑的版本根本没提交，只能一点一点手动撤回来。从那以后我养成了一个习惯：每次 AI 改出一个能用的状态，立刻 git commit。几乎所有老手都会叮嘱这一条。现在我还学会了直接让它自己提交：

帮我 commit 一下当前的改动

坑 3：长对话聊到后面，它会慢慢"失忆"。 对话太长之后，它会忘记前面定下的约定——比如我说过"不要用 any 类型"，聊了几十轮之后，any 又悄悄出现了。解法有两个：定期用 /clear 或 /compact 整理上下文；把硬性的规矩写进 CLAUDE.md，那个文件每次对话都会带上，它想忘也忘不掉。

坑 4：AI 有时候会过度乐观。 有几次测试明明没跑过，它却告诉我"全部完成了"。现在我的做法是，让它宣称完成时必须拿出证据，比如把测试运行的结果贴出来给我看。信任当然要有，但验证也不能少——对 AI 尤其如此。

六、这篇的小结

第一篇写了这么多，核心的意思其实就四句话：

1. Vibe coding 是把"怎么写"交给 AI，把"要什么、对不对"留给自己。判断力这件事，比以前更重要了。

2. Claude Code 真正的护城河在 harness：上下文管理的深度、模型与 harness 的协同设计、对失败的层层兜底。功能会被抄走，工程积累抄不走。

3. 需求描述决定输出质量，列清单比写散文管用。

4. 勤 commit，防失忆，对 AI 的"完成了"保持一点温柔的怀疑。

七、下一篇预告

下一篇想写 CLAUDE.md，这是我自己的 vibe coding 从"随便聊聊"走向"稳定可控"的分水岭。我会把项目里实际在用的 CLAUDE.md 贴出来，讲每一段为什么这么写，以及几个写不好反而帮倒忙的反例。

---

参考资料：

• Claude Code 官方文档：https://docs.anthropic.com/en/docs/claude-code

• 从 Claude Code 看 Harness Engineering：2026 年 Agent 真正拉开差距的地方：https://juejin.cn/post/7641794682347765779

• 看看 Claude Code 怎么做 Harness，这才是 Agent 工程化的真正难点（智源社区）：看看 Claude Code 怎么做 Harness，这才是 Agent 工程化的真正难点 - 智源社区

• 为什么 2026 年我们要拼 Harness（JavaGuide）：为什么 2026 年我们要拼 Harness？ | 二哥的Java进阶之路