最近在选型代码模型的时候我把 Fable、Sol、Kimi K3 三个模型一起放到 SlopCodeBench 上跑了一轮实测。SlopCodeBench 这个名字来自代码大模型评测圈和传统基准最大的区别是它不只看代码能不能通过测试用例还看生成代码里有没有“slop”——也就是冗余代码、无效注释、幻觉 API、过度工程这些水分。对真实工程来说这个维度比刷榜分数更有参考价值因为代码是给人读、给人维护的不只是跑一次测试。下面记录我的评测顺序、环境搭建、指标设计和排查经验适合正在做代码模型选型或者想搭建一套可复现评测流程的读者。先给结论三个模型没有绝对赢家。简单函数任务上差距很小但代码冗余度差异明显长文件重构类任务更考验上下文能力和输入结构批量化跑任务时真正决定体验的往往是失败重试、日志和输出命名而不是模型单次生成质量。下面按实际操作顺序拆开说。1. 先搞清楚 SlopCodeBench 在测什么再谈跑分1.1 它和 HumanEval、MBPP 这类基准的差异HumanEval 给一个函数签名和 docstring让模型补全函数体然后跑预置测试用例。MBPP 思路类似给一段任务描述要求写完整实现。这类基准的核心假设是代码只要通过测试用例就算合格。真实工程并不这么认为。代码一旦进入项目就要被同事阅读、测试、修改和扩展。一次生成 20 行代码里面如果有 5 行是复制粘贴的重复逻辑测试用例照样能过但代码评审的人会头疼。更麻烦的是幻觉 API模型编造了一个不存在的第三方库函数测试用例恰好没有覆盖到部署到线上才炸。这些问题传统正确性基准很难量化。SlopCodeBench 的出现就是把“代码干净程度”变成可量化指标。它不是替代正确性测试而是在正确性基础上增加一层质量审查。slop 这个词在英文技术社区通常指“看起来像模像样、实际没有信息量”的生成内容放到代码场景里就是那些补全正确但很脏、很难维护的代码。1.2 slop 在代码里具体长什么样判断 slop 时主要看四类冗余代码同一个逻辑在文件里重复出现或者生成的函数里塞入调用方根本不关心的中间变量。无效注释每行都写注释但注释只是在复述代码本身或者注释和实现对不上。幻觉 API模型生成了看起来像真实库的函数实际不存在或者参数名、返回结构是编的。过度工程一个从数组里取最大值的需求生成三个接口、两个抽象类加一个配置模块。这四类问题很难用单个自动化脚本覆盖。SlopCodeBench 这类评测通常会结合静态检查、代码审查模板和人工抽检。这也是实际评测里最花时间的部分不能只靠跑测试用例给结论得人工把生成代码逐行扫一遍至少在抽样层面上扫一遍。2. 参测模型的基本盘Fable、Sol、Kimi K3 从哪开始对比2.1 三个模型的定位和部署方式三个模型放在一起比较先要搞清楚它们的运行方式否则后面的测评结果没有意义。从公开信息看Kimi K3 是 Kimi 系列里讨论较多的新一代模型。大家比较关注的点有两个一是 2.8T 参数规模对应的 MoE 架构二是本地部署。本地部署之所以被反复提起是因为很多团队处理的是私有代码不适合全量上传到第三方 API。Kimi K3 本地部署的诉求本质上是数据安全诉求。Fable 和 Sol 的公开资料相对少一些。这里不把它们简单归类成某个固定产品而是建议使用前先确认三件事模型是闭源 API 还是有开源权重、上下文窗口和输入格式、部署方式和运行成本。评测前确认这三件事能省掉大量后面排查的时间。这里说的“对比”是评测方法论加实测后的定性观察的组合。你实际拿到的模型版本、接口调用方式和运行环境可能和这里不完全一样这很正常。评测流程的意义就是让你在自己环境里能复现。2.2 评测前必须固定的一组变量代码模型评测最怕变量不统一。同一个模型温度从 0 调到 0.7结果差别会很大。所以开始前要先固定这组变量。变量建议做法原因temperature0 到 0.2减少随机性利于复现top_p1 或关闭降低样本间波动max_tokens按任务最大长度设置防止长代码被截断模型版本锁定版本号或权重 hash避免模型更新影响对比调用方式统一使用补全或对话式接口不同接口输出差异很大这组变量要写进评测报告。否则过两周复盘看到 92 分和 85 分根本不知道是模型差异还是参数差异。我自己就犯过这个毛病后来养成了习惯每次跑评测前先把参数表写死再动任务。3. 评测环境搭起来先小样本再批量最后全量3.1 运行方式API 还是本地部署三个模型有两种运行方式。API 方式最简单有网络和账号 key 就能跑但要注意调用频率限制和账单。本地方式适合 Kimi K3 这类有开源权重、重视数据私密性的场景。本地部署的核心资源是显存和内存。Kimi K3 参数规模大实际部署时因为量化位数、上下文长度、激活参数不同要求差异很大。这里不给具体数字承诺只讲判断方法先看模型文件的量化位数4bit、8bit再看推理框架文档要求的显存下限最后用一小段输入先跑一次确认能启动、能输出。低配置机器能不能跑能跑但前提是任务规模小。如果只是把 20 条函数生成用例跑完量化到 4bit 并把上下文控制在较短范围8G 显存也有机会。但如果要处理 800 行文件重构需要大上下文显存和内存要求会明显上升。我一般分两步验证第一步模型能加载并输出第二步单条任务稳定跑通。两步都过再考虑批量。3.2 样本设计和 prompt 模板SlopCodeBench 不只考算法题更关注真实工程场景。评测样本可以分成四类简单函数生成数组取最大、字符串反转等测基础正确性。文件级修改给一段现有代码要求加功能或修 bug测上下文理解。长文件重构给 800 行以上代码要求抽取公共逻辑测长上下文和结构能力。小项目生成给需求描述生成多文件小项目测整体架构。每类至少 10 个样本总共 40 个。prompt 模板统一只改任务描述里的具体需求。模板示例你是资深软件工程师。请完成下面的编码任务。 要求 1. 只输出需要的代码不要多余说明。 2. 不要添加不存在的函数或库。 3. 代码要直接可运行结构清晰。 4. 不要重复实现已有逻辑。 任务描述 {task}模板里“不要添加不存在的函数或库”这句话很关键它会把幻觉 API 的风险前置暴露出来。模型如果做不到输出结果会非常典型。3.3 执行顺序单条、小批量、全量不要一上来就全量跑。顺序是先用 3 个样本各跑一遍确认输入、输出和日志正常。再按 SlopCodeBench实测：Fable、Sol、Kimi K3代码模型选型对比
最近在选型代码模型的时候我把 Fable、Sol、Kimi K3 三个模型一起放到 SlopCodeBench 上跑了一轮实测。SlopCodeBench 这个名字来自代码大模型评测圈和传统基准最大的区别是它不只看代码能不能通过测试用例还看生成代码里有没有“slop”——也就是冗余代码、无效注释、幻觉 API、过度工程这些水分。对真实工程来说这个维度比刷榜分数更有参考价值因为代码是给人读、给人维护的不只是跑一次测试。下面记录我的评测顺序、环境搭建、指标设计和排查经验适合正在做代码模型选型或者想搭建一套可复现评测流程的读者。先给结论三个模型没有绝对赢家。简单函数任务上差距很小但代码冗余度差异明显长文件重构类任务更考验上下文能力和输入结构批量化跑任务时真正决定体验的往往是失败重试、日志和输出命名而不是模型单次生成质量。下面按实际操作顺序拆开说。1. 先搞清楚 SlopCodeBench 在测什么再谈跑分1.1 它和 HumanEval、MBPP 这类基准的差异HumanEval 给一个函数签名和 docstring让模型补全函数体然后跑预置测试用例。MBPP 思路类似给一段任务描述要求写完整实现。这类基准的核心假设是代码只要通过测试用例就算合格。真实工程并不这么认为。代码一旦进入项目就要被同事阅读、测试、修改和扩展。一次生成 20 行代码里面如果有 5 行是复制粘贴的重复逻辑测试用例照样能过但代码评审的人会头疼。更麻烦的是幻觉 API模型编造了一个不存在的第三方库函数测试用例恰好没有覆盖到部署到线上才炸。这些问题传统正确性基准很难量化。SlopCodeBench 的出现就是把“代码干净程度”变成可量化指标。它不是替代正确性测试而是在正确性基础上增加一层质量审查。slop 这个词在英文技术社区通常指“看起来像模像样、实际没有信息量”的生成内容放到代码场景里就是那些补全正确但很脏、很难维护的代码。1.2 slop 在代码里具体长什么样判断 slop 时主要看四类冗余代码同一个逻辑在文件里重复出现或者生成的函数里塞入调用方根本不关心的中间变量。无效注释每行都写注释但注释只是在复述代码本身或者注释和实现对不上。幻觉 API模型生成了看起来像真实库的函数实际不存在或者参数名、返回结构是编的。过度工程一个从数组里取最大值的需求生成三个接口、两个抽象类加一个配置模块。这四类问题很难用单个自动化脚本覆盖。SlopCodeBench 这类评测通常会结合静态检查、代码审查模板和人工抽检。这也是实际评测里最花时间的部分不能只靠跑测试用例给结论得人工把生成代码逐行扫一遍至少在抽样层面上扫一遍。2. 参测模型的基本盘Fable、Sol、Kimi K3 从哪开始对比2.1 三个模型的定位和部署方式三个模型放在一起比较先要搞清楚它们的运行方式否则后面的测评结果没有意义。从公开信息看Kimi K3 是 Kimi 系列里讨论较多的新一代模型。大家比较关注的点有两个一是 2.8T 参数规模对应的 MoE 架构二是本地部署。本地部署之所以被反复提起是因为很多团队处理的是私有代码不适合全量上传到第三方 API。Kimi K3 本地部署的诉求本质上是数据安全诉求。Fable 和 Sol 的公开资料相对少一些。这里不把它们简单归类成某个固定产品而是建议使用前先确认三件事模型是闭源 API 还是有开源权重、上下文窗口和输入格式、部署方式和运行成本。评测前确认这三件事能省掉大量后面排查的时间。这里说的“对比”是评测方法论加实测后的定性观察的组合。你实际拿到的模型版本、接口调用方式和运行环境可能和这里不完全一样这很正常。评测流程的意义就是让你在自己环境里能复现。2.2 评测前必须固定的一组变量代码模型评测最怕变量不统一。同一个模型温度从 0 调到 0.7结果差别会很大。所以开始前要先固定这组变量。变量建议做法原因temperature0 到 0.2减少随机性利于复现top_p1 或关闭降低样本间波动max_tokens按任务最大长度设置防止长代码被截断模型版本锁定版本号或权重 hash避免模型更新影响对比调用方式统一使用补全或对话式接口不同接口输出差异很大这组变量要写进评测报告。否则过两周复盘看到 92 分和 85 分根本不知道是模型差异还是参数差异。我自己就犯过这个毛病后来养成了习惯每次跑评测前先把参数表写死再动任务。3. 评测环境搭起来先小样本再批量最后全量3.1 运行方式API 还是本地部署三个模型有两种运行方式。API 方式最简单有网络和账号 key 就能跑但要注意调用频率限制和账单。本地方式适合 Kimi K3 这类有开源权重、重视数据私密性的场景。本地部署的核心资源是显存和内存。Kimi K3 参数规模大实际部署时因为量化位数、上下文长度、激活参数不同要求差异很大。这里不给具体数字承诺只讲判断方法先看模型文件的量化位数4bit、8bit再看推理框架文档要求的显存下限最后用一小段输入先跑一次确认能启动、能输出。低配置机器能不能跑能跑但前提是任务规模小。如果只是把 20 条函数生成用例跑完量化到 4bit 并把上下文控制在较短范围8G 显存也有机会。但如果要处理 800 行文件重构需要大上下文显存和内存要求会明显上升。我一般分两步验证第一步模型能加载并输出第二步单条任务稳定跑通。两步都过再考虑批量。3.2 样本设计和 prompt 模板SlopCodeBench 不只考算法题更关注真实工程场景。评测样本可以分成四类简单函数生成数组取最大、字符串反转等测基础正确性。文件级修改给一段现有代码要求加功能或修 bug测上下文理解。长文件重构给 800 行以上代码要求抽取公共逻辑测长上下文和结构能力。小项目生成给需求描述生成多文件小项目测整体架构。每类至少 10 个样本总共 40 个。prompt 模板统一只改任务描述里的具体需求。模板示例你是资深软件工程师。请完成下面的编码任务。 要求 1. 只输出需要的代码不要多余说明。 2. 不要添加不存在的函数或库。 3. 代码要直接可运行结构清晰。 4. 不要重复实现已有逻辑。 任务描述 {task}模板里“不要添加不存在的函数或库”这句话很关键它会把幻觉 API 的风险前置暴露出来。模型如果做不到输出结果会非常典型。3.3 执行顺序单条、小批量、全量不要一上来就全量跑。顺序是先用 3 个样本各跑一遍确认输入、输出和日志正常。再按