想用国产模型写代码，先纠结的往往是选 Kimi 还是豆包。两家长处不一样，选错不是不能用，而是会在某些活上反复返工。这篇不排高低，只把「什么活该丢给谁」讲清楚：先给你一套从零跑通的步骤，再按写新代码、查报错、读大文件三类任务拆差异，最后给常见问题和排查顺序。数字和版本都别在正文里记，去站内页面看当时的。
想用国产模型写代码，先纠结的往往是选 Kimi 还是豆包。两家长处不一样，选错不是不能用，而是会在某些活上反复返工。这篇不排高低，只把「什么活该丢给谁」讲清楚。
顺序是这样：先给你一套从零跑通的最小步骤，再按写新代码、查报错、读大文件三类任务拆差异，最后给常见问题和排查顺序。数字和版本都别在正文里记，去站内页面看当时的。
从零开始：先让两家都跑通一个最小请求
别一上来就比谁写得好看，先让两家各返回一次正常结果。路径都一样：拿到 Key、填 Base URL、发一次最简请求。字段怎么填、客户端怎么配，站内已经有专门的文章，这里不重复抄一遍，你照着配就行。
- 对齐协议两家都走 OpenAI 兼容协议，所以同一份调用代码只改 Base URL 和模型名就能互换。协议细节拿不准，去 /ai-dict/category/tech 对照概念，别凭记忆改字段。
- 固定输入再比用同一个提示词、同一段代码、同样的输入长度各跑一遍。换了提示词再比结果，等于白比。
- 记基线跑通后用 /tools/speed-test 量一下延迟和首字速度，存个记录。以后觉得「谁快谁慢」时有据可查，不用吵。
写新代码时的差别：看谁更愿意先问再写
写新代码时，两家的差异主要落在三处：给的是整段一次性代码还是分步推进、遇到模糊需求会不会主动追问、改过的地方会不会自己说清改了什么。这三条比单个函数写得好不好更影响返工量。
需求本来就写得很细，输入输出边界都想清楚了，两家差别会明显缩小。反过来，需求还停在「帮我做个登录」，倾向先确认字段和流程的那家更省事，能少一轮推倒重来。
- 多文件、跨模块的改动，重点看它会不会主动去读相关文件再动手，还是凭上下文猜。猜的那家改完容易其他地方坏掉
- 看它交付时有没有说明改了哪几个文件、为什么这么改，没有说明的，你审查时得自己逐行比
- 什么情况下不适用：只是补一个独立小函数、写一段单测，两家差别基本可以忽略，别在这上面纠结
- 需求模糊又没法追问时，宁可自己先写成几条明确的约束再丢过去，比看它猜得准不准更实在
比较编程能力，先比它问得对不对，再比它写得快不快。
排查报错时的差别：先看它能不能要齐信息
把一整段报错和关键代码贴过去，观察它的第一反应：是反问缺什么，还是直接给一个猜测的修法。前者更适合线上问题，后者适合你已经知道大概问题在哪、只是懒得手改的情况。
更值得看的是它给出的是排查顺序还是一个答案。先排除什么、再验证什么，这种回答在真实排错里更省时间；只盯着结论对不对，容易误判它的水平。
| 观察点 | 倾向先问信息的 | 倾向直接给方案的 |
|---|---|---|
| 报错信息不全时 | 先追问日志、环境、复现步骤 | 给一个猜测修法，让你先试 |
| 适合的场景 | 线上问题、难复现的偶发错误 | 本地小报错、已知原因的机械改错 |
| 你要做的验证 | 补充信息后再让它下结论 | 别直接合入，先跑一遍测试 |
| 风险 | 来回多一轮，慢一点 | 改错方向，白改一遍 |
它说「已修复」之后一定要自己跑一遍，别直接合入。诊断对不对，跑一次测试就知道。另外，涉及生产数据、密钥或内部接口地址的报错，先脱敏再贴，这不是信不信任模型的问题，是流程问题。
读大文件和长日志：上下文放得下不等于用得好
往里塞整个仓库没有意义。先按模块切成几块，一次只给相关的部分加上调用方。给太多，注意力被稀释，回答反而更水。上下文长度的上限口径和计费方式，到 /official-api/providers/moonshotai 看当时的数据，别凭印象。
- 判断标准：让它复述文件里某个具体函数做了什么事，复述错说明没真读进去，后面基于它的改法都不可信
- 长日志优先给它筛选后的片段，报错前后几十行就够，全量丢进去既慢又容易抓错重点
- 读陌生老代码时，让它先画一遍调用关系再改，比直接让它改函数安全
- 什么时候不适用：文件本来就只有一两百行，切不切都一样，直接给全
落地对照：按任务分配，而不是二选一
真正省事的做法不是选一家，而是给自己定一张分工表写进项目里：写新逻辑丢给一家、读陌生老代码丢给另一家、机械改错丢给便宜的那家。按任务切，比按品牌切更稳。
| 任务类型 | 丢给哪类模型 | 验证动作 |
|---|---|---|
| 写新逻辑、设计接口 | 愿意先追问、分步推进的那家 | 让另一个模型审一遍改动 |
| 读陌生老代码、理调用链 | 能准确复述函数行为的那家 | 自己抽查一个函数对照原文 |
| 机械改错、补单测 | 响应稳定、成本低的那家 | 跑一遍测试再合入 |
| 线上报错排查 | 先要齐信息的那家 | 按它给的排查顺序走一遍 |
同一个功能可能两边都被用到，记得在提交信息或分支名里标出是哪家生成的，出问题时好回溯。成本别凭感觉，按你一个月大概跑多少 token 去 /tools/model-cost-calculator 估一遍，再决定哪类活值不值得用贵的。
先把基线跑出来别在纸上比参数，先让两家各返回一次结果、量一下速度，再去动手分任务。→常见问题
直接把同一个 prompt 分别发给 Kimi 和豆包，就能看出区别吗？
能看出一点，但不够。单轮问答只反映提示词表达，反映不了多文件改动、追问缺信息、读长文件这些真实场景。至少跑三类任务：写一个新函数、修一段有报错的代码、读一个中等长度文件并回答细节问题，三轮下来差别才稳。
两家都支持 OpenAI 兼容协议，是不是可以随便换？
接口层可以，行为层不一定。同一份调用代码能跑通，不代表工具调用、结构化输出、流式返回的表现一样。切过去之后先拿你已有的提示词和用例回归一遍，别等上线才发现格式对不上。
团队里有人用 Kimi 有人用豆包，要不要统一？
不必强制统一，但要统一记录口径。至少约定：提交信息里标出模型、关键改动有人复核、出问题能复现。统一模型反而可能让团队失去对比依据，规范流程比统一工具更值钱。
