别怪 AI 记不住了,是你没给它写交接文档

我发现在一个很有意思的现象：

很多人用 AI 做项目，第一周特别爽。

一个需求丢进去，AI 立刻开始写代码、改文件、跑命令，看起来效率翻倍。但到了第二周、第三周，或者换了一个对话窗口之后，问题开始暴露：

AI 忘了之前为什么这么设计。

你上个礼拜明明说过的需求，它又开始跟你确认。你刚踩过的坑，它又踩一次。项目做着做着，方向就歪了。

很多人遇到这个情况，第一反应是：AI 不行。

但我的结论正好相反。

AI 不是记不住，是你没给它设计一个能记住的工作环境。

聊天记录不是项目记忆

大多数人和 AI 协作的方式是这样的：

打开一个对话窗口 → 说需求 → AI 开始干活 → 干到一半切窗口 → 回来忘了 → 重新开对话 → 再说一遍需求 → AI 重新理解 → 发现它又从头开始写。

这个循环的关键问题在哪里？

不在 AI，在状态管理。

你做项目的时候，”状态”存在于哪里？存在于你的大脑、你的笔记、你的聊天记录里。但 AI 没有”长期记忆”。每一次新对话，它都是一张白纸。

很多人试图用 Prompt 来解决这个问题。

“你要记住……”、”我之前说过……”、”在上一条对话里……”

但这本质上是在用聊天记录当内存。而聊天记录的容量是有限的，上下文窗口一满，最早的信息就被挤出去了。

这个问题的根源，不是 Prompt 写得不好，是你把项目的”状态”放在了不该放的地方。

正确的方向：把上下文从聊天记录移到项目文档

想通这一点之后，我换了一个思路。

如果 AI 每次新对话都是一张白纸，那我能不能在项目里放一套文档，让 AI 每次开工前先读这些文档，把上下文恢复出来？

就像你换了一个新同事接手项目，你不会让他翻你的聊天记录，而是让他读项目文档。

AI 也是一样的。

我目前在做的几个 AI 项目里，都在用这个思路。我把这个体系叫做 “AI 项目五层记忆系统”，核心就是五份文档：

这五份文档加起来，就是一个 AI 项目的结构化上下文。AI 每次开工前，先读完这五份文档，它就知道：

• • 这个项目是做什么的
• • 哪些事能做，哪些事不能做
• • 哪些坑已经踩过了
• • 现在做到哪一步了
• • 下一步该做什么

你不再需要每次新开对话都”交代一遍背景”。AI 自己读文档，自己恢复上下文。

每层管什么

第一层：SPEC.md — 目标记忆

AI 项目跑偏，90% 是因为需求没有被钉住。

比如你说”帮我做一个 TikTok 选品分析系统”，AI 可能会自己加很多”合理”的功能：用户注册、历史记录、数据可视化仪表盘……

这些听起来都合理，但不是你要的。

SPEC.md 的核心作用就是一句话：明确边界。最重要的不是写”做什么”，而是写”不做什么”。

如果 SPEC 里没有写”不做”，AI 就会自己做主。

第二层：AGENTS.md — 规则记忆

这不是 README。

README 是写给人看的，AGENTS.md 是写给 AI Agent 看的。它规定的是：

• • 开工前必须读哪些文件
• • 文档冲突了听谁的
• • 哪些事情绝对不能做
• • 每个模块什么程度才算完成

它就像项目的”宪法”——不是介绍，是约束。

第三层：tech.md — 技术记忆

这一层是我觉得最值钱的。

做数据项目的人都知道，最痛苦的不是写不出代码，而是：

• • 这个接口看上去能用，实际返回是空的
• • 这个字段文档里有，但免费版不给你
• • 这个参数换成另一个市场就挂了
• • 今天能跑，明天不能跑

这些坑如果只留在聊天记录里，下一个人、下一次迭代，一定会再踩一遍。

tech.md 就是项目的”踩坑资产库”。每条坑都要写清楚：发现了什么、怎么验证的、影响是什么、下次怎么做。

第四层：plan.md — 执行记忆

没有 plan 的 AI 项目，AI 很容易陷入两种状态：一种是一上来就写代码，一种是写完一个不知道下一个是什么。

plan.md 的作用是把大任务拆成可验证的小模块。每个模块有明确的输入、输出、完成标准。

它不是幻想路线图，是执行路线图。

第五层：process.md — 交接记忆

这一层是做给自己和未来 AI 看的。

每次完成一个模块，记录：做了什么、改了哪些文件、跑了什么命令、结果是什么、还有什么问题、下一步是什么。

标准只有一个：另一个 Agent 不用看聊天记录，光读这个文件，就能接手干活。

一个真实案例

我在做一个 TikTok Shop 选品分析的项目（叫 tk_shop_trending），覆盖 4 个数据源。这个项目天然有”多个会话接力”的特性——数据采集、分析、报告生成不在同一个会话里完成。

如果只靠聊天记录推进这个项目，第一天还行，第二天就开始断片。到了第三天，AI 问你”这个接口的参数是什么”——你发现这个问题两周前刚讨论过。

用了这套文档体系之后，最明显的变化是：

• • AI 不再问重复问题
• • 新会话可以在 3 分钟内恢复上下文，不需要从零开始
• • 发现的技术边界被系统性地记录下来，而不是散落在聊天记录里
• • 项目方向更稳定，因为 SPEC 钉住了边界

其中最有价值的，反而是最简单的两个文件：tech.md 和 process.md。

tech.md 记录了 “Echotik 免费版的销量字段全是 N/A”、”Fastmoss 必须用 Playwright，不能改成 requests”——这些一条一条的边界。

process.md 记录了每个模块的完成状态和下一步。即使隔了两周再回来，读一下 process.md，就能知道上次做到了哪里。

不一定适合所有场景

说完了好处，也说一下边界。

这套”五层记忆系统”不是所有项目都需要的。它适合的是：

• • 需要多个会话完成的项目
• • 需要长期维护迭代的项目
• • 有多个数据源、API、自动化的复杂项目
• • 可能被多个 Agent 或多人接手的项目

不适合的是：

• • 一次性的小脚本
• • 临时的试验探索
• • 简单的问题排查

不是所有事情都值得系统化，但中长期 AI 项目必须系统化。

最后说几句

AI 不需要记住一切，AI 需要每次开工之前，能读到对的信息。

这个认知转变对我来说挺关键的。它让我从”怎么优化 Prompt”跳到了”怎么设计项目上下文结构”——前者是战术，后者是系统。

我现在做 AI 项目的标准流程变成了：

1. 1. 先问清楚需求 → 写 SPEC.md
2. 2. 定好规则 → 写 AGENTS.md
3. 3. 做技术探测 → 写在 tech.md
4. 4. 拆执行计划 → 写 plan.md
5. 5. 做完记录交接 → 写 process.md

等用户确认了需求，再开始写代码。

看起来慢，但实际更快。因为 AI 不再问重复问题，不再踩重复坑，每一次新会话都能在 3 分钟内回到轨道上。

这大概就是”状态管理”的威力。

我是做AI产品出海的Peter，一个更关注需求价值，而非AI技术的产品人。