Projects 与 Chats：怎样组织长期上下文而不制造信息垃圾场

聊天没有丢，方向却越来越模糊

你在同一个 project 里改过课程提纲、查过资料、写过周报，还顺手问了两个无关问题。三周以后新开一条 chat，旧规则、旧文件和旧决定一起涌进来。

把内容全留着，心理上很安全。任务却开始为历史付利息。

上下文不是仓库容量问题，而是工作所有权问题。 这节课会跟着一套课程资料，把长期共享层、单次结果和实时工作区分开，让每条信息知道自己该活多久。

Project 是共享上下文容器，Chat 是一次工作线

官方 Projects 文档把 project 用于聚合相关 chats、文件、来源和指令。它适合会持续一段时间、需要多个交付结果的工作。Chat 则承载一条相对独立的工作线：同一个目标的检查、实施、纠偏和验收应尽量留在同一 chat，让决策和证据连续。

把所有工作塞进一个 chat 会出现两个问题：历史决策太多，新的目标与旧约束混淆；多个独立结果共享一个“完成”状态，无法判断哪一项真正结束。反过来，每次追问都新开 chat，又会丢失已经检查的文件、失败记录和审批边界。

三层上下文模型

Project 层：长期共享

适合放：

• 项目目标、稳定受众、产品术语；
• 多个任务都会用到的来源和样例；
• 主文件夹或仓库；
• 长期生效的 project instructions。

不适合放：

• 一次性的草稿和临时截图；
• 已经过期但没有标记版本的资料；
• 不同权限等级的真实敏感数据；
• 互相冲突的多套“最终规则”。

Chat 层：单一结果

一个 chat 最好对应一个可以独立验收的结果。例如“修复移动端结账”“审查本周改动”“把访谈整理为 PRD”分别建 chat，而不是以“今天的所有任务”建一个无限会话。

同一个 bug 的诊断、修复、验证和 follow-up 应保留在同一 chat，因为后续判断依赖前面的证据。若从修 bug 转到重做视觉系统，目标和风险已经改变，应拆出新 chat。

工作区层：真实状态

本地 project 的 primary folder 不只是附件目录，它还是 Git、AGENTS.md、Skill 和配置发现的起点。聊天里“记得”某个状态，不代表工作区仍是那个状态；切换分支、出现未提交改动或文件被外部编辑后，必须重新检查。

用五个判断决定是否新开 Chat

满足任一项，通常应拆分：

1. 最终交付可以单独批准或拒绝；
2. 需要不同文件写权限或外部授权；
3. 会与现有任务并行，可能修改重叠文件；
4. 完成标准与原任务无关；
5. 需要让另一位协作者独立接手。

仍应留在原 chat：

• 对当前结果的事实补充；
• 针对已观察失败的纠偏；
• 同一 Done when 下的测试与修复；
• 要求解释本次 diff 或未运行项。

示例：课程资料知识库

可以建立一个 project：

Project: 现代史课程知识库
共享文件:
- syllabus.md
- source-policy.md
- glossary.md
- handouts/

Chats:
1. 建立资料索引
2. 校对第三章时间线
3. 设计引用检查
4. 生成期末复习页

“校对第三章时间线”的来源核对与修正留在一个 chat；“生成期末复习页”是独立交付，拆开。Project instructions 可以声明“没有来源的事实标待核对”，但某一章的临时争议不要升级为全局规则。

版本与来源管理

共享资料最危险的不是少，而是无法知道哪个是当前版本。为每个关键文件记录：

• 文件名和用途；
• 来源或负责人；
• 生效日期；
• 是否允许修改；
• 被哪几个 chat 使用。

当两份资料冲突，让 Codex报告冲突和影响，不要静默选择“看起来更新”的一份。Project 帮助复用上下文，不替你建立权威性。

练习：画出你的上下文结构

选择一个持续超过两周的工作，输出：

Project 目标：
长期共享资料：
长期规则：
Chat A 的单一交付：
Chat B 的单一交付：
需要留在同一 Chat 的 follow-up：
必须重新检查的工作区状态：
过期资料处理方式：

