双模型流水线：想的不上数据，干的不出内网
双模型流水线：想的不上数据，干的不出内网
AI 辅助编程有个结构性矛盾，很多人卡在这里做选择：顶级推理模型规划能力强，但它是云端 API——生产数据、代码架构要发出去；本地部署的模型数据安全，但推理深度不够，复杂规划做不好。
想的人够不着数据，数据里的人不会想。
大多数人在这两者之间反复横跳：要么图聪明把代码往云上发，要么图安全忍受本地模型的平庸。其实还有第三条路——不选，分工。
架构就一张图
分工的本质是战略层和战术层分离：规划模型管"做什么、怎么拆、选什么技术"，执行模型管"一行一行写出来、跑起来"。中间靠 MCP 协议流转，不是把聊天记录从这边甩到那边。
三个协同机制，决定这套架构是玩具还是系统
方案转交要有格式。 规划模型输出的不是散文，是结构化 JSON：任务描述、技术栈选择、接口定义、文件结构、验收标准。执行端拿到的是施工图，不是会议纪要。
必须有反馈闭环。 执行模型干完活，把执行日志、测试结果通过 MCP 回传给规划模型审查，规划据此调整后续方案。没有这个闭环，规划质量永远停在第一次猜测——那不是协同，是"AI 出方案，人肉执行"的换皮。
上下文分开管。 规划端用大窗口带完整项目背景；执行端靠会话管理吃前缀缓存的稳定性红利，多轮迭代不崩。
两端的选型（2026 年 10 月这版）
规划端要的是窗口和输出余量：1M 上下文装得下完整项目背景，最大 384K 输出装得下完整方案，Tool Calls 全支持。这一档目前就是 DeepSeek V4 Pro、Claude Opus 4.8 这个级别。
执行端的关键是本地部署路径，两条：
- 验证期：单卡量化版。 社区动态量化（GGUF）在 24GB 显存卡（4090/5090）上跑蒸馏版。能跑，接受量化损失——验证够用。
- 生产期：双机小集群。 实测两台 DGX Spark 跑满血 Flash 单流稳定 60-70 tok/s，日常编码达到实用标准。
路线纪律只有一句话：验证期别买硬件，生产期别用量化版硬扛。
安全不是附赠品，是三道门
只读生产数据的 MCP Server 要过五件套：每请求验证的 API Key、SQL 沙箱（只许 SELECT + 黑名单）、参数化查询、敏感字段脱敏、审计日志。别自己造协议，用官方 SDK。
再加三层防护，各堵一类洞：网关堵"不该调的调用"，沙箱堵"执行环境逃逸"，注入检测堵"工具本身被骗"。2026 年 5 月 Ox-Security 披露过 20 万个 MCP server 用 child_process.exec 直接执行用户输入——前车之鉴，MCP 的安全不能想当然。
最容易忽略的一环
反馈闭环。人人都记得搭"想"和"干"，都会忘了把执行结果喂回去。执行结果回传审查，规划质量才会随迭代上升——这一环在，系统是活的；不在，它只是一次性的方案生成器。
聊两句：你们团队现在是怎么处理这个矛盾的——代码全上云图省事，还是本地模型忍着用？如果试过双模型分工，转交格式你们是怎么定的？评论区聊聊，我置顶一条我踩过的坑（提示：格式校验没做，规划输出和执行预期对不上，是这套系统最脆弱的接缝）。
下一篇：给 APP 停服的智能插座刷开源固件，把"云僵尸"硬件救活。关注不迷路。