我以前真心觉得：只要离开这个对话框，Codex 就会把我们一起做过的事忘掉。
这不是一个笨问题。
第一次认真用 Codex 的人，十有八九都会产生这种感觉。你和一个对话框聊了几天，它知道产品叫什么，知道你讨厌什么，知道上一次为什么失败。慢慢地，你会把这种熟悉当成一种关系：这个窗口跟久了，懂我；换一个窗口，就得从头教。
我也这样用过。
后来我的侧栏里出现了总统领、收集员、研发、测试、终审、总账，还有一批永远不下班的“专家”。它们每一个都不能关，因为我怕关掉以后，记忆也跟着没了。结果是，每来一件新事，我先想应该找谁，再把话转过去，再等它回报。窗口越来越多，我反而越来越不知道哪一个说的才算数。
真正让我想明白的，不是某篇说明书，而是一次很普通的软件修复。
那次故障已经做完了机器验证，我看着对话框，忽然问豆豆：“现在归档，会不会把重要东西丢了？”豆豆没有靠聊天里的印象回答。它去核对项目总览和那次质检记录。结果发现，故障现状、验证证据、回退点和下一步，早在我提出这个问题之前就已经写进文件了。
我那一下才明白：安全感并不是这个对话框给我的。是那些已经落盘的事实给我的。
什么时候用：如果你也不敢关掉旧对话框
先问自己一个很直接的问题：
假如这个对话框今天突然不能用了，明天新开的任务能不能只读几份文件，就知道项目现在做到哪儿？
如果不能，不是因为对话框还不够长，而是因为长期事实还没被写出来。
OpenAI 对项目的基础定义很朴素：一件工作会持续一段时间、会产生多个结果，或者会反复使用同一批文件和来源，就适合放进项目；每个不同的结果，再分别开对话框。这里面没有“一个对话聊到死”，也没有“一个按钮建一个项目”。
聊天是工作台，文件才负责接班。
左边那张桌子，就是我早期的用法。旧决定、失败方案、临时日志和今天正在做的事，全压在一起。右边不是“更聪明的聊天”，而是一套更可靠的分工：档案柜保存长期事实，桌面只留下眼前这一件作品。
怎么做：先把“记忆”拆开
很多混乱都来自我们把六种东西叫成了同一个词：记忆。
项目是家。它不是某一个功能，也不是一个好听的文件夹名。它围住的是一件会长期负责的事。产品的源码、规则、网站、版本、质检和发布责任可以住在一个项目里；个人品牌的播客、博客、公众号、书稿和网站也可以住在另一个项目里。
对话框是工作台。它只需要承接眼前这个结果，比如“修复播放器暂停按钮”“完成这一期播客”“把这篇文章改到能读下去”。结果做完，工作台就完成了使命。工作台退休，不等于房子拆了。
模型是引擎。今天用 Terra，明天换 Sol，项目并不会搬家。模型决定这一轮怎么思考和执行，不负责替你保存项目现状。一直使用同一个模型，但关键结论只藏在旧聊天里，照样会接不上；换了模型，只要真源和规则还在，照样能继续。
项目总览是接班纸。它回答的不是“我们聊过什么”，而是“现在真实到了哪一步”：当前版本是什么，哪些已经验证，哪些还没发布，下一步做什么，旧证据到哪里找。
AGENTS.md 是家规。它告诉以后进来的每个任务：哪些目录不能碰，改完要跑什么测试，什么动作必须先确认，候选、发布和用户验收不能混写。官方支持让 Codex 按目录逐层读取这些长期规则。
Skill 是做事的方法。它不保存“这个项目现在怎么样”，而是保存“这类事以后怎么重复做”。比如每一期播客都要经历切稿、配音、响度处理、解码检查和入库。第一次，你应该在普通任务里把路走通；第二次，你会发现步骤开始重复；等输入、输出、脚本和验收都稳定了，再把它做成 Skill。以后不是少开一个对话框，而是每个新对话框都少走一遍弯路。
一句话分清它们：
项目回答“这是谁的事”，对话框回答“这次做什么”，模型回答“这一轮用多大力气”，文件回答“以后从哪里接班”，Skill 回答“这类事通常怎么做”。
三个现场，一看就懂
第一种现场：播放器的暂停按钮失灵。
它不是一个新项目。到播放器所属的产品项目里，开一个“修复暂停按钮并完成真机验证”的任务。修好、验证、把结果写回去，然后归档。以后按钮又出别的问题，再开下一张工作台。
第二种现场：今天要做一期风神播客。
节目属于个人 IP 项目，这一期节目是一个任务。只要研究、写稿、生成和机器质检原本就共同服务同一个成品，它们可以留在同一对话框。可如果做到一半，忽然决定重构播放器，那已经是另一个产品结果，应该去播放器所属项目另开任务。
第三种现场：以后每周都要做一期风神播客。
“这一期”仍然是任务；反复出现的制作方法才是 Skill；如果还要求每周一早上自动启动，那一层叫自动化。不要因为事情每天发生，就养一个永远置顶的“播客员工窗口”。时间、方法和本次结果，本来就是三件事。
容易踩坑：我真的踩过的三条弯路
最早，我把对话框当员工。于是每个岗位都要一个窗口，任务开始在窗口之间旅行。消息送达被写成开工，机器测试又被写成发布，最后连“用户满意”都可能被提前替人说了。
后来，我把聊天历史当知识库。可历史里既有正确结论，也有失败候选、临时授权和过期假设。完整保存过程没有错，错的是让下一次任务靠重读全部过程恢复现状。真正该接班的，只是被核验过的结论和证据。
再后来，我差点把每个新做法都封成 Skill。可尚未跑顺的流程一旦固化，错误也会开始自动复现。一个方法至少要能说清触发条件、输入、输出、边界和验收；最好已经在真实任务里稳定重复过，才值得升级。
验收标准：读完后你应该能回答这些
不用背名词。拿你手边的一件事，试着回答：
- 它长期属于哪个项目？
- 这一次只交付什么结果？
- 项目的当前事实写在哪里？
- 所有后续任务都必须遵守的规则写在哪里？
- 这是一次新结果，还是一种已经稳定重复的方法？
五句都能答出来，你就已经越过了“靠一个对话框记住一切”的阶段。
可复用提示词
请先帮我给这件事找对位置，不要急着动手。
我要的结果：
长期归属的项目：如果不确定，请根据共享文件、规则和责任判断
事实真源：请指出开工前应该读哪几份
不能动的边界：
完成标准：
最后请告诉我：这是现有任务的继续、同项目里的新任务，还是一种已经稳定到值得做成 Skill 的重复方法。
下一篇，我们解决更让人纠结的问题：已经有了项目以后，这个对话框到底该继续、新开，还是归档？
还没有评论。欢迎留下第一句。