Vibe Coding实战：用Claude Code与Codex CLI开启AI协作开发

这次我们聊一个最近被讨论得比较多的开发方式：Vibe Coding。它的核心不是某一款工具，而是一种把自然语言变成软件交付流程的协作方式——你不再逐行手写业务代码，而是把需求、上下文、报错信息交给 AI 编程助手，由它在本地项目里完成读代码、写代码、跑命令、看日志这一整条链路。程序员的主要工作变成两件：把任务说清楚，以及把 AI 改出来的代码审核过关。

这里拿两个目前热度很高的命令行 AI 编程工具做实战：Anthropic 的 Claude Code 和 OpenAI 的 Codex CLI。Claude Code 强在长上下文、多文件分析和持续任务，适合让 AI 在一个已有的工程里反复迭代；Codex CLI 胜在配置简单、沙箱机制明确，适合直接跑自动化补丁和批量化代码改动。两个工具都是终端优先，不是网页聊天窗口，而是直接操作你当前目录的代码，所以才是真正意义上的 AI 协作开发，而不是简单的 AI 问答。

这篇文章会从零开始演示：环境准备、安装、登录鉴权、在真实项目里让 AI 完成一个小功能、把工具接入第三方模型，以及一套能落地的排查清单。如果你第一次接触 Vibe Coding，或者已经在用聊天式 AI 写代码但觉得不够顺手，这篇可以作为直接能用的操作手册。Claude Code 和 Codex CLI 对硬件要求很低，普通开发机就行，真正的算力开销在模型 API 服务端，本地不吃显存，也不需要独立显卡。

1. Vibe Coding 核心能力速览

这个表格是快速判断用的。Claude Code 和 Codex CLI 不是 IDE，也不是聊天网页，它们更像是一个能“看懂整个项目结构”的编程代理。你可以把它理解为：在终端里多了一个随时能够接手局部任务、并且愿意反复改到你满意的结对程序员。

2. Vibe Coding 与传统手写代码的差异

传统开发流程通常是：人打开编辑器，想清楚逻辑，逐行写函数，运行看结果，再打开日志或者断点定位问题。Vibe Coding 把这个链路拆成了“意图 — 生成 — 验证 — 修正”四个环节。人负责提供意图和验收标准，AI 负责把意图转化成 diff，人再负责检查 diff 是否符合预期。这不是让 AI 替你做决定，而是把重复性的代码拼装、搜索、补全、报错分析交给 AI，把决定权留在自己手里。

这个差异在改动已有项目时体现得最明显。以前如果接到一个旧仓库，要先花时间找到相关文件、理解调用链、然后再动手。现在你只需要给 AI 指出入口文件，让它自己追踪调用关系、定位逻辑问题，然后直接修改。Claude Code 和 Codex CLI 都支持在项目里搜索、读取文件、执行测试命令，所以它们能处理的不只是单个文件，而是跨模块的完整任务。

Vibe Coding 和普通聊天写代码最本质的区别是“有本地上下文”。网页聊天机器人只能靠你贴代码片段，AI 编程代理却能自己打开你的文件、运行你的测试。这样生成的代码会更贴合项目现状，而不是泛泛而谈的示例代码。但代价是：它会真的改动你的文件。所以使用 AI 编程代理的前提是你有 Git 管理，至少也要有可靠的备份，否则 AI 改错文件的时候，你很难做精细回滚。

3. 适用场景与使用边界

3.1 适合谁用

第一类是零基础入门者。Vibe Coding 让一个不了解框架细节的人也能快速搭出可运行的小工具，比如网页爬虫、PDF 批量处理脚本、本地文件整理工具。第二类是业务开发中的“多面手”，日常要写前端、后端、脚本，没时间把所有语言的生态细节都记下来，AI 编程代理可以按需补知识。第三类是资深工程师，他们使用 Claude Code 这类工具不是为了学语法，而是减少返工，把精力放在架构设计和代码审查上。

3.2 不适合什么场景

不适合的场景也很明确：第一，核心交易系统、支付、权限、加密这类高风险模块，AI 改完必须有人工安全审计，不能直接合入；第二，完全无人工审核的自动化流水线，尽量不要让 AI 直接提交并发布；第三，涉及大量未公开业务逻辑、敏感数据、密钥、内部 IP 的代码，不要放进第三方模型 API 的上下文里。Vibe Coding 是加速工具，不是免责工具。

