Vibe Coding实战：Cursor与Claude Code组合驱动全栈开发工作流

很多人第一次听到 Vibe Coding 这个词，第一反应往往是两个极端：要么觉得“以后程序员不用写代码了”，要么觉得“AI 写出来的代码根本不能上生产”。这两种判断都有偏差。Vibe Coding 真正改变的不是“写不写代码”，而是“你用什么样的方式去驱动代码生成、验证和交付”。如果只把它理解为“让 AI 随便写写”，那等于把一台数控机床当成了电风扇用。

这篇文章要讲的，是一套能直接落地的 AI 全栈开发工作流：用 Cursor 承担编辑器内的持续编码，用 Claude Code 承担项目级的任务执行，再配合一组有效的提示词和工程约束，把从需求到前后端联调再到运行验证的完整链路打通。读完你能跑通一个全栈示例项目，也能理解为什么这两款工具不是替代关系，而是互补关系。

1. Vibe Coding 到底解决什么问题

先给 Vibe Coding 一个不算严格但足够实用的定义：它是一种“用自然语言描述意图，用 AI 生成代码，由人来审查、验证和修正”的开发方式。名字里的 Vibe 指的是“状态”和“意图”，不是“随便”和“糊弄”。它和传统写代码最大的区别，不是键盘敲得少了，而是你的工作重心从“怎么实现”转移到了“实现什么、怎么验收、哪里容易错”。

传统开发流程大概是这样的：

• 需求评审，产出 PRD。
• 架构设计，产出技术方案。
• 编码实现，写 Controller、Service、DAO。
• 自测，修 Bug，联调，提测。
• 上线后发现还有问题，继续循环。

在 Vibe Coding 流程里，有些环节没有消失，但顺序和粒度变了。你不再需要先花很长时间把方案文档写到滴水不漏，而是可以先把目标说清楚，给出关键约束和验收标准，让 AI 先生成第一版可运行的代码，然后你基于运行结果去调整。这里的关键词是“可运行的代码”。AI 生成的代码如果不能跑，那它只是一堆漂亮的文本；如果第一步不是“让项目跑起来”，后面所有优化都没有讨论基础。

它真正解决的痛点是三类：

第一，从零到一启动项目的成本。以前要搭建一个前后端分离的项目，需要手动处理脚手架、目录结构、依赖版本、跨域配置、数据库连接。这些工作不是不会做，而是重复且低价值。AI 可以在几分钟内生成一个结构完整的初始项目，你把精力留在业务逻辑上。

第二，跨技术栈的学习门槛。如果你熟悉后端但不熟悉 React 的状态管理，或者熟悉前端但对 Node 服务端不太熟，Vibe Coding 能让你快速跨过“Hello World 级”的陌生感，生成可用代码后再去读、去改、去理解。它不能替代深入学习，但能大大压缩“从零到能动手改”的周期。

第三，需求层面的快速验证。很多需求其实在写出来之前，你自己也没想清楚最终效果。与其花一天做详细设计，不如用 20 分钟让 AI 生成一个粗糙但真实可用的原型，然后对着原型调整。AI 的价值在这个阶段不是“一次写对”，而是“快速产生一个可以讨论的对象”。

但注意，Vibe Coding 不适合解决所有问题。它适合逻辑相对清晰、边界明确、可以用文本准确描述的任务；它不太适合那种隐含大量业务规则、需要多年领域经验才能判断对错的核心系统。AI 可以帮你写支付回调的代码框架，但支付状态的最终正确性，依然需要人去设计、评审和测试。

2. Cursor 和 Claude Code：不是替代关系，而是工作流的两端

很多人在选型时会纠结：Cursor 和 Claude Code 到底选哪个？实际用下来你会发现，这个问题问错了。它们处于 AI 编程工作流的不同位置。

Cursor 是 AI 优先的编辑器（IDE）。它本质上是 VS Code 的一个分支产品，最核心的特点是深度集成了 AI 对话、代码补全、代码修改、跨文件理解和终端联动。适合的场景是“在编辑器里持续编程”：你一边看代码、一边写需求、一边让 AI 修改当前文件或相关文件。它的模型能力和编辑器上下文结合得比较紧，能感知当前打开的文件、选中区域和项目结构。对于前端开发、库函数调用的即时补全、单文件重构这类任务，Cursor 非常顺手。

