很多人用 AI coding 工具时会先按模型强弱分任务。我现在更倾向于按“验证成本”分。因为低成本模型写出来的代码不是不能用。真正的问题是你能不能快速确认它没写坏。下面这 7 个检查点是我现在拆 routine coding 任务前会先看的。## 1. 任务能不能一句话讲清楚如果一个任务要解释半天说明它可能不是 routine task。适合拆出去的任务一般很清楚- 补 README 示例- 给这个函数补 5 个边界测试- 把 CSV 转成 JSON- 修这个类型错误- 整理 changelog如果 prompt 写着写着变成需求文档那就别急着交给便宜模型。## 2. diff 会不会很小低成本模型适合先处理小 diff。但这里的小不只是行数少还要行为简单。比如改 README行数多一点也没关系因为不影响运行时。但一个 routing helper 只改 20 行也可能很危险因为它可能影响 fallback。## 3. 输出是不是容易 reviewreview 成本低才是真的便宜。适合低成本模型的输出通常有这些特点- 一眼能看懂- 错了容易删- 不影响线上行为- 不需要理解太多业务上下文文档、示例、测试、格式化脚本大多在这个范围里。## 4. 有没有测试有测试的任务更适合拆。尤其是你能提前列出边界- 空输入- null- 重复值- 非法参数- 默认配置- fallback- 正常输入如果模型写完以后测试能跑过至少有一层兜底。没有测试也不是不能做但风险要上调。## 5. 有没有手动验证步骤有些小工具和配置样例不一定有测试但可以手动验。我会要求输出里带上1. 怎么运行2. 输入什么3. 预期输出是什么4. 哪些边界要看如果验证步骤讲不清楚说明这个任务可能不适合自动拆。## 6. 有没有隐藏行为这是最容易翻车的地方。只要碰到下面这些我会默认提高风险- fallback- 默认值- 权限- 支付- 计费- 限额- 兼容逻辑- 数据迁移这些地方的问题不一定会报错但可能会悄悄改行为。小重构就是典型例子。代码看着更干净但默认分支变了。## 7. review 成本是不是低于自己重写最后一个问题最现实我检查它的时间会不会比自己写还久如果你要花 30 分钟确认一个 10 分钟能写完的 patch那这个任务就不该拆。低成本模型省的是低判断成本任务的时间不是替你省掉判断。## 我现在的任务分层比较适合- 文档- 示例- 测试- 类型修复- lint- 小脚本可以起草- issue template- API wrapper- 配置样例- 简单迁移说明不建议直接交- 重构- routing- fallback- 默认值- 权限/计费/支付- 没测试的业务逻辑## 总结低成本模型适不适合写代码不是一个抽象问题。更好的问法是这个任务生成便宜验证也便宜吗如果生成便宜、验证很贵那最后可能一点都不省。AI coding 的成本不只在 token还在 review。拆任务前先把验证路径想清楚比纠结模型强弱更重要。