Codex 更新后，老用户先别急着重装

Codex 更新后，最容易让人误判的一件事是：原来的图标不见了，打开应用后变成了 ChatGPT。

先别急着卸载，也不要马上清空本地配置。

从新版界面来看，Codex 更像是被放进了统一应用里。入口变了，项目、终端、Diff 和任务页面不一定跟着消失。

老用户真正要做的，不是重新安装一遍，而是先确认三件事：

• 当前登录的账号对不对；
• 原来的项目目录还在不在；
• Codex 入口和工作区权限是否正常。

新用户则要先分清 Chat、Work、Codex 的用途，再跑一个只读任务熟悉流程。

更新后，Codex 到底去哪了？

新版应用打开后，默认进入的可能是 ChatGPT 主界面。

左上角通常会出现多个入口，例如 Chat、Work、Codex。具体名称和排列方式可能随应用版本、账号类型或系统平台变化，不能只按旧版图标寻找。

进入 Codex 后，重点看左侧项目列表。

如果旧项目还在，说明工作区入口基本找对了。接着打开项目，检查终端、任务记录和文件访问权限。

我更建议老用户按这个顺序确认：

1. 打开新版应用，不要先删除旧目录。
2. 确认当前登录账号。
3. 在左上角切换到 Codex。
4. 查看原项目是否出现在左侧。
5. 打开项目后执行只读操作。
6. 确认终端和 Git 状态正常。
7. 最后再尝试修改文件。

所谓只读操作，可以是：

pwd ls git status

也可以直接让 Codex：

先不要修改任何文件。 请读取当前项目目录，说明： 1. 项目使用了什么技术栈； 2. 入口文件在哪里； 3. 当前 Git 分支和工作区状态； 4. 如果要运行测试，应该执行什么命令。 只给出分析，不要写入文件。

这一步很重要。

如果连项目目录、分支或运行命令都没有确认，就直接让工具“重构整个项目”，后面出了问题很难判断到底是入口、权限、上下文，还是模型本身导致的。

Chat、Work、Codex，别只看名字

这三个入口的区别，实际使用几次就能感受到。

Chat 更适合讨论。

比如梳理需求、解释报错、比较两个方案，或者把一段混乱的产品描述整理成开发任务。

Codex 更适合执行。

它关注的是项目文件、终端命令、代码变更、测试结果和 Diff。

Work 更偏向文档和交付物。

如果当前任务是整理报告、处理资料、生成文档或制作内容，可以优先看看 Work 是否提供了更合适的工作区。

一个比较实际的用法是：

先在 Chat 里把需求说清楚，再把明确的修改要求交给 Codex。

例如不要直接在代码任务里输入：

帮我把登录功能重构一下。

这句话对人都不够清楚，更别说让工具直接动项目。

可以先在 Chat 中整理成：

项目是一个 React 前端和 Node.js 服务。 目标： - 登录接口增加验证码校验； - 不修改现有用户表结构； - 登录失败时保留原错误码； - 前端需要补充加载状态； - 修改后运行 auth 相关测试。 暂时只分析涉及的文件和改动范围，不要修改代码。

确认范围后，再把这段要求放入 Codex 任务。

如果界面提供 “Add to task” 或类似操作，可以把聊天中已经确认的内容加入正在执行的任务。

但不要把它理解成“所有聊天记录都会自动同步”。

项目路径、终端状态、已打开文件、任务权限，仍然要在 Codex 当前工作区里重新确认。

尤其是同时打开多个项目时，聊天里说的是 A 项目，任务却绑定到了 B 项目，这种错误比模型答错更麻烦。

三档模型怎么选，别只看高低档

素材中的界面展示了 Sol、Terra、Luna 三档模型。

如果你的应用里也出现这三个名称，可以先按任务特征选择。这里说的是使用策略，不代表每个账号、版本都一定提供相同模型。

我会看四个问题：

• 要不要同时改多个文件？
• 是否需要运行测试并根据结果继续修改？
• 是否涉及架构判断？
• 改错后返工成本高不高？

这比简单地问“哪个模型最强”更有用。

Luna：适合快速确认

Luna 可以放在低风险的小任务上。

比如：