Claude Code 更像是一个命令行里的 AI Agent（代理）。它不是编辑器，而是在终端里运行的智能体。它会读项目结构、搜索代码、读取文件、执行命令，然后基于整个项目上下文去完成一个比较大的任务。比如“帮我把这个模块从 callback 改成 async/await，并跑测试确认不破坏现有逻辑”，这类跨文件、需要真正执行命令的任务，是 Claude Code 的主场。它不关心你用的是哪个编辑器，只要项目能被命令行访问，它就能干活。

以一个全栈项目为例，典型的分工方式大概是：

这个表格背后有一个判断：Cursor 更适合“以文件为单位”的编程，Claude Code 更适合“以任务为单位”的编程。你完全可以在 Cursor 里写代码，遇到跨文件任务时切换到终端使用 Claude Code；也可以在 Claude Code 里完成大任务后，回到 Cursor 里逐文件审查结果。

除了 Cursor 和 Claude Code，你很可能还听说过 “Codex CLI ”、“Gemini CLI”之类的 AI 编程工具。它们的基本思路是类似的，都是让 AI 通过命令行理解项目、执行任务。这篇文章以 Cursor 和 Claude Code 为组合，是因为它们分别代表了“编辑器内 AI”和“Agent 式编程”两类最有代表性的实践，两者组合出来的工作流，可以无缝迁移到其他同类工具上。

3. 环境准备：从安装到第一次跑通

实操之前先确认环境。这里的版本细节请以你实际安装时的情况为准，重点在于理解每一步在做什么。

3.1 基础环境要求

• 操作系统：Windows / macOS / Linux 都可以，但终端命令会有差异。
• Node.js：建议安装 Node.js 18 或更高版本。全栈项目需要 npm，Claude Code 也依赖 Node.js。
• Git：用于版本管理和查看改动。
• 一个能访问 Claude 模型的有效凭据（例如 Claude 订阅，或 Anthropic API 密钥）。具体获取方式请以官方文档为准。
• 可选：Docker，用于隔离数据库或 Redis 等依赖服务。

3.2 安装 Cursor

从官网下载对应系统的安装包。安装后它会引导你导入 VS Code 扩展和配置。如果你是 VS Code 用户，第一次打开时几乎可以无缝过渡。Cursor 支持导入你已有的settings.json、快捷键和扩展，这一点对老用户很重要。

第一次启动后，建议先做一个配置动作：确认你自己的语言习惯。如果你希望 AI 用中文回答问题，可以在 Cursor 的对话窗口里直接说“后续请用中文回答”；不同版本对中文的支持方式不同，以实际界面为准。

关于“Cursor 汉化”和“Cursor 设置中文”这类高频问题，简单说一下：Cursor 本身是英文界面为主，但你可以通过以下方式提高中文使用体验：

• 对话时明确要求 AI 用中文回答。
• 在 AI 规则 / 自定义指令配置中写一条“Always respond in Chinese”。
• 安装中文语言包或自定义界面翻译插件，但注意这不会影响 AI 模型的生成质量。

3.3 安装 Claude Code

Claude Code 通过 npm 全局安装。打开终端，执行：

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

安装完成后确认版本：

claude --version

如果 npm 全局安装目录不在系统的 PATH 里，需要配置环境变量。Linux/macOS 可以检查 npm 的 bin 目录：

npm bin -g

然后把该目录加入 PATH。

3.4 初始化和认证

在项目根目录运行：

claude

第一次运行会引导你进行身份认证。如果使用 Claude 订阅账号，需要完成登录授权；如果使用 API 密钥，需要在登录时选择 API Key 方式并填入密钥。这里有一个必须提醒的安全点：不要把 API 密钥写进项目代码或提交到 Git 仓库。建议把密钥放在环境变量中，例如：

export ANTHROPIC_API_KEY="你的密钥"

在 Windows PowerShell 中对应的写法是：

$env:ANTHROPIC_API_KEY="你的密钥"

认证成功之后，你会在终端看到一个交互式输入框，这表示 Claude Code 已经可以读取你的项目目录并开始工作。

