Column 1
Column 2
下面我从模型“性格/强项”出发，解释我上面那套选择逻辑背后的原因。核心思路是：软件开发里不同环节对模型的要求不同，本质上是在权衡 推理稳定性、工程落地能力、交互成本（速度/额度/价格）、上下文策略、工具调用可靠性。
1) GPT‑5.2‑Codex：偏“工程执行型”的 coding 专用模型
你可以把它理解成更像一个能推进产出的高级工程师：目标明确时，非常擅长把任务拆成可落地步骤并往前推。
典型特点（导致我的选择偏好）
- 对“写代码/改代码/补测试/修复”这类闭环任务更激进：倾向于快速进入实现，产出完整 patch 风格的修改，而不是长时间讨论。
- 更贴近 agentic coding 的交互形态：Codex 系列围绕 coding agent 工作流强化（例如 CLI 场景里会强调进度跟踪、工具使用等）。[1]
- 适合“已知目标、需要高产出”的阶段：比如“按现有接口加功能”“把这段重构成可测试结构”“补齐单测并跑通”。
因此我会建议它用于
- 实现推进：功能实现、重构落地、批量改动
- 测试生成/修复闭环：你已经知道要怎么改，只需要它把活干完并自检（跑测试、补用例）
选择原因一句话：当你需要“把事情做完”而不是“把问题想清楚”时，Codex 往往更合适。[1]
2) Claude Sonnet 4.5：偏“主力通用型”，高性价比日常开发
Sonnet 4.5 更像一个高质量主力同事：日常需求、常规改动、解释代码、写文档、生成脚手架等，速度和成本体验通常更友好，综合能力也很强。[2]
典型特点
- 综合能力强且更“轻快”：适合作为默认模型，保持高频工作流不断档。
- 对代码阅读、写作、改动建议都稳：但在“超复杂推理链/高风险跨模块改动”上，可能不如 Opus 那么“谨慎且深”。
因此我建议它作为
- 默认日常模型：小需求、常规 refactor、读代码问答、生成文档/注释、简单脚本
选择原因一句话：日常开发 80% 的活，优先用 Sonnet 4.5 能获得更好的吞吐与成本体验，同时质量足够高。[2]
3) Claude Opus 4.5：偏“推理审慎型”，复杂问题/高风险改动更稳
Opus 4.5 更像一个擅长深度思考的技术负责人：尤其适合处理你这类可能涉及并发、状态机、边界条件、长链路依赖的复杂工程问题。
典型特点（这正是我建议它用于“复杂环节”的原因）
- 长链路推理更稳：能更系统地做约束梳理、风险清单、边界条件覆盖、回归面分析。
- 在真实修 bug/命令行任务等基准上表现很强（可视作“复杂工程任务”的侧面证据）。[2]
- 更适合“先想清楚再动手”：尤其当你不确定影响面、怕引入隐性 bug 的时候。
因此我建议它用于
- 需求/设计/方案评审：架构取舍、接口边界、异步时序推演
- 高风险 Debug：竞态、死锁、资源生命周期、时序问题
- 跨模块大型改动前的影响面梳理
选择原因一句话：当错误代价高、系统复杂、需要把“为什么这样改”说清楚时，Opus 的审慎推理能显著降低返工风险。[2]
4) 把“特点 → 选择”压缩成一个可执行规则
- 默认 Sonnet 4.5：让你的日常节奏最快、成本最稳。[2]
- 遇到“复杂/高风险/并发时序/跨模块影响面不清” → 升级 Opus 4.5：先把问题空间收敛，再实施。[2]
- 目标非常明确、你希望快速落地并闭环测试 → 用 GPT‑5.2‑Codex：更偏工程执行推进。[1]
如果你把你最常见的 2–3 类任务（例如：asyncio handler 重构、驱动适配、CI/测试补齐）列出来，我可以按你的任务结构给一份“默认模型 + 升级触发条件 + 提示词模板”的最小工作流。
