AI Coding 开始进入“分工时代”：我做了一个 CodexSaver，把低成本任务交给 DeepSeek

过去一年，AI Coding 的叙事基本只有一个方向：

模型越来越强。

从代码补全，到 Chat 模式，再到 Agent 模式，大家都在追求一个更强的模型：更强的推理、更长的上下文、更好的代码理解、更自动化的执行能力。

这当然是对的。

但当我开始高频使用 Codex 之后，另一个问题变得越来越明显：

我们正在用一个非常强、也非常贵的模型，做大量并不需要它亲自完成的事情。

比如：

• • 扫描 repo
• • 查找文件
• • 总结代码
• • 写单元测试
• • 修 lint
• • 更新 README
• • 生成 boilerplate
• • 做一些局部、低风险的小改动

这些任务当然需要模型能力。

但它们真的需要最强模型来做吗？

这就是我做 CodexSaver 的起点。

GitHub 地址：

https://github.com/fendouai/CodexSaver

一、过去的 AI Coding：一个模型干所有事情

现在大多数 AI Coding 工作流，本质上还是：

User ↓One Powerful Model ↓Everything

无论任务是架构设计、复杂 bug 定位、安全审查，还是写测试、扫文件、改文档，通常都交给同一个模型。

这个方式简单、直接，也符合我们对 AI Agent 的直觉：

“既然模型够强，那就让它全部做。”

但这里有一个隐藏问题：

软件开发任务并不是同质的。

写代码里面至少有几种完全不同的认知劳动：

第一类是高价值判断，比如：

• • 要不要这样设计？
• • 这个抽象是否合理？
• • 这个变更有没有安全风险？
• • 这个 patch 是否会破坏边界条件？
• • 这个迁移是否可能造成数据问题？

第二类是低风险执行，比如：

• • 找到某个函数
• • 总结某个文件
• • 给已有函数补测试
• • 修几个格式问题
• • 改 README
• • 生成重复性代码

这两类任务对模型的要求完全不同。

但今天我们经常用同一个模型做所有事。

这就像你请了一个非常贵的 Staff Engineer，然后让他每天帮你修 lint、补注释、扫目录。

不是不能做。

而是不划算。

二、真正贵的，不只是推理，而是吞吐量

很多人一开始以为 AI Coding 贵，是因为“推理贵”。

但我自己的体验是：

在实际开发中，大量成本并不是花在最复杂的推理上，而是花在吞吐量上。

比如一个任务让 Codex：

• • 读一堆文件
• • 理解目录结构
• • 找相关模块
• • 生成测试
• • 再根据测试失败来回修改

这里面有很多 token 消耗，其实并不是高难度 reasoning，而是大量“读取、整理、生成、重复”。

尤其是在大 repo 里，context 一变大，成本就会快速上升。

这让我开始意识到：

AI Coding 的成本优化，不应该只看模型单价，而应该看任务分工。

不是所有任务都应该走同一个模型。

三、未来的 AI Coding：不同模型负责不同类型的认知劳动

我现在越来越相信一个判断：

AI Coding 正在进入“分工时代”。

过去的 AI Coding 是：

一个模型干所有事情

未来的 AI Coding 会变成：

不同模型负责不同类型的认知劳动

这其实很像真实的软件团队。

在真实团队里，不同人负责不同工作：

• • Tech Lead 负责架构和关键判断
• • Senior Engineer 负责复杂实现和 review
• • Junior Engineer 负责相对明确的执行任务
• • CI/CD 负责机械化验证
• • 工具链负责格式化、测试、构建

一个健康的软件团队，不会让最贵的人干所有事。

AI Coding 也一样。

未来的 AI Coding 系统里，也不应该只有一个“超级模型”。

更合理的结构应该是：

强模型负责判断便宜模型负责执行工具负责验证Router 负责调度

这就是 CodexSaver 想验证的方向。

四、CodexSaver 是什么？

CodexSaver 不是另一个代码 Agent。

它更像是 Codex 的一个“成本优化外包层”。

它的核心思路是：

Codex 仍然是主 AgentDeepSeek 只是低成本 WorkerCodexSaver 负责判断哪些任务可以外包

架构大概是这样：

User ↓Codex ↓CodexSaver Router ↓DeepSeek API ↓Codex Review ↓Final Output

在这个体系里，Codex 的角色发生了变化。

它不再是“什么都自己干”的执行器，而是更像一个技术负责人：

• • 判断任务类型
• • 判断风险
• • 决定是否外包
• • 审查 DeepSeek 返回的结果
• • 决定是否采用 patch
• • 做最终质量把关

