现在的 AI 编程工具开始提供模型选择：GitHub Copilot coding agent 支持 model picker，Claude、Codex、Copilot 等也越来越多地出现在同一个开发流程里。很多讨论会迅速滑向“哪个模型最强”。这个问题当然重要，但对个人开发者来说，更有用的问题是：什么任务该用什么模型，什么时候不值得用贵模型。

我的判断是，多模型 coding agent 的核心不是“永远选最强”，而是按任务风险和不确定性分层。模型能力会变，价格会变，工具集成也会变。把开发流程绑定到单一模型崇拜上，并不稳。

一个实用分层

低风险任务可以用便宜、快速的模型，比如生成 README 草稿、补简单类型、整理提交信息、解释报错。中等风险任务需要更强的代码理解能力，比如跨文件重构、测试修复、接口适配。高风险任务才值得调用更强模型：权限逻辑、并发问题、数据迁移、支付流程、安全审查。

实战里可以把模型选择写进工作流，而不是每次靠感觉。比如：默认模型处理小改动；涉及 auth、billing、migration、worker 的任务自动升级模型；超过一定文件数量的 diff 才触发高级 review；失败两次后切换模型或停止。

这样做的好处是可复盘。你可以知道贵模型到底花在了哪里，也能判断它是否真的降低了返工成本。如果一个模型只是在写文案时更有气势，那不值得为它支付高级 coding agent 成本。

踩坑：强模型也会被坏上下文拖垮

第一个坑是把所有问题都归因于模型不够强。很多时候，AI 写不好不是因为模型弱，而是项目没有测试、边界没说清、工具返回混乱、错误日志不完整。换模型之前，先检查上下文质量。

第二个坑是忽视延迟和成本。高级模型适合复杂任务，但不适合每个小问题都调用。个人开发者尤其要小心“无感成本”：一次两次不明显，一个月下来就是一笔工具账单。

第三个坑是没有基准任务。建议给自己的项目准备 5 个固定任务：修一个历史 bug、补一组测试、解释一段复杂逻辑、改一个接口、做一次安全审查。每换模型或工具，就用这些任务试一遍。体感很容易骗人，固定任务更诚实。

结论

多模型 coding agent 会成为常态，但开发者不需要站队。更成熟的做法，是把模型当成不同成本、不同能力的工程资源。便宜模型做低风险重复活，强模型做高不确定性任务，人负责边界和最终判断。别把模型选择当信仰问题，它更像一次资源调度。

参考：GitHub Copilot coding agent 更新：https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/