codex-coworker

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Codex as Coworker

把Codex当作同事来使用

Codex is a capable senior engineer you can delegate to. Think of it as having a coworker who can:

Draft specs while you think through architecture
Implement code based on patterns you've identified
Review your work for bugs and edge cases
Write tests for code you've written
Brainstorm approaches to a problem

Your tokens are expensive and limited. Codex tokens are cheap. Delegate aggressively.

Codex是一位能力出众的资深工程师，你可以将任务委托给它。你可以把它看作这样一位同事：

在你构思架构时起草规格说明
根据你确定的模式实现代码
检查你的工作是否存在Bug和边缘情况
为你编写的代码撰写测试用例
针对问题构思多种解决思路

你的token成本高昂且数量有限，而Codex的token成本很低。大胆地将任务委托给它。

Invocation

调用方式

Preferred: Moonbridge MCP (unified interface)

mcp__moonbridge__spawn_agent({
  "prompt": "Implement X following the pattern in Y. Run pnpm typecheck after.",
  "adapter": "codex",
  "reasoning_effort": "high"
})

Parallel tasks (multiple agents at once):

mcp__moonbridge__spawn_agents_parallel({
  "agents": [
    {"prompt": "Implement feature A", "adapter": "codex", "reasoning_effort": "high"},
    {"prompt": "Write tests for A", "adapter": "codex", "reasoning_effort": "medium"},
    {"prompt": "Review for bugs", "adapter": "codex", "reasoning_effort": "high"}
  ]
})

Fallback: CLI (when MCP unavailable)

bash

codex exec --full-auto "Implement X" --output-last-message /tmp/codex-out.md 2>/dev/null

优先选择：Moonbridge MCP（统一接口）

mcp__moonbridge__spawn_agent({
  "prompt": "按照Y中的模式实现X。完成后运行pnpm typecheck。",
  "adapter": "codex",
  "reasoning_effort": "high"
})

并行任务（同时调用多个Agent）：

mcp__moonbridge__spawn_agents_parallel({
  "agents": [
    {"prompt": "实现功能A", "adapter": "codex", "reasoning_effort": "high"},
    {"prompt": "为A编写测试用例", "adapter": "codex", "reasoning_effort": "medium"},
    {"prompt": "检查代码中的Bug", "adapter": "codex", "reasoning_effort": "high"}
  ]
})

备用方案：CLI（当MCP不可用时）

bash

codex exec --full-auto "实现X" --output-last-message /tmp/codex-out.md 2>/dev/null

Then validate via: git diff --stat, pnpm test, or read summary only if needed

然后通过以下方式验证：git diff --stat、pnpm test，或仅在需要时查看摘要


**Interactive session for complex problems:**
```bash
codex "Let's design the data model for this feature"


**针对复杂问题的交互式会话：**
```bash
codex "让我们为这个功能设计数据模型"

Token Economics

Token 经济成本

Your output tokens cost 5x your input tokens. Codex tokens are separate.

Codex generates 1000 tokens of code → costs Codex, not you
You read Codex's output → input tokens (cheap)
You generate same code yourself → output tokens (expensive)

Net savings: ~80% on code generation by delegating to Codex.

To maximize savings:

Have Codex write to files directly
Validate by running tests or checking
```
git diff --stat
```
Only read full output when debugging failures

你的输出token成本是输入token的5倍，而Codex的token是独立计算的。

Codex生成1000个代码token → 消耗的是Codex的token，而非你的
你阅读Codex的输出 → 消耗你的输入token（成本低）
你自己生成相同的代码 → 消耗你的输出token（成本高）

通过委托给Codex，代码生成的成本可节省约80%。

为了最大化成本节省：

让Codex直接将代码写入文件
通过运行测试或查看
```
git diff --stat
```
来验证
仅在调试故障时才阅读完整输出

Reasoning Effort

推理算力等级

Vary reasoning effort based on task complexity:

Task	Effort	When
Simple edits, boilerplate	`medium`	Getters, CRUD, obvious changes
Most implementation (default)	`high`	Features, refactors, tests
Complex debugging, architecture	`xhigh`	Race conditions, security, hard bugs

