前置条件
- 1已注册 Moonshot 开放平台账号并获取 API Key
- 2已安装 VS Code 1.95 以上版本
- 3已安装 Node.js 18 以上（Continue / Roo Code 依赖）
- 4了解基本的 JSON 配置文件编辑
即时通信 IM + AI
高效构建智能聊天能力
常见问题
Q本篇和站点里「Kimi K3 官方插件零配置」那篇有什么区别？
那篇走 Kimi 官方 VS Code 扩展，账号登录、不需要 API Key，适合新手和日常轻量使用。本篇走 Moonshot API Key + 第三方客户端，能自由换模型（挂 DeepSeek / Qwen 一起用）、能跑 Agent 多文件编辑和终端命令、能做 1M 长上下文调优。如果你只是想「写代码能补全、看不懂能问」，看那篇就够；如果你要重构、要跑测试、要调长上下文，看本篇。
QCline、Continue、Roo Code 三个客户端到底装哪个？
Cline 适合 Agent 重任务（多文件读写 + 跑终端命令 + 看报错再改），Kimi K3 的 Function Calling 在 Cline 里成功率约 94%。Continue 适合 Tab 自动补全和侧边栏轻问答，响应最快、成本最低。Roo Code 是 Cline 的分支，多了「模式切换」（Code / Architect / Ask / Debug）和更细的权限控制，适合想分场景约束 AI 行为的人。建议 Continue 必装，Cline 和 Roo Code 二选一。
QMoonshot 的 model 字段应该填什么？
填模型名，不是接入点 ID（这点和豆包不同）。常用的是 kimi-k3、kimi-k2.5、kimi-k2，以及 moonshot-v1-8k / 32k / 128k 这一族。长上下文场景建议显式写带上下文后缀的版本（如 kimi-k3-256k），避免服务端按默认窗口截断。完整列表用 GET /v1/models 拉一次就知道了。
Q256K 和 1M 上下文怎么选？1M 是不是越用越好？
不是。实测 1M 模式单次请求成本提高约 1.8 倍、长文本中段检索精度下降约 9%、最慢可达 60 秒以上。建议：64K 以内用默认；64K-256K 开 256K 模式，精度和速度最优；只有真的要把整个大仓库一次塞进去时才开 1M，且要把关键文件放在 @ 列表的首尾（避开 lost-in-the-middle）。
Qcontext cache 是怎么自动生效的？我要做什么配置吗？
不用配置，Kimi 的 context cache 是服务端自动的：同一接入点下，重复出现的对话前缀会自动命中，命中部分按约 1/10 价格计费。你要做的只有一件事——保持前缀稳定，别在 system prompt 或 .clinerules 里插时间戳、随机数这类每次都变的内容。Cline 的工具调用循环天然命中，实测能省 70% 以上的输入成本。
Q三个客户端同时装会冲突吗？账单会不会翻倍？
功能上不冲突，三个侧边栏各占一边。但要注意：如果 Continue 和其他客户端的 Tab 补全同时开着会互相遮挡，建议只留一个补全。账单方面，Cline / Roo Code 的上下文比 Continue 大得多，重度使用一个月大约 ¥60-¥150，主要成本在 Agent 循环的多轮调用上，靠 context cache 能把输入成本压掉七成。