DeepSeek 则负责相对低成本、低风险、高吞吐的任务：

• • 搜索代码
• • 解释代码
• • 写测试
• • 修 lint
• • 改文档
• • 生成样板代码
• • 做局部小改动

一句话：

DeepSeek does the work.Codex makes the decisions.

五、为什么不是 Multi-Agent？

很多人第一反应可能是：

“这不就是 Multi-Agent 吗？”

其实不是。

我一开始也想过做成多 Agent 系统，但很快放弃了。

因为很多 Multi-Agent 项目最后会遇到几个问题：

第一，Agent 太多，context 爆炸。

第二，角色边界不清晰，几个模型互相聊天。

第三，debug 非常困难。

第四，成本不降反升。

所以 CodexSaver 故意做得非常克制：

CodexSaver 不是 Agent 系统，而是 Router 系统。

它不追求让多个 Agent 自主协作。

它只做一件事：

判断一个任务是否值得交给低成本模型

如果值得，就调用 DeepSeek。

如果不值得，就留给 Codex。

这个设计简单，但非常关键。

因为成本优化系统最重要的不是“看起来智能”，而是“可控、可解释、可验证”。

六、Router 才是核心

CodexSaver 里最重要的部分，不是 DeepSeek API。

而是 Router。

Router 要回答一个问题：

这个任务，应该由谁来做？

比如：

适合交给 DeepSeek 的任务：

write_testsfix_lintdocscode_searchexplainboilerplatesimple_refactor

不适合交给 DeepSeek 的任务：

architecturesecurityauthpaymentmigrationpermissionambiguous requirementsfinal review

这背后有一个非常实际的判断：

低成本模型可以帮你节省成本，但不能把高风险决策交出去。

所以 CodexSaver 里会有一些保守规则：

• • 涉及 auth，不轻易外包
• • 涉及 payment，不轻易外包
• • 涉及 migration，不轻易外包
• • 涉及 security，不轻易外包
• • 模糊需求，不轻易外包
• • 大 patch，不轻易接受
• • 测试失败，回退给 Codex

这不是因为 DeepSeek 不行。

而是因为在 AI Coding 里，真正危险的不是模型能力不足，而是模型过度自信。

一个低成本 Worker 可以写代码，但最终必须由 Codex 审。

七、为什么用 MCP？

CodexSaver 的另一个设计选择是：通过 MCP 接入 Codex。

MCP 的价值在于，它让模型可以用标准方式访问外部工具和上下文。OpenAI 的 Codex 文档也明确支持在 CLI 和 IDE extension 中使用 MCP server。(OpenAI Developers)

这意味着 CodexSaver 不需要做奇怪的终端注入，也不需要假装成一个人类用户去操作 Codex。

它就是一个标准工具：

codexsaver.delegate_task

Codex 可以自然调用它：

{  "instruction": "Add unit tests for user service",  "files": ["src/user/service.ts"],  "constraints": ["Do not modify production logic"]}

CodexSaver 返回结构化结果：

{  "status": "success",  "summary": "Added unit test draft",  "patch": "...",  "changed_files": ["tests/user/service.test.ts"],  "commands_to_run": ["pytest"],  "risk_notes": []}

然后 Codex 做 review。

这个体验非常自然。

因为 CodexSaver 不是要取代 Codex，而是成为 Codex 的一个低成本工具。

八、为什么用 DeepSeek API？

一开始我也考虑过接 DeepSeek-TUI。

但后来发现，最优雅的方式其实是直接调用 DeepSeek API。

原因很简单：

• • API 比 TUI 更稳定
• • 输出更容易结构化
• • 更容易做 JSON schema
• • 更容易统计成本
• • 更容易重试和 fallback
• • 更适合作为 Codex 的 Worker

DeepSeek API 支持 OpenAI 兼容风格调用，这让接入成本很低：很多情况下只需要改 base_url 和 api_key，就可以用类似 OpenAI SDK 的方式调用。(DeepSeek API Docs)

这正好适合 CodexSaver 的定位：

DeepSeek 不需要成为一个完整 Agent。

它只需要成为一个稳定、便宜、可控的 Worker。

九、这不是个孤立想法，LLM Routing 正在变成方向

CodexSaver 不是凭空冒出来的想法。

更大的背景是：LLM routing 正在成为一个重要方向。

所谓 model routing，就是维护多个模型，然后根据任务复杂度、成本、延迟和质量要求，把请求路由给最合适的模型。