Via Moonbridge MCP:

mcp__moonbridge__spawn_agent({
  "prompt": "Debug this race condition",
  "adapter": "codex",
  "reasoning_effort": "xhigh"
})

Via CLI (fallback):

bash

codex exec --full-auto -c model_reasoning_effort=xhigh "Debug this race condition"

Default to

high

. Drop to

medium

for trivial work. Escalate to

xhigh

for genuinely hard problems.

根据任务复杂度调整推理算力等级：

任务	算力等级	适用场景
简单编辑、样板代码	`medium`	Getter方法、CRUD操作、明显的代码变更
大多数实现任务（默认）	`high`	功能开发、代码重构、测试用例编写
复杂调试、架构设计	`xhigh`	竞态条件、安全问题、疑难Bug

通过Moonbridge MCP调用：

mcp__moonbridge__spawn_agent({
  "prompt": "调试这个竞态条件问题",
  "adapter": "codex",
  "reasoning_effort": "xhigh"
})

通过CLI调用（备用方案）：

bash

codex exec --full-auto -c model_reasoning_effort=xhigh "调试这个竞态条件问题"

默认使用

high

等级。对于琐碎任务可降至

medium

，对于真正复杂的问题则升级为

xhigh

。

When to Delegate

何时委托任务

Good candidates:

Implementation from a clear spec or pattern
Writing tests for existing code
Code review and analysis
Drafting specs for you to refine
Exploring multiple approaches in parallel
Boilerplate and CRUD operations
Refactoring with clear before/after

Keep for yourself:

Novel architecture decisions
Deep codebase reasoning you've already done
Integration across unfamiliar systems
Anything requiring context you already have loaded
Quick one-liners where overhead isn't worth it

适合委托的场景：

根据清晰的规格说明或模式实现代码
为已有代码编写测试用例
代码评审与分析
起草规格说明供你完善
并行探索多种解决思路
样板代码与CRUD操作
有明确前后标准的代码重构

适合自己处理的场景：

创新性的架构决策
你已经完成深度思考的代码库逻辑
跨陌生系统的集成工作
任何需要你已掌握的上下文信息的任务
执行成本高于收益的快速单行代码编写

Parallel Work

并行工作

You can think while Codex works:

Have Codex draft code while you design the architecture
Have Codex write tests while you implement
Get Codex's review while you plan the next step

你可以在Codex工作的同时进行思考：

在你设计架构时，让Codex起草代码
在你实现功能时，让Codex编写测试用例
在你规划下一步工作时，获取Codex的评审意见

Trust but Verify

信任但要验证

Always review Codex output before committing. Run tests. Check it fits codebase patterns. Codex is good but not infallible.

在提交代码前务必检查Codex的输出。运行测试，确保它符合代码库的模式。Codex很出色，但并非万无一失。

Context Passing

上下文传递

Give Codex enough context to succeed:

Reference specific files or patterns to follow
Include relevant constraints
Be specific about what you want

Bad: "Write a user service" Good: "Implement a UserService class following the pattern in src/services/AuthService.ts. Include CRUD operations for users with proper error handling."

为Codex提供足够的上下文以确保任务成功：

引用具体的文件或需要遵循的模式
包含相关的约束条件
明确说明你的需求

反面示例："编写一个用户服务" 正面示例："按照src/services/AuthService.ts中的模式实现UserService类。包含用户的CRUD操作，并添加适当的错误处理。"

Pre-Delegation Checklist

委托前检查清单

Before delegating, ask yourself:

Does this file have existing tests? → Add to prompt: "Don't break existing tests in [test file]"
Should Codex ADD or REPLACE? → Be explicit: "ADD to this file" vs "REPLACE this file" → Default to ADD unless rewrite is intentional
What quality gates should Codex run? → Include: "Run pnpm typecheck && pnpm lint after changes"
What patterns should Codex follow? → Include: "Follow the pattern in [reference file]"

在委托任务前，问自己以下问题：

