---
id: GUIDE-003
sequence: 6
number: "006"
kind: guide
slug: codex-task-lifecycle
label: Codex 入门 02
category: AI 协作
topics:
  - 对话框生命周期
  - 归档
  - Skill
  - Worktree
audience: 已经开始用 Codex，却总在纠结要不要续聊、换框或收起来的人
read_minutes: 11
title: 这个对话框，到底该继续、新开，还是归档？
subtitle: 我不再按聊天轮数管理侧栏，只问：还是不是原来那个结果
summary: 用几个真实现场讲透继续、新开、置顶、归档、退出活跃区和删除的区别，并给出一个不会误伤进行中工作的收口方法。
published_at: "2026-08-06"
updated_at: "2026-08-07"
version: v0.4
verification: verified
visibility: public
publication_state: published
legacy_path: ""
public_url: https://aixlg.com/exp/codex-task-lifecycle/
wechat_url: ""
source_href: https://aixlg.com/exp/codex-task-lifecycle/
source_cta: 阅读完整指南
article_state: ""
takeaways:
  - 还是原来的结果就继续
  - 结果变了，在同一项目新开
  - 归档是收起，删除才是销毁
deliverables:
  - 继续、新开和归档的现场判断法
  - 对话框与项目退出活跃区的收口步骤
  - Skill、自动化和子智能体的分流方法
source_refs:
  - https://learn.chatgpt.com/docs/projects
  - https://help.openai.com/en/articles/20001333-how-to-archive-and-delete-codex-chats-in-the-chatgpt-app
  - https://learn.chatgpt.com/docs/build-skills
  - https://learn.chatgpt.com/docs/environments/git-worktrees
replaces: []
revisions:
  - version: v0.4
    date: "2026-08-07"
    note: 经小龙哥确认正式发布，文章、原始 Markdown、机器目录与独立播客一并进入公网经验包。
  - version: v0.3
    date: "2026-08-06"
    note: 新增宁宁与明明的独立播客版，用真实场景逐一判断继续、新开、置顶、归档、移除和删除；完成高配音频机器质检并嵌入文章。
  - version: v0.2
    date: "2026-08-06"
    note: 根据小龙哥 40 分反馈重写，以卡顿续查、目标漂移和验收待定等真实现场讲清任务生命周期。
  - version: v0.1
    date: "2026-08-06"
    note: 初版候选，建立继续、新开、归档和删除的基础规则。
audio:
  - label: 播客版 · 第二期
    note: 宁宁 × 明明｜11:54｜高配版，机器质检通过
    src: /exp/audio/codex-task-lifecycle-20260806.mp3
---

> 有一次，一个软件设置完以后还是很慢。那一刻最正确的动作，不是为了“上下文干净”另开对话框，而是留在原地继续查。

因为问题没变，想得到的结果没变，连“什么叫修好”都没变。

另一次，我们从研究一种动画效果开始，聊着聊着做了演示，又走到产品网站，再走到公司网站。每一步都能解释，可回头一看，对话框的名字还叫“研究动画”，里面早已塞进了几种完全不同的交付物。

那一次，正确动作恰好相反：该收口，该新开。

这两个现场让我放下了一个很机械的习惯——按聊天轮数判断对话框寿命。五轮不一定该换，五十轮也不一定该留。真正要看的只有一件事：你现在要的，还是开头那个结果吗？

## 什么时候用：每次手放到“新建”或“归档”上时

很多人管理对话框靠感觉：长了就换，旧了就删，重要就置顶。这样做最大的问题，是界面变干净了，工作可能被切断；或者工作已经结束了，侧栏却永远像一排没还清的债。

我现在会先看三条线。

目标线：最终想解决的，还是同一个问题吗？

产物线：正在改的，还是同一个页面、同一篇文章、同一个候选版本吗？

验收线：怎样才算完成，有没有从“本地能看”变成“正式发布”，或者从“机器通过”变成“等真人确认”？

三条线都没有实质变化，就继续。任何一条已经变成另一个结果，通常就该新开。项目相同，不等于永远只用一个对话框。

![当前作品留在原桌继续，另一个结果拥有新桌；完成品进入可取回的档案架，删除只留在角落。](/exp/images/codex-chat-lifecycle.jpg "继续、新开、归档和删除，是四种完全不同的动作。")

## 怎么做：先判断工作还活着没有

### 同一条证据链没走完，就留在原地

设置以后依然卡顿，继续原任务。第一次修复没过真机，继续原任务。你补了一句“按钮再往左一点”，而这仍是当前界面的同一轮验收，也继续原任务。

这些补充都没有创造一个新的最终结果。此时换框，只会把报错、尝试过的办法和当前候选切成两半。所谓“对话越短越好”，在这里反而会害人。

### 验收对象变了，给它一张新桌子

文章写完以后，忽然要重构承载它的播放器，新开。研究已经得出方法，下一步要正式改公司官网，新开，而且进入公司官网所属项目。一个产品版本已经完成，接下来要做下一版，也应该有一张新的工作台。

还有一个很实用的信号：当对话框标题已经无法诚实地说出当前交付物，通常就该停下来检查了。标题叫“商业评估”，里面却在连续修启动故障、改状态栏、做发布，这不是任务勤奋，是目标已经借壳。

