低成本AI工作流：为什么任务边界、测试和回读比模型价格更重要

有一次，我把一项边界很清楚的代码任务交给了低成本模型。

它按要求交了文件，也写了测试，程序确实能跑。可我重新核对真实目标时，还是发现了三处错误配置。它没有卡住，没有报错，甚至看起来完成得挺漂亮。

这反而比直接失败更危险。直接失败会逼着人停下来，安静的错误却会顺着下一步继续走：先进入构建，再进入部署，最后出现在用户面前。如果没有人在中间回头看一眼，所谓“便宜”，只是把成本从调用账单挪到了返工和事故里。

我以前想得更简单。重复、机械、范围明确的事情，当然应该交给更便宜的模型和本地脚本。能力强、价格更高的模型，只留下来处理架构、复杂判断和真正需要创造力的部分。

这个方向我现在依然认同。我的判断变化在另一处：分工本身并不会自动省钱。真正省钱的是，分出去以后，每一步仍然知道自己在做什么，错了会停在哪里，谁来判断它到底算不算完成。

模型可以便宜，完成标准不能含糊

如果任务只是“帮我把这段代码优化一下”，模型很容易给出一个看起来完整的答案。

可“完整”到底是什么意思？是文件生成了，还是测试真的跑过？是本地页面能打开，还是线上路径也正确？是程序没有报错，还是用户真正完成了那一步？

这些问题如果不提前说清楚，能力再强的模型也只能猜。低成本模型猜错的概率也许更高，但问题不只在模型。很多时候，是我们把一个模糊愿望扔给它，却期待它交回一个可以直接上线的产品。

所以我现在更在意任务包里的几件事：允许改哪里，输入从哪里来，最后应该产出什么，用什么测试验收，失败以后怎么退回。

它们听起来像管理流程，但其实更像公路上的护栏。护栏不会替司机开车，也不会让车跑得更快；它只负责在判断失误的时候，不让一次偏离直接变成翻车。

能用脚本判断的事，不再让模型凭感觉判断

这段时间，我正在把重复同步、定时轮询和健康检查交给本地确定性脚本。

原因并不复杂。一个文件是否存在、接口是否返回预期状态、页面标题是否变化，这些问题本来就有明确答案。让模型反复判断，不仅浪费额度，还会让同一件事在不同时间得到不同解释。模型更适合处理另一类问题：这个变化值不值得做成产品，文章里的判断有没有信息差，两个看似相近的需求究竟是不是同一件事。

脚本负责说“发生了什么”，模型负责讨论“这意味着什么”。但就算这样，最后仍然需要回读。

代码测试通过，不代表产品已经上线；发布工具点击成功，不代表平台页面真的出现了内容；调度器显示正常结束，也不代表业务动作已经完成。

我现在越来越相信，很多自动化最缺的不是更聪明的执行者，而是最后那一下确认：真实世界到底有没有发生我们以为发生的事。

复杂度没有消失，只是应该放在更值得的位置

反过来说，这套做法也可能被批评为太重。

如果只是做一个临时原型，或者验证一个随时可以丢掉的想法，把范围、回滚、回读都写得很细，确实可能比直接动手还慢。不是每一个小动作都值得建一套完整流水线。

这个反方意见我认同。我还在摸索的，是哪类任务应该轻装上阵，哪类任务一旦开始重复，就必须补上门禁。现在能确定的边界只有一个：当任务会接触公开发布、用户数据、账号权限，或者它会日复一日地自动运行时，错误就不再是一次性的。省掉的那点设计时间，很可能只是晚一点再付。

所以我现在并不急着证明某个模型一定更强，也不想为了省额度把所有事情都交给便宜工具。

我更关心的是：低成本模型做它真正能胜任的事；脚本接走那些有标准答案的重复动作；复杂判断和最终发布，仍然留在有人负责的位置。

模型越来越便宜是好事。但如果错误也因此变得更安静，我们真正需要升级的，就不是下一次模型选择，而是那道能在上线前把错误拦下来的门。