当前位置：首页 > news >正文

小白速通 Codex App：带录播回放

news 2026/5/30 11:42:15

文末有录播地址

早上 9 点，你同时有三件事要干：改一个页面、修一个小 bug、整理一份项目说明。

以前这三件事排在一起，你大概率会先挑一个做，剩下两个往后拖。用 AI 编程以后，情况变了。你可以让不同任务并行跑，自己回来只看结果、看 diff、看哪里需要确认。

这也是我为什么要重点讲 Codex App。

Codex 入口很多，CLI、IDE、Cloud/Web、Mobile 都能聊。但对小白来说，第一步不是把所有入口都学一遍。第一步是先找到一个能看见任务、能看见改动、能看见验收结果的地方。

Codex App 就是这个地方。

先说清楚，老金我一直是 Win 党。Windows 相关内容主要来自我的使用习惯和资料核对；Mac 相关信息来自官方文档和网上资料收集，我没有长期在 Mac 上跑完整工作流。Mac 用户可以参考，但遇到系统权限、Computer Use、Appshots、锁屏运行这些细节，自己还要按官方文档和实际界面再试一遍。

这篇文章只重点讲 Codex App。

一句话讲清楚 Codex App

Codex App 可以理解成一个 AI 编程工作台。

它不是单纯聊天框，也不是普通编辑器。你可以在里面打开项目，创建 thread，让 Codex 读文件、改文件、跑命令、看网页预览、检查 diff、用插件、调用 Skill，还能设置自动化任务。

我更愿意把它理解成三件东西放在一起：

这套东西对工程师来说可能只是效率工具。

对小白来说，它更重要的价值是：让 AI 干活这件事变得可见。

你能看到任务在哪里跑，改了哪些文件，哪里等你确认，最后结果能不能收。

下载地址和安装入口

先把地址放前面，别让大家第一步就到处找。

如果你是 Windows 用户，最直接的方式是 Microsoft Store 搜 Codex，安装官方 Codex App（需要网络环境）。

如果你是 Mac 用户，去官方 Codex App 页面下载 macOS 版本。页面上会区分 Apple Silicon 和 Intel Mac，别下错。

Linux 用户这篇不重点讲 App。Linux 更适合走 CLI 或 IDE 扩展。

如果你只想 5 分钟试一下

虽然这篇重点讲 App，但 CLI 适合拿来做一次快速体验。你要是想先确认 Codex 能不能跑，可以用下面命令。

CLI虽然是编程的最强形态，但老金觉得Codex APP才是在Codex生态中做的最好的产品。反观Claude Code我更推荐CLI。

然后web和mobile使用方法，建议在录播中查看。

macOS / Linux：

curl -fsSL https://chatgpt.com/codex/install.sh | sh codex

Windows PowerShell：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex" codex

npm 方式：

npm install -g @openai/codex codex

Homebrew 方式：

brew install --cask codex codex

我还是那句话：小白别一上来就扎进 CLI。

CLI 强，但终端、路径、环境、权限、Node 版本这些东西会把人绕晕。你只是想先用 AI 做点东西，先装 App 更稳。

平台功能速查表

这张表先给你一个大概判断，不用背。

这篇重点讲 Windows 和 Codex App。Mac 相关能力我会提醒，但不装成我实测。

Codex App 的界面怎么看

打开 App 后，先别急着输入“帮我做个项目”。

先看三个位置。

左边是项目和 thread。一个项目可以有很多条 thread。你可以把官网、后台、小工具、文档项目分开放，不要全塞在一个聊天里。

中间是会话区。你给任务、Codex 回答、任务推进，都在这里发生。

右侧或相关面板是 Review、Diff、文件改动、Git 状态、预览结果。这里才是你收活的地方。

很多小白只看聊天区。

Codex 说“我完成了”，你就信了。这个习惯不好。AI 说完成只是它的口头交付，你还要看它改了哪些文件、有没有越界、页面能不能打开、测试有没有跑。

聊天区负责沟通，Review 负责验收，这两个位置别混。

我们从左到右来讲解。

第1+2步：你需要加入一个项目文件夹，推荐使用现有文件夹，可以是空的。

第3步：在加入的文件夹项目上，点击新建对话。

第4步：在聊天区域输入内容即可开始。

这里先讲聊天区域的功能。

1、可以在聊天区域选择对应的项目。

2、选择你要使用的场景。本地就是主干，推荐建立基础骨架时使用。其次频率最高的应该是新worktree，这个在下面讲它为什么重要。云端是可以快速通过移动端等链接做一些小任务的，因为它的使用模型目前应该是5.3。

3、分支，分支和工作树可能对大家会产生歧义，这里简单解释一下：

分支（Branch）是 Git 里的不同开发路线，用来区分主线、修 Bug、新功能等代码方向。

工作树（Worktree）是把同一个仓库的不同分支放到不同文件夹里，让多个任务可以同时改代码，互不干扰。

4、其他一看就懂的，但是这里要说一下，模型并不是最高就最好，而是相对于你要做的任务选择合适的。否则就是又慢，又贵。