3.5 建立最小测试项目

为了快速验证整套工具可用，新建一个测试目录：

mkdir vibe-demo cd vibe-demo git init

然后在 Cursor 中打开这个目录，再在终端运行claude，进入 Claude Code 交互界面后输入一句最简单的指令：

在这个目录里创建一个 package.json，然后告诉我下一步可以做什么。

如果两个工具都正常响应，说明环境已经就绪。接下来我们用一个真正的全栈项目来跑通完整流程。

4. 工作流设计：从需求到提示词的拆解

全栈开发中使用 AI 编程，最大的坑不是 AI 能力不够，而是你的“需求描述”和“验证方式”没有设计好。很多人抱怨 AI 写出来的代码不能用，其实换一个角度看，是“你让它造的并不是你真正想要的东西”。

所以，在写任何提示词之前，建议先建立一个工作流框架：

1. 目标（Goal）：这个任务最终要交付什么？是“一个能增删改查的待办事项页面”，还是一套完整的“前后端认证系统”？
2. 约束（Constraints）：技术栈是什么？用哪个框架？数据存哪里？要不要权限控制？
3. 验收（Acceptance Criteria）：用户操作完哪个动作后，系统应该出现什么结果？用哪些命令可以验证？
4. 禁止项（Forbidden）：哪些事情不能做？比如“不要把数据库连接密码写进代码”“不要修改已有的登录逻辑”。

框架有了，提示词才不会变成“一句含糊的愿望”。比如你只说“帮我写一个 todo 应用”，AI 可能会用各种技术栈写一个和你的项目完全不同的东西。但如果你说：

在当前项目里创建一个全栈待办事项应用。 技术栈：前端用 React + Vite，后端用 Node.js + Express，数据用 JSON 文件存储。 功能要求： - 用户可以添加待办事项 - 用户可以标记待办事项为已完成 - 用户可以删除待办事项 - 页面刷新后数据不丢失 验收标准： - 运行 npm run dev 能同时启动前后端 - 浏览器打开 http://localhost:5173 可以完成添加、勾选、删除操作 - 重启服务后数据仍然存在 约束： - 不要引入数据库 - 不要引入 UI 组件库 - 代码保持简洁，优先使用函数组件和 Hooks

这段描述之所以比“写一个 todo 应用”更有效，是因为它包含了技术栈、功能点、验收方式和约束条件。AI 生成代码后，你不需要“猜”它做了什么，而是可以直接验证。

在实际项目中，你不需要每次都写这么长。如果你是第一次使用某个项目，或者 AI 对这个代码库不熟悉，第一次的提示词要尽可能详细；等 AI 逐渐理解项目结构之后，后续任务可以用更短的描述，比如“参照现有 crud 接口的写法，给用户模块加一个导出 Excel 的接口”。

这里提一下 Vibe Coding 和 Spec-Driven 的关系。Vibe Coding 强调快速生成和迭代，Spec-Driven（规格驱动开发）则强调在写代码之前先把行为规格明确，比如输入、输出、错误处理、边界条件。两者不是对立关系。更好的实践是：在一个任务的粒度上使用 Vibe Coding 的快速迭代，在核心业务规则上使用 Spec-Driven 的思路来约束。全栈开发中，你不可能只靠感觉就把支付状态机写对，但你可以用感觉快速生成一个原型，再用规格把核心逻辑补严。

5. 全栈实战：用 Cursor + Claude Code 完成待办事项应用

现在进入核心部分。我们来实现一个最小但完整的全栈待办事项应用，前端用 React + Vite，后端用 Node.js + Express，数据用 JSON 文件持久化。

这个项目的完整代码并不复杂，但可以用来演示一个真实的关键能力：AI 不是只生成单个文件，而是能跨前后端完成一整套功能。这也是全栈开发场景中对 AI 编程工具真正的考验。

5.1 先让 Claude Code 初始化项目结构

在项目根目录的终端中，进入 Claude Code 交互界面：

claude

输入第一轮指令：

我要在当前目录创建一个全栈待办事项应用。 请帮我： 1. 用 Vite 创建 React 前端项目结构 2. 用 Express 创建后端服务 3. 在根目录创建 README.md 说明启动方式 4. 不要安装额外依赖，只生成项目文件

