同一模型在不同 IDE 中表现差异的根本原因
模型能力 ≠ 实际表现。工具层、System Prompt、上下文管理、任务编排四个维度决定了同一模型在不同 IDE 中的真实体验差距。
核心观点
模型是引擎，IDE 是整辆车。同一台引擎装进不同的车，跑出来的结果取决于传动系统、操控逻辑和调校水平——而不只是引擎本身。
一、工具层（Tool Layer）
模型本身不执行任何操作，它只是「发出指令」，真正干活的是宿主提供的工具。
- 工具定义质量：工具的 name、description 写得好不好，直接影响模型是否能正确选择和调用
- 工具覆盖度：缺少某些工具时，模型会用「次优方案」绕路，结果变差
- 错误处理：工具失败后是否有重试、降级、反馈机制
- 返回值质量：工具返回的内容是否干净、结构化，还是噪音很多
二、提示工程（System Prompt）
System Prompt 是模型的「操作手册」，质量差异极大。
- 角色定义：模型是否清楚自己在做什么任务
- 行为约束：何时主动执行，何时停下来确认
- 任务格式：输出结构是否有明确规范
- 边界处理：模糊指令下该怎么办 Claude Code 的 system prompt 是 Anthropic 内部持续迭代的，Kiro / Cursor 等是各自团队自行维护的。
三、上下文管理（Context Management）
长任务中，如何管理 context window 决定模型「是否记得自己在干什么」。
- 压缩策略：超出窗口时保留哪些信息、裁剪哪些
- 注入时机：代码、文件、错误信息何时注入上下文
- 状态追踪：多步任务中当前进度如何维持 管理差 → 模型后期「失忆」、重复操作、方向漂移。
四、任务编排（Agentic Loop）
多步骤任务需要一个调度循环来驱动模型持续执行。
- 循环设计：何时继续、何时终止、何时等待用户
- 中间状态反馈：执行进度是否回传给模型
- 子任务拆分：复杂任务是否被合理分解后再执行
五、模型选型匹配度
不同模型有不同的「性格」，与宿主场景的匹配度影响表现：
- Opus：能力强，但谨慎、慢，需要宿主给足够清晰的指令
- Sonnet：执行效率高，更适合快速迭代的 agentic 场景
- 宿主如果没有针对模型特性做调优，强模型反而可能不如弱模型流畅
实际排查建议
| 问题现象 | 可能原因 | 应对方式 |
|---|---|---|
| 任务中途卡住 | 工具调用失败没有重试 | 查看 IDE 的 agent log |
| 执行方向偏 | System prompt 不够清晰 | 完善 .kiro/steering 文件 |
| 感觉「笨」、不主动 | 模型过于谨慎 | 试试换 Sonnet，反而更流畅 |
| 执行完不对 | 上下文被截断 | 拆分任务，避免单次 session 太长 |