批量代码生成降本实践：Kimi-K3-低速版的性价比打法

500个文件的老项目Java 17改造，用Kimi-K3跑完账单21块8，换K3-低速版重跑同样的任务，11块2。活一模一样，钱差了一半。两条路跑的是同一套调度脚本、同一份提示词模板，唯一变量是模型档位，所以这个差价是干净的对照数据。这半年我们组把批量类的代码生成任务全切到了低速版，踩了一些坑，也攒出一套稳定的调度打法，这篇摊开聊聊。

低速版慢在哪，也省在哪

先摆价格。Kimi-K3：输入3.0元/百万tokens、输出1.2元/百万tokens；K3-低速版：输入1.5元/百万tokens、输出0.8元/百万tokens，正好是K3的一半。

代价是速度。实测同一个DTO转Lombok的生成任务，K3平均10秒出结果，低速版要45秒上下。实时对话里这个差距能急死人——你盯着屏幕等它转圈。但批量场景完全反过来：任务扔进队列挂机跑，我在乎的是总账单，不是单个任务响应几秒。下班前提交，第二天早上收结果，45秒和10秒没有区别。补一句体感：低速版的"慢"是排队加生成都慢，白天高峰期一个请求排队十几秒很正常，夜里反而流畅——所以我们的批量任务统一夜里跑，算是把这个档位的错峰定位用足了。

四类活，放心丢给它

不是所有任务都适合省这个钱。半年跑下来，低速版稳定胜任的就四类：

DTO/VO批量转换。 老项目一堆手写getter/setter的DTO，转Lombok的@Data，或者把散落各处的BeanUtils.copyProperties重构成MapStruct的mapper。模式极度固定，模型基本在套模板，低速版和K3干出来的东西没差别。

Java 8升17的适配改造。 java.util.Date换LocalDate、匿名内部类换lambda、清理javax.xml.bind这类被移除的API。单文件改动有明确套路，规则能写成清单。

批量补注释和JavaDoc。 最没技术含量但最磨人的活。老代码十年没人写注释，让模型逐文件读代码补JavaDoc，质量要求不高，人肉再扫一遍改改措辞就行。

多租户分支同步改造。 SaaS版上线前，给两百多个Service方法统一加租户上下文参数，Mapper的XML统一加tenant_id过滤条件。规则就十几条，但触面广——Service入参、ThreadLocal上下文、每条SQL都要过一遍。手工预估两周的活，批量跑一晚上，人只处理了十几个特殊场景。

这四类活的共性：规则固定、单文件简单、量大、偶尔出错重跑也不心疼。K3的强项——复杂逻辑的一次成型率——在这类任务里发挥不出来，等于花钱买了用不上的能力。也有人问为什么不拿K3.1-Pro跑批量：输入2.0、输出1.5元/百万tokens，两头都比低速版贵，强推理能力在套模板的活里同样用不上，纯属浪费。

反过来，三类活别图便宜丢给低速版：跨文件的重构——模型看不全调用链，改完这头漏那头；需要业务决策的改造，比如订单状态机调整；资金强一致相关的逻辑。这些任务低速版一次成型率低，重试烧掉的token加上人工返工，省的钱不够填坑。

一个简单的判断标准：任务能写成"固定的规则清单 + 单文件输入"，就是低速版的菜；需要理解跨文件业务上下文才能做决策的，留给K3或者K3.1-Pro。顺带说一句，Kimi系列三档模型的长上下文都是几十万tokens级的窗口，单个老文件连带相关接口定义整段塞进提示词毫无压力，这也是批量改造敢一文件一请求的底气。

调度脚本：队列、重试、校验，缺一不可

核心结构直接放出来，基于飞算JavaAI的模型接口封装，调度部分是纯Java：

public class BatchRefactorRunner {
    private static final int MAX_RETRY = 3;
    private static final int WORKERS = 3; // 低速版并发别开大，后面讲为什么

    private final BlockingQueue<RefactorTask> queue = new LinkedBlockingQueue<>();
    private final Path failedDir = Path.of("build/refactor-failed");

    public void run(List<Path> files) throws Exception {
        files.forEach(f -> queue.offer(new RefactorTask(f, 0)));
        ExecutorService pool = Executors.newFixedThreadPool(WORKERS);
        for (int i = 0; i < WORKERS; i++) {
            pool.submit(this::consume);
        }
        pool.shutdown();
        pool.awaitTermination(8, TimeUnit.HOURS);
    }

    private void consume() {
        while (true) {
            RefactorTask task = queue.poll();
            if (task == null) break;
            try {
                String prompt = buildPrompt(Files.readString(task.file()));
                String result = callModel(prompt);        // 调模型接口
                if (validate(task.file(), result)) {      // 三层编译校验
                    writeBack(task.file(), result);
                } else if (task.retry() < MAX_RETRY) {
                    queue.offer(task.nextRetry());        // 失败重排
                } else {
                    moveToFailed(task);                   // 落失败目录，人工处理
                }
            } catch (Exception e) {
                log.warn("task failed: {}", task.file(), e);
                if (task.retry() < MAX_RETRY) queue.offer(task.nextRetry());
            }
        }
    }

    static String buildPrompt(String code) {
        return """
            你是Java升级助手。将以下Java 8代码升级为Java 17兼容代码，规则：
            1. java.util.Date/Calendar 替换为 LocalDate/LocalDateTime，保持字段语义
            2. 单方法匿名内部类替换为 lambda（仅限函数式接口）
            3. 禁止修改任何 public/protected 方法签名
            4. 只输出完整文件内容，不要任何解释
            代码：
            %s
            """.formatted(code);
    }
}

