Codex 更新后最容易让人误判的一件事是原来的图标不见了打开应用后变成了 ChatGPT。先别急着卸载也不要马上清空本地配置。从新版界面来看Codex 更像是被放进了统一应用里。入口变了项目、终端、Diff 和任务页面不一定跟着消失。老用户真正要做的不是重新安装一遍而是先确认三件事当前登录的账号对不对原来的项目目录还在不在Codex 入口和工作区权限是否正常。新用户则要先分清 Chat、Work、Codex 的用途再跑一个只读任务熟悉流程。更新后Codex 到底去哪了新版应用打开后默认进入的可能是 ChatGPT 主界面。左上角通常会出现多个入口例如 Chat、Work、Codex。具体名称和排列方式可能随应用版本、账号类型或系统平台变化不能只按旧版图标寻找。进入 Codex 后重点看左侧项目列表。如果旧项目还在说明工作区入口基本找对了。接着打开项目检查终端、任务记录和文件访问权限。我更建议老用户按这个顺序确认打开新版应用不要先删除旧目录。确认当前登录账号。在左上角切换到 Codex。查看原项目是否出现在左侧。打开项目后执行只读操作。确认终端和 Git 状态正常。最后再尝试修改文件。所谓只读操作可以是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。这类任务的难点不是代码量而是上下文和依赖关系。如果只是改一个按钮文案却使用最高档模型通常只会让等待时间和调用消耗增加结果未必更好。可以先用这张表做粗略判断任务情况可优先尝试解释报错、改文案Luna单文件、小范围修改Terra普通功能开发Terra跨文件但边界清楚Terra 或 Sol陌生项目排查Sol架构调整、复杂重构Sol模型选择也不是一次定死。先用较轻量的模型定位问题发现上下文复杂、测试反复失败再切换更强的模型往往比所有任务都使用 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 结果不对不要只看模型说“已经完成”。直接检查 Diffgit diff git status重点看是否修改了任务范围之外的文件是否顺手改了配置、依赖或格式化结果。发现范围不对时先撤销变更再重新拆任务。5. 任务中途失败打开任务日志定位失败位置文件读取失败命令不存在依赖安装失败测试报错网络请求失败权限不足模型返回格式不符合工具要求。不要连续点击重试。把失败日志和已经完成的步骤保留下来再从失败环节继续通常比从头运行更容易定位原因。新用户的 API 配置先确认工具是否支持新用户可以从 ChatGPT 应用或目标工具的官方文档开始安装。这里要把两种情况分开。如果使用官方账号登录就按应用提供的登录流程操作。如果使用 API 登录或自定义模型服务前提是目标工具明确提供了对应配置入口。并不是所有 Codex 版本、所有账号都支持填写自定义 Base URL。Base URLhttps://token.ithinkai.cn/v1 API KeyYOUR_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 这类中