一句话总结
Claude Projects 给你一个持久的工作区：共享文件（Project Knowledge）、自定义 Instructions、以及统一归档的对话历史。坑在于把它当成”文件夹”，什么都往里塞。截至 2026 年 6 月，在 Claude.ai 上用 Opus 4.7 或 Sonnet 4.6 对话，付费计划给你 500K token 的上下文窗口，Projects 再叠一层检索（RAG）把容量撑得更大——但文件越多，检索就越容易抓错。真正有效的做法和”全部上传”正好相反：3 到 7 个精选文件、精炼的 Instructions，再加一个每次出结论就回写、重传的 decisions.md。
这篇解决什么问题
大多数团队会把每一版草稿都塞进 Project，指望检索自己理清，结果就是答案模糊、口吻漂移、对话信誓旦旦地引用你三周前删掉的旧稿。这篇把”文件夹”模型换成”精心维护的工作区”模式，能撑过几个月的使用和模型升级。
这篇适合谁看
跑多周工作的 Claude Pro（$20/月）、Max（$100 或 $200/月）、Team、Enterprise 用户：研究、长写作、代码库分析、长期客户交付、重复产品评审。如果你一周开一次新对话、每次都要把同样五条事实重讲一遍，这篇就是给你写的。免费账户最多只能建 5 个 Project，所以本文默认你用的是 Project 不限量的付费计划。
Project 里到底有什么（2026 年 6 月）
一个 Project 把三样东西打包，并在里面每个对话间持续生效：
| 组成部分 | 作用 | 实际限制 |
|---|---|---|
| Project Knowledge | 任何对话都能引用的共享文件 | 单文件 30 MB；文件数不限，但每次查询只装载相关片段 |
| 自定义 Instructions | 对 Project 内每个对话都生效的系统提示 | 只受上下文窗口限制，没有固定字数上限 |
| 对话历史 | 归在同一 Project 下的所有对话 | 在 Project 内共享，但不会自动作为上下文注入 |
有两条事实决定了整套工作流。第一，在 Claude.ai 上用 Opus 4.7 和 Sonnet 4.6 对话，付费计划的上下文窗口是 500K token（Enterprise 还能更高；Claude Code 开启用量额度后可达 1M）。第二，当 Project Knowledge 大到装不下时，Claude 会切到检索增强生成（RAG），Anthropic 的说法是容量可扩展至多 10 倍——但 RAG 只抓它判断相关的片段，所以可能漏掉内容，也从不保证单次回复能完整召回整份文档。
第二点正是”文件越多越糟”的原因。文件超过大约十个，检索抓错片段的概率就明显上升，会把噪声当成信号。
什么时候该用 Project，什么时候别用
| 该用 Project | 该用普通对话 |
|---|---|
| 任务需要跨多次对话的持续上下文 | 一次性问题 |
| 你能说出 3 个”每次对话都该装载”的文件 | 你还不知道产出该是什么形状 |
| 你需要跨数周稳定的角色和口吻 | 配置时间会超过省下的时间 |
| 多人协作同一交付物（Team/Enterprise 共享） | 只是在随便探索 |
最清晰的信号：你能说出三个”每次关于这个话题的对话都该装载”的文件名。
具体步骤
- Project 名用”产出”，不用”主题”。“Q3 产品上线计划”，而不是”营销”。产出命名逼你定义”完成”。
- **Instructions 控制在 1000 字以内。**写清角色、受众、口吻、忽略什么、2 到 3 条成功标准。回读一遍，把”请提供帮助”这类空话砍掉。Instructions 对 Project 内每个对话都生效，所以要严但别太绝对（一条死板的”只用正式英文回复”在你随口问件小事时也会发作）。
- **只上传 3 到 7 个每次对话都会用到的文件。**过期稿、跑题资料不要进。文件名要显式——
spec.md、voice.md、decisions.md——这样 Claude 会按名引用，而不是说”你上传的那个文档”。Project Knowledge 支持 PDF、DOCX、CSV、TXT、XLSX、HTML 和图片，单文件最大 30 MB。 - 每个新对话先报子目标。“今天：用
voice.md重写上线邮件。输出一个 180 字版本 + 3 个标题变体。” - **把结论回写到
decisions.md并重传。**这是收益最高的单一习惯。Project 文件是快照——本地改了不重传就会默默不同步，直到你替换上传的那份。 - **每两周清理一次。**换掉旧文件、删掉没结果的对话、根据真正有效的做法反过来精修 Instructions。
用第一次跑动来校准搭法
- 选一个低风险交付物——一封邮件、一节章节、一个 bug ticket。
- Project 完整跑一遍，中途别改 prompt、文件或模型。别忍不住”调”到一半。
- 每段产出标”能直接用 / 需要改 / 完全错”，记下哪些 Instructions 对应了”错”。
- 第二次只改一个变量，通常是 Instructions。同 Knowledge 换 Instructions，能告诉你瓶颈在系统提示还是素材本身。
交付前的质量检查
- 用 Instructions 里的成功标准去核对产出，而不是”看起来漂不漂亮”。
- 事实、页码、文件路径、命令都独立核验。Claude 会自信地转述你的文件，哪怕精度已经滑了，而且 RAG 可能抓错了片段。
- 标出 RAG 抓不到的人工判断风险：客户机密、上传材料的版权、走错方向的代价、代码改动的上线影响。
让这套流程可复用
- 把 Instructions 存成片段，新客户或新书 60 秒就能克隆出结构。
- 给每类 Project 备一套”起手文件集”：写作类必备
voice.md和outline.md；咨询类必备brand.md和prior-deliverables.md。 - 每个 Project 留一个
lessons.md——记录 Claude 每次读错文件、跑偏口吻、编造事实。3 到 4 条之后规律就显现，反过来回填到 Instructions。 - 每月跑一次冒烟测试。模型版本、文件处理、UI 都更新得很勤。
- 代码类 Project 加一个
conventions.md：命名、错误处理、“绝不这么写”清单。比把整个仓库传上去有用得多，也能让 RAG 更聚焦。
一个完整示例：客户交付 Project
Instructions 写清客户、受众、口吻。Knowledge 放品牌规范、两份过往交付、一个滚动的 decisions.md。每个对话只处理一节——绝不两节——结束时往 decisions.md 追加一段并重传。在 Team 计划上，你把 Project 以只读（“Can use”）共享给评审，把编辑权限（“Can edit”）给真正动笔的两个人，这样反馈集中在一处，而不是散落在各个对话里。
容易踩的坑
- **存储便宜就一口气塞 30 个文件。**过 10 个，RAG 抓错片段的概率明显升高，会把噪声当成信号。
- **忘了 Instructions 对每个对话都生效，**包括无关话题。
- **把 Project 文件当成活文档。**它是快照，除非你重传；本地改了不重传就默默不同步。
- **工作和个人实验混在一个 Project。**口吻漂移得快，你对产出的信任也跟着漂。
- **不养成
decisions.md习惯。**没有它，每个新对话都在重新讨论已经定过的问题。 - **永远不清理。**两个月的 Project 会积一堆死文件，拖垮检索质量。
FAQ
- Project 跨 session 记得聊天历史吗？: Projects 共享的是文件和 Instructions，不是聊天历史。每个对话的上下文都是从头开始。想要延续，就重传总结（也就是
decisions.md习惯）。 - Project 能多大？: 单文件最大 30 MB，文件数不限，但 Claude 只通过 RAG 装载相关片段。文件量超过大约 10 万 token 后，检索会变糊、响应变慢。保持精简。
- 在 Project 里对话时真实的上下文窗口是多少？: 截至 2026 年 6 月，在付费 Claude.ai 计划上用 Opus 4.7 或 Sonnet 4.6 是 500K token，Enterprise 可更高。超出窗口的 Project Knowledge 通过 RAG 提供，而不是整份装载。
- 能和团队共享 Project 吗？: 可以，在 Team 和 Enterprise 计划上，权限分”Can use”（查看并对话）和”Can edit”（修改 Knowledge 和 Instructions）。个人 Pro 和 Max 的 Project 仅对你账户私有。
- 大工作要拆成多个 Project 吗？: 交付物不同就拆。一个 Project 对应一个交付，比”一个 Project 对应一个客户”好剪枝，也能让检索更紧凑。
- Knowledge 文件多久刷新一次？: 最少两周一次，或任何会改变事实源的决定之后立刻刷。