Claude 总想劝你换路，Codex 却在埋头开工：AI 编程该怎么选、怎么用？
你有没有碰过这种场面？
你说：“帮我把这个旧项目接上支付功能。”
Claude 看了一眼代码，开始认真劝你：
这个架构耦合较深，支付流程涉及安全、幂等、回调校验……建议考虑重构，或者换一套更合适的方案。
你还没来得及回话，Codex 已经打开文件、改接口、补测试了。
它的气质很像团队里那个老哥：领导说“今天得上线”，他不讨论人生哲学，先把活干起来。没有路？绕过去。缺个接口？先搭一个。报错？接着查。
这不是谁更聪明的问题，而是两类 AI 的默认工作方式不一样。用对位置，你能少掉很多无效拉扯。⚙️
两种 AI，像两种不同的同事
Claude：擅长踩刹车的人
Claude 往往更关注这些事：
- 需求本身是否合理
- 方案有没有隐藏风险
- 现有架构能不能扛住
- 有没有更稳、更省维护成本的路径
- 你是不是在用一个临时补丁掩盖长期问题
这类提醒很有价值。
比如你要给一个没有鉴权的内部接口直接暴露公网，Claude 多半会立刻拦你。此时别嫌它烦。它不是不想干活，是在提醒你：这玩意儿上线后，可能不是加班，是事故复盘。
问题在于，有些场景根本不需要一场架构研讨会。
比如老板下午要看一个演示页面，你只需要把 Excel 数据做成可筛选表格。Claude 若连续给你列出数据建模、权限系统、缓存策略、容灾方案……人会有点崩溃。
Codex：擅长把事情推进的人
Codex 的工作风格更偏执行：
- 找到相关文件
- 读取现有代码
- 直接修改
- 运行命令验证
- 遇到报错继续排查
- 反复迭代到能跑
它适合那种边界明确、能验证结果的任务。
例如：
- 给 React 页面加一个筛选器
- 修复某个接口返回 500
- 把 Python 脚本改成批量处理 CSV
- 给项目补单元测试
- 根据设计稿调整 CSS
- 清理一批重复代码
你说“按钮点了没反应，帮我修”，它通常不会先劝你重写整个前端。它会去找事件绑定、查控制台、看请求，然后动手修。
这股“先干再说”的劲儿，在赶工时特别香。
别站队：把两者串成一条流水线
最省心的做法是：Claude 管方向，Codex 管施工。
一个负责把坑标出来，一个负责扛着铲子下去填。
可以按下面这个流程来。
场景：给老项目加“导出订单 Excel”功能
1. 先让 Claude 做需求和风险检查
把项目背景、技术栈、目标说清楚：
这是一个 Vue 3 + Node.js 的订单后台。
我需要增加“导出订单 Excel”功能。
要求：支持按日期筛选，单次最多导出 5 万条，导出的文件包含订单号、用户、金额、状态、创建时间。
请输出：
1. 推荐实现方案
2. 可能踩到的性能和安全问题
3. 接口设计建议
4. 必须确认的需求细节
不要写代码。
你会拿到一份比较像样的施工前检查单。
重点看这几项：
- 大数据量导出是否会压垮接口
- Excel 文件由前端生成还是后端生成
- 时间范围有没有限制
- 金额、手机号等字段是否需要脱敏
- 导出权限怎么控制
- 导出任务要不要异步处理
这一步花 10 分钟，能救你后面 2 小时的返工。
2. 把确定后的任务交给 Codex
别只丢一句“加个导出 Excel”。
你给得越具体，它干得越利索。
请在当前项目实现订单导出 Excel 功能。
约束：
- 前端：Vue 3
- 后端：Node.js + Express
- 使用现有的订单查询条件
- 日期范围最多 31 天
- 导出字段：订单号、用户昵称、支付金额、订单状态、创建时间
- 金额保留两位小数
- 单次导出超过 1 万条时，接口返回明确提示
- 普通管理员只能导出自己负责门店的数据
执行要求：
1. 先定位订单列表、查询接口和权限校验相关文件
2. 直接修改代码
3. 补充必要的错误处理
4. 增加测试或至少提供可执行的验证步骤
5. 完成后列出修改过的文件和测试结果
这段提示词的核心不是“写得客气”，而是让 Codex 少猜。
AI 最怕的不是任务难，是需求里全是空气。
让 Codex 真正能干活的 4 个关键动作
给它验收标准，别只给愿望
“做得好看一点”“优化一下性能”这种话，人都不一定听得懂，别为难 AI。
换成可检查的标准：
- 页面加载时间低于 2 秒
- 接口错误时展示具体提示
- 移动端 375px 宽度不横向滚动
- 测试命令必须通过
- 不允许修改数据库表结构
Codex 很适合解决有终点的问题。你把终点线画出来，它会跑得很快。
要求它先读代码，再改代码
很多翻车，不是模型不会写，而是它没搞清项目现状就开改。
可以直接加一句：
修改前，请阅读相关模块，并用不超过 8 条要点说明当前实现逻辑。确认后再开始修改。
对复杂项目尤其有用。
你会提前发现它是不是找错了文件，是不是把 A 模块当成 B 模块。这比改完一堆代码再返工舒服多了。
一次只推进一个可验证的小目标
别上来就说：
把整个系统重构成微服务，顺便加权限、国际化、支付和数据大屏。
这句话等于让 AI 原地表演魔术。
拆成小任务更稳：
- 抽离订单查询服务，并保证现有接口测试通过
- 增加导出接口
- 增加前端导出按钮和下载逻辑
- 补权限校验
- 做边界数据测试
每完成一步，就运行一次测试、看一次 diff、提交一次 Git。
别把 AI 当许愿池。把它当一个手速极快、需要你盯验收的开发同事。
让它在失败时提供证据
“没修好”没意义。
你要的是它告诉你：卡在哪里、试过什么、下一步怎么做。
直接用这段：
如果无法完成，不要跳过问题，也不要假装已经修好。
请输出：
- 失败的具体原因
- 报错原文
- 已尝试的排查步骤
- 需要我补充的文件、权限或信息
- 风险最小的替代方案
这能有效减少那种“代码看着写了，运行一看全红”的尴尬场面。
Claude 什么时候该出场？
别因为它爱提醒，就把它踢出工作流。
下面这些任务，Claude 往往很适合：
架构选择
你纠结 Redis、数据库缓存、消息队列该怎么搭？
把业务量、成本、团队能力、现有技术栈扔给 Claude，让它列方案和取舍。重点不是要一个“标准答案”，而是提前知道每个选择会付出什么代价。
代码审查
Codex 写完一轮后，把 diff 交给 Claude 审：
请审查下面的代码改动。
重点检查：安全漏洞、权限绕过、空值处理、并发问题、性能风险、和现有业务规则冲突的地方。
按“必须修复 / 建议修复 / 可以接受”分类。
这套组合很实用。
Codex 负责冲刺，Claude 负责在终点线前看看你鞋带是不是散了。
需求反推
产品说：“做一个用户增长功能。”
这种需求听完，脑子里通常只剩一串问号。
让 Claude 反问：目标用户是谁？增长指标是什么？触发条件是什么？数据从哪来？失败怎么算？
问清楚再写，能避免大家忙三天，做出一个谁也说不清有没有用的按钮。
常见坑：别把“能执行”误认为“可以闭眼交付”
Codex 的执行力越强，越需要你守住下面几条线。🚧
坑 1：没看 diff 就合并
AI 可能顺手改到无关文件，也可能为了让测试通过，删掉你本来需要的校验。
怎么做：
- 每次只处理一个任务
- 查看 Git diff
- 关注删除操作
- 核对环境变量、权限逻辑、数据库操作
- 跑测试，再手动走一遍核心流程
坑 2：让 AI 自己决定业务规则
“退款后积分要不要扣？”“取消订单后优惠券是否退回？”
这不是代码问题，是业务决策。
AI 能给建议，别让它替你拍板。它写错了，代码依旧能跑；麻烦就在这儿。
坑 3：把密钥和真实用户数据一股脑发进去
API Key、生产数据库连接串、身份证号、完整手机号，统统别直接贴。
用脱敏样本、虚拟配置、最小必要上下文。
哪怕工具支持私有仓库，习惯也要养好。安全这事，出问题之前看着都像“有点多余”。
坑 4：Claude 提醒风险，你就觉得它在偷懒
有些风险确实该绕开。
比如你想让 AI 写一个“忽略 SSL 校验”的请求，或者为了赶时间把权限检查删掉。它如果拒绝或强烈劝阻，别急着换模型硬干。
问一句：
在不取消安全校验的前提下，有没有临时可上线的替代方案？
这才是把提醒变成生产力的姿势。
一套可以直接复制的协作模板
用 Claude 做方案把关
你是资深技术负责人。
项目背景：
[填写技术栈、现有架构、业务背景]
我要完成的目标：
[填写具体目标]
约束条件：
[填写上线时间、预算、性能要求、不能动的模块]
请帮我输出：
1. 推荐方案及原因
2. 需要确认的业务规则
3. 技术风险与规避动作
4. 最小可上线版本范围
5. 交给编码助手执行时，应该拆成哪些任务
请讲人话，别泛泛而谈。
用 Codex 做落地开发
请在当前代码仓库完成以下任务：
目标：
[填写一个明确功能]
验收标准：
- [标准 1]
- [标准 2]
- [标准 3]
约束：
- 不修改 [指定模块]
- 保持现有接口兼容
- 不新增未经说明的依赖
执行流程：
1. 定位相关文件并说明当前逻辑
2. 给出简短实施计划
3. 修改代码
4. 运行测试、构建或检查命令
5. 汇报修改文件、验证结果和遗留风险
遇到不确定的业务规则时，停下来提问，不要自行编造。
结语：一个负责想清楚，一个负责干到底
Claude 的“别急，换条路试试”，有时会让人抓狂；Codex 的“没办法就想办法”，又很容易让人上头。
真正成熟的用法，不是选边站。
需求模糊、风险高、涉及架构时，找 Claude 把路看清。
任务明确、需要改代码、需要跑命令时，让 Codex 下场开干。
你负责业务判断和验收。
一个 AI 帮你少走弯路，另一个 AI 帮你少熬夜。这个组合，才值钱。