3.3 版权、隐私与合规边界

AI 生成的代码可能来自训练数据中的类似实现，使用前要确认许可来源，尤其是准备商用或开源发布的时候。公司内部项目是否允许把代码片段发送给云端模型 API，取决于团队的安全策略。个人项目也建议把 API Key、密码、内网地址从代码里抽离出来，用环境变量或密钥管理工具替代。另一个容易忽略的点是：不要把用户隐私数据直接写在提示词里，比如手机号、身份证、地址等信息，测试阶段用脱敏数据。

4. 环境准备与前置条件

Claude Code 和 Codex CLI 都是命令行工具，因此环境准备相对简单。核心是四样：能跑 Node.js 的操作系统、npm 包管理器、能正常访问对应模型 API 的网络环境、一个可用账号或 API Key。

需要特别说明的是，Claude Code 本身不依赖本地大模型推理，不涉及显存占用、CUDA 驱动这些传统 AI 部署问题。它更像一个智能终端助手，所有自然语言理解发生在模型服务端。如果你在本地部署过 Stable Diffusion、TTS 这类模型，会发现 AI 编程代理的部署难度要低得多。

5. Claude Code 安装部署与启动

5.1 安装 Claude Code

Claude Code 的官方推荐安装方式是通过 npm 全局安装。终端执行：

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

安装完成后验证版本：

claude --version

如果 npm 全局目录不在 PATH 里，Windows 可能需要手动把 npm 全局路径加进环境变量，macOS/Linux 一般会自动处理。可以用which claude或where claude确认可执行文件位置。

5.2 登录与鉴权

直接在项目目录启动claude命令，第一次进入会引导你登录账号，或者填写 API Key。如果你已经有 Anthropic API Key，可以提前设置环境变量，避免每次交互登录：

export ANTHROPIC_API_KEY="你的API密钥"

Windows PowerShell 下写法是：

$env:ANTHROPIC_API_KEY="你的API密钥"

鉴权成功后，Claude Code 才能开始读取当前目录的文件并调用模型。

5.3 用 Claude Code 启动一个项目

进入一个项目目录，执行：

cd /path/to/your/project claude

进入交互界面后，你可以直接用自然语言描述任务。例如：

请分析当前目录下的 main.py，输出主要函数清单， 并把其中重复的数据库连接逻辑提取成一个公共方法。

Claude Code 会先扫描项目结构、读取相关文件，然后给出修改计划。确认后会直接改动文件。它不是一次性问答，而是可以持续对话，你可以连着说“再补一个日志”“把报错信息改得友好一点”，它会基于上下文继续修改。

5.4 常用内建指令

交互界面里有一些非常有用的内建指令：

如果说“Claude Code 和普通聊天 AI 有什么区别”，这组指令就是答案。它不是一个只能回复文本的模型，而是一个拥有文件系统操作权限和命令执行能力的终端代理。

5.5 接入兼容模型服务

Claude Code 默认调用 Anthropic 官方接口，但它的协议是兼容的，可以通过环境变量把底模换成其他提供商。现在很多国内模型服务商提供了 Anthropic 兼容接口，方便开发者在不改变客户端的情况下切换模型。下面是一个通用配置模板，实际地址和模型名要以服务商文档为准：

export ANTHROPIC_BASE_URL="https://你的服务商接口地址/v1" export ANTHROPIC_AUTH_TOKEN="你的API密钥" export ANTHROPIC_MODEL="服务商支持的模型名"

如果你用这种兼容接口，注意 Claude Code 的某些高级特性，比如部分请求格式和工具调用协议可能受到服务商兼容程度影响。第一次接入兼容模型时，先跑一个简单的文件修改任务，确认 AI 能成功读文件、写文件，再上真实项目。

6. Claude Code 实战：从自然语言到功能落地

6.1 实战场景：做一个待办事项小工具

为了演示完整链路，我在空目录里初始化一个 Python 项目，要求 Claude Code 实现一个命令行待办事项工具。对话指令如下：

在当前目录创建一个 Python 命令行工具 todo.py，功能包括： 1. 添加待办：python todo.py add "写周报" 2. 列出待办：python todo.py list 3. 完成待办：python todo.py done 1 4. 删除待办：python todo.py delete 1 数据保存到本地 todo.json 文件。 要求错误处理完整，并打印清晰提示。

