1. 为什么我放弃了全上大模型的土豪玩法先说结论大模型想思路、小模型写代码这套组合拳核心不是省钱而是把合适的活儿交给合适的模型。我是在连续踩了三次坑之后才彻底想明白这件事的。第一次踩坑是接了个内部工具项目需求挺简单——解析Excel报表、生成PDF、塞进企业微信机器人。我当时图省事全程用GPT-4级别的大模型API来写prompt写得也很随意。结果月底账单出来光是API调用就烧掉了将近200美元而且代码质量并没有想象中那么高。大模型确实能理解复杂业务逻辑但写一些模板化的CRUD、正则、文件读写时它杀鸡用牛刀还动不动给你自由发挥出多余的依赖。第二次踩坑是反过来的——想省钱全用小模型。结果遇到个稍微复杂的SQL联表查询优化小模型给出的方案明显有逻辑硬伤我在里面硬是排查了两个小时最后发现是它生成的JOIN条件少了个索引字段。那次之后我意识到纯粹在模型大小上做单选题根本就不是正确的解题方式。第三次踩坑最有启发。我尝试在一个项目里同时接入多个模型让大模型做架构设计和任务拆解小模型负责具体函数实现。第一版就跑通了而且成本骤降——之前每天烧掉6-7美元组合拳之后每天不到1.5美元。更意外的是代码质量反而更稳定了因为分工明确之后大模型不用分散精力去写那些低难度代码小模型也不会被超出能力范围的任务带跑偏。这三次经历让我总结出一个核心判断AI编程的成本和效率本质是个任务分级问题。就好比你不会让架构师去填报销单也不会让实习生去设计系统架构——模型选择也应该按任务的认知复杂度来分层。所以这篇文章我想把我实际跑通的这套大模型想思路、小模型写代码的工作流完整拆给你看。没有任何厂商赞助也没有夸大其词的噱头就是一套我可以每天打开终端就在用的方法。适合这几类人看独立开发者API成本敏感但又不想牺牲代码质量小团队技术负责人想把AI编程落地到日常开发流程里对AI编程感兴趣但被模型越大越好洗脑想换个思路的从业者我先把整套架构画在脑子里然后一步步说清楚选哪些模型、用哪些工具、怎么设计任务拆解流程、踩过哪些坑、以及最终实际效果如何。
