低成本 AI 编程模型的验证阶梯

不要再问一个模型是否足够强大来完成某项任务。

开始问你验证输出的速度有多快。

这种思维转变会改变你使用廉价 AI 模型的方式。不要将它们视为昂贵模型的弱化版。要将它们视为那些具有“短验证路径”任务的执行者。

对于输出结果直观的任务，使用低成本模型。

示例：

• README 清理
• 使用示例
• 代码注释
• 更新日志 (Changelog)
• 小型格式化脚本
• Issue 模板

如果模型写了一个糟糕的 README，你会立即发现。修复起来既快又便宜。

对于可测试的工作，使用低成本模型。

如果你定义了预期行为并运行测试套件，你可以使用更便宜的模型来编写初稿。你必须在提示词 (prompt) 中设定严格的边界。

不要说："Add tests for this helper." 而要说："Add tests for empty input, null input, duplicate values, invalid config, default config, and normal input. Do not change runtime code."

这迫使模型在验证框架内工作。

对于具有明确人工检查任务的，使用低成本模型。

示例：

• CLI 输出格式化
• 配置示例
• 迁移演练 (dry-run) 说明
• 小型数据转换脚本

对于这些任务，强制要求模型包含：

• 如何运行代码
• 使用什么输入
• 预期输出是什么
• 需要检查哪些边界情况

如果模型无法解释如何验证其自身的输出，那就不要信任它。

避免在涉及高风险重构时使用低成本模型。

微小的改动往往隐藏着巨大的危险。一个简短的 diff 可能会破坏回退路径 (fallback path)、权限检查或兼容性分支。

对于涉及以下内容的任务，应提高风险等级：

• 回退机制与默认值
• 路由与权限
• 计费与速率限制
• 迁移与向后兼容性

这些故障在标准的代码审查中很难被发现。它们需要深度的上下文信息。

根据验证成本来分配你的工作：

• 低成本：模型起草。你快速验证。 • 中成本：模型起草。人工编辑。 • 高成本：强力模型协助。需要测试和大量的人工审查。

任务规模并不重要。如果一个任务难以验证，那么它就是昂贵的。

AI 编程的成本不在于生成，而在于信任。

Source: https://dev.to/zephyrelabs369/a-verification-ladder-for-low-cost-ai-coding-models-p16

Optional learning community: https://t.me/GyaanSetuAi