如果目标没变，但旧日志已经多到模型反复引用失败候选、忘记最新决定，也可以换框。先把当前事实和剩余步骤写进项目总览，再开一张干净工作台续接。不是把整段聊天复制过去。

### 归档只是让工作台退休

OpenAI 当前把归档用于把对话从活跃侧栏收起来。归档后的对话仍然保留，可以在设置中找到；删除则不可恢复。这个区别解决了我很长时间的一块心病：归档不是失忆，更不是销毁。

但“可以按下归档”仍然要过一道实践检查。我会看六件事：

1. 交付物已经真实存在，或者任务安全停在一个写清楚的闸门上。
2. 当前准确状态已经写出来，没有把“候选”顺手写成“已发布”。
3. 下一个任务需要知道的事实、决定和证据，已经回到项目总览或质检文件。
4. 子智能体、命令、临时服务和自动化没有还在偷偷运行。
5. 当前对话没有正在等验证码、扫码、用户马上回复或外部回执。
6. 如果改过代码，分支、未提交改动和工作树的归属已经清楚。

满足以后，归档的是施工现场。项目、成果和证据都还在。

### 机器通过了，但我还没验收，能不能归档？

这正是最容易说错“完成”的地方。

如果你马上要在原对话里试听、试装或反馈，就先留着，方便沿同一条证据链继续。如果验收动作已经记到明确的外部待办，候选、风险和回退点也都写进项目文件，当前后台没有继续运行，那么任务可以归档，但状态必须老老实实写“机器质检通过，用户验收待定”。

归档没有替你验收。它只让侧栏安静。

### 被外部条件卡住，能不能归档？

可以，但要先把“怎么恢复”写清楚。

比如必须等硬件到场、法律确认或另一方回信。只要阻塞点、恢复条件、下一步和责任人都已经外置，当前对话也不需要继续挂着等，它就可以退休。条件满足后，恢复旧对话或在同一项目开新任务都行。

反过来，如果你刚让用户去扫二维码、输验证码、听一段音频，或者后台命令还在跑，就先别收。桌子上的机器还没断电，不能只因为下班时间到了就把桌布盖上。

## “移除”到底是什么意思

“把它移除”在口语里很方便，在执行时却太含糊。

如果只是“不想再在活跃侧栏看见”，用归档。如果是旧项目已经分流完、以后不再承接新工作，让它退出活跃区，同时保留历史源码、证据和回退能力。如果是确定再也不需要，愿意承担无法恢复的后果，才叫删除。

所以豆豆以后遇到“移除”，应该先把它翻译成这三种具体动作之一，而不是直接当成删除授权。

一个旧项目退出活跃区，也不是把整个目录扔掉。正确顺序是：先把仍在生长的内容迁回真正所属的项目；再把最终归属、旧证据位置和“不再承接新工作”写清；最后归档旧任务，让旧项目从日常入口退场。极简保留的是责任，不是把回滚路也一刀切掉。

## 什么时候不是新开对话框，而是做成 Skill

判断也不复杂。

你要的是另一个结果，就开新任务。你要的是以后每次遇到这类事，都按同一套方法稳定完成，才考虑 Skill。

比如“做本周这期播客”是任务；“每期播客都按固定音色、分段、响度和质检流程制作”是 Skill；“每周一早上自动启动这套流程”是自动化；“这一次同时查三组互不重叠的资料”才需要临时子智能体。

第一次做，先别急着封装。等触发条件、输入、输出、边界和验收都稳定了，最好在真实任务里重复跑通，再把方法收进 Skill。一个提示词可以是起点，Skill 是已经验证过的做法连同脚本、模板和资料的长期包装。

## 容易踩坑：侧栏干净不等于工作完成

- 每一句补充都新开，证据链会被切碎。
- 结果已经换了还硬聊，旧目标和新风险会互相污染。
- 全部置顶，只会让置顶失去意义；它只是最近常用，不增加记忆。
- 归档后顺手删除，会把可恢复收纳升级成不可恢复销毁。
- 正式测试全扔进一个“测试项目”，最后只剩一句不知道对应哪个版本的“测试通过”。
- 自动化还没跑顺就定时执行，只会更稳定地重复错误。

## 验收标准：十秒钟做一次判断

下次准备继续输入时，问一句：

> 我现在要验收的，还是这场任务原来那个结果吗？

是，就继续。不是，就在正确项目里新开。

准备归档时再问一句：

> 交付在不在，事实写没写，后台停没停，还等不等当前回复？

都清楚，就归档。只是嫌乱，默认也先归档，不删除。

## 可复用提示词

~~~text
请审计当前这个 Codex 对话框，不要按聊天轮数判断。

先说清它最初的目标、当前产物和验收标准，再判断我刚补充的需求是否仍是同一个结果。

请明确建议：继续当前对话框、在同一项目新开、转到另一个项目，还是收口归档。

如果建议归档，请核对交付物、准确状态、项目接班文件、后台进程、待回复闸门和代码现场。除非我明确授权永久销毁，否则不要把“移除”理解成删除。
~~~

第三篇，我们继续处理另一个极端：不再把一个对话聊到死以后，[是不是项目越多越安全，模型越强越正确](/exp/codex-model-workflow/)？