别让长会话毁掉你的AI项目

最近我在用Codex做项目的时候，越来越确定一件事：很多项目不是死在技术上，而是死在“会话拉得太长”上。

一开始真的爽。你选中一个项目文件夹，告诉AI需求，让它改代码、调页面、修bug、加新功能，它都能接得住。前面说过的话，它看起来也记得很清楚。

但只要会话一长，恶梦就来了。它开始忘记你一开始强调过的约束条件。它开始把旧方案和新方案搞混。最要命的是，它一边帮你在修新bug，一边悄悄把前面已经写好的功能给改怀了。

你越解释越累，Token烧得飞快，AI反而越来越懵。很多人以为是自己提示词没写好，我后来踩够了坑才发现，根本不是。更大的问题是：我们太容易把“聊天记录”当成“项目记忆”了。

一、聊天记录，根本算不上项目记忆

聊天记录只适合当下沟通，完全不适合做长期记忆。因为一个聊了很久的窗口里，混着太多杂质了：

当上下文变得非常长，AI的注意力和窗口就会被压缩。它看到的不再是干净的代码库，而是一团被污染的历史残影。这时候你就会明显感觉到：明明前面它挺懂我，后面怎么越做越偏？

二、真正靠谱的项目记忆，必须放在文件里

我现在更推荐一种玩法：不要让AI靠聊天记录去硬记项目，要让它每次都重新读取根目录里的项目文件。

我现在开项目，根目录下必定固定放4个Markdown文件：

这样做有一个极大的好处：新开的窗口不需要瞎猜，AI不需要靠“记忆力”硬撑，你也不用一次次在聊天框里重复“我前面不是说过了吗”。

三、我现在最喜欢的节奏：一个任务，一个新会话

以前我也舍不得关掉老会话。总觉得重新开一个，又要重新介绍背景，浪费Token。后来我算了一笔账才反应过来，真正贵的根本不是新会话开头那几句提示词。

真正贵的是：

所以最省钱、最省心的方式反而是：新会话 + 根目录项目文件 + 当前任务文件。

每次新建一个干净的窗口，第一句话直接扔给它：

请先阅读 PROJECT_CONTEXT.md、CURRENT_TASK.md、DECISIONS.md、TASK_LOG.md，如果有 README.md 也一起看。请以当前代码和这些项目文件为准，不要依赖旧会话假设。然后再开始干活。

整个过程稳得可怕。

四、一个会话，最好只做一件事

这一点我现在感受太深了。千万不要在一个会话里，今天聊产品规划，明天改UI排版，后天修接口bug，顺手再让它搞部署，最后回头还让它改改文案。

主题塞得越多，上下文混乱得越快。真正顺畅的节奏是分工极度明确：这个会话只做首页UI。这个会话只修登录漏洞。这个会话只处理移动端适配。这个会话只整理项目上下文。

一个任务做完，直接让AI做收尾动作：

请更新 CURRENT_TASK.md、DECISIONS.md、TASK_LOG.md，记录本次完成内容、剩余问题和下一步。

收到确认后，直接关闭这个会话。下一次开个全新的窗口，继续接力。

五、如果旧会话已经乱了，千万别硬撑

如果你发现AI已经开始漏掉约束、说话前后矛盾、回答越来越泛泛而谈，这时候千万不要硬着头皮继续往下开发新功能。

最好的做法，是立刻让这个旧会话“封箱”。不要让它再写新代码，而是利用它最后的残余记忆，把信息整理回项目文件里。

你可以直接这样对它说：

这个会话已经很长，上下文可能被污染。现在不要继续开发新功能。请基于当前项目文件和本会话已经完成或讨论过的内容，更新 PROJECT_CONTEXT.md、CURRENT_TASK.md、DECISIONS.md、TASK_LOG.md。保持简洁、准确，不确定的地方标注“待核实”，不要编造。

这一步做完，旧窗口的使命就结束了。你得到的是一个更新过的、干净的项目文件，可以让新窗口无缝接手。

六、最后想说句心里话

以前很多人用AI做项目，完全依赖于“AI还记不记得我前面说过啥”。但项目只要规模稍微大一点，你就会发现这种方式极其脆弱。

真正能让你的项目持续往前推进的，绝对不是聊天窗口里的历史记录，而是一套可读取、可检查、可交接、可修正的文件接力系统。

如果你最近也遇到过用Codex越聊越乱、代码越写越崩、Token越烧越心疼的情况，别急着硬干。

先把这4个文件建起来： PROJECT_CONTEXT.md CURRENT_TASK.md DECISIONS.md TASK_LOG.md

从下一个新窗口开始，让AI先读文件，再动代码。你会明显感觉到，你的项目终于不再是靠AI的“记性”在勉强维持，而是靠一套清晰的流程在稳步往前走。

你在用AI写代码的时候，踩过最长、最乱、最费钱的一次会话有多夸张？欢迎在评论区聊聊。