这里特意加了“不要安装额外依赖”，是为了让 AI 先生成文件，安装动作由你自己控制在确认依赖列表之后。如果 AI 的执行涉及到自动执行命令，Claude Code 会请求你的权限。建议第一次运行时选择允许，但认真看每一条要执行的命令。

AI 完成后，项目结构大致会变成这样：

vibe-demo/ ├── README.md ├── client/ # 前端 React 项目 │ ├── package.json │ ├── vite.config.js │ └── src/ │ ├── main.jsx │ └── App.jsx └── server/ # 后端 Express 项目 ├── package.json └── index.js

这个阶段的成果是“一个骨架”，你不需要一步到位，先把结构确认清楚。

5.2 编写后端 API

在第二轮对话中，让 AI 完成后端功能：

请完成后端服务代码。 要求： - 提供 GET /api/todos 返回所有待办事项 - 提供 POST /api/todos 创建待办事项 - 提供 PUT /api/todos/:id 切换完成状态 - 提供 DELETE /api/todos/:id 删除待办事项 - 使用 JSON 文件存储数据，文件路径为 server/data/todos.json - 如果 data 目录或文件不存在，自动创建 - 添加 CORS，允许前端开发服务器访问 - 端口使用 3001

完成后，server/index.js的代码类似这样：

// server/index.js const express = require('express'); const fs = require('fs'); const path = require('path'); const cors = require('cors'); const app = express(); const PORT = 3001; const DATA_DIR = path.join(__dirname, 'data'); const DATA_FILE = path.join(DATA_DIR, 'todos.json'); app.use(cors()); app.use(express.json()); function readTodos() { if (!fs.existsSync(DATA_FILE)) { return []; } const content = fs.readFileSync(DATA_FILE, 'utf-8'); return JSON.parse(content || '[]'); } function writeTodos(todos) { if (!fs.existsSync(DATA_DIR)) { fs.mkdirSync(DATA_DIR, { recursive: true }); } fs.writeFileSync(DATA_FILE, JSON.stringify(todos, null, 2)); } app.get('/api/todos', (req, res) => { res.json(readTodos()); }); app.post('/api/todos', (req, res) => { const { title } = req.body; if (!title) { return res.status(400).json({ error: 'title is required' }); } const todos = readTodos(); const todo = { id: Date.now().toString(), title, completed: false, createdAt: new Date().toISOString() }; todos.push(todo); writeTodos(todos); res.status(201).json(todo); }); app.put('/api/todos/:id', (req, res) => { const todos = readTodos(); const todo = todos.find(t => t.id === req.params.id); if (!todo) { return res.status(404).json({ error: 'todo not found' }); } todo.completed = !todo.completed; writeTodos(todos); res.json(todo); }); app.delete('/api/todos/:id', (req, res) => { const todos = readTodos(); const filtered = todos.filter(t => t.id !== req.params.id); writeTodos(filtered); res.json({ success: true }); }); app.listen(PORT, () => { console.log(`Server running at http://localhost:${PORT}`); });

这里有几个值得注意的设计：

• 用Date.now().toString()做 id，虽然简单，但在本地项目中完全够用；如果你想支持多人并发和更可靠的唯一性，可以用crypto.randomUUID()。
• readTodos和writeTodos两个函数把数据读写集中封装，后续要切换成 MySQL 或 MongoDB，只需要替换这两个函数。
• 请求体校验只做了“title 是否存在”的检查，这只是基础校验，生产环境还需要处理字段类型、长度限制等问题。

如果 AI 没有自动创建server/package.json，你需要手动确认它包含相关依赖：

{ "name": "server", "version": "1.0.0", "main": "index.js", "scripts": { "start": "node index.js", "dev": "node --watch index.js" }, "dependencies": { "cors": "^2.8.5", "express": "^4.19.2" } }

然后安装依赖并启动：

cd server npm install npm run dev

后端没有启动日志中的报错，说明第一步成功。可以用 curl 验证：

curl http://localhost:3001/api/todos

预期输出是一个空数组：

[]

5.3 编写前端页面

回到 Claude Code，继续输入前端要求：