我重点讲一下 Worktree

Worktree 是 Codex App 里非常值得小白先搞懂的东西。

你可以把它理解成：Codex 给某个任务开了一个独立小工位。它在那个小工位里改代码、试方案、跑任务，不直接污染你的主目录。

这对小白很关键。

你不懂代码时，最怕的不是 AI 不会写，而是它改乱了你不知道怎么回退。

命名时建议直接使用对应的英文名，避免忘记了这个worktree是干啥的。

在上面的截图里对应创建就行了，这里就不放重复截图了。

举个例子：

每个任务单独跑。做对了，再合并。做错了，直接扔。

这比在主项目上一层一层叠改安全多了。

Review 面板怎么看

你看不懂代码也要看 Review。

小白不用一上来理解每一行代码。先看范围。

这么操作：

AI 很勤快。有时勤快得让人头疼。

你让它改个表单，它可能顺手“优化”一堆别的东西。对小白来说，先管住范围，比追求一次性完美更重要。

插件 & Skill

插件先装哪些

插件别全装。

我建议小白先装少量，等真的需要再加。

插件越多，权限越多，上下文越复杂。小白一开始装太多，最后自己都不知道 Codex 能碰哪些东西。

Skill 是什么

Skill 可以理解成可复用的工作方法。

你每次都要提醒 Codex：先读项目，不要改文件；改完说明动了哪里；不要碰数据库；页面要检查手机端；不确定就说不确定。

这些话反复说，很烦。那就做成 Skill。

对的，Skill以及上面的插件，Codex App都给了快捷的创建方案。

我建议小白先做三个。

project-audit 可以这样写：

请创建一个 project-audit skill。 用途：在不修改文件的情况下，阅读当前项目结构，并用产品经理能听懂的话解释项目。 输出： 1. 项目是做什么的 2. 前端在哪里 3. 后端在哪里 4. 启动方式是什么 5. 主要配置文件有哪些 6. 当前看起来容易出问题的地方 7. 建议下一步先做什么 要求： - 不修改文件 - 不运行破坏性命令 - 不确定的地方直接标注“不确定”

change-review 可以这样写：

请创建一个 change-review skill。 用途：在 Codex 完成修改后，帮我用小白能懂的话检查改动。 输出： 1. 改了哪些文件 2. 每个文件为什么改 3. 有没有无关改动 4. 有没有新增依赖 5. 有没有修改配置 6. 有没有影响数据库、鉴权、支付、部署 7. 建议我运行哪些命令验证 要求： - 先说风险，再说细节 - 不要只列文件名 - 如果发现范围越界，要明确提醒

frontend-check 可以这样写：

请创建一个 frontend-check skill。 用途：检查网页原型或前端页面是否适合普通用户阅读。 检查： 1. 桌面端是否清楚 2. 手机端是否拥挤 3. 主按钮是否明显 4. 表单字段是否完整 5. 信息层级是否清楚 6. 是否引入了不必要的依赖 7. 是否有可读性问题 要求： - 优先用 Browser 预览 - 修改前先输出检查结果 - 修改时保持范围小

这三个不花哨，但能救很多小白。

Browser 和 Chrome Extension 怎么分

Codex App 里的 Browser 很适合做页面。

比如你做一个活动页、落地页、报名表单，让 Codex 打开本地页面预览。它能看到页面哪里太挤、按钮是不是明显、手机端有没有问题。

你可以这样写一些检查项：

请用 Browser 打开 index.html 预览。 先不要修改。 帮我检查： 1. 桌面端第一屏是否信息清楚 2. 手机端是否拥挤 3. 报名按钮是否明显 4. 表单字段是否完整 5. 页面有没有明显不协调的地方 检查完先告诉我结果，再等我决定是否修改。

你还可以指哪改哪：

Chrome Extension 用在另一类场景，这样打开。

如果网页需要登录，比如公司后台、Gmail、CRM、内部工具，Browser 未必能处理登录态。这时候可以考虑 Chrome Extension，用你当前 Chrome 的登录环境。

一句话：

不要为了显得高级就让 AI 操作浏览器。能稳定解决问题就行。

Pets 是什么

这个很多人会误会。

Pets 不是普通插件，它在 Codex App 的设置里。位置是：

你可以选择内置宠物，也可以刷新本地自定义宠物。输入/pet可以唤醒或收起，。

它会显示当前 thread 状态。比如 Codex 正在跑、等你输入、等你 review。你在别的窗口里工作时，瞄一眼就知道它是不是卡住了。

它更像一个状态提醒，加一点陪伴感。你同时跑多个 thread 时，有点用。小白刚开始用，也会觉得这个工具没那么冷冰冰，不过对于老金这个钢铁直男来讲。。。有点儿累赘，但是看起来大多数人来讲好像还蛮喜欢的。

想自定义宠物，可以装：

$skill-installer hatch-pet

然后让它创建：

$hatch-pet create a new pet inspired by my recent projects

