Vibe Coding 工具链实战：让 AI 写代码更稳的 15 个工具与配置思路

最近一段时间，很多开发者都在尝试 Vibe Coding，也就是通过自然语言和 AI 编程工具协作，让 AI 帮忙写代码、改 bug、补测试、整理文档，甚至完成一部分功能开发。

但实际用下来会发现一个问题：AI 写代码并不是“说一句需求，然后等它自动完成”。如果项目稍微复杂一点，只靠一句 prompt 很容易出现几个问题：

• 不理解项目结构，改错文件；

• 使用过时 API，生成不能运行的代码；

• 一次性改动太大，后续不好 review；

• 修一个 bug，又引入新的问题；

• 没有跑测试，只是“看起来写完了”。

所以我更倾向于把 Vibe Coding 理解为一种新的开发工作流，而不是单个工具。真正好用的 AI 编码流程，通常需要几层能力配合：

1. 一个能读代码、改文件、跑命令的 Coding Agent；

2. 一份明确的项目说明文件；

3. 一套约束 Agent 行为的规则或 Skills；

4. 足够准确的代码上下文；

5. 必要的调试、测试和 review 流程。

下面整理一批我认为比较值得关注的工具和配置方式，不做排名，主要从实战使用角度说明适合什么场景。

---

一、先选一个主力 Coding Agent

Vibe Coding 的第一层，是选择一个能真正参与开发流程的 Coding Agent。它不只是聊天窗口，而是可以读取项目、修改文件、执行命令，并和你一起完成开发任务。

1. Claude Code

Claude Code 是目前很多人做 AI 编码时会优先尝试的工具之一。它适合放在终端或 IDE 流程里，用来做代码阅读、局部重构、bug 修复、测试补充等任务。

比较适合的用法是：

• 让它先阅读相关文件，不要直接动手改；

• 要求它先给修改计划；

• 每次只改一个小目标；

• 修改后说明改了哪些文件、为什么这么改；

• 最后让它提示需要人工检查的点。

不建议一上来就让它“重构整个项目”或者“一次性实现完整系统”。Agent 能做事，但仍然需要人控制范围。

---

2. Codex CLI

Codex CLI 更适合喜欢终端工作流的开发者。它的使用方式比较直接：在本地项目目录里，让 AI 读取、修改、运行代码。

适合的场景包括：

• 小型工具脚本；

• 单个 bug 修复；

• 给已有项目补 README；

• 给函数补测试；

• 分析报错日志并定位问题。

我的经验是，CLI 类工具更适合“边跑边改”。不要只让它生成代码，还要让它执行测试、查看报错、再继续修。

---

3. Gemini CLI

Gemini CLI 也是终端型 AI Agent，适合做代码库查询、文件修改和自动化任务。它的优势是比较适合和 Google 生态或命令行流程结合。

可以尝试的用法：

# 示例：让 Agent 先理解项目结构
请先阅读项目目录结构，说明主要模块作用，不要修改文件。

# 示例：限定任务范围
只修改 src/api 目录下和订单查询相关的逻辑，不要调整 UI。

这里的重点不是具体工具，而是工作方式：先理解，再计划，再小步修改。

---

4. Aider

Aider 是比较经典的终端 AI pair programming 工具，适合和 Git 配合使用。它比较适合有明确目标的小步开发，比如：

• 修改某个函数；

• 修复一个测试失败；

• 重构一段重复逻辑；

• 解释一组代码变更。

Aider 的一个好处是比较贴近“结对编程”的感觉。你可以明确告诉它哪些文件需要参与上下文，减少它在整个项目里乱找信息。

---

5. Cline / OpenCode / Crush

这类工具可以理解为开源或轻量化的 AI 编程 Agent。它们适合想尝试不同模型、不同 IDE 或终端体验的开发者。

实际选择时，我建议重点看三点：

• 是否能清楚展示它要改什么；

• 是否方便接入项目上下文；

• 是否能配合测试、终端、Git 使用。

如果只是聊天生成代码，不一定适合真实项目。真正进入工程开发，最重要的是可控、可回滚、可验证。

---

二、用 AGENTS.md 给 AI 一份“项目说明书”

很多 AI 写代码翻车，不是模型不会写，而是不知道项目规则。