让另一个人只看这张结构图，判断应该在哪里加入一项新任务。如果对方无法判断，说明层级仍以“话题”而不是“结果和权限”组织。

完整案例：把“产品上线”拆成可维护的上下文结构

假设一个项目持续六周，包含需求、设计、开发、发布和复盘。如果只建一个超长 Chat，后期每个问题都会带上大量过期决定；如果每次都新建独立 Project，稳定文件和规则又会反复上传。

推荐结构：

Project：会员中心上线
├── 共享文件：已批准 PRD、术语表、设计原则、发布边界
├── Chat 01：需求冲突与决策记录
├── Chat 02：移动端页面实现
├── Chat 03：支付回归与上线检查
└── Chat 04：发布后事故复盘

Project 保存跨任务仍有效的事实；Chat 保存完成一个结果所需的过程、证据和修正。

文件进入 Project 前的四个问题

1. 它是否会被两个以上任务反复使用？
2. 它是否仍是当前权威版本？
3. 它的作用能否用一句话说明？
4. 它是否包含不应被所有相关 Chat 共享的敏感信息？

一份临时日志通常留在诊断 Chat；已批准的 API schema 适合进入 Project；包含真实客户数据的导出文件不应为了方便被长期共享。

决定继续当前 Chat 还是新开

情况	选择	原因
修复刚完成，但浏览器验收失败	继续当前 Chat	同一结果的验证闭环
已交付修复，开始写无关的营销文案	新 Chat	目标、上下文和验收都变了
同一页面出现第二个相关回归	通常继续	需要原 diff 和验证证据
想比较两个互不依赖的架构方向	分开任务或分支	避免结论和文件状态互相污染

新开 Chat 不是清除不喜欢的结论。若之前发现了真实约束，应该把它写入权威文件或新任务 brief，而不是假装不存在。

上下文维护：添加、替换、归档

长期 Project 需要版本卫生：

• 添加：新材料有稳定价值，并写清角色；
• 替换：新版正式取代旧版，记录生效日期；
• 归档：旧版仍有历史价值，但不应指导当前实现；
• 删除：错误、重复或不应长期保存的材料。

提示词里写“使用最新文件”并不能解决两个文件都叫 final.pdf 的问题。版本、日期、权威状态必须在材料本身或索引中可见。

一份轻量 Project 索引

不需要引入复杂知识管理系统。一份 project-index.md 就可以记录文件角色、权威状态、校准日期和关联 Chat：

approved-prd.md | 当前权威 | 2026-07-30 | 所有实现任务
api-v1.md | 历史参考 | 已由 api-v2.md 取代 | 事故复盘
launch-risks.md | 当前维护 | 每周更新 | 发布检查
customer-export.csv | 临时敏感材料 | 不进入共享层 | 单次分析

索引让下一次任务先看到材料边界，而不是重新猜哪个 “final” 才是真的。

故障诊所

Project 越用越笨

现象通常不是“上下文窗口不够”，而是权威与临时材料混在一起。先做文件清单，标出当前、历史、草稿和敏感级别，再删除或归档噪声。

新 Chat 重复问已经决定的问题

决定只存在旧对话，没有进入共享决策记录。把稳定结论写入 Project 文件，并注明依据和日期。

一个 Chat 同时做五个结果

进度更新无法判断哪个结果完成。按独立交付物拆分，并给每个 Chat 单一 Done when。

知识检查

一份“支付事故原始日志”与“已批准的支付失败处理规则”谁更适合放在 Project 共享层？通常是后者。原始日志服务一次诊断，规则服务多个后续任务；前者还可能含敏感信息。

让每条上下文都有归宿

拿一个你已经使用很久的 project，给里面的内容贴三种标签：长期共享、单次任务、只代表当时现场。

该拆的新开 chat，该更新的回到源文件，该删除的不要因为「也许以后有用」继续留着。真正可维护的上下文，不是记得最多，而是发生冲突时知道该信谁。

完成检查

• Project 只承载长期共享上下文
• 每个 Chat 有独立完成标准
• 同一结果的纠偏与验证没有被拆散
• 本地工作区状态不会被聊天记忆替代
• 冲突和过期来源有显式处理规则