SayCraft 的核心是 AI，AI 的核心是选模型。这篇记录我们怎么选模型、怎么换模型、怎么把选定的模型性能榨干——以及为什么最后锁死了一个模型不再折腾。
两个角色，两套选型逻辑
SayCraft 的 AI 链路分两个角色：协调器（coordinator）和编码器（coder）。
协调器负责听懂用户在说什么，拆成技术需求。它跑在我们自己的 API 服务器上，通过 DashScope（阿里云百炼）统一网关调用各种国产模型。
编码器是 E2B 沙箱里的 Claude Code 进程，负责写代码。它走 Anthropic 兼容协议，可以接不同的模型后端。
这两个角色的选型逻辑完全不同：协调器要快，编码器要好。
协调器选型：速度碾压质量
5 月中旬，协调器最初用的是 Kimi K2.5。效果还行，2.8 秒一轮决策。
5 月 28 号做了一次正式横评，测了 10 个模型。结论很意外：deepseek-v4-pro 质量最高（9/10），但一轮要 43 秒。在会议场景里，用户说完一句话要等 43 秒才有反应——实时感完全没了。
最后选了 qwen3.6-flash，8.4 秒一轮，质量 7/10。我的判断是：宁可 plan 质量差一点，也不能让用户等半分钟。协调器的产出不是直接给用户看的（它生成的是内部 plan），质量够用就行，速度才是体验瓶颈。
分类器：14 个模型准确率一模一样
分类器（classifier）是协调器之前的一道轻量筛选——判断用户说的话是不是"可操作的需求"。这个角色换了四次模型：qwen-turbo → qwen3.6-flash → qwen-plus → qwen-flash。
最有趣的发现是：14 个模型在分类准确率上完全一致。区别纯粹是延迟。qwen3.6-flash 虽然准确率一样，但它默认开了 950 token 的推理思考——对一个二分类任务来说太浪费了。最终选了 qwen-flash，1 秒出结果，准确率不变。
如果任务足够简单，模型之间没有质量差异，那就用最便宜最快的。别为了"万一需要"而上大模型。
编码器选型：用户亲自终结了讨论
编码器的选型经历更曲折：
- 5 月：先用 Kimi K2.5，后升 K2.6
- 6 月 2 号：换成阶跃星辰的 step-3.7-flash——结果实测效果不行，当天就回滚到 deepseek-v4-flash
- 6 月 6 号：锁定 deepseek-v4-flash，直接移除了前端的模型选择器，"每个人都用 deepseek flash"
6 月 12 号的对话里，我说了一句话终结了后续所有模型探索：
"其他的模型都不如 deepseek flash，我自己测试过了你不用试了。"
不是说其他模型不好，是在编码场景下、在我们的模板体系里，deepseek-v4-flash 的综合表现最稳。与其花时间做横评，不如把选定模型的性能榨干。
关闭思考模式：砍半构建时间
这是整个模型优化里最精彩的一段。
DeepSeek 的思考模式（thinking）默认开启——模型在输出答案之前会先内部推理一番。对复杂问题有帮助，但对我们的编码场景来说，推理 token 占了大量时间却没有对等的质量提升。
我半个月前就想关掉它，但一直没成功。问题出在传导链太复杂：
- Claude Code 有个
EFFORT_LEVEL环境变量——设成max看起来像"最大努力"，实际上是在请求最深思考，跟我想要的完全相反 - DeepSeek 的 effort 有一个地板：low、medium、high 全映射到 high，降不下去
MAX_THINKING_TOKENS=0让 CLI 省略 thinking 字段，但 DeepSeek 默认开思考——你不传这个字段它就自己开
最后找到的唯一有效方案：通过代理层显式注入 thinking: {type: "disabled"}。
关闭后的 A/B 测试结果：
- Todo 场景：构建时间从 273 秒降到 140 秒（砍半）
- 赛博朋克模板：构建时间从 398 秒降到 244 秒
- 首 token 响应时间（TTFT）：从 13.6 秒降到 2.8 秒
我检查了关闭思考后的成品质量，没有明显退步。批准上线。
Prompt 瘦身：从 51KB 砍到 33KB
关闭思考的同时，我们做了一轮 coder prompt 瘦身：从 50,950 字符砍到 32,883 字符，减了 35%。
砍掉的主要是"过程管控"类规则——教 AI 怎么批量处理、怎么自我检查、怎么更新 todo。这些规则本意是好的，但实测发现模型并不真的遵守它们，反而增加了 prompt 处理时间。
关闭思考 + prompt 瘦身的组合拳效果：从用户说话到首个可见 UI 变化，115 秒 → 26 秒，快了 4.4 倍。
构建时间的 79-90% 是模型推理。非模型优化（网络、编译、文件 IO）的天花板只有 25-35 秒。真正的杠杆是减少模型思考的时间。
一个关键发现：Context 注入的代价
有一次我们尝试给 Claude Code 注入额外上下文（2-8KB 的快照信息），想让它更好地理解当前状态。
结果 deepseek-v4-flash 的首 token 时间从 30 秒暴涨到 130-180 秒——三到六倍。这是在三场真实生产会议中观测到的，不是 benchmark。
原因是自适应思考模型（deepseek、o1 这类）会根据输入复杂度调整推理深度。你塞越多上下文进去，它思考得越久。对这类模型，"给更多信息"不等于"得到更好结果"，反而可能大幅拖慢速度。
这次之后我们立了一条规矩：任何"往 Claude 输入里推更多内容"的改动，都要先测量端到端延迟，再决定是否上线。
总结：我的模型选型哲学
做了一个多月，沉淀下来几条原则：
- 协调器要快不要强——它的产出是内部 plan，不直接面向用户，够用就行
- 编码器只用一个模型并榨干它——不做多模型路由，不做运行时切换，减少变量
- 分类任务用最便宜的模型——如果所有模型准确率一样，区别只在延迟和成本
- 测量驱动决策——每次模型切换都有 trace 对比和用户验收，不靠直觉
- 不要给自适应思考模型塞太多上下文——它会因此想更久，不一定想更好
最后一条可能是最反直觉的：在 LLM 的世界里，"信息越多越好"这个常识不一定成立。
产品在这：saycraft.ai