适用读者：在 Codex / Claude Code / Cursor 之间选一个的人；听了一堆"Vibe Coding"但不知道从哪开始的人。
前置：S24-B01（认识 AI 编程工具）、B02（跑通第一个任务）、S21-J01（Agent 循环）、S19-J03（提示词四层）。
覆盖旧文：3659（AI 编程工具全景图）、3660（协作心态）、3661（什么是 Vibe Coding）、3662（Prompt 进阶）、3663（Prompt 基础）、3664（常用 Prompt 模式）、3665（从需求到 Prompt）、3667（Codex 安装配置）、3668（Cursor 安装配置）、3669（开发环境搭建）、3670（工具精通篇导读）、4586（vibe coding 教程）、3666（Codex 快速上手）、3688（Claude Code 快速上手）、3703（Cursor 快速上手）→ 15 篇 / 约 11 万字符。
扩展点：E-S24-015（三工具的四维对照：执行位置/权限模型/上下文注入/可扩展面）、E-S24-016（Vibe Coding 的适用边界与三条止损线）、E-S24-017（需求→Prompt 的六段转换法）。
下一篇：S24-J05 · 配置资产谱系。
1. 一句话结论
三个工具的差异不在"谁更聪明"，在四个工程默认值：代码在哪跑（本机/云端/编辑器内）、权限默认多松、上下文自动注入什么、能用什么扩展。选型就是选这四个默认值与你团队的匹配度。
出处：
A-3659（全景）、A-3667/A-3668（安装配置）、A-3666/A-3688/A-3703（三个快速上手）。
2. 四维对照（E-S24-015）
| 维度 | Codex（CLI/云端） | Claude Code（CLI） | Cursor（IDE） |
|---|---|---|---|
| 执行位置 | 本机 CLI + 云端任务（GitHub 触发） | 本机 CLI（终端内） | 编辑器内（VS Code 分支） |
| 权限默认 | 沙箱 + 逐次审批；可配置放行档位 | 逐次审批（可 --dangerously-skip-permissions 慎用） |
编辑器内改动 + diff 预览/接受 |
| 上下文注入 | AGENTS.md（仓库根，层级向上查找）+ 自动读文件 |
CLAUDE.md（项目/用户级）+ 自动读文件 |
.cursor/rules + @文件/@符号 显式引用 |
| 可扩展面 | MCP、Skills、Hooks、云端环境 | MCP、Skills、Slash Commands、Subagents、Hooks、Plugins | MCP、Rules、四大模式（Chat/Composer/…） |
| 最强场景 | 长时间无人值守任务、批量改动、CI 集成 | 复杂多步重构、需要子代理并行 | 边写边改、交互式小步迭代 |
判据："任务粒度决定工具"——
一次改 1~2 个文件、要即时反馈 → Cursor
一次改 10+ 文件、要跑测试与命令 → Claude Code / Codex CLI
要在 CI/PR 上自动跑、人不盯着 → Codex 云端任务
版本口径：三工具迭代极快（Codex CLI、Claude Code、Cursor 均在月级更新），本文对照的是"结构差异"，具体命令与开关以官方文档当日版本为准（待核）。
3. Vibe Coding 的边界与三条止损线（E-S24-016）
Vibe Coding = 用自然语言描述意图，让模型生成并迭代代码，人做验收而非逐行编写
| 适合 | 不适合 |
|---|---|
| 原型/一次性脚本/内部工具 | 有强一致性与资金安全的核心链路 |
| 有完善测试与类型系统的代码库 | 无测试、无类型、无 code review 的库 |
| 个人或小团队探索性开发 | 多人并发改同一模块（合并冲突爆炸） |
| UI 调整、样板代码、迁移脚本 | 授权/加密/并发等安全敏感逻辑 |
三条止损线（触发即停手，回到人工）：
① 连续 2 轮修复引入新问题（净增 bug）→ 停止对话式修补，回到最小复现 + 人工定位
② 一次改动跨 5 个以上模块且无法用测试覆盖 → 拆成可验证的小步
③ 模型开始"编造 API/配置项" → 停下核对官方文档，不要顺着改（幻觉会连锁）
判据："能不能验证"决定能不能 vibe——有测试与类型系统的代码库，AI 改错能被立刻抓住；没有的话，错误会静默积累到上线。
4. 需求 → Prompt 的六段转换（E-S24-017）
① 目标：一句话说清"谁在什么场景下要什么结果"
② 现状：相关文件/函数/约束（贴真实代码，不描述）
③ 边界：不许动的部分（接口签名、数据库 schema、公共组件）
④ 验收：怎么判断做对了（测试用例、期望输出、性能数字）
⑤ 步骤：允许的改动顺序（先加测试再改实现）
⑥ 失败处理：信息不足时（提问/停下），不许猜
示例（可直接抄）：
# ① 目标
让 /api/orders 支持按 created_at 区间筛选，并保持现有分页行为。
# ② 现状
<贴 OrderController#list、OrderQuery、对应 XML 的当前实现>
# ③ 边界
- 不改 OrderQuery 的字段顺序与既有字段名
- 不改数据库 schema；只允许加索引的迁移脚本
- 不改 PaginationResponse 结构
# ④ 验收
- 新增集成测试：区间边界（含首尾）、空区间、非法日期格式
- 现有 27 个测试全绿；P99 不劣化 >10%
# ⑤ 步骤
1) 先写失败测试 2) 改 Query/XML 3) 补索引脚本 4) 跑全量测试
# ⑥ 失败处理
信息不足时列出缺口并停止，不要臆造字段名或索引名。
判据："③ 边界"和"⑥ 失败处理"是最少被写、也最省钱的两段——绝大多数"AI 改坏了"都发生在没写这两段的时候。
5. 协作心态：三条（3660 的重写）
| 心态 | 反面 | 说明 |
|---|---|---|
| 它是执行者，不是决策者 | 让它决定架构与取舍 | 方案选型、边界划分、安全策略必须人定 |
| 审阅是主要工作 | 只看 diff 大小就通过 | 读 diff 的语义，尤其错误处理与边界条件 |
| 小步提交 | 一次几千行改动 | 每步可回滚，出问题能二分 |
Code review 检查清单（AI 改动专用）：
□ 有没有新增"看起来合理但没人要"的抽象？
□ 错误处理是吞掉了还是真的处理了？
□ 有没有把 catch 里塞 return null / 空数组？
□ 新增依赖是否必要（版本、许可证、体积）？
□ 测试是真断言还是"能跑就行"？
□ 有没有偷偷改公共接口/日志级别/配置默认值？
6. 反例：六种"Vibe 起来就收不住"
| 现象 | 根因 |
|---|---|
| 越改越乱 | 无边界段，模型自由重构 |
| 幻觉 API | 顺着模型给的接口名往下写，没核对文档 |
| 测试全绿但线上报错 | 测试是模型写的，断言按实现写而非按需求 |
| 合并冲突地狱 | 多人同时让 AI 改同一模块 |
| 密钥进仓库 | 未限制读取 .env，也未配 ignore |
| 无法回滚 | 一次提交几千行，没有分步 |
7. 自测
- 三工具的四个工程默认值？任务粒度如何决定选择？
- Vibe Coding 适合/不适合的场景？三条止损线？
- 需求→Prompt 六段？哪两段最常被漏？
- AI 改动 review 的六项检查？
答案
- 执行位置/权限默认/上下文注入/扩展面；小步交互用 Cursor，多文件改动用 CLI，CI 自动化用云端任务。
- 原型与有测试的代码库适合，核心链路与安全逻辑不适合；净增 bug、跨 5 模块无测试、开始编造 API。
- 目标/现状/边界/验收/步骤/失败处理；边界与失败处理。
- 多余抽象、错误处理、吞异常、新依赖、假测试、偷偷改公共接口。
8. 下一篇
S24-J05 · 配置资产谱系 —— AGENTS.md、CLAUDE.md、.cursor/rules、Skills、Slash Commands、Hooks、Plugins 七类资产：各管什么、写错的后果、以及一套跨工具可复用的写法。
本篇属于系列《S24 · AI 编程工具》。旧文来源：A-3659–3670、A-4586、A-3666/3688/3703（15 篇）；扩展点 E-S24-015/016/017。工具版本按 2026-11 时点，具体命令以官方文档为准（待核）。