在 AI 编辑器里试用一周 GPT-5 后，有人觉得再也回不去 Claude Sonnet，也有人认为 GPT-5 更慢、会把项目改坏。本文梳理双方分歧的真实来源，并从上下文质量、任务拆分、模型分工三个方面给出可落地的混合工作流与检查清单。
同一个 AI 编辑器里，把主力模型从 Claude Sonnet 换成 GPT-5 用上一周，有人得出「回不去了」的结论，也有人试用后立刻换回 Claude。两种声音都很强烈，但仔细看会发现，他们说的其实不是同一件事：一个在讲「卡住时谁能把我捞出来」，另一个在讲「谁一次就把代码改对」。
这类对比帖很容易变成情绪对撞。真正有价值的部分是：什么任务、什么提示方式、什么验收标准下，哪个模型更合适。下面把分歧拆开，再给一套可以直接照做的分工方法。
分歧集中在哪几个点
| 维度 | 偏向 GPT-5 的反馈 | 偏向 Claude 的反馈 |
|---|---|---|
| 卡死循环 | Claude 有时会绕在同一个思路里出不来，换模型能跳出循环 | 换模型只是绕开了问题，根因还是上下文没给清 |
| 一次改对率 | 调低推理强度后，小改动命中率高 | GPT-5 会把项目改得错误百出，还得回头收拾 |
| 等待时间 | 愿意等，结果对就行 | 思考时间明显更长，交互节奏被打断 |
| 动手速度 | — | 收到需求立刻开改，反馈快 |
| 复杂任务 | 上下文给足、先规划后开发时完成度不错 | Sonnet 在长链路重构里更稳 |
| 成本与额度 | 额度更耐用，试用期体验好 | 消耗快，几天就用完 |
值得注意的是，那条「完成度很不错」的反馈附带了两个前提：提示写了上百字，并且严格走「规划 → 产品文档 → 开发」的顺序。这基本说明了问题不在模型，而在输入质量。
为什么同一件事评价会两极
提示的完整度差了一个量级
一句「帮我修一下这个 bug」和一段带复现步骤、报错原文、约束条件、验收标准的说明，对任何模型都是两种难度。模型越偏向「先想再做」，对信息缺口就越敏感：信息不足时它会自行补全假设，假设一错，改动就发散。
模型的默认行为不同
Sonnet 倾向快速给出可执行的改动，适合小步快跑；GPT 系列默认思考时间更长，推理强度可调。用低推理强度跑明确的小任务，和用高强度跑开放式重构，体验完全是两个产品。觉得「慢」的，多半是用了高强度去做本该一句话解决的事；觉得「改坏项目」的，多半是把大范围改动一次性丢给了它。
评判标准不一样
有人看第一次输出能不能直接用，有人看最终代码能不能跑。前者对速度敏感，后者对正确性敏感。同一个模型在这两套标准下会得到相反的评价。
试用期放大了心理预期
免费额度内的体验，和长期按量使用时的成本感受不同。另外，不同编辑器、不同套餐开放的模型和参数并不一致，价格、额度、模型可用性请以官方最新说明为准，不要拿别人的体感当预算依据。
一套可落地的混合工作流
第一步：先把规矩写进项目
在仓库里放一份规则文件（不同工具叫法不同，例如 rules、AGENTS.md 之类），把下面这些固定下来：
- 技术栈与版本约束，禁止随意升级依赖
- 目录职责：哪个目录放业务逻辑，哪个放工具函数
- 常用命令：安装、启动、测试、类型检查、格式化
- 代码风格与命名约定
- 明确禁止项：不要改构建配置、不要动 CI、不要新增依赖、不要改动公开接口
这份文件的作用是让每次对话都自带背景，而不是靠你在提示里反复重复。
第二步：用固定模板提需求
目标：<一句话说明要达成的结果>
范围：只允许修改 src/xxx 下的文件，不要动依赖和构建配置
现状：<相关文件已引用；报错原文如下：……>
约束：<技术栈 / 风格 / 兼容性要求>
验收：<测试命令通过；接口返回结构不变；页面行为不变>
步骤：先给出改动计划，我确认后再动代码
最后一行很关键。先要计划、再要代码，可以在一半的成本上发现方向错误；直接要代码，等于把审查工作推迟到 diff 阶段。
第三步：按任务类型分工
| 任务类型 | 建议做法 |
|---|---|
| 明确的小改动、单文件修复 | 用响应快的模型或低推理强度，一轮一改 |
| 跨文件重构、架构调整 | 用思考时间长的模型，先出方案和影响面清单 |
| 死循环、反复改不对 | 停掉当前会话，换模型 + 重新组织上下文 |
| 收尾与回归 | 换另一个模型做交叉审查，专门找反例 |
分工的核心不是选出「更好的模型」，而是让不同模型承担不同阶段：一个负责出方案，一个负责落地，第三个负责挑刺。
第四步：处理死循环
遇到模型在同一个思路里打转，继续追问通常无效。有效的做法是：
- 结束当前会话，不要在同一条错误路径上叠加纠正
- 新开会话，只贴最小可复现片段、完整报错、已尝试过的两种方案及结果
- 要求它先输出诊断结论（根因假设 + 验证方法），再动代码
- 换一个模型复述同样的信息，对比两边的根因判断
换模型之所以有效，往往不是因为它更强，而是因为新会话把累积的错误上下文清掉了。
第五步：保证随时能回滚
- 每完成一个可验证的小步骤就提交一次，提交信息写清改了什么
- 让模型改动前先跑一次测试，改动后再跑一次，把两次输出都贴回来
- 大改动前先建分支，diff 逐段看，不要整体接受
- 把「新增依赖」「改配置」「删文件」三类改动单独列出审查
第六步：别让环境成为变量
如果经常让模型跑长时间任务，本地机器的资源占用、休眠断网、连接中断都会变成「模型不稳定」的错觉。这种情况下，把运行环境换成一台长期在线的机器是可选做法之一，例如租用整台放在机房的远程 Mac（新加坡独享远程 Mac），按月使用、远程连接，可以长时间挂着跑 Claude Code 这类工具，本地只负责看结果。是否值得取决于你的任务时长和网络状况，先小规模验证再决定。
注意事项
- 官方提示指南值得读：面向编码场景的提示建议通常会把「先规划、给上下文、明确验收」讲得更细，比在社区里比对体感更有用。
- 基准测试不等于你的仓库：公开评测反映的是平均情况，你的项目有特定框架、历史包袱和风格约定，只有自己的回归测试能给出结论。
- 额度与价格会变：模型版本、免费额度、计费方式更新频繁，做长期方案前查官方文档。
- 代码与密钥边界：不要把生产密钥、客户数据、未公开代码贴到不受控的通道里，团队使用前确认合规要求。
- 别人的结论只能当线索：同一模型在不同编辑器里的默认参数、上下文打包方式都不同，体验差异未必来自模型本身。
小结
「回不去 Claude」和「GPT-5 太烂」并不矛盾，它们描述的是不同任务、不同提示质量下的真实体验。想把两者都用好，记住三件事：把项目规则和验收标准写清楚，把大任务拆成可回滚的小步，按阶段而不是按喜好分配模型。真正决定输出质量的，往往不是模型名字，而是你给它的上下文和约束。