validate() 里的校验别只做一层：写入临时目录 → 模块编译 → 全量编译，三道闸都过才算成功。为什么这么狠，下面踩坑部分讲。RefactorTask就是个record，装文件路径和重试次数；用BlockingQueue的好处是失败重排天然线程安全，工作线程无脑poll就行。长上下文在这里也要用足：提示词里除了文件本身，把该文件调用到的接口签名一并贴上，模型改起来心里有谱，一次过率能从八成提到九成以上——多花的输入token没几个钱，值。

提示词怎么写：规则清单比客套话有用

批量任务的提示词，核心不是客套话，是规则清单加反例。每类任务维护一份规则模板，放进仓库跟代码一起review，出问题就迭代。我们Java 17升级这份模板磨到第四版，长这样：

【任务】Java 8 -> Java 17 语法与API升级
【必须】
- java.util.Date/Calendar -> LocalDate/LocalDateTime，时区保持系统默认
- 匿名内部类 -> lambda（仅限函数式接口）
- e.printStackTrace() -> log.warn("...", e)
【禁止】
- 不得修改 public/protected 方法签名
- 不得引入任何新依赖
- 不得改动既有注释与日志文案
- 只输出完整文件内容，禁止解释、禁止markdown围栏
【反例】曾出现模型把 if (user != null) 整段删除——本任务只做API替换，不改控制流

【禁止】那一栏比【必须】还重要。第一版没写"不得引入新依赖"，模型给三个文件偷偷塞了hutool，全量编译找不到包。反例那段更是被坑出来的：有次它把判空逻辑"顺手优化"没了，单测全红。批量场景里模型没有对话上下文可追问，规则写得越死，产出越稳。

两口坑，都是token换来的教训

坑一：合并prompt省token，结果输出截断。 第一批DTO转换我犯了懒，把20个DTO拼进一个prompt，想着省19次的固定开销。结果输出到第12个文件被截断，后半段文件内容残缺，写回之后编译全线飘红，重试又得整包重来，token反而多花一倍。后来死守一条：一文件一请求。失败粒度小，重试只补单个文件，账单再没飙过。

坑二：校验只做了单文件编译。 低速版有一次"好心办事"，把 List<Order> findByUser(Long userId) 的签名自作主张改成了带分页的 Page<Order> findByUser(Long userId, int page, int size)。单文件编译当然过——它自己内部自洽。但调用这个方法的七八处代码全挂了，全量编译一跑才现形。所以校验必须是三层：文件写入成功、模块编译通过、全量编译通过，少一层都防不住模型的"热心"。

附带一个小经验：并发别贪。开10线程跑低速版，半小时吃了七八次限流，降到3路反而全程丝滑。低速版的定位本来就是错峰填谷，压太狠没意义。失败目录里的文件也别急着删，每周扫一遍，把失败原因归类补进规则模板——模板就是这么一轮轮喂出来的。

算一笔账：500个文件的改造任务

按实际跑下来的均值：每个文件改造，输入（文件内容+规则说明）约12000 tokens，输出约3000 tokens，失败重试率按10%计。

输入总量：500 × 12000 × 1.1 ≈ 660万tokens
输出总量：500 × 3000 × 1.1 ≈ 165万tokens

模型	输入费用	输出费用	合计
Kimi-K3	660万÷100万×3.0 = 19.8元	165万÷100万×1.2 ≈ 2.0元	21.8元
K3-低速版	660万÷100万×1.5 = 9.9元	165万÷100万×0.8 ≈ 1.3元	11.2元

单次任务省10块，看着不痛不痒，真正拉开差距的是量。把今年三个季度的批量任务台账拉出来：

任务	文件数	输入tokens	输出tokens
老系统Java 17改造	500	660万	165万
DTO转Lombok	300	320万	90万
批量补JavaDoc	800	850万	210万
多租户分支改造	200	440万	110万

合计输入2270万、输出575万tokens，光这批任务的账单——

K3：2270÷100×3.0 + 575÷100×1.2 = 68.1 + 6.9 = 75.0元
K3-低速版：2270÷100×1.5 + 575÷100×0.8 = 34.05 + 4.6 = 38.65元

再把这些零散批量任务摊到每月，我们组月均消耗输入150M、输出40M tokens——

K3：150×3.0 + 40×1.2 = 498元/月
K3-低速版：150×1.5 + 40×0.8 = 257元/月

一个月差241元，一年接近3000。对我这种自费充额度的小团队来说不是小数。更值钱的是预算分层的思路：批量任务切低速版省出来的额度，砸给K3.1-Pro去跑核心业务逻辑的强推理任务，贵的模型花在刀刃上，而不是浪费在套模板的活里。

时间账也得认：500个文件低速版串行约8小时，晚上提交早上收；3路并发能压进3小时。不赶时间的活，晚半天无所谓。

效果复盘也交代一下：500个文件里467个一次过三道闸，21个重试1次过，12个进了失败目录。人工接手发现真正搞不定的只有3个——一个用了sun.misc.Unsafe，一个靠反射hack私有字段，一个native方法声明；剩下9个只是规则没覆盖到的边角，补进模板后第二批就没再犯。随机抽50个文件人工review，揪出2处语义偏差，都是Date转LocalDate时默认时区的问题，当场修掉。人对批量产出的信任是一点点建立的，前提是抽查不能停。

你手上的批量改造任务还在人肉一行行改吗？你有什么更狠的省钱姿势，评论区聊聊。