12.1 项目起手势

从一句话开始

打开终端，cd 到你存放项目的目录，然后输入：

claude

Claude Code 启动后，你的第一条指令可以很简单：

"我想做一个 MP3 音频可视化应用，HTML5 项目，帮我创建项目骨架。"

然后，看它干活。

你会看到 Claude Code 开始创建文件：一个 index.html、一个 style.css、一个 app.js。它可能还会问你要不要初始化 npm 或者安装一些依赖。别担心——它每做一步都会告诉你。

AI 可能会反问的问题：

有时候 Claude Code 不会直接执行，而是会反问一些澄清问题：

• "你希望用 CDN 引入外部库，还是全部用原生 Web API？"
• "是否需要支持拖拽上传 MP3 文件？"
• "项目是否需要 npm 初始化？"

这些反问不是"麻烦"，而是 AI 在帮你补全你没说清楚的信息。你不需要一次性回答所有问题——你只需要回答当前能回答的。"全部用原生 API，不需要 npm 初始化，拖拽功能后续再加"——AI 就会按这个方向执行。

初始化的结果

几秒钟后，你会在项目目录中看到类似这样的结构：

mp3-visualization/
├── index.html
├── style.css
├── app.js
└── .gitignore

这就是你的项目骨架。是的，从零到三个文件，只用了一句话。

如果你想要不同的项目类型，指令也可以不同：

• "创建一个 React + Vite 项目，用于 mp3 可视化" → AI 会用 Vite 脚手架初始化
• "创建一个 Next.js 项目，用于音频工具集" → AI 运行 create-next-app
• "创建一个 Python Flask 项目，用于音频处理" → AI 创建 Python 项目结构

不同的指令会触发不同的初始化方式。但核心逻辑一样——你说了，AI 做了。

检查 AI 做了什么

在继续之前，花 30 秒看看 AI 生成的初始代码。不是要你读懂每一行——而是建立一种习惯：AI 生成后，你先看一眼。

打开 index.html，确认它引用了 style.css 和 app.js。打开 app.js，看看里面是不是有一个基本的音频上下文（AudioContext）创建代码。对于初学者来说，你只需要确认结构合理即可。

这里有几个简单的检查点：

1. 文件都在吗？ 骨架包含的文件数量和预期一致吗？
2. 引用正确吗？ index.html 中 link 和 script 的路径指向了正确的位置吗？
3. 代码不是空的吗？ js 文件不是空的——至少有一段有意义的代码。

你不需要"审查"代码的正确性——只是"看一眼"而已。如果你发现文件结构明显不对（比如缺少了 css 文件），直接告诉 AI 修复。

为什么要先创建骨架，而不是一次性生成全部功能

你可能想问：为什么不直接说"帮我生成一个完整的 MP3 可视化应用"？

原因有两个：

第一，一次性生成全部功能，AI 容易在中途偏离方向。 如果 AI 一次生成太多代码，它可能在过程中"忘了"你最初的要求，或者生成的某些部分不符合你的预期，但你很难在大量代码中找到问题。

第二，分步推进让你在每个阶段都有决定权。 骨架 → 布局 → 功能 → 调试 → 部署——每一步你都能说"这里不对，改成那样"。如果你一次性生成全部，回头修改的成本比逐步推进高得多。

骨架的作用就像盖房子之前先搭脚手架——它不是最终产品，但它定义了后面的工作怎么展开。

如果对结果不满意

这是 Vibe Coding 中很常见的情况——AI 第一次给出的不一定完全符合你的想法。没关系，直接说：

"我不想用 CDN 引入外部库，全部用原生 Web API 实现。重新生成。"

或者：

"把项目改成 TypeScript 版本，帮我初始化一个 Vite 项目。"

即时纠偏的能力，比"一次性说对"重要得多。这也是 Vibe Coding 的核心循环：说→看→调→再说。

如果 AI 创建的项目不是你想要的怎么办？ 你有几个选择：

• 让 AI 重来： "这个不符合要求，重新创建一个只包含 index.html、style.css 和 app.js 的纯前端项目。"
• 让 AI 修改现有项目： "把已创建的 Vite 项目改成纯 HTML5 项目，去掉所有构建工具。"
• 你自己先想清楚再开始： 在启动 claude 之前，花 2 分钟想清楚你要用什么技术栈。不一定需要精确到每个工具，但至少确定：纯前端还是全栈？用框架吗？用 TypeScript 吗？

关于 Git 和第一次提交

AI 创建完骨架后，是一个很好的时机做第一次 Git 提交：

"帮我初始化 Git，创建 .gitignore，然后做第一次提交。"

AI 会运行 git init，创建 .gitignore，然后 git add . 和 git commit -m "init: project skeleton"。

为什么要在这个时候做第一次提交？因为这是项目的"干净状态"——骨架已搭好，但还没开始填功能。如果你之后改乱了，随时可以回到这个状态重新开始。

项目骨架的作用

骨架本身不做任何"业务逻辑"，它定义了项目的结构、文件之间的依赖关系、开发服务器的启动方式。有了骨架，后面每一轮迭代你都在"填肉"而不是"搭架子"。

你把骨架描述清楚了，AI 就有了上下文锚点——它知道文件在哪里、结构长什么样、你在用什么技术栈。后续每一次对话，它都不需要重新猜测。

一个形象的类比：骨架就像你做菜前洗好切好的食材。你不需要在炒菜的过程中停下来切葱——食材已经准备好了，你直接开火。骨架就是你项目中的"食材准备"。

这一步的关键

不要花时间想"结构应该怎么设计"。 骨架是可以随时改的。让 AI 先给一个合理的默认结构，你在后续迭代中自然会发现哪里需要调整。这是 Vibe 方式与传统开发方式的一个重要区别——先有，再优。

传统开发中的"设计先行"模式会给你一种错觉：结构想得越清楚，后面写代码越顺利。但在 Vibe Coding 中，这个逻辑不成立了——因为 AI 可以在任何阶段帮你重构结构。你不需要在起点就想好终点在哪里。

一个实用的起步心态： 你现在的目标不是"做一个完美的 App"，而是"做一个能跑的东西"。能在浏览器中打开、能看到一个页面、能点击一个按钮——这就是第一次成功。从那里开始，你再一步步往里面加东西。