Claude Code 会生成代码并默认附带说明。我在这里复现它的典型输出结构：代码文件创建完成、依赖说明、运行方式。这个步骤的核心不是代码本身写得多好，而是它理解了“数据持久化到 JSON”这个需求，没有把数据放在内存里。

6.2 让 AI 补测试与修复问题

第一次生成的代码可能不完整，这时继续对话可以进入修正循环。例如：

请为 todo.py 写一个 unittest 测试文件， 覆盖添加、列出、完成、删除四种操作，并确保测试不会污染已有数据。

Claude Code 会创建一个test_todo.py，使用临时目录模拟数据文件。然后我们可以让它运行测试：

运行测试，如果有报错请修复代码，直到测试全部通过。

这一轮下来，它已经把“代码生成、测试补齐、跑通验证”三件事一起做完了。这个流程和手动编程最大的区别是，你只需要控制验收标准，不需要替 AI 逐行写逻辑。

6.3 查看变更并回滚

AI 改完后，用 Git 查看 diff 最直观：

git diff --stat git diff

如果对改动不满意，直接回滚：

git checkout -- .

实践上我会建议，每让 Claude Code 完成一个独立功能就手动提交一次 Git，这样后续任何一个需求描述失误，都不至于累及整个仓库。

7. Codex CLI 安装与实战

7.1 安装 Codex CLI

Codex CLI 是 OpenAI 推出的命令行 AI 编程工具，同样基于 npm 安装：

npm install -g @openai/codex

安装后确认版本：

codex --version

在项目目录中直接启动：

cd /path/to/your/project codex

Codex CLI 会进入一个交互式终端，你可以直接输入任务描述，它会先分析项目，再给出修改方案。

7.2 常用启动参数

Codex CLI 支持多种非交互模式，方便脚本化和批量任务。例如：

# 直接执行一个任务，然后退出 codex "为当前项目添加 README.md，内容包含安装和运行说明" # 允许 AI 自动执行命令，适合在可信环境中运行 codex --ask-for-approval=never # 限制 AI 文件写入范围 codex --sandbox workspace-write

--sandbox参数尤其值得关注。它有三种常见级别：只读模式、允许写工作目录模式、完全开放模式。第一次使用建议先保持默认或只允许工作区写入，避免 AI 误改系统文件。

7.3 Codex 配置文件

Codex CLI 的配置文件位于~/.codex/config.toml。你可以在这里指定默认模型、输出风格、历史记录等。下面是一个简化示例：

model = "gpt-5-codex" model_provider = "openai"

如果你通过兼容接口接入第三方模型，可以仿照下面的模板添加 provider：

model = "your-model-name" model_provider = "custom" [model_providers.custom] name = "Custom Provider" base_url = "https://你的服务商接口地址/v1" env_key = "CUSTOM_API_KEY"

设置好CUSTOM_API_KEY环境变量后，Codex CLI 会自动读取该变量用于鉴权。这里需要说明：不同服务商的模型对 Codex 工具调用协议兼容程度不一样，接入后先跑一个“创建文件并写入内容”的简单任务验证是否正常。

7.4 Codex 的沙箱与权限模式

Codex CLI 的优势之一是权限控制相对清晰，尤其是沙箱机制。默认情况下，它会限制 AI 只能访问当前工作目录，避免危险操作。实际使用中常见的问题是，AI 要读取系统配置文件或安装依赖时被沙箱拦截，这时候可以按需调整模式：

# 只读模式，AI 不能修改任何文件 codex --sandbox read-only # 允许写当前工作目录 codex --sandbox workspace-write # 完全访问，谨慎使用 codex --sandbox danger-full-access

从工程角度看，批量化修改任务适合用 workspace-write 模式，而涉及安装系统依赖、修改全局配置的任务需要人工确认后再切到完全访问模式。

8. 从 AI 对话到 AI 协作开发的完整工作流

很多人的 Vibe Coding 卡在“聊天”阶段，原因是提需求太随意。AI 编程代理不是搜索引擎，它需要清晰的上下文和验收标准。这里给出一套可复用的任务提示词模板：

你现在是资深 Python 后端工程师。请在我给出的仓库里完成以下改造： 1. 目标：给 /api/v1/user 接口增加分页返回； 2. 约束：沿用现有异常处理方式，不要引入新的框架； 3. 验收：新增 tests/test_pagination.py，覆盖空列表、单页、多页三种情况； 4. 只修改必要文件，改完列出变更清单。