比如它不知道：

• 项目怎么启动；

• 测试命令是什么；

• 哪些目录不能改；

• 命名风格是什么；

• API 调用规范是什么；

• 提交前要检查哪些内容。

这时可以在项目根目录放一个 AGENTS.md 文件，把这些规则写给 AI Coding Agent 看。可以把它理解为“写给 AI 的 README”。

一个简单示例：

# AGENTS.md

## 项目说明
这是一个前端管理后台项目，主要技术栈是 React + TypeScript。

## 常用命令
- 安装依赖：npm install
- 本地启动：npm run dev
- 运行测试：npm run test
- 代码检查：npm run lint

## 修改规则
- 不要直接修改 package-lock.json，除非明确需要变更依赖。
- 不要改动 public/config 目录下的生产配置。
- 新增接口请求时，优先复用 src/api 中已有封装。
- 修改组件时，需要检查是否影响移动端布局。

## 提交前检查
- 确认 npm run lint 通过。
- 确认相关测试通过。
- 总结修改文件和修改原因。

这类文件的价值不在于写得多，而在于把项目里“开发者默认知道的规则”显性化。AI 不会自动知道你的团队习惯，必须把约束写出来。

---

三、用 CLAUDE.md 约束 Agent 行为

如果主要使用 Claude Code，可以再准备一个 CLAUDE.md。它更偏向于约束 Claude 在项目里的行为方式。

例如：

# CLAUDE.md

## 工作原则
- 在修改代码前，先阅读相关文件并说明理解。
- 对非简单任务，先给出修改计划，再开始动手。
- 每次只围绕一个明确目标修改，不做无关重构。
- 不确定时先提问，不要猜测业务规则。
- 修改完成后，说明改动点、影响范围和需要人工检查的地方。

## 代码修改要求
- 优先做最小修改。
- 不要删除已有注释，除非注释已经明显错误。
- 不要擅自调整目录结构。
- 不要引入新依赖，除非说明必要性。

## 测试要求
- 能跑测试时，优先运行相关测试。
- 测试失败时，先分析失败原因，不要反复盲改。

这种配置的作用，是把 AI 从“积极生成代码”拉回到“谨慎完成任务”。对于真实项目来说，谨慎比速度更重要。

---

四、Superpowers：给 Coding Agent 加一套开发方法论

Superpowers 的思路不是单独生成某段代码，而是给 coding agent 增加一组可组合的 skills，让 Agent 在开发过程中更有章法。

它适合解决的问题是：AI 很会写代码片段，但不一定会按软件工程流程做事。

例如一个比较合理的流程可能是：

1. 先理解需求；

2. 找到相关代码；

3. 写一个小的实现计划；

4. 修改最小范围代码；

5. 补测试或运行已有测试；

6. 做一次 review；

7. 总结改动和风险。

这和普通 prompt 的区别在于，普通 prompt 往往只描述结果，而 skills 会让 Agent 在过程中按步骤行动。

适合使用 Superpowers 的场景：

• 需求不是一两行代码能解决；

• 涉及多个文件；

• 需要拆任务；

• 需要 review 和测试；

• 希望形成比较固定的 AI 编码工作流。

如果只是改一个错别字、补一个简单判断，就没必要上复杂流程。

---

五、andrej-karpathy-skills：用一份 CLAUDE.md 减少常见翻车

andrej-karpathy-skills 本质上是一份面向 Claude Code 的行为指南，目标是减少 LLM coding 中常见的错误。

它比较适合拿来做参考，而不是原样照搬。比如其中一些思路可以提炼成自己的项目规则：

• 不要过早写代码；

• 先理解上下文；

• 保持小步修改；

• 对复杂任务保持谨慎；

• 不要为了完成任务而忽略测试；

• 对不确定的业务逻辑不要擅自猜。

这类规则看起来简单，但非常实用。AI 编码最大的问题往往不是不会写，而是太快动手、太自信、改动范围太大。

---

六、Context7：解决“AI 写旧 API”的问题

AI 写代码时，一个很常见的问题是使用过时 API。

比如前端库、后端框架、SDK 版本变化很快，如果模型记忆里的知识比较旧，就可能生成已经废弃的写法。

