• 置顶对话：把这个会话固定到侧边栏靠前位置，方便常用会话长期保留在上面。
• 重命名对话：手动改这个会话的标题，不影响会话内容，只是更好找。
• 归档对话：把会话从主列表收起来，通常不是删除，只是移到归档区。
• 标记为未读：给会话重新打上“未读”状态，方便之后回来继续看。
• 在“访达”中打开：直接用 macOS 的 Finder 打开这个会话对应的本地工作目录。
• 复制工作目录：复制这个会话当前绑定的文件夹路径。
• 复制会话 ID：复制这个会话的唯一标识，一般用于排查问题、引用会话、内部定位。
• 复制深度链接：复制一个能直接打开这个会话的链接，通常用于自己快速跳转，或发给有权限的人。
• 派生到本地：基于当前会话“另开一个本地分支会话”继续做，原会话保留，新会话单独发展。
• 派生到新工作树：基于当前会话新建一个 Git worktree 来继续，适合并行开发、试不同方案、避免互相污染。
• 在迷你窗口中打开：把这个会话放到更小的独立窗口里，适合边写代码边看对话。

自动化

Codex App 的自动化，最适合处理这三类事：

1. 到时间再做
   比如：
   • 明天上午提醒你跟进一个 PR
   • 每周一整理一次待办
   • 两小时后回到当前线程继续处理
2. 重复但规则明确
   比如：
   • 每天固定时间检查某个项目状态
   • 每周生成一次例行汇总
   • 周期性提醒你做某个维护动作
3. 需要等待条件变化
   比如：
   • 监控某个结果是否出现，再通知你
   • 等一个任务跑完后再继续后续步骤
   • 某个状态变化时唤醒当前对话

简单说，它特别适合：

• 提醒
• 定时执行
• 持续跟进
• 把长流程拆成多次自动推进

不太适合的场景是：

• 需要你当场拍板的高风险操作
• 规则很模糊、每次都要重新判断的任务
• 需要秒级实时响应的控制场景

CodeX使用技巧

Codex App 最实用的技巧，不是“会不会用”，而是“怎么提需求更省来回”。

提问方式

• 用 目标 + 约束 + 验收标准 说需求。比如：把登录页改成双栏布局，保留现有接口，不动后端，移动端也能用
• 想让我直接干，就明确写：直接改，不用先讲方案
• 想先对齐思路，就写：先看代码，给我一个最小改动方案
• 给入口信息会快很多：报错日志、相关文件路径、复现步骤、localhost 地址、截图

最好用的几种请求

• 帮我定位这个报错，顺手修掉并跑一遍相关测试
• review 这次改动，优先看 bug / 回归风险 / 漏测
• 重构这个模块，但不要改对外接口
• 把这段需求落成代码，并告诉我改了什么
• 先读项目，再帮我找最适合下手的位置

让结果更稳的技巧

• 限定范围：只改前端、不要碰数据库、不要改现有 API
• 限定风格：保持当前设计风格、按现有组件体系写
• 限定风险：优先最小改动、不要引入新依赖
• 限定输出：最后给我一段 PR 说明、顺便补测试

调试时最有效

• 贴完整报错，不要只贴最后一行
• 告诉我：你期望什么、实际发生了什么
• 如果是前端问题，最好加上：哪个页面、哪个按钮、怎么复现
• 如果是接口问题，最好加上：请求参数、返回值、环境

和 Codex 配合的心法

• 大任务别一句话全塞完，按阶段推进更稳
• 让它“先看再改”，通常比直接盲改更可靠
• 让它“改完自查”，比如：改完跑测试，再告诉我风险
• 如果你要的是判断，不是改代码，就直接说：先别改，先评估

万能提示词

你先阅读相关代码，再帮我处理这个任务。

目标：
[我要实现什么]

背景：
[这个功能/问题出现在哪里，为什么要做]

范围：
[允许你改哪些文件/模块]
[不要改哪些部分]

约束：
[比如：不要改后端、不要改接口、不要引入新依赖、保持现有风格]

相关信息：
[文件路径 / 页面路径 / 接口信息 / 报错日志 / 截图说明 / localhost 地址]

当前现象：
[现在发生了什么]

期望结果：
[我希望最后变成什么样]

验收标准：
[例如：按钮可点击、移动端正常、测试通过、构建通过]

执行方式：
[直接改，不用先讲方案] 或 [先分析，再给最小改动方案]

输出要求：
最后告诉我：
1. 改了什么
2. 为什么这么改
3. 风险点
4. 跑了哪些验证