写代码这件事我这半年基本已经离不开 AI 了。不夸张地说我最近几个个人项目的代码八九成都是 AI 帮着写的。但这里有个前提我不是只靠一个模型硬扛。我是拿贵的大模型当“技术顾问”来用让它帮我拆需求、定方案、理清思路真正落地写代码的时候换成本地跑的小模型上场让它按着既定方案去执行。这套“大模型想思路小模型写代码”的组合拳打下来我实际体验了三个多月最大的感受就四个字省钱高效。先说清楚这套思路到底解决了什么问题。如果你试过全程用 GPT-4 这类大模型写代码大概率遇到过几个痛点一是贵稍微复杂的任务聊上几十轮几块钱就没了二是慢云端服务高峰期响应有时候能拖到十几秒三是上下文容易乱聊到最后模型经常把前面的需求忘了改一处崩三处。而纯用本地小模型呢也不是不行就是代码写得太“平”没有设计感——让它写个工具函数没问题你一让它做技术选型或者梳理模块边界它就露怯了。后来我调整了用法让两类模型各干各擅长的活这才真正把 AI 变成了顺手好用的“开发搭子”。这篇文章我就把整个组合拳的打法、工作流、成本账、以及踩过的坑从头到尾捋一遍你如果也在用 AI 辅助开发或者正纠结要不要本地部署小模型可以参考我这套方案能少走不少弯路。1. 组合拳的核心思路让模型干自己最擅长的活1.1 为什么不是“一个大模型干到底”很多人用 AI 写代码习惯是一路聊到底从“帮我写个登录功能”开始一直聊到“把 Redis 缓存加上”“改成 JWT 登录”全程靠一个大模型输出。这个用法不是不行而是效率很低。原因在于模型的能力是有“偏好”的。能力越强的模型它的“推理深度”和“上下文理解能力”越强但这也意味着它每次响应都要消耗更多的计算资源反应更慢、成本更高。你拿这种模型去生成一堆重复性高的样板代码、CRUD 接口、配置文件本质上是在用大炮打蚊子既浪费钱又浪费时间。反过来能力弱一些的小模型虽然整体智力不如大模型但它的“响应速度”和“单次成本”有压倒性优势。让它机械地按既定规范去生成代码它反而比大模型更听话——不会自由发挥也不会动不动就自作主张加一堆你不需要的东西。所以我后来把工作流拆成了两层就像公司里“设计师”和“施工队”的关系。大模型负责画图纸、定标准、解难题小模型负责按图施工、批量执行。图纸清楚施工队干活就不会跑偏图纸模糊再强的施工队也只能瞎猜。1.2 大模型和小模型的边界到底画在哪经过一段时间的使用我总结了一套相对稳定的分工规则按任务类型来划分边界大模型负责需求分析、技术选型、系统设计、算法思路梳理、代码审查、疑难 Bug 排查、写提示词模板。小模型负责生成常规代码、补全函数实现、编写单元测试、处理 JSON 解析、翻译旧代码、批量生成配置文件。这套分工的核心逻辑是“思考类”任务天然需要强推理能力这类任务量少、频次低不能省“执行类”任务量大、模式固定追求的是速度和成本没必要用大模型。举个例子我前段时间做一个数据采集项目需要把 30 多个网站的页面解析逻辑统一梳理一遍。我先用大模型分析了不同网站的 DOM 结构差异让它给出了一套统一的解析框架和接口规范框架定好之后剩下的每一类页面的具体解析函数就全扔给本地小模型去写。小模型按着统一的接口规范批量生成代码速度飞快而且因为规范定得死它也没法自由发挥。整个过程很顺畅几乎没有返工。2. 落地这套方案需要准备什么2.1 模型选型大模型选谁小模型选谁先说我目前实际在用的组合作为参考大模型这一端我选的是云端 API 接入方式。主要用 DeepSeek 的 API 做日常的思路梳理和技术设计偶尔涉及复杂的代码审查会切到更贵的模型。选择标准很简单智商在线、上下文窗口够长、API 稳定。为什么不用本地部署大模型因为考虑到成本单是买一张能跑得起 70B 以上参数模型的显卡就已经是一笔不小的开销了再加上电费和机器折旧综合算下来远不如按量付费的 API 划算。除非你有强烈的数据隐私要求否则日常开发用云端 API 是最优解。小模型这一端我选择本地部署。最早用过 Ollama 跑 Qwen2.5-Coder-7B后来试过 CodeLlama-7B 和 DeepSeek-Coder-6.7B综合体验下来 Qwen2.5-Coder 系列最适合写代码。一个是它对中文指令的理解比较好代码生成的“手稳”另一个是生态完善社区里有大量量化好的版本可以直接下载。推荐配置参考小模型方案硬件要求实际体验Qwen2.5-Coder-7B-Q48GB 显存即可代码生成质量高速度约 30-50 token/sQwen2.5-Coder-14B-Q416GB 显存理解能力明显提升速度约 20-30 token/sDeepSeek-Coder-6.7B8G 显存老牌选择代码补全质量好但中文理解一般我自己用的是 3060 12GB 显卡跑 7B 量化版单次生成速度完全够用日常写代码的时候几乎感知不到延迟。2.2 工具链怎么串起来API 调用和本地模型的协同工具链路这部分我踩过不少坑刚开始是两套工具来回切换浏览器开一个大模型网页当“顾问”本地再开一个 IDE 插件写代码。但这样来回切换的割裂感很强用起来难受。后来我把整条链路整合成了这样思路阶段用 API 调用大模型我写的提示词走官方 SDK 直接请求返回结果保存成 Markdown 文档。编码阶段本地跑 Ollama 服务暴露一个 OpenAI 兼容的接口给开发环境调用通过 Continue 这个插件接入 VS Code。审查阶段写好的代码批量调用大模型 API 做 Review检查逻辑漏洞和潜在 Bug。这里要重点说一下本地小模型的真正杀手锏是“OpenAI 兼容接口”。现在主流的本地推理框架都支持这个协议这意味着你代码里只要写一份base_urlhttp://localhost:11434/v1的配置就能无缝切换云端大模型和本地小模型。我写了一个简单的工具脚本通过环境变量控制走本地还是走云端这样日常的机械代码生成默认走本地遇到复杂问题再手动切到云端大模型。3. 实操演示一整套完整开发流程是怎么跑的3.1 第一步用大模型把方案想清楚这部分很关键。很多 AI 辅助开发翻车问题不在写代码那一步而在“需求没拆清楚”就急着让 AI 写。正确做法是先用大模型把方案聊透。比如我之前接到一个需求要写一个 Python 脚本从多家电商平台抓取商品价格并定时对比历史价格生成降价提醒。如果我直接把这句话甩给小模型它大概率会给他搞一个粗制滥造的爬虫脚本代码能用但健壮性很差不去处理反爬不懂设置代理更不会用异步。市面上很多教程都这么写但生产环境根本没法用一跑就被封。我用大模型梳理思路时的提示词大致是这样的我需要开发一个多平台商品价格监控脚本。 现状没有现成代码从零开始。 约束目标网站各不相同反爬策略差异大每天跑一次数据量不大要兼顾稳定性和可维护性。 请帮我 1. 拆解这个项目需要的核心模块和每个模块的职责边界 2. 对比“纯requests同步”和“httpx异步”两种方案推荐一个并说明理由 3. 给出数据库表结构设计 4. 列出可能遇到的反爬风险和应对策略。大模型返回的答案基本覆盖了所有关键点它建议用httpx异步方案理由是对比 requests 更适合批量请求场景给出了products、price_history、alert_rules三张表的建表 SQL还提前指出“频率控制、User-Agent 池、失败重试”这三件事必须在设计阶段就考虑。这份思路文档就是后面小模型写代码的“施工图纸”照着它写不会跑偏。3.2 第二步把方案拆成小模型能看懂的任务方案文档有了但直接整篇喂给小模型可不行。小模型的上下文窗口有限一次性塞太多内容它会丢三落四。正确做法是把任务拆成一个一个的“小卡片”每张卡片只做一件事边界要清晰。我用的是这种任务卡片模板任务实现 fetch_price(product_id) 输入product_id (int)商品ID 输出当前价格(float)和抓取时间(datetime) 规则 - 目标URL从数据库读取格式见 schema.sql - 请求 headless 浏览器模拟 - 失败要重试3次间隔2秒 - 返回值的字段名统一为 price 和 fetched_at 参考代码关联上一个任务文件 fetch_products.py 中的 get_page 函数每张小卡片的信息密度不用太高重点是“前面模块的输出是什么后面模块的输入要什么”。小模型拿到了清晰的输入输出规范生成的代码准确率会大幅提升。我实测下来任务拆得越细小模型代码的可用率越高。如果直接把一个大模块扔给它经常会出现接口对不上、字段命名不统一的问题返工成本反而更高。3.3 第三步小模型批量执行写代码方案拆好之后就到了小模型的主场。我实际在 VS Code 里用 Continue 插件配 Ollama连续写了十几个函数。生成速度基本是秒回体验很流畅。中间遇到一个细节值得拿出来说小模型写的代码风格比较“平”不太会考虑异常场景。比如让它写“从数据库读取商品信息”这个函数它可能只会处理正常情况不会捕获连接异常也不会处理数据库没数据的情况。后来我在任务卡片里专门加了一行“必须考虑异常处理”情况立刻好转。小模型不是不会写而是你不说它就不做有点像执行力很强但主动性不足的初级工程师你得把需求写清楚、把边界画明白。再一个技巧是用“参考代码”来约束风格。同一套系统里如果第一个文件的代码风格是snake_case第二个文件小模型可能会写成camelCase。解决方法很简单每个任务卡片都附上一小段已生成的代码让它照着风格写。这样整体代码的一致性会好很多。3.4 第四步大模型做 Code Review 兜底小模型批量生成的代码质量能到“能跑”的级别但要直接上线心里还是没底。这时候就需要大模型出马做审查。我把整个项目的代码目录结构和小模型生成的关键代码文件发给大模型提示词大概意思是请审查以下代码重点关注 1. 并发场景下的数据一致性 2. 数据库连接是否及时释放 3. 是否有隐藏的异常处理漏洞 4. 代码风格是否一致。 输出格式按“问题严重性高/中/低”列表给出每个问题附修改建议。大模型一次 Review 帮我发现了 7 个潜在问题。印象最深的两个一个是小模型写的数据库查询没有设置超时时间在数据库响应慢的情况下整个爬虫会被卡死另一个是某个函数在try里捕获了所有异常会把KeyboardInterrupt也吞掉导致 CtrlC 都无法停止程序。这两个问题靠我肉眼 Review 不一定能看出来但大模型一眼就抓到了。这套流程走完其实只花了很少的成本。做方案和审查用的大模型 API全部算下来不到 10 元钱本地小模型跑的代码生成除了电费等于零成本。4. 算一笔帐组合拳到底省了多少4.1 成本对比全用云端大模型 vs 组合拳我知道很多人关心钱的问题我拿实际数据说话。做那个商品价格监控项目我对比了两种方案。方案A全程用云端大模型编码。从需求分析到最终代码完成大概经历了 200 次交互其中大模型单次响应平均消耗 2000-3000 token再加上对话历史反复回传消耗的 token一次交互的成本大约在 0.05-0.08 元。但麻烦的是聊到最后上下文太长模型容易“忘事”导致重复改代码。实际跑下来总花费超过 40 元耗时约 3 天其中大量时间在等待响应和反复调对话。方案B用组合拳重新做一遍。大模型只需要 10 次左右的交互定方案 逐步 Review每次消耗较多但总成本很低小模型写代码约 40 次交互全走本地零成本。总花费不到 5 元实际开发时间压缩到 1.5 天。成本项方案A全用大模型方案B组合拳API 调用费约 40 元约 5 元等待响应时间累计约 3 小时约 20 分钟代码返工次数4 次1 次最终项目总耗时3 天1.5 天对于高频使用 AI 辅助开发的场景这种成本差距会更明显。如果你每天写 50 次代码生成请求全用大模型一天就是好几块钱全走本地小模型成本是零。一个月下来差距就是上百块一年就是上千块。如果你是独立开发者或者小团队这不是一笔可以忽略的钱。4.2 省的不只是钱更是等待的时间比省钱更重要的其实是省时间。云端大模型在高峰期响应慢有时候一条生成请求要等 10-20 秒。本地小模型呢7B 量化模型在我的 3060 上能跑到 40 token/s写一段 100 行的代码也就 20 秒左右而且这个速度是稳定的不会因为人多排队就变快变慢。更爽的是本地模型无限次调用不心疼。你完全可以让它试错生成一种写法不满意改提示词再来一次再不满意换个角度重写。云端大模型你每次提问都要算钱心里总会不自觉地去“省着用”反而降低了探索的欲望。而本地模型没有这个心理负担可以放手让它多试几版优中选优。5. 常见问题与排查技巧实录5.1 小模型生成的代码质量不稳定怎么办这是我被问到最多的问题。本地小模型不是每次都能生成完美的代码偶尔也会出现逻辑错误、API 用错的情况。我的经验是“三分靠模型七分靠提示词”。小模型对模糊指令的容错率低所以提示词里的每个细节都很重要。具体来说有三个提升质量的关键点第一给出具体的输入输出示例。不要只说“写一个函数解析日期”而是给一个真实的示例“输入 2025-03-15 14:30:00输出 datetime 对象”。小模型看到示例生成的代码准确率会高很多。第二把大模型的方案文档片段直接贴在任务卡片里。比如技术选型是大模型定的“用 httpx 异步请求”就把这句话原样写进提示词。小模型不会自己去做技术选型但如果你告诉它选型结果它会非常忠实地执行。第三限定代码风格和框架版本。明确说“使用 Python 3.10 语法使用 SQLAlchemy 2.x 版本”这种硬约束能避免很多兼容性问题。5.2 本地部署小模型常见的坑本地部署本身的坑也不少分享几个典型的坑一Ollama 默认只监听本机地址。如果我想让局域网内另一台电脑也用这个模型就不能直接用默认配置。需要在启动时设置环境变量OLLAMA_HOST0.0.0.0这样才能通过局域网 IP 访问。坑二显存不够会疯狂卡顿。模型一跑就占满显存再开 IDE、浏览器整个电脑都会变慢。解决办法一个是换更小的量化版本另一个是调整 Ollama 的并发参数让它同时只能处理一个请求。坑三模型的“幻觉”比想象中更隐蔽。小模型在生成代码时可能会“编造”一个根本不存在的库函数而且编造得非常自然。比如让它写文件操作它可能会瞎编一个filehelper模块。每次生成完代码我都要求它“列出用到的外部依赖”方便我核对是否真实存在。5.3 什么时候必须切回大模型并不是所有代码任务都适合交给小模型。我总结了几种“必须切回大模型”的场景跨模块重构涉及多个文件、多个模块的改动小模型往往顾此失彼改一个地方破坏了另一个地方。性能优化需要深入分析算法复杂度、数据库索引、缓存策略的问题小模型给出的建议经常是在“皮毛”层面。框架兼容排查升级依赖后出现了一堆报错需要综合判断报错原因时小模型根本处理不了这种复杂上下文必须靠大模型的大窗口和强推理能力才能兜住。实际上这也是组合拳的核心优势永远不要求某一个模型面面俱到而是让它们在各自擅长的场景里发挥最大的价值。需要思考时我不吝啬那几毛钱的 API 费需要执行时我也不浪费大模型的算力去写那些重复代码。6. 这套打法还能怎么扩展6.1 从“写代码”走向“审代码”我最近在尝试一个新的方向用大模型来审小模型写的代码但它并不是只做一次性的最终 Review。我调整了工作流让每次小模型生成完代码之后马上自动调大模型 API 做一次“快速体检”检查是否有明显的语法问题、命名规范和潜在的逻辑漏洞。如果有问题直接把大模型给出的修改建议作为新的提示词再丢给小模型修改。相当于组了一个“AI 流水线”每一轮小模型写完大模型检查再回头让小模型改来回几轮代码质量能逼近大模型直接写的水平而成本仍然只有后者的几分之一。目前我已经把这个流程的一部分通过脚本自动化了。大致逻辑是本地文件保存后触发小模型生成初始代码接着自动调用大模型 API 做 Review并把 Review 结果和修改建议写到一个临时文件里。我只需要最后看一眼结论就行。6.2 用 Agent 把流程彻底串起来更进阶的玩法是把这套组合拳封装成 Agent。比如开发一个简单的自动化 Agent它的角色分配是规划 Agent 调用大模型负责拆解需求、生成任务卡片执行 Agent 调用本地小模型负责按任务卡片写代码质检 Agent 再调用大模型负责代码审查。三个 Agent 之间通过配置文件传递信息人的角色从“写代码的人”变成“监督流水线的人”。这条路我已初步跑通了不过它还不够成熟主要瓶颈在于任务拆分的自动化程度还不够高。目前我用的是半自动方案大模型拆好卡片之后我人肉确认一遍再交给执行 Agent。全自动跑还有一个坑是“级联错误”——大模型拆任务时如果理解错了需求小模型会忠实地把错误执行出来最后返工成本反而更高。所以我的建议是自动化可以搞但关键节点的“人工确认”不能省。经过这几个月的实践这套“大模型想思路小模型写代码”的组合拳已经被我当成标准工作流来用了。我最大的体会是AI 辅助开发的核心从来不是“哪个模型更强”而是“怎么让不同层级的模型协同配合”把每个模型的长处都发挥到极致。省下来的不仅是真金白银更是大把的时间以及反复调试的耐心。如果你也想提高 AI 写代码的效率和性价比不妨先从“重活累活交给小模型烧脑的事情交给大模型”开始试试。