Context7 的定位就是把最新的、版本相关的文档和代码示例放进 LLM 上下文。简单来说，它解决的是“AI 参考资料不够新”的问题。

适合场景：

• Next.js、React、Vue、NestJS 等框架升级；

• SDK 版本变化频繁；

• 第三方库 API 不熟；

• 需要根据官方文档写代码；

• AI 经常生成不存在的方法。

使用这类工具时，最好在 prompt 里明确说明：

请优先基于当前版本文档生成代码，不要使用旧版本 API。
如果不确定 API 是否存在，请先查文档再写实现。

这比单纯说“帮我写一个功能”更稳。

---

七、Serena：让 Agent 更懂大型代码库

小项目里，把几个文件发给 AI 就够了。但在中大型项目里，问题会变复杂：

• 函数在哪定义？

• 哪些地方引用了这个方法？

• 改一个类型会影响哪些模块？

• 这个类和其他类是什么关系？

• 应该在什么位置插入代码？

Serena 的价值在于给 AI Agent 提供更接近 IDE 的语义级能力，比如代码检索、编辑、重构、调试等。它不是简单把整个项目塞给模型，而是帮助 Agent 按代码结构理解项目。

适合场景：

• 老项目维护；

• 大型代码库定位问题；

• 多文件重构；

• 需要按符号、引用关系查代码；

• 不希望 AI 只靠全文搜索猜测。

如果项目已经比较大，上下文管理会变得很关键。此时比起“把所有代码都给 AI”，更好的方式是让 AI 找到真正相关的部分。

---

八、Repomix：把代码仓库整理成 AI 友好的上下文

Repomix 适合做代码审查、项目分析、重构评估这类任务。它可以把本地或远程代码仓库打包成适合 AI 阅读的格式，比如 Markdown、XML、JSON 或纯文本。

比如可以用于：

• 让 AI 快速理解项目结构；

• 让 AI 做代码质量分析；

• 让 AI 帮忙写项目说明文档；

• 让 AI 分析技术债；

• 给不支持直接读取仓库的模型提供上下文。

示例命令：

# 输出为 markdown 格式
repomix --style markdown

# 输出为 json 格式
repomix --style json

需要注意的是，不要把包含密钥、内部配置、客户数据的代码直接打包给外部模型。使用前最好先检查 .env、配置文件、证书、日志等敏感内容是否被排除。

---

九、Playwright MCP：让 AI 参与前端页面验证

很多前端 bug，只看代码不够，还要打开页面看实际效果。

Playwright MCP 可以让 AI Agent 通过浏览器自动化能力和网页交互。它适合用于：

• 复现页面 bug；

• 检查按钮点击流程；

• 验证表单提交；

• 做简单端到端测试；

• 辅助生成 Playwright 测试脚本。

比如可以让 Agent 做这样的任务：

请打开本地页面，复现“点击提交按钮后没有提示”的问题。
先观察页面行为，再判断可能原因，不要直接修改代码。

前端开发里，AI 最大的短板之一是“看不到页面实际运行效果”。浏览器自动化工具可以在一定程度上补上这个缺口。

---

十、Chrome DevTools MCP：辅助前端调试

Chrome DevTools MCP 适合做更偏调试类的工作，比如：

• 查看控制台报错；

• 分析网络请求；

• 检查页面性能；

• 查看 DOM 状态；

• 辅助定位前端问题。

但这类工具也要注意边界。它会让 AI 接触浏览器中的信息，所以不建议在已经登录个人账号、后台系统、生产系统的浏览器环境里随便使用。更稳妥的做法是准备单独的测试环境和测试账号。

---

十一、Spec Kit：不要只 Vibe，复杂任务先写规格

Vibe Coding 很适合快速尝试，但复杂任务不能只靠“感觉写代码”。

如果是一个新功能，最好先写清楚规格：

• 用户要完成什么；

• 输入输出是什么；

• 有哪些边界条件；

• 涉及哪些页面和接口；

• 哪些情况要报错；

• 如何验收；

• 要不要补测试。

Spec Kit 代表的是 Spec-Driven Development，也就是先写规格，再让 AI 根据规格实现。它比较适合中大型功能、多人协作或需要长期维护的项目。

一个简单规格可以这样写：