请完成前端 React 页面： - 使用函数组件和 Hooks - 页面展示待办事项列表 - 顶部有一个输入框和“添加”按钮 - 每个待办事项右侧有一个“完成”按钮和一个“删除”按钮 - 完成状态的行显示删除线 - 页面加载时从 GET /api/todos 获取数据 - 添加、切换、删除操作分别调用对应 API - 使用 fetch，不要引入 axios

完成后，client/src/App.jsx会类似这样：

// client/src/App.jsx import { useEffect, useState } from 'react'; const API_BASE = 'http://localhost:3001/api'; function App() { const [todos, setTodos] = useState([]); const [title, setTitle] = useState(''); async function fetchTodos() { const res = await fetch(`${API_BASE}/todos`); const data = await res.json(); setTodos(data); } async function addTodo() { if (!title.trim()) return; await fetch(`${API_BASE}/todos`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ title }) }); setTitle(''); fetchTodos(); } async function toggleTodo(id) { await fetch(`${API_BASE}/todos/${id}`, { method: 'PUT' }); fetchTodos(); } async function deleteTodo(id) { await fetch(`${API_BASE}/todos/${id}`, { method: 'DELETE' }); fetchTodos(); } useEffect(() => { fetchTodos(); }, []); return ( <div style={{ maxWidth: 500, margin: '50px auto', fontFamily: 'system-ui' }}> <h1>待办事项</h1> <div> <input value={title} onChange={e => setTitle(e.target.value)} onKeyDown={e => e.key === 'Enter' && addTodo()} placeholder="输入待办事项" style={{ padding: 8, width: 300 }} /> <button onClick={addTodo} style={{ padding: 8, marginLeft: 8 }}> 添加 </button> </div> <ul style={{ listStyle: 'none', padding: 0 }}> {todos.map(todo => ( <li key={todo.id} style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'center', padding: '12px 0', borderBottom: '1px solid #eee' }} > <span style={{ textDecoration: todo.completed ? 'line-through' : 'none', color: todo.completed ? '#999' : '#333' }} > {todo.title} </span> <div> <button onClick={() => toggleTodo(todo.id)} style={{ marginRight: 6 }}> {todo.completed ? '取消完成' : '完成'} </button> <button onClick={() => deleteTodo(todo.id)}>删除</button> </div> </li> ))} </ul> </div> ); } export default App;

前端代码的关键点：

• 所有操作完成后都重新调用fetchTodos拉取最新列表。这种方式简单直观，适合数据量小的场景；如果数据量大、操作频繁，可以考虑在本地直接更新 state，减少不必要请求。
• API_BASE写的是固定地址，这在本地开发没有问题。但生产环境的前后端一般部署在同域或用 Nginx 做反向代理，建议改成相对路径/api，由服务端代理转发。
• 样式是内联样式，目的是让示例足够短，去掉 CSS 文件依赖。真实项目中不建议大规模使用内联样式。

安装前端依赖并启动：

cd client npm install npm run dev

Vite 默认端口是 5173，启动后浏览器访问http://localhost:5173。

5.4 用 Claude Code 修复和联调

到了这一步，大概率会发生下面某一种情况：

• 后端启动时报错，某个依赖缺失。
• 前端控制台报跨域错误。
• 数据添加成功后列表不刷新。

这就是 Claude Code 最有价值的场景。你可以直接把控制台的错误信息复制给它，例如：

前端页面点击“添加”按钮后，控制台报错如下： Access to fetch at 'http://localhost:3001/api/todos' from origin 'http://localhost:5173' has been blocked by CORS policy. 请检查后端 CORS 配置并修复。

Claude Code 会读取后端文件，分析 CORS 配置，然后给出修复方案或直接修改代码。注意：它可能会直接调用命令重启服务，你需要确认它执行的每一条命令。

真实项目中大量时间消耗在“报错信息 → 理解原因 → 定位文件 → 修改 → 重启验证”这个循环里。Claude Code 把循环中“理解原因和定位文件”这一步大大压缩了，剩下的验证还得你自己盯着。

5.5 数据持久化验证

完成上述步骤后，做数据持久化验证：

cd server npm run dev