该文件是否已有测试用例？ → 在提示中添加："不要破坏[测试文件]中的现有测试用例"
应该让Codex添加代码还是替换代码？ → 明确说明："向该文件添加代码" vs "替换该文件" → 除非有意重写，否则默认选择添加
Codex需要运行哪些质量检查？ → 包含："修改完成后运行pnpm typecheck && pnpm lint"
Codex需要遵循哪些模式？ → 包含："遵循[参考文件]中的模式"

Prompt Templates

提示模板

Adding to existing file (safest):

向现有文件添加代码（最安全）：

ADD a new [function/component] to [file].
Follow the pattern used in [reference].
Don't modify existing functions.
Run pnpm typecheck after.

向[文件]中添加一个新的[函数/组件]。
遵循[参考文件]中的模式。
不要修改现有函数。
完成后运行pnpm typecheck。

Replacing/rewriting (use cautiously):

替换/重写代码（谨慎使用）：

REPLACE [file] with [new implementation].
Note: This file has tests in [test file] - ensure they still pass.
Run pnpm typecheck && pnpm lint after.

用[新实现]替换[文件]。
注意：该文件的测试用例位于[测试文件]中——确保测试仍能通过。
完成后运行pnpm typecheck && pnpm lint。

New file from scratch:

从零开始创建新文件：

Create [file] implementing [spec].
Follow patterns from [reference].
Run pnpm typecheck after.

创建[文件]以实现[规格说明]。
遵循[参考文件]中的模式。
完成后运行pnpm typecheck。

With quality gates (recommended):

包含质量检查的提示（推荐）：

bash

codex exec "ADD [function] to [file]. Follow pattern in [ref]. \
  Don't break tests in [test file]. Run pnpm typecheck after." \
  --output-last-message /tmp/codex-out.md 2>/dev/null

bash

codex exec "向[文件]中添加[函数]。遵循[参考文件]中的模式。 \
  不要破坏[测试文件]中的测试用例。完成后运行pnpm typecheck。" \
  --output-last-message /tmp/codex-out.md 2>/dev/null

Post-Delegation Validation

委托后验证

After Codex completes:

Check what changed:
bash
```
git diff --stat
```
Run quality gates:
bash
```
pnpm typecheck && pnpm lint
```
Run tests:
bash
```
pnpm test
```
If tests broke:
- Check if Codex deleted/renamed functions tests depend on
- Look for wholesale file replacement when ADD was intended
- Review imports that may have been removed
Review integration points:
- You handle complex integration across files
- Check redirects, configs, and cross-file dependencies

Codex完成任务后：

检查变更内容：
bash
```
git diff --stat
```
运行质量检查：
bash
```
pnpm typecheck && pnpm lint
```
运行测试：
bash
```
pnpm test
```
如果测试失败：
- 检查Codex是否删除/重命名了测试依赖的函数
- 查看是否在要求添加代码时进行了整文件替换
- 检查可能被移除的导入语句
检查集成点：
- 由你处理跨文件的复杂集成
- 检查重定向、配置和跨文件依赖

Why Moonbridge MCP

为什么选择Moonbridge MCP

Use Moonbridge for all Codex delegation:

Method	When
`mcp__moonbridge__spawn_agent`	Primary method — unified interface
`codex exec` CLI	Fallback when MCP unavailable

Key benefits:

Mixed parallel: Run Codex + Kimi in same
```
spawn_agents_parallel
```
call
Consistent params: Same interface for both adapters
Better control:
```
reasoning_effort
```
for Codex,
```
thinking
```
for Kimi

See

/delegate

for full orchestration patterns.

所有Codex委托任务优先使用Moonbridge：

方式	适用场景
`mcp__moonbridge__spawn_agent`	主要方式——统一接口
`codex exec` CLI	当MCP不可用时的备用方案

核心优势：

混合并行： 在同一个
```
spawn_agents_parallel
```
调用中同时运行Codex和Kimi
参数一致： 两个适配器使用相同的接口
更好的控制： 为Codex设置
```
reasoning_effort
```
，为Kimi设置
```
thinking
```

查看

/delegate

获取完整的编排模式。