本地 AI 写代码，要看多久交出可用结果

字出来得很快，工作却还没有结束#

设想一个本地编程助手：回答几乎不停顿，改完代码后却反复修测试，最后还要人接手。另一个助手输出慢一点，但修改更集中，一次就通过检查。团队该选哪个？

这是一个选型假设，不是对某款产品的实测结论。它提醒我们，用户真正等待的是可用的修改，不只是屏幕上的文字。

Recursive 于 2026 年 10 月 21 日发布 Flint，一款面向本地编码 Agent 的开放权重模型。它让“把编码助手放在自己设备上”多了一个值得测试的选项。我的判断是：测试单位应该是一套能完成任务的配置，而不是单独一个模型名字。

同一个模型，换个运行方式，速度也会变#

官方 rec 引擎仓库给了一个有用的对照：同样运行 Flint，在 M4 Pro、48GB 内存、4-bit 权重条件下，rec 的生成吞吐量是 llama.cpp 的 1.4–2.6 倍。测试覆盖 1K–252K 的输入长度，每次输出 1,024 token，每种长度运行五次，不计输入提示词处理（prefill）阶段的时间。

“Token”可以粗略理解为模型处理的文字片段；这个指标回答的是生成阶段有多快。这里比较的是同模型的两种引擎，不是两个模型谁更聪明，也不是整个编程任务快了同样倍数。

发布页另报 M4 Pro MacBook Pro 在短上下文下超过 125 token/秒。不要把短输入时的速度当成一个大型仓库长时间工作后的保证。

对产品团队，这意味着验收记录不能只写“用了 Flint”。还要记录权重版本、量化方式、引擎版本、设备和输入长度。量化就是把权重用更省空间的精度保存；它可能改变质量和资源占用，换了之后应该复测。

先确认用户的设备能承接哪一套配置#

模型卡写明，Flint 总参数约 398 亿，每生成一个 token 激活约 25 亿参数。激活得少，有助于减少计算，但不意味着只需要装下那一小部分权重。模型卡中的 BF16（较高精度的权重版本）下载约 80GB，本地量化版本另行提供。

rec 当前列出的要求是 M4 Pro、M5 Pro 或 M5 Max，至少 48GB 统一内存、约 30GB 空闲磁盘；它针对单会话优化。其他运行方式另有条件，因此这些要求也不是 Flint 所有部署方案的统一门槛。

如果产品要服务不同配置的员工电脑，我会先列设备清单，再决定本地能力覆盖哪些人。不要先承诺“人人离线可用”，上线时才发现多数设备不在已验证范围。

同样需要先澄清输入规模：发布页说支持最高 512k 上下文，并推荐不超过 256k；模型卡记载的配置是 262,144 token，输入和输出共同占用。产品承诺应以选定配置的验证结果为准，不能把宣传上限直接写成所有长度都可靠。

公开成绩能帮你选候选，不能替你验收工作流#

Flint 发布评测中的 BF16 版本报告：Terminal-Bench 2.1 为 54.9%，SWE-bench Pro v2 为 89.7%，SWE-bench Verified 为 74.2%。前者考察终端任务，后两者考察代码仓库中的问题解决；三项不是同一套试卷，不能互相比高低。

这些编码 Agent 成绩使用至少五次尝试的平均 pass@1，也就是重复评测单次尝试的成功率，不是让系统试五次、挑一次成功就计分。Terminal-Bench 使用 Terminus 2，可联网；SWE-bench 使用 mini-swe-agent，不联网。它们是安排模型使用工具和执行任务的外层程序。原文给出的 Agent 任务超时上限可达五小时，不能据此推断日常请求几秒就能完成。

模型卡还明确说，不同来源的评测设置有差异。比如 Flint 在 Terminal-Bench 中将联网检索到现成解法的结果计为失败，其他开发者公布的成绩未必这样处理。因此本文不据此给其他模型排座次。

我的产品验收会从一个边界明确的任务开始，比如修复一个已有测试能覆盖的小问题。固定任务、工具权限、上下文和时间预算，分别跑候选配置，同时记录：

• 修改是否通过测试，以及是否改坏了原本正常的行为。
• 从提交任务到通过验收用了多久，包括读输入、生成、运行工具、重试和人工返工。
• 多少任务需要转给更强的模型或人工，转交时已有工作能否保留。

这组记录能帮助团队做具体取舍：如果输出变快，但返工没有减少，就别急着扩大任务范围；如果某一类小任务稳定通过，可以先开放这一类，而不是直接替换所有云端能力。

本地运行，也要保留动作边界#

模型留在设备上，有利于控制推理数据流向。但完整产品还有联网工具、插件、日志和失败后的云端转交。是否会把代码传出去，需要按实际配置检查，不能只凭“本地模型”四个字判断。

我会把读仓库、改文件、执行命令和对外发布分开授权。涉及重要修改时保留人工复核，出现失败时能撤回改动。模型卡也提醒，模型可能生成错误代码或不恰当的工具调用；输出格式正确，不代表动作正确。

本地编码模型的价值，最终要落到一件事上：在用户拥有的设备与可接受的权限内，能否更稳定地交出可用结果。吐字速度值得关注，但它只是验收的起点。

来源与边界#

• 发布来源：Introducing Flint，Recursive；官方更新目录标注发布日期为 2026 年 10 月 21 日。本文讨论发布版 Flint，不把自动研究体系的宣传推演为已证实的普遍收益。
• 模型与评测：RecursiveSI/flint 模型卡，2026 年 10 月 22 日读取。权重采用 Apache 2.0；上述成绩为厂商报告，使用 temperature 1.0、top-p 0.95、top-k 20。不同模型的工具、预算和评分处理不能默认相同。
• 速度与部署：rec 官方 README，同期读取。其引擎对照排除了输入提示词处理阶段，不能代表完成任务的总时延，也不能直接外推到多人并发。
• 未验证的部分：本文没有下载或运行 Flint，没有复现成绩；所读材料未提供真实业务任务的端到端成本、人工返工率或生产安全失败率。硬件购置、维护与人工检查仍是成本，即使本地生成不按 API token 付费。
• 本文判断：设备分层、小任务试点、全流程计时、权限与转交设计是产品建议，不是 Recursive 已验证的业务收益。上线门槛应由自己的任务和风险决定。