大型 AI 项目不要把聊天记录当项目记忆

大型项目中，真正的问题通常不是“新上下文不方便”，而是：

项目状态只存在聊天记录里，没有独立保存成可复用的项目记忆。

大型项目不应该依赖一个无限增长的聊天窗口。更实际的做法是：

项目上下文文件 + 阶段快照 + 总控对话与执行对话分离

这样即使换新对话，也不需要重新解释整个项目。

一、不要把聊天记录当项目记忆

一个对话问得特别长，会逐渐出现这些问题：

早期需求被后面的内容覆盖
AI 忘记之前确定的字段和接口
已废弃的方案仍然留在上下文里
报错日志和临时代码占用大量上下文
AI 很难判断哪一版信息才是最新的
修改一个模块时，被其他无关内容干扰

所以正确思路不是坚持使用一个聊天，而是：

聊天负责执行任务
项目文件负责保存事实
Git 负责保存代码历史

二、建立一个项目上下文包

在项目根目录创建：

project/
├── AGENTS.md
├── docs/
│   ├── PROJECT.md
│   ├── ARCHITECTURE.md
│   ├── CURRENT_STATE.md
│   ├── DECISIONS.md
│   ├── TASKS.md
│   ├── API.md
│   └── DATABASE.md
├── backend/
├── frontend/
└── README.md

其中最重要的是下面五个文件。

1. PROJECT.md：项目基本信息

只保存长期稳定的信息：

# 项目基本信息

## 项目名称
冰雪景区综合服务系统

## 项目目标
为游客和景区工作人员提供门票、民宿、公告、订单及运营统计服务。

## 用户角色
- 游客
- 运营人员
- 系统管理员

## 技术栈
后端：
- JDK 17
- Spring Boot 3.3.x
- MyBatis-Plus 3.5.x
- MySQL 8.0
- Redis 7

前端：
- Node.js 20
- Vue 3
- TypeScript
- Element Plus

## 核心模块
- 用户认证
- 景区管理
- 门票管理
- 订单管理
- 民宿管理
- 公告活动
- 数据统计
- 系统管理

这个文件不要频繁修改。

2. CURRENT_STATE.md：当前开发状态

这是每次开启新对话时最有用的文件。

# 当前项目状态

更新时间：2026-07-16

## 已完成
- 后端项目初始化
- 前端项目初始化
- MySQL 数据库连接
- 统一返回 Result
- 全局异常处理
- 用户登录
- JWT 身份认证
- 门票分类管理

## 正在开发
订单创建功能。

## 当前实现情况
已经存在：
- Order 实体类
- OrderMapper
- OrderController
- 订单表和订单明细表
- 前端订单列表页面

尚未实现：
- 创建订单
- 库存扣减
- 重复提交防护
- 订单事务
- 创建订单测试

## 当前问题
创建订单时需要解决：

1. 库存并发扣减。
2. 订单价格必须以后端为准。
3. 重复点击不能产生重复订单。
4. 订单和库存必须在同一事务中。

## 下一步
实现订单创建服务和对应测试。

它相当于项目的“存档点”。

3. DECISIONS.md：已经确定的决定

AI 最容易反复改变已经确定的设计，所以要单独记录。

# 已确定的项目决策

## DEC-001：采用单体模块化架构

状态：已确定

原因：
当前项目规模不需要微服务，部署和答辩以简单可靠为主。

禁止：
不得擅自拆分成 Spring Cloud 微服务。

---

## DEC-002：数据库变更使用 Flyway

状态：已确定

规则：
- 已执行的迁移文件不得修改。
- 每次数据库变更新建迁移文件。

---

## DEC-003：接口统一返回 Result<T>

状态：已确定

格式：

{
  "code": 200,
  "message": "success",
  "data": {}
}

禁止：
不得为某个模块重新创建另一套返回结构。

这样新对话中的 AI 不会重新建议一套完全不同的架构。

4. TASKS.md：任务清单

# 项目任务

## 当前里程碑：订单模块