浏览器中添加两条待办事项，然后按Ctrl + C停掉服务，再重新启动。你会发现数据还在，因为它已经被写入了server/data/todos.json。

查看一下这个文件：

cat server/data/todos.json

内容是格式化后的 JSON 数组。这就是在最简实现中“重启不丢数据”的验证方式。

6. 运行结果与效果验证

一个全栈项目跑通后，不要急着说“完成了”。建议建立一个标准的验证清单，把“能跑”变成“能确认跑对了”。

6.1 功能验证

6.2 接口验证

如果你想单独验证后端接口，不需要经过前端页面，直接用 curl：

curl http://localhost:3001/api/todos curl -X POST http://localhost:3001/api/todos \ -H "Content-Type: application/json" \ -d '{"title":"用 curl 添加的待办"}'

6.3 如何判断是否成功

判断标准不是“页面能打开”，而是“用户完整走完一个闭环之后，数据状态符合预期”。上面表格中的每一项，都要能稳定复现。如果某些操作时好时坏，多半是竞态问题，比如前端在fetchTodos还没返回时又发起了下一次请求，或者在服务端数据读写时出现了并发覆盖。

7. 常见问题与排查方法

AI 生成代码并不总是完美的，尤其是把前后端串起来的时候，很容易踩到下面这些坑。

7.1 排查顺序建议

遇到全栈联调问题，我建议按下面的顺序排查，不要上来就改代码：

1. 先看后端日志：服务有没有收到请求？有没有抛出异常？
2. 再看浏览器控制台：是网络错误还是 JS 运行时错误？
3. 用 curl 单独测接口：绕过前端，确认接口本身是否正常。
4. 检查网络请求的 URL：是不是端口、路径写错了？
5. 最后才怀疑 AI 生成的逻辑：打印关键数据，逐步确认。

很多时候问题不在 AI，而在于本地环境、端口占用或命令执行失败。

8. 最佳实践与工程建议

工具再好用，如果使用方式不约束，项目最终还是会乱。下面这些建议是基于实际工程经验的总结，希望你在使用 AI 编程时能少走弯路。

8.1 提示词要面向“验收”，而不是面向“愿望”

写提示词时，多想想“我如何验证它完成了”。一句“写一个用户登录”太模糊；一段“用户提交用户名密码后，验证数据库匹配，匹配则返回 token，不匹配返回 401，并在响应体里包含错误信息”就有明确验收点。AI 真正需要的不是你对产品的愿望，而是你对行为的具体描述。

8.2 让 AI 小步提交，不要一次性生成巨型功能

一个常见的失败模式是：“帮我实现整个电商系统”。AI 要么生成一个结构复杂但漏洞百出的骨架，要么根本执行不下去。更稳妥的做法是把任务拆成可独立验证的步骤：先做商品列表接口，再做商品详情，再做购物车。

在你给 AI 下任务时，也可以主动强调“分步完成”。例如：

请分步骤完成这个功能。第一步先完成后端接口，完成后再告诉我下一步怎么验证。

8.3 一定要查看 AI 生成的 diff

Claude Code 和 Cursor 都会以 diff 的形式展示修改内容。不要直接点“全部接受”。每一处修改都要过一遍，尤其是：

• 是否有删除你本来要保留的逻辑？
• 有没有引入新的依赖？版本是否合理？
• 有没有把密码、密钥、敏感路径写进代码？
• 是否有明显不符合项目既有风格的地方？

AI 生成代码时，对“现有代码”的理解可能不完整，有时会产生破坏性修改。把它当成一个“速度快但需要复核的实习生”，会是比较贴切的定位。

8.4 用版本控制兜底

在每次让 AI 执行较大任务之前，先确保当前代码已提交：

git add . git commit -m "chore: 完成待办事项应用基础版本"

这样就算 AI 把代码改坏了，你也可以随时回滚。回滚操作本身也能成为 AI 工作流的一部分——直接告诉 Claude Code “请把上一次提交后的修改全部撤销”，它能理解你的意思并执行。

8.5 不要让 AI 直接操作生产环境

AI 编程工具应该被限制在开发环境或测试环境中。涉及生产环境配置、数据库变更、密钥轮换等高风险操作，建议不要让 AI 直接执行。你可以让它生成命令，但执行和审批由人来做。