• 解释一段报错；
• 说明配置文件的作用；
• 写一个简单的正则表达式；
• 把函数改成更易读的写法；
• 根据接口文档生成一个请求示例。

这类任务通常不需要模型长时间分析项目全貌。

Terra：日常开发的默认档

如果任务只涉及一两个文件，需求也说得比较清楚，Terra 更适合作为日常默认选择。

例如：

• 给现有页面增加一个按钮；
• 修改一个接口参数；
• 补充单元测试；
• 调整表单校验；
• 写一个数据清洗脚本；
• 解释当前项目目录。

这里有个很实用的判断：

如果你能明确说出“改哪几个文件、达到什么结果、用什么命令验证”，通常不需要一上来就使用最高档模型。

Sol：留给高返工成本的任务

Sol 更适合需要连续判断的任务。

例如：

• 陌生仓库排查；
• 跨模块重构；
• 前后端同时调整；
• 长期存在但原因不明的 Bug；
• 修改后需要多轮运行测试；
• 审查一组关联文件的 Diff。

这类任务的难点不是代码量，而是上下文和依赖关系。

如果只是改一个按钮文案，却使用最高档模型，通常只会让等待时间和调用消耗增加，结果未必更好。

可以先用这张表做粗略判断：

模型选择也不是一次定死。

先用较轻量的模型定位问题，发现上下文复杂、测试反复失败，再切换更强的模型，往往比所有任务都使用 Sol 更容易控制。

一个比斐波那契更有用的测试任务

新用户第一次使用时，不要拿生产项目直接试。

找一个可以随时恢复的测试仓库，给 Codex 一个小而完整的任务：

请先读取项目结构，不要修改文件。 目标：为用户注册接口增加邮箱格式校验。 请输出： 1. 需要检查的文件； 2. 当前校验逻辑； 3. 建议修改的位置； 4. 需要补充的测试用例； 5. 预计执行的测试命令。 等待我确认后再修改。

这个任务能同时检验几件事：

• Codex 是否能访问项目；
• 当前工作区是否正确；
• 模型能否理解项目结构；
• 终端命令是否可执行；
• 任务是否会在未确认时直接写文件。

如果只是解释一个函数，Luna 一般就够用。

但如果任务需要定位接口、读取校验逻辑、补测试并运行命令，Terra 会更合适。

如果项目结构陌生，而且注册流程横跨前端、服务端和数据库，才有必要考虑 Sol。

这里不要迷信模型档位。

真正影响结果的，往往是任务边界有没有写清楚。

“修改登录功能”很模糊；“只修改src/auth和tests/auth，不得改数据库结构，完成后运行指定测试”就清楚得多。

内置浏览器：方便，但权限风险更大

浏览器能力适合资料整理和网页操作，前提是账号权限控制得住。

如果任务涉及登录后的网页，先确认当前浏览器使用的账号，不要默认它就是你想要的账号。

比较适合拿来做的事情包括：

• 汇总几个公开文档；
• 对比产品页面；
• 整理网页中的表格；
• 下载指定文件；
• 从内部知识库提取指定字段。

不建议一开始就让它执行这些动作：

• 发送邮件；
• 删除云端文件；
• 发布文章；
• 修改线上配置；
• 提交付款或审批；
• 处理含有身份证、银行卡、密钥的页面。

浏览器任务最好拆成两段。

第一段只读取和整理：

打开指定页面，提取产品名称、版本、发布日期和官方链接。 不要提交表单，不要发送消息，不要修改页面内容。

第二段再人工确认输出，决定是否执行写入操作。

多标签页功能适合同时对照资料，但要明确每个页面的用途。

例如：

• 第一个标签页放官方文档；
• 第二个标签页放项目仓库；
• 第三个标签页放数据表；
• 第四个标签页用于输出结果。

如果只说“综合这些网页给我结论”，最后很可能得到一段没有来源标记的摘要。

Template Creator，先拿一份周报试

Template Creator 更适合固定格式、重复提交的文档任务。

不要一上来上传一套复杂的公司模板。先拿一份已经使用过的周报测试，看看标题、表格和段落结构能保留多少。

上传样例后，说明这些内容：