- [x] 创建订单表
- [x] 创建订单实体
- [x] 创建订单查询接口
- [ ] 实现订单创建 DTO
- [ ] 实现订单金额计算
- [ ] 实现库存原子扣减
- [ ] 实现订单事务
- [ ] 实现重复提交防护
- [ ] 编写单元测试
- [ ] 编写接口测试

## 暂不处理
- 微信支付
- 自动退款
- 消息队列
- 微服务拆分

“暂不处理”很重要，可以防止 AI 擅自扩大范围。

5. AGENTS.md：AI 工作规则

# AI 开发规则

## 开始任务前

必须先阅读：

1. docs/PROJECT.md
2. docs/CURRENT_STATE.md
3. docs/DECISIONS.md
4. docs/TASKS.md
5. 当前任务相关代码

## 修改规则

- 只修改当前任务涉及的文件。
- 不进行无关重构。
- 不擅自升级依赖。
- 不擅自修改数据库字段。
- 不删除已有正常功能。
- 不虚构项目中不存在的工具类。
- 优先复用已有公共组件。
- Controller 不直接操作 Mapper。
- Entity 不直接作为新增、修改接口参数。

## 完成任务后

必须：

1. 执行编译。
2. 执行测试。
3. 列出修改文件。
4. 说明测试结果。
5. 更新 CURRENT_STATE.md。
6. 更新 TASKS.md。
7. 如有新架构决定，更新 DECISIONS.md。

三、把上下文分成三层

这是最实用的上下文管理办法。

第一层：永久上下文

长期基本不变化：

PROJECT.md
ARCHITECTURE.md
AGENTS.md
编码规范
技术版本
角色和模块

第二层：动态上下文

随着开发不断更新：

CURRENT_STATE.md
DECISIONS.md
TASKS.md
API.md
DATABASE.md

第三层：当前任务上下文

只提供当前任务需要的信息：

具体需求
相关数据库表
相关 Controller
相关 Service
相关前端页面
完整报错
验收条件
允许修改范围

开启新对话时，不需要把整个旧对话复制过去，只提供这三层中真正相关的部分。

四、采用一个总控对话加多个执行对话

不要让一个聊天同时负责所有事情。

总控对话

长期保留，只负责：

项目规划
任务拆分
架构决定
检查进度
决定下一步做什么
维护上下文文件

不要在总控对话里粘贴大量报错和完整代码。

执行对话

每个模块或任务一个：

对话 1：登录权限
对话 2：门票管理
对话 3：订单创建
对话 4：库存并发
对话 5：前端页面
对话 6：测试和排错

任务完成后，把结果压缩到 CURRENT_STATE.md，然后关闭这个执行对话。

结构相当于：

                总控对话
                   │
       ┌───────────┼───────────┐
       │           │           │
   登录对话    订单对话     前端对话
       │           │           │
       └──────更新项目文件──────┘

总控对话不需要记住所有实现细节，因为项目文件才是最终事实来源。

五、旧对话太长时，生成阶段快照

可以直接在当前长对话中发送下面这段：

请把当前对话压缩成一份可用于新对话继续开发的项目快照。

要求不要复述聊天过程，只保留当前仍然有效的信息。

请按照以下结构输出：

# 项目快照

## 1. 项目目标

## 2. 技术栈及准确版本

## 3. 当前目录结构

## 4. 数据库表及关键字段

## 5. 已完成的功能

## 6. 正在开发的功能

## 7. 已确定且不得随意改变的设计决策

## 8. 已废弃的方案
说明哪些方案已经被否定，避免新对话重新采用。

## 9. 当前存在的问题

## 10. 相关文件路径

## 11. 当前代码行为

## 12. 下一步任务

## 13. 下一步验收标准

## 14. 禁止修改范围

## 15. 新对话开始时需要优先阅读的内容

要求：

- 只记录最新有效状态。
- 删除重复信息。
- 旧方案与新方案冲突时，以最新确认的方案为准。
- 不要声称未经过验证的代码已经运行成功。
- 对尚未确认的信息标记为“待确认”。

