Codex桌面版使用指南

1
2
3
4
5
6
7
8

# npm 安装  
npm install -g @openai/codex  
  
# Homebrew 安装（macOS）  
brew install --cask codex

# 验证
codex --version

1
2
3

{
  "OPENAI_API_KEY": "sk-你的APIYI密钥"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# === 全局（放在文件最顶部）===
model = "gpt-5.4"                 # 默认模型，可按需改成 gpt-5.5 等
model_provider = "apiyi"          # 使用下面定义的 apiyi 供应商
preferred_auth_method = "apikey"  # 用 API Key 认证（不要用 chatgpt 登录）

# === API易 供应商定义（放在文件最末尾）===
[model_providers.apiyi]
name = "apiyi"
base_url = "https://api.apiyi.com/v1"
experimental_bearer_token = "sk-你的APIYI密钥"
wire_api = "responses"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

model_provider = "deepseek"
model = "deepseek-v4-flash"
preferred_auth_method = "apikey"
forced_login_method = "api"
model_reasoning_effort = "high"
model_catalog_json = "~/.codex/models.json"

[model_providers.deepseek]
name = "deepseek"
base_url = "https://api.deepseek.com/"
wire_api = "responses"
experimental_bearer_token = "<Your API Key>"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"
model_catalog_json = "~/.codex/models.json"

[model_providers.ZAI]
name = "ZAI"
base_url = "https://open.bigmodel.cn/api/v1"
wire_api = "responses"
experimental_bearer_token = "<Your API Key>"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# 全局配置

## 语言规则
- 所有回答都使用中文
- 技术术语可以保留英文，但是要提供中文解释
- 代码注释使用中文
- 文档和说明优先使用中文编写

**例外情况**：
- 代码本身（变量名、函数名等）可以使用英文
- 命令行指令保持原样
- 配置文件内容根据实际需要决定语言

## 1. 先思考，后编码
**不要想当然。不要掩饰困惑。主动暴露取舍。**  
在实现之前：  
- 明确陈述你的假设。若有不确定，请提问。  
- 若存在多种理解方式，请列出来——不要自行默默选一个。  
- 若有更简单的做法，请说出来。在有充分理由时，可以提出异议。  
- 若有不清晰之处，停下来。指出哪里令人困惑，然后提问。

## 2. 简单优先
**用最少的代码解决问题。不做推测性工作。**  
- 不添加未要求的功能。  
- 不为一次性使用的代码构建抽象。  
- 不提供未被要求的“灵活性”或“可配置性”。  
- 不为不可能发生的场景编写错误处理。  
- 如果你写了 200 行代码，而 50 行就能解决，请重写。  
问问自己：“资深工程师会觉得这过于复杂吗？” 如果是，就简化。

## 3. 手术式改动
**只动必须动的地方。只清理自己造成的混乱。**  
编辑现有代码时：  
- 不要“改进”相邻代码、注释或格式。  
- 不要重构没有问题的东西。  
- 匹配现有风格，即使你个人更喜欢其他写法。  
- 如果发现不相关的死代码，可以提及——但不要删除。  
当你的改动产生“孤儿”代码时：  
- 移除因**你的改动**而不再使用的导入/变量/函数。  
- 除非被要求，否则不要移除先前已存在的死代码。  
检验标准：每一行改动都应直接追溯到用户的请求。

## 4. 目标驱动执行
**定义成功标准，循环执行直至验证通过。**  
将任务转化为可验证的目标：  
- “添加校验” → “为无效输入编写测试，然后让测试通过”  
- “修复 bug” → “编写一个能复现该 bug 的测试，然后让测试通过”  
- “重构 X” → “确保重构前后测试均通过”  

对于多步骤任务，简要陈述计划：  
1. [步骤] → 验证：[检查项]  
2. [步骤] → 验证：[检查项]  
3. [步骤] → 验证：[检查项]  

强有力的成功标准让你能独立循环推进。弱标准（如“让它工作”）则需要不断澄清。