• 哪些标题必须保留；
• 哪些字段需要替换；
• 哪些段落只能由人工填写；
• 表格列顺序是否不能变化；
• 输出格式是 PPT、文档还是表格。

例如：

请根据这份周报样例生成模板。 必须保留： - 一级标题； - 项目进度表； - 风险与待办两个章节。 每周需要替换： - 日期； - 完成事项； - 阻塞问题； - 下周计划。 不要自动改写数据，不要删除空字段。 先输出模板结构，等待确认后再生成正文。

模板能保留结构，不代表复杂排版一定完全一致。

实际检查时，重点看：

• 表格是否错列；
• 日期是否还是上一期；
• 项目名称有没有残留；
• 数字和单位是否对应；
• PPT 文本是否溢出；
• 公式或引用是否被当成普通文字处理。

如果每次生成后都要重新修一半格式，这个功能就不适合直接用于最终交付。

更稳的方式是把它当作初稿工具，先验证结构，再逐步增加自动化范围。

老用户更新后的完整检查路径

老用户最容易犯的错，是看到新界面后直接重装。

建议先按下面的顺序排查。

1. 入口找不到

检查应用是否完成更新，并确认当前登录账号。

然后完全退出应用再重启，观察左上角是否出现 Codex 或相关工作区入口。

如果仍然没有，检查是否处在正确的工作区。

2. 项目列表为空

先看本地项目目录是否还存在。

再确认当前账号和原来使用的账号一致，最后检查项目是否需要重新授权。

不要因为列表为空，就立刻删除本地文件或重新初始化仓库。

3. 终端无法执行

先运行只读命令。

如果pwd、ls、git status都失败，问题更可能出在终端权限、工作目录或系统环境，而不是模型回答质量。

4. Diff 结果不对

不要只看模型说“已经完成”。

直接检查 Diff：

git diff git status

重点看是否修改了任务范围之外的文件，是否顺手改了配置、依赖或格式化结果。

发现范围不对时，先撤销变更，再重新拆任务。

5. 任务中途失败

打开任务日志，定位失败位置：

• 文件读取失败；
• 命令不存在；
• 依赖安装失败；
• 测试报错；
• 网络请求失败；
• 权限不足；
• 模型返回格式不符合工具要求。

不要连续点击重试。

把失败日志和已经完成的步骤保留下来，再从失败环节继续，通常比从头运行更容易定位原因。

新用户的 API 配置，先确认工具是否支持

新用户可以从 ChatGPT 应用或目标工具的官方文档开始安装。

这里要把两种情况分开。

如果使用官方账号登录，就按应用提供的登录流程操作。

如果使用 API 登录或自定义模型服务，前提是目标工具明确提供了对应配置入口。并不是所有 Codex 版本、所有账号都支持填写自定义 Base URL。

Base URL：https://token.ithinkai.cn/v1 API Key：YOUR_API_KEY Model：以服务文档为准，最新模型 gpt-5.5、claude-opus-4-8、gpt-image-2 等可按文档查看；涉及图片生成时，以 0.05¥/图起、2k/4k 支持等服务文档说明为准。

最常见的几个误区

误区一：把界面变化当成项目丢失

先查账号、工作区和本地目录。

重装应该是后手，不是第一反应。

误区二：让工具直接修改生产代码

先读目录、看 Git 状态、列出改动文件，再生成 Diff。

涉及数据库、部署配置和线上服务时，必须保留人工确认。

误区三：所有问题都使用最高档模型

小任务用轻量模型，普通开发用中档模型，复杂排查再升级。

如果任务描述本身不清楚，换模型也不会自动补齐需求。

误区四：只看“任务完成”，不看 Diff 和测试

代码工具的完成提示只能说明流程结束。

真正需要确认的是：

git diff git status npm test

具体测试命令以项目配置为准。

写在最后

这次更新对老用户来说，麻烦主要在入口变了，而不是必须重新学一套开发流程。

更新后先确认账号、项目和终端，再用只读任务验证工作区。确认无误后，才进入写入和测试阶段。

新用户也不用急着研究所有功能。

先完成一次“读取项目—列出改动—生成 Diff—运行测试”的完整流程，基本就知道 Codex 是否适合自己的项目。

至于模型，日常开发从 Terra 这类中