已有研究把 model routing 描述为一种降低 LLM 推理成本的方法：在多个候选模型中，把 prompt 路由给“足够完成任务的最小模型”。(OpenReview)

也有研究在讨论质量、成本、延迟之间的动态权衡，比如 MixLLM 会根据查询估计质量和成本，再决定交给哪个模型，以获得更好的质量/成本/延迟 trade-off。(ACL Anthology)

这说明一个趋势：

未来我们不会只问：

哪个模型最强？

而会问：

这个任务，用哪个模型最划算？

这正是 CodexSaver 想在 AI Coding 场景里做的事情。

十、CodexSaver 的实际效果

目前 CodexSaver 还是一个早期项目。

但在模拟 benchmark 和典型任务里，它已经展示出一个很有意思的方向：

Codex only:  $0.52CodexSaver:  $0.18Saved:  65%

当然，这个数字不是要证明所有项目都能固定节省 65%。

真正重要的是：

它证明了 AI Coding 里有大量任务是可以被拆出去的。

尤其是：

• • 写测试
• • 修 lint
• • 更新文档
• • 解释代码
• • 搜索代码
• • 小范围重构

这些任务非常适合交给低成本模型。

而 Codex 只需要保留在最重要的位置：

判断、验收、兜底

十一、我认为这会改变 AI Coding 的产品形态

今天很多 AI Coding 产品还在比拼：

• • 谁模型更强
• • 谁上下文更长
• • 谁 Agent 更自动
• • 谁能一次改更多文件

但我觉得下一个阶段，大家会开始关注另一个问题：

AI Coding 的成本结构是否健康？

如果一个 AI Coding 系统所有任务都调用最强模型，那它一定很贵。

如果它完全依赖便宜模型，那质量和安全又不稳定。

真正合理的系统，应该是分层的：

高风险 → 强模型低风险 → 便宜模型机械验证 → 工具最终审查 → 强模型

这就是“分工时代”的 AI Coding。

它不是一个模型的胜利，而是一个系统设计的胜利。

十二、CodexSaver 现在做到了什么？

现在 CodexSaver 已经有了一个最小可运行版本：

• • MCP server
• • Router
• • DeepSeek API client
• • Context packer
• • Verifier
• • Cost estimator
• • AGENTS.md policy
• • Codex config 示例

项目结构大概是：

codexsaver/├─ codexsaver_mcp.py├─ codexsaver/│  ├─ router.py│  ├─ deepseek_client.py│  ├─ verifier.py│  ├─ cost.py│  └─ context.py├─ .codex/│  └─ config.toml├─ AGENTS.md└─ README.md

使用方式也很简单：

export DEEPSEEK_API_KEY=sk-xxxpython cli.py "add unit tests for user service" \  --files src/user/service.ts \  --dry-run

在 Codex 里，则通过 MCP 工具调用：

codexsaver.delegate_task

十三、这个项目还很 early

我不会把它包装成一个已经完美解决问题的工具。

现在它还有很多可以改进的地方：

• • Router 还是规则驱动
• • 成本统计还可以更精确
• • Verifier 还可以接真实 test runner
• • patch apply 还可以更安全
• • routing policy 可以变成自学习
• • 可以支持更多模型
• • 可以做 dashboard
• • 可以沉淀真实 benchmark

但方向已经比较清楚了：

CodexSaver 不是为了替代 Codex。

它是为了让 Codex 更像一个技术负责人。

少干低价值重复劳动。

多做高价值判断。

十四、总结：AI Coding 的下一阶段，是分工

如果用一句话总结 CodexSaver，我会说：

它不是一个 DeepSeek wrapper。它是一个 AI Coding 分工实验。

过去的 AI Coding：

一个模型干所有事情

未来的 AI Coding：

不同模型负责不同类型的认知劳动

强模型负责：

• • 判断
• • 架构
• • 安全
• • review
• • fallback

便宜模型负责：

• • 搜索
• • 解释
• • 生成
• • 测试
• • 文档
• • 重复执行

工具负责：

• • lint
• • test
• • diff
• • benchmark
• • cost accounting

Router 负责：

• • 分配任务
• • 控制风险
• • 平衡成本
• • 保证质量

这才是我认为 AI Coding 接下来真正会发生的变化。

不是单点模型越来越强。

而是整个系统越来越像一个工程团队。

GitHub：

https://github.com/fendouai/CodexSaver

如果你也在研究 AI Coding、MCP、LLM routing、agent infra，欢迎一起交流。

我越来越确定：

AI Coding 正在进入分工时代。