文章编写于7.16
最近一段时间，我一直在折腾一种新的 AI 编程模式：
让高级模型负责需求分析、系统设计和任务拆解，再让基础模型负责具体执行。
产生这个想法，原因其实很现实。
Claude 对国内账号越来越不友好，GPT 的使用成本也越来越高。国内模型虽然进步很快，但在复杂项目、长程任务和上下文一致性方面，和顶级模型相比还是有一些差距。
既然如此，为什么一定要让最强、最贵的模型从头干到尾？
能不能像真实的软件团队一样：
GPT 当项目经理和架构师，国内模型当开发。
为了验证这个思路，我选择了一个真实项目，连续测试了多组，今天我们就挑选最经典的三轮进行讨论。
测试项目：社群活动管理系统
这次没有选择比较简单的待办清单或者博客网站，而是针对一套社群活动管理系统进行测试。
系统包括活动、里程碑、成员、报名、签到、投票等功能。
项目规模不算特别大，但已经涉及前后端、数据库，以及多个模块之间的数据关联，足够测试 AI 能不能持续完成一个相对完整的项目。
所有测试的方式基本一致：
先让 GPT 设计整个系统，再把全部里程碑一次性交给 AI，让它按照顺序持续执行。
不是完成一个里程碑，我再给它一个新指令。
而是从项目开始，就把完整规划全部交给它，看它能不能连续工作几个小时，把所有里程碑依次完成。
这里主要是我感觉 goal 模式吸引人，想要同时体验一下。
第一轮：GPT 只设计到模块
第一轮，GPT 主要负责把系统拆分成模块。
例如成员管理、活动管理、报名、签到和投票，每个模块作为一个里程碑。
至于每个模块内部具体要创建哪些页面、接口和数据表，没有继续拆得特别详细。
随后，我将全部里程碑一次性交给 Claude Code，由不同的国内模型负责执行。
这一轮最长的任务，是 GLM 方案，连续跑了大约4个小时，真不怪大家说它比较慢。
Claude Code + GLM
整体模块生成比较完善，大部分功能都做了出来。
单独看了下前端和后端工程，都没什么大问题，
唯一一个问题是前后端接口调用对不上，路径 api 前缀错误。
Claude Code + MiniMax
模块生成同样比较完整，代码也没有明显的语法错误，甚至 GLM 的对接错误也没有出现。
但打开页面以后，总有一种比较古老的管理后台感。
功能基本都有，但布局、组件和视觉风格比较传统。
这也说明，代码能力和产品审美确实是两回事。
Claude Code + Agnes
Agnes 是一个完全免费的模型。
直接没有完整生成。
可能是长程任务过程中，遇到了并发、服务压力或者连接中断，可能并不足以代表其真实水平。
Claude Code + Qwen 3.5 35B 本地部署
前面的功能生成得还不错，但越往后，模块缺失越明显。
有些页面做了，接口没接上；有些接口写了，前端没有真正使用。
本地部署在成本和数据安全方面确实有优势，但长上下文和持续执行能力还有提升空间。
TRAE CN + GLM-5.2
这是第一轮里一个比较特殊的测试，TRAE 本身没有 goal 模式，但由于里程碑、任务文档的存在，TRAE 是可以知道要做的事情的。
实际效果比我预想中好，分析和实现能力并没有比 Claude Code 差太多，主要问题同样是前后端接口存在一些小偏差。
最大的问题反而是资源。
没有优速通的话，白天基本用不了，只能晚上跑。
不过至少说明，TRAE 本身也已经具备了一定的长程任务能力。
第二轮：GPT 继续拆解到具体任务
第一轮以后，每个模型效果都不是很好，和我平时修改单个任务的表现相差挺大。
我开始怀疑，问题可能不只是模型能力，而是任务拆得还不够清楚。
所以第二轮，我让 GPT 在模块基础上继续向下拆解，明确每个里程碑需要完成哪些具体任务。
需要说明的是，第二轮依然是将全部里程碑和全部任务一次性交给 Claude Code，让它从头执行到尾。
这一轮最长的任务，连续跑了大约8个小时。
Claude Code + Qwen 3.5 35B
因为是自部署的，并没有额度限制，并且前面生成的部分还可以，这一轮优先试试。
前面模块和任务，生成效果依然不错，但后面的生成还是出现了功能点缺失。
我的猜测是，任务拆得更细，虽然单个任务实现起来会更加精准，但整个长程任务规划所需的上下文也变得更大，而这点，小参数模型好像效果不是很好。
估计需要一些记忆插件的配合，将部分规划信息从显存转移到硬盘，让 AI 释放一些上下文空间。
Claude Code + MiniMax
执行到大约三分之一时，直接触发了额度限制（Starter订阅）。
已完成部分还可以，但后面的任务没有机会继续执行了。
这也是实际使用中无法回避的问题：
模型能力决定它能不能做，额度则会决定这个方案能不能落地。
Claude Code + GLM
这次使用的是借来的 Max 订阅，整体效果不错。
大部分任务顺利完成，最终结果比较接近预期。
虽然依然有一些小问题，但已经从"能不能开发"，变成了"还需要几次对话就能完成了"。
也是这三轮里面最能接受的版本。
Claude Code + Agnes
依旧没有完整执行。
连续两轮都没有跑完，之后我就放弃测试这个模型了。
第三轮：换成 OpenCode
前面都是 Claude Code，虽然这个是大家普遍认可的最强 Code Agent，但最近的各类事情，逼着我们得找个替换方案，因此我也试了下 OpenCode。
任务规划依然沿用第二轮：GPT 设计模块，并继续拆解到具体任务，然后将全部里程碑、任务一次性交给 OpenCode 执行。
OpenCode + DeepSeek V4 Flash
因为前面 Claude Code + GLM 已经初步达到了预期，所以，OpenCode 就没有先尝试 GLM。
选择了国内单价超低的 DeepSeek V4 Flash，但效果远没有达到预期。
平时修改个别小任务时有体会，相比更佳的一些模型，DeepSeek Flash 会有一些偏差，当处理长程任务时，这个偏差叠加后，效果差的有点远。
甚至很多功能页面都在报错。
OpenCode + Big Pickle
这是了解 OpenCode 时发现的免费内置模型，这得去试试。
结果就是，这个组合的效果出奇地好。
虽然也有一些小问题，组件没有对齐，菜单sql没有正常生成，但项目结构、模块实现和任务连续性都不错，没有编译性错误，整体效果和 GLM 接近。
这也是第三轮里最大的惊喜。
之后，会着重和 GLM 再做一次进一步的对比。
GPT 设计，国内模型开发，能不能跑通？
当然，这次测试并不算严格。
不同组合使用的额度、时间和服务状态并不完全相同，也没有做到真正意义上的控制变量。整个项目目前也还没有彻底结束。
但最初想验证的问题，已经基本有了答案：
GPT 负责设计，国内模型负责开发，这条路线确实能够跑起来。
至于为什么有的组合能持续推进，有的会遗漏任务；为什么任务拆得更细，效果反而不一定更好，这背后可能还需要根据具体模型定制适合它们的 Harness 或者 Loop 机制才行。
Harness 和 Loop 我还在继续研究，但要是等全部内容结束再分享，估计又得猴年马月了，所以今天先给大家同步个中间成果，后续我会持续分享这块工作。