同时用了Claude Code 和 Codex，我发现 AI 编程最大的骗局，就是大家都在比谁写代码更快。 真正把 AI 用进实际项目之后，我越来越觉得： … · @TJwithAI · TwKit

@TJwithAI

同时用了Claude Code 和 Codex，我发现 AI 编程最大的骗局，就是大家都在比谁写代码更快。 真正把 AI 用进实际项目之后，我越来越觉得： 模型写代码的速度，可能是最不值得关注的指标。 为什么？ 因为 AI 编程最贵的成本，根本不是 Token，而是返工。 这一个多月，我反复使用 Claude Code 和 Codex，逐渐摸索出几款模型的不同定位。 先说 Claude： ① Sonnet 5.5：日常开发的高效打工人。 速度快、执行干脆，写小功能、修改代码、处理常规需求都很舒服。 很多简单任务根本没必要动用旗舰模型。 ② Opus 5.5：执行体验最舒服的主力。 长时间连续开发、复杂任务执行，我很喜欢用它。 Claude Code 的自动执行体验确实丝滑，不用频繁盯着它。 但在一些复杂后端项目中，它偶尔会顾此失彼。 让它修 A，结果影响 B；让它修 B，又遗漏 C 的业务约束。 看起来一直在干活，实际上可能一直在制造新的工作。 ③ Fable 5.1：高难度任务的备选。 面对需要深入推理、复杂规划的任务，我会考虑它。 但旗舰模型并不意味着所有任务都能做得更好，关键还是看任务类型。 再说 Codex： ④ GPT-6 Sol：复杂业务开发的常用选择。 在我处理的一些多模块项目里，它对业务逻辑和模块关联的理解，往往更符合我的预期。 但缺点也明显，有时候审题不准，反复确认和修改也挺折磨人。 ⑤ GPT-6.1 Sol：能力不差，但额度消耗让我头疼。 之前我做过一次实际对照： 同样运行 26 分 25 秒： GPT-6.1 Sol High：消耗约 31% 的五小时额度。 Claude Opus 5.5 High：消耗约 14.7% 的五小时额度。 这不是严格的 Token 效率测试，但在我当时的订阅环境下，额度消耗差距确实很明显。 ⑥ GPT-6 Astra：专门拿来啃硬骨头。 当一个复杂后端问题反复修改仍然无法解决，我会让 Astra 重新分析整个业务逻辑，而不是继续在原来的错误方向上打补丁。 在我处理过的一些棘手任务里，它确实帮我解决了其他模型反复折腾的问题。 用了这么久，我最大的改变，不是换了哪个模型，而是换了使用 AI 的方法。 以前我给 AI 的指令是： “帮我把这个功能做好。” 现在我会先让它回答三个问题： 这个修改会影响哪些模块？ 哪些现有业务逻辑绝对不能破坏？ 修改完成后，准备怎么验证没有引入新问题？ 只有这三个问题说清楚，我才让它开始动代码。 因为 AI 编程真正的效率，不是 10 分钟写完 1000 行代码，而是改完之后不用再花两个小时修 Bug。 所以我现在越来越不关心哪个模型跑分第一。 我只关心一件事： 同样一个任务，谁让我返工最少、消耗额度最少、最终完成得最好，谁才是真正有性价比的模型。 你们长期用 Claude Code 和 Codex 的，有没有同感？ 有些模型用起来特别爽，但真正算总账，未必最省时间。

曝光 14 · 评论 0 · 点赞 0 · 书签 0