用小模型跑赢大模型的工程细节

让几个中等尺寸的开源模型分工协作，在硬核编程测试集上的准确率，能追平甚至超过单次调用顶尖旗舰模型。开源社区最近复现的一组实验展示了这一点：五个Qwen 27B模型在特定协作流程下，解决了绝大多数高难度题目，单次解题中位数成本不到四毛钱，总开销显著低于直接调用顶级闭源模型。

真正起作用的并不是复杂的模型微调，而是非常克制的工程编排。

实验里把任务拆解为规划者、两个独立构思不同算法的提案者、整合解题者、测试执行器以及负责复核的管理者。最关键的设计有两个：第一，每个角色启动时都不携带庞大的历史对话，上下文完全独立，所有状态只保存在磁盘文件中；第二，是否做对由确定性的测试脚本说了算，而不是让模型自己评估自己的输出。

很多团队在构建复杂Agent时，常常把所有角色的对话一股脑塞进长上下文里，最后往往陷入胡言乱语或过度自我确认。让模型退回成纯粹的“计算单元”，用外部文件和传统脚本做硬性约束，反而大幅提升了可靠性。同时，这也意味着在消费级显卡或廉价云端API上，中小团队能够以极低成本获得顶级代码生成能力。

对一人公司或小型技术团队而言，这里隐藏着一个清晰的AI创业方向：针对明确边界的任务，销售高度确定性的自动化解决流程，而不是卖大模型的交互界面。

大企业在采购外部工具时，往往极度排斥不透明的长对话式Agent，因为不可控且计费难以预测。但在数据抓取校验、老旧代码重构、测试用例补全，或者根据特定规范自动生成解析器等窄场景中，企业需要的是“扔进去一个任务，脚本验证通过才交付”。这些场景通常伴随清晰的输入输出标准，非常适合用这种结构化的多小模型流水线去解决。

一人团队完全可以不碰复杂的底层基础设施，直接挑选一个企业内部耗时严重且输入输出定义清晰的环节。例如，专门为金融分析师提供财报数据解析脚本的自动校验服务，或者为特定技术栈提供代码迁移工具。产品形态可以极为轻巧，一个简单的后台队列，一组写死的角色提示词，配合一段确定性的单元测试逻辑。

第一批种子客户通常不在通用开发者社区，而是在那些被繁琐格式转换折磨的垂直行业。你可以直接承接特定格式清洗或测试迁移的手工单，用这套工作流在后台自动化处理，先验证整套链路的准确率与容错率，再考虑产品化交付。

这种模式的风险也很明确。实验中暴露出一个典型问题：一旦管理者角色给出了错误的测试用例或反例，整个小团队就会被带偏，甚至把原本正确的程序推倒重写。把这套流程推向商业化交付之前，如何用穷举校验或交叉验证来防范“机器带偏机器”，是比换用更大模型更需要优先解决的工程瓶颈。