让 GPT 判断，让国产模型干活：我的 AI 编程降本实践

项目背景

在使用 Codex 时会遇到一个问题：Codex 额度不太够用。

重度使用 Codex 的用户深有体会，它有 5 小时额度、周额度 的窗口限制，用完之后只有等待下一次额度重置。

我在用 Codex 时，看重的是它作为强模型的判断力：架构设计、拆解问题、判断风险，以及最后进行质量把关。

问题最关键的部分是它一开始判断 问题怎么拆，以及最后判断 这个改法对不对。

至于中间很多活都很机械，例如：

• 跑 lint、typecheck、test、smoke 命令
• 整理错误日志
• 查找定位问题文件
• 在一个很小的范围里尝试修复
• 生成一版补丁

与此同时，今年国产模型进步明显。DeepSeek、Qwen、GLM、Kimi 这类模型，可能暂时还不适合直接接管复杂架构判断，但在一些 边界清楚、失败成本低、结果可验证 的任务上，已经足够用了。

这时候我想一个问题：能不能把两类模型放到同一个工程流程里，让 Codex/GPT 和国产模型像一个团队一样分工：

• Codex 像团队 leader，负责理解需求、拆任务、定边界、看风险、最终验收
• worker 像具体执行者，负责跑命令、读日志、整理结果、生成局部补丁草稿
• 工具层 负责把任务、验证、产物、权限和审计串起来，避免协作失控

和其他方案对比

后来看到一篇《一个可以让 Codex 可用额度翻倍的方法》，讲的是将其他模型作为subagent接进 Codex，让 GPT 模型负责管理，再把检索、写作、审查等任务进行分配。其中，Codex 不只用 GPT 自己干活，可以更像一个调度者进行指挥完成工程任务。

在这个问题上，常见的方案有：

方案	更适合解决什么	我觉得还缺什么
/loop	让模型围绕一个任务持续执行、验证、再修复	适合推进单个任务，但容易变成"让模型一直跑"
subagent	把其他模型接进 Codex，让 GPT 调度不同 agent	更偏模型接入和协作入口
mcp-code-worker	给 Codex/GPT 提供一个受控执行层	补上 worker registry、evaluation、artifact、validation、patch inspect 和 apply gate

项目定位

mcp-code-worker 的工作原理是：

Codex / GPT（团队 leader）
        |
        v
   mcp-code-worker（受控执行层）
        |
        v
国产模型 / 低成本模型 worker（执行者）

在这个分工里：

• Codex/GPT 负责理解需求、拆任务、定边界、看风险、最终验收
• worker 只负责被切好的执行任务
• mcp-code-worker/cw 负责 worker 注册、能力评估、仓库上下文、验证命令、任务产物、patch gate

问题

在接入过程中有两个问题

• 接入的模型能力怎么样？是否具备生产的各项能力？
• 模型的 patch 产物要接受 Codex/GPT 验收，是否符合 Codex 要求？

针对第一个问题，我让注册的模型干活之前先做 smoke evaluation / coding evaluation；对于第二个问题，不能直接相信worker生成的补丁修改，必须先 propose、inspect，再 apply。我在项目里针对不同模型做了大量兼容适配，以及内置相关提示词，避免输出只是一段自然语言，方便 Codex 检查 scope、artifact、validation 和 next action。

所以 mcp-code-worker 做的不只再加一个模型入口，而是补一层 受控执行层：先通过能力评估，限定 worker 能做什么，再记录它做了什么，最后让 Codex 判断结果能不能收。

使用介绍

mcp-code-worker 现在是一个 CLI + MCP server，目前它能做：

• 对注册的 worker 做 smoke / coding evaluation
• 让 worker 在指定 scope 下做 review、fix plan、patch proposal
• 运行 typecheck、lint、test 这类确定性验证
• 把任务报告、验证结果、生成补丁建议、patch inspection 存成可追溯 artifact
• 通过 MCP 暴露给 Codex，让 Codex 作为 host 调度这些能力

当前默认存储在：

~/.code-worker/<workspace-id>/

以deepseek-v4-pro为例，常用的 CLI 的命令如下：

cw init
cw doctor

cw worker registry add \
  --worker=deepseek-pro \
  --provider=openai-compatible \
  --model=deepseek-v4-pro \
  --base-url=https://api.deepseek.com \
  --allow-write

cw auth login --worker=deepseek-pro
cw doctor --probe --worker=deepseek-pro

cw worker evaluate --suite=smoke --worker=deepseek-pro --save
cw worker evaluate --suite=coding --worker=deepseek-pro --save

cw task start \
  --goal="Review packages/core and propose safe improvements" \
  --scope=packages/core \
  --worker=deepseek-pro \
  --require-profile \
  --typecheck \
  --propose-patch \
  --inspect-patch \
  --allow-write-session

cw task report <taskId>

如果接 Codex：

cw mcp config --host=codex
cw doctor --mcp --host=codex
cw mcp list-tools

MCP 侧现在暴露的能力有：cw_start_task、cw_resume_task、cw_get_task_report、cw_read_task_artifact、cw_run_host_worker、cw_evaluate_worker、cw_apply_patch 等等。

最后

mcp-code-worker 不是一个"让任何模型自动改完整个仓库"的项目。它的很多设计都在阻止模型太自由：显式 worker、能力评估、scope、dry-run、task artifact、patch inspect、双重 apply gate、host final review。

不建议一上来就让 worker 大范围改代码，而是先 dry-run，先报告，先 inspect，再决定要不要 apply。适合下放给 worker 的任务，一般有几个特点：范围小、结果可检查、失败成本低、验证方式明确。

比如：

• 总结一段错误日志
• 读几个指定文件做 review-lite
• 在 packages/core 这种明确文件夹/文件生成修复建议
• 根据 typecheck/lint 输出准备 patch 建议
• 跑一轮验证并整理报告

不适合直接下放的任务也很明显：

• 大规模重构
• 模块边界重新设计
• 需求本身还没想清楚
• 涉及安全、权限、数据迁移的高风险改动
• 需要判断产品方向或架构取舍的问题

这些更应该让主力模型和开发者一起完成。

多模型协作最重要的不是 谁替代谁，而是 每一层都知道自己该做什么、不该做什么。

如果你经常用 Codex，觉得它额度掉得太快，而且又有低成本模型不知道怎么放进开发流程里，那可以试一下 mcp-code-worker 。

参考链接

• npm 地址: www.npmjs.com/package/mcp...
• README: github.com/vndmea/mcp-...