# 功能：订单状态筛选

## 目标
用户可以在订单列表页按订单状态筛选数据。

## 状态范围
- 全部
- 待支付
- 已支付
- 已取消

## 交互规则
- 默认展示全部订单。
- 切换状态后重新请求列表接口。
- 请求失败时展示错误提示。
- 筛选条件需要保留在 URL query 中。

## 验收标准
- 状态切换正确。
- 刷新页面后筛选状态不丢失。
- 接口失败时有错误提示。
- 不影响原有分页逻辑。

把需求写到这个程度，AI 生成的代码通常会稳定很多。

---

十二、Taskmaster / BMAD-METHOD：把需求拆成任务再交给 AI

如果一个需求比较大，不建议直接让 AI 一次性完成。

更好的方式是先拆任务：

1. 阅读需求；

2. 拆分模块；

3. 确定每个任务的输入输出；

4. 先完成最小可运行版本；

5. 再补测试、异常处理和文档；

6. 最后做 review。

Taskmaster、BMAD-METHOD 这类工具或方法，适合帮助开发者把需求拆成更小的开发任务。它们不一定适合所有人，但背后的思路值得借鉴：不要让 AI 一次性吞下整个需求。

---

十三、我的一个推荐组合

如果只是想开始尝试，不需要一次性安装所有工具。可以先从这个组合开始：

轻量组合

适合个人项目、小脚本、小型前端项目：

• Claude Code / Codex CLI / Gemini CLI 任选一个；

• AGENTS.md；

• Repomix；

• Git diff 人工 review。

中等项目组合

适合已有项目维护：

• Claude Code 或 Cline；

• AGENTS.md + CLAUDE.md；

• Context7；

• Serena；

• Playwright MCP；

• 单元测试 / E2E 测试。

复杂功能组合

适合新功能开发或多人协作：

• Spec Kit；

• AGENTS.md；

• Superpowers；

• Context7；

• Serena；

• Playwright MCP；

• 人工 code review。

这三个组合的区别不在于“哪个更高级”，而在于任务复杂度不同。小任务不要流程过重，大任务不要只靠一句 prompt。

---

十四、使用 AI 写代码的几个注意事项

最后补几个比较实际的经验。

1. 不要把生产权限交给 Agent

不要让 AI 直接连接生产数据库、生产后台、真实用户数据。AI 可以辅助写代码，但不应该绕过开发、测试、审核流程。

2. 每次只让 AI 做一个明确任务

比如：

请修复登录按钮重复提交的问题。
只修改登录表单相关代码，不要重构其他模块。

不要这样写：

帮我优化整个系统。

范围越大，失控概率越高。

3. 让 AI 先读代码，再写代码

一个比较稳的 prompt 是：

先阅读相关文件，说明你对当前实现的理解。
不要修改代码。
等我确认后，再给出修改方案。

这一步可以过滤掉很多误解。

4. 保留 Git diff review

AI 改完代码后，一定要看 diff。重点看：

• 有没有改无关文件；

• 有没有删除已有逻辑；

• 有没有引入新依赖；

• 有没有硬编码；

• 有没有绕过异常处理；

• 有没有影响安全逻辑。

5. 测试不能省

AI 生成代码不等于代码正确。至少要跑：

• lint；

• 单元测试；

• 相关接口测试；

• 前端关键流程测试；

• 必要时手工验证。

---

总结

Vibe Coding 的核心不是“让 AI 替你写完所有代码”，而是把 AI 放进一个更可控的开发流程里。

比较稳定的思路是：

• 用 Coding Agent 负责执行；

• 用 AGENTS.md / CLAUDE.md 说明项目规则；

• 用 Superpowers / Skills 约束工作流程；

• 用 Context7 解决文档和 API 时效问题；

• 用 Serena / Repomix 管理代码上下文；

• 用 Playwright MCP / Chrome DevTools MCP 做前端验证；

• 用 Spec Kit 把复杂需求先规格化；

• 最后用测试和人工 review 收口。

工具本身会不断变化，但这套思路相对稳定：
先给上下文，再给规则；先拆任务，再写代码；先跑验证，再合并结果。

这样使用 AI 写代码，体验会比单纯“丢一句需求给模型”稳定很多。