Settings 推荐怎么调

App 里的设置别乱点，先看这些。

自定义指令可以这么写：

来源：GitHub - multica-ai/andrej-karpathy-skills: A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls. · GitHub

# CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed. **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. ## 1. Think Before Coding **Don't assume. Don't hide confusion. Surface tradeoffs.** Before implementing: - State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - don't pick silently. - If a simpler approach exists, say so. Push back when warranted. - If something is unclear, stop. Name what's confusing. Ask. ## 2. Simplicity First **Minimum code that solves the problem. Nothing speculative.** - No features beyond what was asked. - No abstractions for single-use code. - No "flexibility" or "configurability" that wasn't requested. - No error handling for impossible scenarios. - If you write 200 lines and it could be 50, rewrite it. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. ## 3. Surgical Changes **Touch only what you must. Clean up only your own mess.** When editing existing code: - Don't "improve" adjacent code, comments, or formatting. - Don't refactor things that aren't broken. - Match existing style, even if you'd do it differently. - If you notice unrelated dead code, mention it - don't delete it. When your changes create orphans: - Remove imports/variables/functions that YOUR changes made unused. - Don't remove pre-existing dead code unless asked. The test: Every changed line should trace directly to the user's request. ## 4. Goal-Driven Execution **Define success criteria. Loop until verified.** Transform tasks into verifiable goals: - "Add validation" → "Write tests for invalid inputs, then make them pass" - "Fix the bug" → "Write a test that reproduces it, then make it pass" - "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: ``` 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] ``` Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. --- **These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

这段话很朴素，但好用。

它能把 Codex 的默认工作方式往“小白可验收”方向拉一点。

AGENTS.md 要不要写

要写。

AGENTS.md 可以理解成项目规则。Codex 进项目以后，先知道哪些地方别乱动。

你可以在项目根目录放一个，这是个极简版本，你也可以通过 /init 反向推导当前项目内容：

# 项目协作规则 - 修改前先输出计划 - 不要主动新增依赖 - 不要修改数据库结构 - 不要修改支付、鉴权、部署配置，除非我明确同意 - 前端改动需要检查移动端显示 - 每次改动后说明修改了哪些文件、为什么改、怎么验证 - 如果信息不确定，直接标注“不确定” - 优先做最小改动，不要大范围重构

它不能保证 AI 永远不犯错。

但至少比你每次临时补一句“别乱改”靠谱。

5 分钟上手任务

先别拿公司老项目练手。

新建一个空文件夹，做一个静态页面，比如“周末露营活动报名页”。

第一句话不要写：

帮我做个好看的活动页。

这句话太虚。

可以这样写：

我想做一个“周末露营活动报名页”的网页原型。 先不要创建文件。 请先告诉我： 1. 你准备生成几个文件 2. 页面会分成哪几块 3. 哪些内容需要我确认 4. 做完以后我应该怎么验收 页面给普通朋友看，手机和电脑都要能读。 内容包括活动标题、时间地点、费用、行程安排、报名表单、注意事项。

方案没问题，再发：

按刚才方案执行。 请在当前空目录创建一个可以直接用浏览器打开的 index.html。 限制： - 只做静态单页 - 不接后台 - 不使用外部图片 - 不安装依赖 - 不生成复杂工程 验收： - 打开 index.html 能看到完整页面 - 手机和电脑都能正常阅读 - 表单包含姓名、电话、人数、备注 - 底部有明显的“我要报名”按钮 完成后告诉我： 1. 生成了什么文件 2. 怎么打开 3. 你做了哪些设计取舍 4. 我应该检查哪几个地方

这就是任务卡。

目标、范围、限制、验收都在里面。AI 可以发挥，但不能乱跑。

并行任务怎么用

回到开头那个例子。

早上 9 点，你要同时做三件事：

在 Codex App 里，你可以开三个 thread，让它们分别跑。

但别让它们都在主目录里乱改。能用 worktree 就用 worktree。每个 thread 单独隔离，最后回来 Review。

你不是要盯着 AI 每一秒。

你要做的是回来收结果。看它有没有越界，测试有没有过，文档有没有写成人话。

这就是 Codex App 比较适合小团队和产品经理的地方。

任务可以派出去，但收活口还在你手里。

Automations 先做只读

Automations 很好用，但小白别第一天就让它自动改代码。

先做只读。官方的案例里就有一些不错的。

再比如你也可以自己建立，每天晚上检查最近改动：

每天晚上 10 点检查这个项目最近 24 小时的 Git 改动。 请输出： 1. 今天改了哪些主要内容 2. 哪些文件改动最大 3. 有没有看起来风险较高的改动 4. 有没有未完成的 TODO 5. 明天建议先检查什么 限制： - 不要修改文件 - 不要提交代码 - 不要运行破坏性命令 - 不确定的地方标注“不确定”

这个安全。

它只读，只总结，不动项目。等你熟悉以后，再让它在 worktree 里做小修复。

自动化最怕没边界。

没边界的自动化，比手动犯错还烦。