生成后保存为：

docs/CURRENT_STATE.md

六、新对话只需要发送一个接力提示词

开启新对话时，不需要重新讲整个项目，可以这样写：

这是一个已经开发中的项目，不是从零开始。

请先阅读：

- AGENTS.md
- docs/PROJECT.md
- docs/CURRENT_STATE.md
- docs/DECISIONS.md
- docs/TASKS.md
- 与当前任务相关的代码

当前任务：

实现订单创建功能。

验收标准：

1. 门票库存不足时不得创建订单。
2. 价格必须由后端查询。
3. 创建订单与扣减库存处于同一事务。
4. 相同 requestId 不得生成重复订单。
5. 自动测试必须通过。

允许修改：

- backend/src/main/java/.../order/
- backend/src/test/java/.../order/

禁止修改：

- 登录认证模块
- 公共返回类
- 已有数据库迁移文件
- 前端代码

请先分析现有实现和影响范围，再执行修改。
不要重新设计整个项目。

这比把旧对话全部复制过去更准确。

七、代码文件本身也应该成为上下文

对于 AI 编程，最可靠的上下文不是聊天总结，而是仓库里的实际代码。

例如处理订单功能时，只需要让 AI 读取：

OrderController.java
OrderService.java
OrderServiceImpl.java
OrderMapper.java
Order.java
OrderCreateDTO.java
Ticket.java
TicketMapper.java
相关 SQL
相关测试

不需要把景区公告、民宿、用户管理的全部代码都放进去。

原则是：

提供与当前任务有关的完整上下文，而不是提供整个项目的所有上下文。

八、每完成一个任务就建立一个检查点

推荐固定执行：

完成任务
  ↓
运行测试
  ↓
Git 提交
  ↓
更新 CURRENT_STATE.md
  ↓
更新 TASKS.md
  ↓
必要时更新 DECISIONS.md
  ↓
开始下一个任务

Git 提交示例：

git add .
git commit -m "feat(order): implement ticket order creation"

然后在 CURRENT_STATE.md 记录：

## 最近完成

提交：
feat(order): implement ticket order creation

实现：
- 后端计算订单金额
- 原子扣减门票库存
- requestId 重复提交防护
- 订单创建事务

验证：
- mvn test 通过
- 订单正常创建测试通过
- 库存不足测试通过
- 重复请求测试通过

这样即使换对话，也可以根据代码和 Git 状态继续工作。

九、不要频繁传递完整总结，要传递变化

新对话已经读取项目文件后，后续任务只说明变化即可：

上一任务已经完成订单创建。

本次只增加“取消待支付订单”功能。

新增规则：

1. 只有待支付订单可以取消。
2. 只能取消本人的订单。
3. 取消后恢复库存。
4. 订单取消和库存恢复必须在同一事务。
5. 已支付订单不能通过该接口取消。

这叫增量上下文，比每次重复整个项目更省。

十、推荐的实际使用方式

结合常见的 Java、Spring Boot、RuoYi、Vue 项目，可以采用：

一个项目文件夹
    +
一个总控对话
    +
每个模块一个执行对话
    +
每完成一个任务更新 CURRENT_STATE.md
    +
每完成一个功能进行 Git 提交

具体节奏：

1. 在总控对话中拆出一个小任务。
2. 创建一个新执行对话。
3. 执行对话读取项目上下文文件。
4. 完成代码和测试。
5. 更新项目状态文件。
6. 提交 Git。
7. 把完成结果告诉总控对话。
8. 总控对话安排下一个任务。

十一、关键结论

不要追求：

一个对话从项目开始一直聊到项目结束

应该追求：

任何一个新对话
都能在读取 5 个项目文件后
准确恢复当前项目状态

判断上下文管理是否合格，可以看这个标准：

即使旧聊天全部消失，只保留代码仓库、项目文档和 Git 历史，新的 AI 仍然能够继续开发。

这才是大型 AI 项目最稳定的上下文管理方式。