为什么这个模板有效？因为它给了 AI 四个必要信息：角色定位、目标、约束、验收标准。AI 编程代理最怕的不是任务难，而是目标不明确。

8.1 用 Git 分支隔离 AI 改动

每次让 Claude Code 或 Codex CLI 干活前，先建一个专用分支，这样既能保留原始代码，又能方便对比。例如：

git checkout -b feature/ai-generated-pagination

AI 完成修改后，你在分支上 review diff，确认无误再合入主分支。这比让 AI 直接改主分支安全得多。

8.2 批量任务的正确姿势

如果你有一批文件需要处理，比如给所有模块补齐类型标注，不要一次性丢给 AI 说“全部改完”。更稳妥的做法是拆成小任务，一次处理一个目录，每完成一批跑一次测试。Codex CLI 的非交互模式适合这种批量场景：

codex "给 src/utils 目录下的所有 Python 文件添加完整类型标注，不改变现有逻辑"

Claude Code 的持续任务模式则适合让 AI 在后台一直处理问题清单，例如“修复所有测试文件里被标记为 TODO 的地方”。这类任务可以挂在后台，间隔一段时间回来 review。

8.3 多工具切换

实际开发中我倾向于把 Claude Code 和 Codex CLI 配合使用：复杂需求分析、多文件关联改动先交给 Claude Code，因为它上下文管理能力强；需要快速生成通用代码或跑多个独立小任务时用 Codex CLI，因为它配置简洁、沙箱明确。两者也可以配合 VS Code 的插件使用，在编辑器里直接看到 AI 的改动建议。

9. 常见问题与排查方法

这组表格是实际排错时的快速索引。AI 编程代理的报错并不神秘，绝大多数问题集中在三类：路径找不到、网络不通、模型名不匹配。先解决这三类，再深入排查权限和沙箱。

10. 最佳实践与合规提醒

10.1 让 AI 只做局部改动

AI 编程代理最大的风险是“好心办坏事”。它可能为了满足你的需求，顺手重构了依赖它的其他模块。所以任务描述里最好加一句“只修改必要文件，不要改动无关代码”。每次 review diff 时，重点看改动范围是否超纲。

10.2 敏感信息不进提示词

不要把你账号的 API Key、数据库密码、内网地址直接写进 Copilot 或 CLI 提示词里。AI 会把上下文发送到模型服务端处理，也可能被写入日志。正确做法是让代码从环境变量读取敏感配置，提示词里只写变量名。

10.3 加一个自动检查 Hook

Claude Code 支持 Hook 机制，可以在命令执行前后触发自定义脚本。建议在项目里加一个提交前检查，比如自动跑ruff、eslint、pytest，这样 AI 改完代码后，质量检查能第一时间拦截明显问题。

10.4 模型生成代码也要人工复核

Vibe Coding 不等于“AI 说可以就可以”。AI 生成的代码可能在单元测试下通过，但存在边界条件遗漏、异常捕获缺失、并发安全性不足。涉及支付、权限、数据删除等敏感场景，必须有人工走查和集成测试。AI 是放大器，你的习惯有多好，放大出来的结果就有多好。

10.5 控制成本与接口调用量

Claude Code 和 Codex CLI 都依赖云端模型 API，长任务会产生持续 token 消耗。建议批量任务先小范围试跑，确认提示词有效后再铺开。也可以给每次任务设定明确范围，避免 AI 在无关文件上反复“思考”和修改。

如果你想开始尝试 Vibe Coding，最应该做的第一件事不是写复杂功能，而是在一个 Git 仓库里建一个空目录，让 Claude Code 或 Codex CLI 生成一个最简单的命令行工具，跑通“需求表达 — 代码生成 — 测试执行 — 人工 review”这条链路。跑通一次，你就能理解这种开发方式到底适合自己项目的哪些环节。最容易踩的坑是任务描述含糊、让 AI 一次性改太多文件、以及在未初始化 Git 的情况下让 AI 自由发挥。避免这三个坑，Vibe Coding 的收益会非常明显。后续可以继续扩展的方向是：把 Hook 检查接入团队流水线、用 Skills 沉淀团队规范、把 AI 编程代理接到内部任务管理系统，让代码生成、检查、提交形成自动化闭环。建议先收藏，然后挑一个小项目验证一下。