Claude Code 额度不够时很容易先问一个问题哪些任务可以交给低成本模型这个问题没错但我现在会先补一句这个任务有没有独立的验证证据如果没有便宜模型写得再快后面也可能把 review 成本吃回来。1. 为什么不能只看生成成本低成本模型最容易被误用的地方不是它不会写代码而是它很会把“看起来能通过”的东西一起写出来。比如让同一个模型写 patch补测试解释为什么测试能证明没问题表面上流程很完整实际上验证者和生成者是同一个来源。这时候测试可能只是在验证模型自己以为的行为而不是验证真实需求。所以我现在会把任务先拆成两件事生成能不能便宜验证能不能独立、便宜、可复查第二件事更重要。2. repro有没有最小复现不要只写配置为空时报错。更好的写法是输入空 JSON 文件 {} 触发路径导入 - 校验 - 报错 期望空配置走默认配置并提示缺省项如果连最小复现都写不出来这个任务还不适合交给低成本模型直接改。因为模型不知道自己要修的是哪个行为只会猜一个看起来合理的行为。3. expected behavior正确行为是什么“不要报错”不是足够清楚的验收标准。更具体的 expected behavior 应该像这样空配置 - 加载默认配置 记录一条缺省提示 不静默吞掉 不直接抛栈这一步的作用是把“模型以为的行为”和“产品实际要的行为”分开。很多小 bug 不是因为模型不会写代码而是因为它把默认值、fallback 或兼容逻辑猜错了。4. existing tests有没有已有测试这里要注意existing tests 指的是已有测试不是模型刚补出来的测试。如果原来就有 config import suite而且覆盖了空配置那这个任务的验证成本比较低。如果没有覆盖就诚实写existing tests: config import suite但未覆盖空配置这不是坏事。空值的意义是告诉自己这块要靠人验不能让模型自己补一个 green test 就当通过。5. logs有没有真实日志或输入输出日志必须是跑出来的不是模型解释出来的。可以是线上错误堆栈本地复现输出一份匿名后的输入样例CLI 实际输出不能是模型总结的“应该会报错”模型编出来的日志没跑过的预期输出低成本模型可以帮忙整理日志但不能凭空生成日志当证据。6. diff risk这次改动碰到了哪些边界我会特别看这些词fallback默认值权限计费迁移公共接口隐藏状态变化如果 diff risk 落在这些地方我不会只看 diff 大小。有些改动很短但风险很高。比如把一个默认值从false改成true代码只改一行但行为可能影响很多用户。这类任务不适合直接让模型一路改完。7. human acceptance哪些地方必须人确认最后一项是 human acceptance。比如默认配置语义不能变 提示文案需要产品确认 迁移逻辑需要人工 review这一步不是形式主义。它是在说明哪些判断不能交给模型自己决定。如果 human acceptance 是空同时任务又碰到了默认值、权限、计费或迁移我会默认它还不能进自动化流程。8. 我的简单判断规则低成本模型适合先写草稿的前提是证据独立 证据便宜 证据可复查如果证据只有模型自己的解释或者只有它自己刚写的测试那它最多是草稿。真正省成本的不是生成便宜而是验证也便宜。Claude Code 额度不够时低成本模型当然可以帮忙。但在写代码前我会先问这 6 个验证证据有没有准备好。