验证成本才是真正的 AI 编程成本
以前在为编程选择 AI 模型时，我总会问一个问题。
哪个模型足够强大，能胜任这项任务？
这个问题没问题。但它不再是我的首要问题了。
更好的问题是：我能多快验证输出结果？
这种思维方式改变了你使用低成本模型的方式。不要把它们看作是大模型的“弱化版”，而要将它们视为处理“短验证路径”任务的工人。
有些任务的审查成本很低，因为你可以立即看到结果。
• README 清理 • 使用示例 • 代码注释 • 更新日志说明 • 小型格式化脚本 • Issue 模板
如果模型写了一段糟糕的 README，你能一眼看出来。你只需删掉那部分即可。这个错误虽然烦人，但几乎不消耗你的成本。这就是低成本模型的最佳用途。
下一类是可测试的工作。
如果你可以定义预期行为并运行测试套件，那么可以用更便宜的模型来写初稿。你必须给模型明确的边界。
不要说：为这个 helper 添加测试。
要说：为空输入、null 输入、重复值、无效配置、默认配置和正常输入添加测试。不要修改运行时代码。
这迫使模型在验证框架内工作。
有些任务缺乏自动化测试，但允许进行清晰的手动检查。
• CLI 输出格式化 • 配置示例 • 迁移试运行说明 • 小型数据转换脚本
对于这些任务，要求模型包含：
- 如何运行代码
- 使用什么输入
- 预期输出是什么
- 需要检查哪些边界情况
如果一个模型无法解释如何验证它自己的工作，那就不要信任它的代码。
小规模重构是危险的。Diff 可能看起来很短且整洁，但行为可能会在隐藏路径、默认值或权限检查中发生变化。
当任务涉及以下内容时，请提高警惕：
- Fallbacks（回退机制）
- Defaults（默认值）
- Routing（路由）
- Permissions（权限）
- Billing（计费）
- Rate limits（速率限制）
- Migrations（迁移）
- Backwards compatibility（向后兼容性）
这些错误在标准的代码审查中很难发现，它们需要深层的上下文。
按验证成本分配你的工作：
- 低验证成本：使用低成本模型起草。
- 中等验证成本：使用低成本模型，然后由人工编辑。
- 高验证成本：使用强大的模型，并配合测试和人工审查。
任务规模并不重要。如果一个任务难以验证，那么它就是昂贵的。
AI 编程昂贵的部分不在于生成，而在于信任。
Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354
Optional learning community: https://t.me/GyaanSetuAi