Chat
问问题、讨论、比较方案、写文字。
不需要操作项目文件面向开发同事 · 2026
今天不背功能。只学一条可复用的开发链路:把「状态筛选」做完并验收。
先说明结果,再让 Codex 动手;先有证据,再算完成。
步主链路
条完整流程
个必防难点
主链路必讲;插件与细节在附录,主链路跑通后再看。界面可能随版本更新,操作原则不变。
主链路 · 01 · 2 分钟
Project 负责装上下文,不是第四种模式。
问问题、讨论、比较方案、写文字。
不需要操作项目文件报告、表格、课件等可审核成果。
目标是一个交付物读代码、改文件、跑测试、看 Diff。
需要开发工具和技术细节官方依据:Use ChatGPT
主链路 · 02 · 1 分钟
项目把相关任务和本地文件夹放在一起。需要长期做、会产生多个结果时再创建。
codex-class-demo。项目菜单 → Edit project 可继续添加目录;将代码仓库设为 Make primary,它会成为新任务默认工作目录和 Git 操作目标。
官方依据:Projects and chats
主链路 · 03 · 1 分钟
项目复用文件和规则,任务保留自己的对话与结果。不要把所有工作塞进同一条任务。
代码库不同、上下文无关,或不希望任务访问另一组目录。
仍是同一项目,但目标从调查变为实现、审核或发布。
一次性问题,不需要共享文件、规则或后续任务。
Primary folder:新任务默认目录,也是 Git、Worktree、PR 和自动发现 AGENTS.md 的主要目标。
Secondary folders:仍可搜索、读取和编辑,但不会自动发现其中的项目配置。
适合一起放:前端 + 后端、代码库 + 配套文档。
应该拆项目:彼此无关,或需要限制每条任务可访问的目录。
主链路 · 04 · 4 分钟
用“增加状态筛选”贯穿整堂课:先知道终点,再学习每一步怎么做。
按已确认计划实现状态筛选。 完成后运行现有测试,并用浏览器验证三种筛选。 不要提交、推送或修改无关文件。
检查当前改动是否满足验收条件。 列出运行过的测试、浏览器操作和仍未验证的风险。 不要根据代码推测页面已经可用。
修复 Code Review 中确认的问题。 保持改动最小,补充回归验证,然后再次 /review。 不要顺便重构无关代码。
主链路 · 05 · 3 分钟
Plan 用来调查、提问和锁定实现方案;确认后再实施。
目标:给任务清单增加状态筛选。 范围:只修改前端,不增加依赖。 限制:保留现有本地数据。 验收:全部/待办/完成筛选正确,刷新后数据不丢。 请先检查现有实现并给出完整计划,不要修改文件。
模型:默认即可;卡住再升高推理,不要一上来 Max。详见附录 A13。
先检查计划中的文件范围、风险和验收条件。确认无误后明确回复:“按这个计划实施,完成后运行测试并汇报证据。”不要让 Plan 阶段一边调查一边偷偷改文件。
主链路 · 06 · 2 分钟
点击输入框左下角的权限标签;它会影响 Codex 可访问的范围以及何时停下来问你。
官方依据:Agent approvals & security · Permission profiles;三档名称以当前桌面版为准。
主链路 · 07 · 4 分钟
在发送任务之前选择运行位置。发送后,Codex 才会创建隔离目录并开始工作。
main 或目标开发分支开始。看不到 Worktree?先检查当前项目是不是 Git 仓库,以及是否在 Codex 桌面应用。
还没创建?只切换选择器不算创建,要输入任务并发送。
就近坑 1:缺依赖 / 缺配置新目录默认只有 Git 跟踪的文件。.env 等被忽略文件不会自动出现;需要时用 .worktreeinclude,或 Handoff 回本机环境。
就近坑 2:改完别悬着托管 Worktree 里的改动默认还不在你的日常分支上。验证完要么在这里建分支,要么 Handoff 回 Local。
官方依据:Git worktrees
主链路 · 08 · 3 分钟
状态筛选写完代码后,不要直接相信“看起来跑过了”。按固定顺序检查。
防什么:改错目录、改错分支、准备提交到错误仓库。
重点看:Local 还是 Worktree、当前分支、Changes 文件数与增删行。
提交前四问:仓库对吗?环境对吗?分支对吗?Diff 对吗?
防什么:长时间 Working、假进度、以为“做过”就是“做对”。
重点看:读文件、跑命令、搜索、是否在等输入。
原则:“做过”不等于“做对”;仍要核对测试、页面和最终结果。
这里专门防第 3、4 个坑:改错落点,以及用“看起来跑过了”代替验收。界面问题可用 Browser Annotation 定点标记,比“这个页面不好看”更准。
官方依据:Environments · Terminal · Browser;详细五工具说明见附录 A14。
主链路 · 09 · 5 分钟
测试证明功能能跑;Review 检查改动是否安全、正确、可维护。
/review 默认只报告问题,不会自动修改工作区。
第一次:审未提交修改,重点找真实缺陷、回归和遗漏测试。
修复后:运行相关测试,不能只回复“已修复”。
第二次:重新审当前 Diff,确认修复没有引入新问题。
PR 前:再与基础分支比较,确认没有夹带无关提交。
主链路 · 10 · 2 分钟
托管 Worktree 里的改动,默认还不在你的日常分支上。先验证,再决定:在这里建分支,或交回本机 Local。
点 Create branch here 把改动挂到正式分支,再提交、推送或发 PR。(术语:脱离 Detached HEAD)
适合改动已完整验证把任务和改动交回本地仓库,再用现成 IDE、服务或硬件环境验证。
适合必须依赖本机环境从项目菜单创建永久 Worktree,适合长期并行分支。
普通一次性任务不需要.env 等被忽略文件不会自动出现;需要时配置 .worktreeinclude。主链路 · 11 · 2 分钟
先对照现象,再执行对应动作。每个问题都能现场演示,不讲空泛原则。
立即取消任务,按输入框上箭头找回提示词;重新选择 Local 或 Worktree 后再发送。
Worktree 默认只有 Git 文件。运行初始化脚本;被忽略的配置用 .worktreeinclude,依赖本机环境则 Handoff 到 Local。
Review 会显示项目当前 Git 改动。切到 Last turn 看本轮,再分别核对 staged、unstaged 和与 main 的差异。
先停止修改,在 Terminal 运行 pwd、git status --short --branch、git diff --stat;确认用户已有改动后再处理。
打开 Activity 看停在检索、命令执行还是等待输入;再到 Terminal 看进程。确认无进展才取消,不要重复发同一任务。
核对启动目录、端口和进程;用 Browser 查看真实 URL、Console 与 Network,并确认打开的是当前 Worktree 启动的服务。
先不要修改、回退或删除文件。请依次告诉我: 1. 当前 Environment 是 Local 还是 Worktree; 2. 当前目录、分支和 git status --short; 3. 最后执行的命令与原始错误; 4. 本轮实际修改了哪些文件; 5. 建议的最小恢复动作和验证方法。
主链路 · 12 · 2 分钟
每一步都对应开场那 5 个难点里的至少一项。
聊 / 交付 / 动代码
防:选错入口、任务塞太多
上下文与长期约定分清
防:每次重说一遍规则
先锁范围和验收
防:边查边改
发送后才创建
防:改错目录 / 分支
环境、分支、Diff
防:改在错误位置
核对真正执行过什么
防:假进度
执行证据 + 结果证据
防:推测验收
修复之后再复核
防:夹带改动、漏边界
Codex 最有价值的地方,不是“替你写代码”。
而是把调查、实现、验证和审核连成一条可靠流程。固化 · 选讲 · 5 分钟
主链路跑通后再写。仍用「状态筛选」例子:AGENTS 管长期约束,Skill 管可复用流程,Hook 管固定时点脚本。
状态筛选例子:改前端后必须 npm test;不修改 .env 与无关模块;汇报测试证据。
触发:任务开始自动读取。
状态筛选例子:「整理发布说明」做过两三次后,做成 $release-note 步骤与验收。
触发:$名称 或描述匹配。
状态筛选例子:Stop 时跑固定 lint/test。不替代完整 CI。
触发:事件 + matcher。
# 项目规则 - 修改前阅读 README 和现有测试。 - 状态筛选相关改动完成后运行:npm test && npm run lint - 不修改 .env、生成文件和无关模块。 - 汇报修改文件、测试结果和未验证风险。 - 未经确认不要提交、推送或发布。
准确命令、目录边界、代码规范、验证门槛、敏感操作限制。
Token、密码、一次性需求、过时路径,以及“写好一点”这类空话。
AGENTS.md 规定“必须测试” → Skill 说明“怎么整理发布说明” → Hook 在 Stop 时做固定检查;CI 仍是最终门禁。Git 个人默认(分支前缀、Draft PR)见附录 A12。
官方依据:AGENTS.md · Build skills · Hooks
个人:~/.codex/AGENTS.md 通用习惯与安全边界。
项目 / 模块:仓库或子目录 AGENTS.md,越靠近当前目录优先级越高。
Skill 位置:仓库 .agents/skills/名称/SKILL.md,或个人 ~/.agents/skills。
Hook:Settings → Hooks;新增非托管脚本先审再信任。细节页见附录 A9–A12。
附录 A1 · 按需
一个给当前任务补能力,一个把当前目录交给你熟悉的本机工具。
注意:只是打开当前目录,不会把 Worktree 改成 Local,也不等于 Handoff。
官方依据:Goal mode · Skills · Desktop app;具体菜单以当前版本为准。
附录 A2 · 按需
报错、设置、设计稿或预览页面难以描述时,直接补充视觉与文字上下文。
发送前检查:截图和窗口可读取文字都会共享给 ChatGPT;账号、Token、客户信息等敏感内容先隐藏。部分应用只能提供可见截图,不能代替完整文件或插件。
官方依据:Appshots(目前仅支持 macOS 桌面应用)。
附录 A3 · 按需
不讲安装流程。只记住:什么时候用,以及让它交付什么。
写方案、说明和复盘;PDF 用于读取规范与检查最终版。
做测试矩阵、字段映射、数据核对和迁移清单。
把技术方案、培训内容或事故复盘做成可演示课件。
把周报、PPT、表格的固定结构做成下次可复用模板。
快速制作并发布演示页、内部工具或静态网站。
打开真实页面,点击验收、查控制台、截图并标记问题。
需要操作本机应用、又没有更合适接口时使用。
评审页面流程和视觉问题,再给出可执行的改版建议。
先说清要交付的结果,再选择最匹配的插件;不需要为了“可能有用”一次装很多。
官方说明:Plugins · Skills & Plugins
附录 A4 · 按需
这四个工具在方案、测试、迁移、汇报阶段使用频率很高。
设计文档、接口变更说明、发布说明、复盘报告。
读取规范、检查排版、交付不可随意编辑的最终版。
测试矩阵、数据核对、字段映射、迁移清单和统计。
技术方案评审、培训课件、发布演示和事故复盘。
官方依据:Work with files
附录 A5 · 按需
保留结构、语气与视觉风格;下一次只提供新内容。
提供一份代表性参考文件,说明要保留的结构、排版和语气;生成后先检查预览。
从对应工具的 Template Gallery 选择,或输入 $artifact-template-模板名,再描述本次内容。
核对旧项目名、人员、日期和业务数据是否已替换;格式是否仍与参考一致。
把附件《项目周报.docx》做成个人模板。保留标题层级、表格、字体和页眉;移除项目名、人员、日期与业务数据。以后输入本周进展、风险和下周计划即可生成新周报。先给我模板预览和隐私检查结果。
参考文件会保留在个人模板中,先去除密钥和隐私。个人模板默认私有;团队共享需再打包成插件。
依据:当前已安装 Template Creator 插件说明;模板本质是可复用 Skill。通用机制见 Build skills。
附录 A6 · 按需
适合快速做演示页、内部工具、看板和小型 Web 应用;不必先搭建单独的部署流程。
原型、培训页、活动页、内部看板、小工具。
必须接入现有 CI/CD、网关或公司服务器的正式系统。
为研发团队做一个值班任务看板网站。支持新增任务、负责人、状态筛选和本地保存。先生成可预览版本,完成浏览器验收后再问我是否部署。
Sites 的部署链接就是正式线上版本。还没验收时,明确要求“只保存版本,不要部署”。可用范围和额度可能受账号、地区及工作区设置影响。
官方依据:Sites
附录 A7 · 按需
适合 UI 占位图、Banner、背景、插画和演示素材;不是用来替代真实产品截图。
为内部值班系统生成一张空状态插画。 主体:整齐的任务清单与一个绿色完成标记。 风格:简洁扁平、白底、低饱和绿色。 尺寸:16:9。不要文字、Logo、人物和渐变。
修改已有图:明确写“只改什么”和“必须保留什么”,一次只调整一个重点,避免构图漂移;图片中的文字和业务细节仍要人工复核。
官方依据:Image generation
附录 A8 · 按需
比“这个页面不好看”更精确,适合布局溢出、间距、遮挡和局部样式问题。
附录 A9 · 按需
把长期、稳定、可验证的约定放进去;不要每次重新提示。
~/.codex/AGENTS.md所有项目都适用:表达语言、通用安全边界、默认工作习惯。
<repo>/AGENTS.md整个仓库适用:构建与测试命令、架构边界、禁止修改范围。
<repo>/module/AGENTS.md只约束该目录:模块专属命令、框架约定和验收要求。
官方依据:AGENTS.md · Personalization
附录 A10 · 按需
同一类任务做过两三次,并且步骤、边界和验收基本稳定时,再创建 Skill。
$skill-creator,或从“+”菜单选择不要塞进去:密码、Token、个人绝对路径、一次性需求和未经验证的破坏性命令。Skill 是做法,不是秘密仓库。
官方依据:Build skills
附录 A11 · 按需
它是在 Codex 生命周期固定时点运行的确定性脚本,不依赖模型“记得做”。
新增或变更的非托管 Hook 必须重新审核和信任;先看脚本,再启用。
官方依据:Hooks
附录 A12 · 按需
设置负责个人默认值;仓库规则、CI 和团队约定仍是最终标准。
给 Codex 新分支统一前缀,便于识别负责人或来源。
必须服从仓库合并策略,不要个人随意切换。
默认关闭;确需改写历史也只用 --force-with-lease。
开发中默认开草稿,验证完成再转 Ready。
Inline 留在当前任务;Detached 适合独立、较长审核。
固定语言、标题和描述结构,减少每次重复提示。
统一提交格式可以写进设置;禁止提交的内容、测试门槛和分支策略应写进仓库规则并由 CI 兜底。
界面依据:Desktop settings · Code Review;具体 Git 项以当前版本为准。
附录 A13 · 按需
推理越高通常越慢、用量越大。不是越高越好。
复杂、开放、需要判断与成品质量。
日常编码、工具调用、速度质量平衡。
明确、重复、批量和结构化任务。
适合能拆成多个独立部分的大任务。普通任务不需要。
Sol + Medium:跨模块改造、定位复杂缺陷、交付培训网站。
Terra + Medium:日常接口开发、补测试、改配置。
Luna + Light:批量改名、格式整理、明确的重复修改。
升级推理:先保持模型不变,确实卡住再从 Medium 调高。
官方依据:Models
附录 A14 · 按需
课堂先记住“什么时候用”和“用它完成什么”;细节留作课后查阅。
什么时候:写完代码、提交或发 PR 前。
怎么开:点 Review,选择未暂存、已暂存、分支或本轮改动。
例子:确认只改了需求文件,并留下行级评论。
注意:看 Diff 与 /review 自动分析不是一回事;需 Git。
什么时候:跑测试、脚本、Git 或开发服务。
怎么开:点 Terminal,默认位于当前项目或 Worktree。
例子:npm test、git status。
注意:命令会真实执行;先看目录,破坏性操作先确认。
什么时候:验收网页、交互、截图和控制台。
怎么开:Terminal 启动服务后,用 Browser 打开本地地址。
例子:逐个点击筛选,并检查页面和控制台。
注意:与日常 Chrome 配置隔离;网页内容也可能不可信。
什么时候:快速定位和打开当前项目文件。
怎么开:点 Files,输入文件名或沿目录定位。
例子:直接跳到 src/App.tsx。
注意:只覆盖已添加目录;单个文件不代表完整调用链。
什么时候:主任务进行时,顺手问一个短问题。
怎么开:点 Side chat,写清“只解释,不修改文件”。
例子:解释当前报错,或比较两个实现。
注意:需要独立交付或长时间执行时,新建任务。
官方依据:Terminal · Browser · Code Review;Files 与 Side chat 入口以当前界面为准。
课前准备
安装后即可使用 Chat、Work 与 Codex。文件已缓存到 219,内网可直接下载。
注意:内置 Browser 使用独立浏览器配置,不自动继承日常 Chrome 登录;外部网页内容不可信,敏感操作仍需确认。