更需要警惕的是：不要把生产数据库的密码、云服务的 Secret Key 直接放在项目根目录的.env文件里，然后让 AI 去读取。一旦 AI 把文件内容写入对话记录或日志，就是一次信息泄露。

8.6 打造自己的 AI 规则文件

Cursor 支持自定义指令（Custom Instructions），Claude Code 也支持CLAUDE.md这样的项目记忆文件。这是一个很值得投入的习惯。

你可以在项目根目录创建一个CLAUDE.md，内容类似于：

# 项目规范 - 本项目使用 JavaScript，不使用 TypeScript - 后端使用 Express，前端使用 React + Vite - 所有日期字段使用 ISO 8601 格式 - 接口错误统一返回 { error: string } 结构 - 修改代码前先说明修改计划，再执行 - 不要删除未提及的代码和文件

这样每次 AI 读取项目时，都会把这些约束当作背景知识。你会发现，后续对话质量会有明显提升，AI 不会反复问你已经说过的基础问题。

Cursor 的规则设置通常可以在设置面板中找到“AI Rules”或“Custom Instructions”入口，把同样内容填进去即可。这套“项目级记忆 + 全局规则”的组合，会让你在多个项目之间切换时保持稳定一致的 AI 行为。

8.7 从 Vibe Coding 走向 Harness 和 SDD

如果你对 AI 编程的探索止步于“让 AI 写个列表页”，那它对你的价值还很有限。再往前走一步，值得了解两个概念：

• Harness：可以理解为给 AI 套上的一层“工程缰绳”，包括权限控制、文件白名单、命令允许列表、自动测试、评审流程等。它的核心不是限制 AI，而是让 AI 的行为可预测、可控制。
• SDD（Spec-Driven Development，规格驱动开发）：在写代码前先定义行为的输入、输出、错误分支和边界条件。它和 Vibe Coding 并不冲突，而是互补。用 Vibe Coding 快速搭建原型，用 SDD 把核心逻辑的规格写清楚，再让 AI 按规格修正。

对个人开发者来说，从“随机对话式编程”升级到“结构化任务式编程”，是最值得花时间的方向。你可以先从维护一个CLAUDE.md开始，再逐步为关键模块补充规格文档，最后把测试命令纳入每次 AI 任务的验收标准。

9. 一次全栈 AI 协作的真实体验

回到文章开头的问题：Vibe Coding 到底可不可靠？如果把“可靠”定义为“完全不用看代码就能上线”，那答案是不可靠。但如果把“可靠”定义为“在一个明确的约束和验收框架下，让 AI 完成大量重复而繁琐的编码工作，最后由人来审核关键逻辑”，那它完全可靠，而且效率提升明显。

在这套 Cursor + Claude Code 的组合中，最值得掌握的不是某一条具体命令，而是分工思维：

• 编辑器内的连续编程交给 Cursor，享受即时补全和上下文唤起的流畅。
• 项目级的跨文件任务交给 Claude Code，让 Agent 帮你搜索、修改、执行和验证。
• 人负责定义目标、审核 diff、控制安全和判断业务正确性。

这三层职责区分清楚之后，AI 编程的能力边界和你的掌控边界也就都清晰了。

如果你想让这套工作流真正变成自己的习惯，建议不要只做“看完就算了”的读者，而是现在就动手执行：建一个空项目，装上 Cursor 和 Claude Code，把上面那个待办事项应用从零写一遍，然后尝试自己加一个新功能。比如给待办事项加一个截止时间字段，并支持按截止时间排序。你会在这个过程里体会到“用自然语言驱动代码”的真正感觉。

继续往下走的方向也很明确：一是研究 Harness 和权限控制，让 AI 可以在更接近生产环境的条件下安全地工作；二是学习 SDD，把你项目中的核心业务规则从“大概意思”变成“可验证的规格”；三是关注 MCP（Model Context Protocol）这类让 AI 连接外部数据源和工具的标准，你会发现 AI 编程的边界正在从“写代码”往“操作系统”方向延伸。工具迭代很快，但“定义目标、约束 AI、审查结果、持续改进”这套方法论不会过时。