最快修复： Project 撞到了你订阅档位的文件上限，所以上传按钮变灰，弹出 “this Project has reached the maximum number of files”。这是按订阅强制执行的上限，不是 bug——截至 2026 年 6 月，每个 Project 上限是 5 个（Free）、25 个（Plus / Education）、40 个（Pro / Team / Enterprise）。把按天存的日志文件合并成一份（Step 1）通常 60 秒就能腾出最多槽位，而且检索质量还会更好。升级是最后手段，不是第一选择。
OpenAI 在 2025 年 9 月 3 日上调了这些上限（Plus 原来是 20），所以还在说”20 个”的老攻略已经过时。如果你 Files 面板里显示的 cap 是别的数，以你自己错误弹窗里的数字为准——弹窗反映的是你账号的实时上限。
另一种症状：如果上传远没到上限就卡住或停住（比如 Project 才 8-10 个文件，新上传一直转圈、传不上去），那是另一个 UI 卡死 bug，不是文件数超限——删任何东西之前先跳到是上限，还是上传卡死 bug？。
常见原因
按命中率从高到低：
1. 每段对话 / 每天日志都单独存成一个文件
最常见。每次导出、每场会议笔记、每天的日志都单独存成 .txt 或 .md，几周下来文件数飞快冲过 20。
如何判断：Project → Files 里看到 15 个以上文件名都是 2026-05-01.md、2026-05-02.md 这种按天分文件。
2. 原始版和处理版都上传了
你传了 report.pdf 又传了 report-summary.md，过一阵又传 report-v2.pdf，本来一个文件能装下的事用了三个槽。
如何判断：好几个文件内容重叠，同一主题不同格式。
3. 静态参考文档应该放进 Custom GPT 而不是 Project
风格指南、品牌话术、术语表——这种几乎不变的内容应该塞进 Custom GPT 的 Knowledge，把 Project 槽位留给真正在改的活文件。
如何判断：文件 30 天没动过但还占着 Project 槽位。
4. Project 边界膨胀，三个目标共用一个 Project
最早设的”Q2 营销活动”，慢慢又塞进了客户调研笔记、竞品分析、品牌话术。每个主题都正常需要文件，于是撞墙。
如何判断：把文件名列一遍，能明显看出聚成 2-3 个不同主题。
5. 历史 chat 导出文件占着槽位
很多人把过去的 chat 文字稿当记忆备份传进 Project，数量涨得很快，但检索时几乎用不上。
如何判断：文件名形如 chat-export-*.txt 或 transcript-*.md。
6. 撞了单文件大小上限被迫手动切分
60 页 PDF 因为撞了单文件上限被拆成 4 个 chunk——本来一个文件的事，占了 4 个槽。
如何判断：文件名后缀带 -part1、-part2。
是上限，还是上传卡死 bug？
两种故障长得很像，动手删文件之前先分清楚。
| 信号 | 真·文件上限（本文） | 上传卡死 bug |
|---|---|---|
| 出故障时的文件数 | 正好到订阅上限（Plus 25、Pro 40） | 常常才 8-12 个，远没到上限 |
| 报错文字 | ”this Project has reached the maximum number of files” | 没报错，或者上传转圈一直转不完 |
| 上传按钮 | 变灰 / 不可点 | 能点，但文件就是传不上去 |
| 解法 | 清理文件（本文） | 刷新页面、一次只传一个、换浏览器/App |
如果你属于上传卡死那一列：硬刷新页面（或者彻底退出手机 App 再打开），然后一次只传一个文件，别一把拖一堆——一次拖 5 个以上最容易触发卡死（单批上限是 10 个文件）。如果单个文件还是卡，就把它的文字直接粘进 Project 里的 chat，粘贴文字不占文件槽位。该问题在 OpenAI 开发者论坛 截至 2026 年 6 月仍有反馈。
下面都默认你是真的撞到上限了。
动手前先确认
- 弄清你订阅类型实际的上限——Free 5 / Plus 25 / Pro / Team / Enterprise 40，错误弹窗里写着你账号的实时 cap。
- 标一下哪些文件最近 chat 里还在被引用，哪些已经几周没出现。
- 清理之前先用一句话把 Project 的真实定位写下来——“这个 Project 只处理 X”——后面取舍以这句话为准。
- 记住周边的几个限制，免得清理时撞上第二堵墙：单批最多传 10 个文件、单文件 512MB / 约 2M token，以及横跨 chat、Project、GPT Knowledge 共用的 每用户 25GB / 每组织 100GB 存储上限。
需要收集的信息
- 订阅类型 + 错误弹窗里写的具体上限（截至 2026 年 6 月：Free 5 / Plus 25 / Pro / Team / Enterprise 40）。
- 完整文件列表 + 最后修改时间（在 Files 面板按时间排）。
- 每个文件最近一次被检索到的大致时间（在 chat 历史里搜文件名）。
- 是否还有别的 Project 没撞 cap，可以分担溢出。
- 是否有 Custom GPT 权限（Plus 及以上）——有的话就是天然的归档区。
最短修复路径
按收益从高到低，前两步一般能腾出 5-10 个槽位而几乎不损失内容。
Step 1：把同主题的小文件合并成一份
10 份每日日志，在本地拼一下：
cat 2026-05-*.md > may-2026-log.md
# 或者带 section 标题：
for f in 2026-05-*.md; do
echo "## $f" >> may-2026-log.md
cat "$f" >> may-2026-log.md
echo -e "\n\n" >> may-2026-log.md
done传 may-2026-log.md，把那 10 份日记删掉。净省 9 个槽位，而且因为相关内容在同一份文档里，检索质量还提升了。
Step 2：把 30 天没被引用的文件归档
去最近 chat 里搜每个文件名。一个月没被模型引用过的文件多半是死重量。搬出去：
Project → Files → 悬停文件 → Download（存到本地 /archive/<project-name>/）
→ 从 Project 里 Delete每个 Project 都在本地留一个 archive 文件夹，需要时随时能再传回来。
Step 3：把静态参考迁去 Custom GPT
风格指南、术语表、品牌话术、schema 定义——一周以上不变的内容统统进 Custom GPT 的 Knowledge：
新建一个 Custom GPT，用参考域命名
（如 "Acme Style Guide GPT"）
→ 把所有静态参考文件传进去
→ 在 Project Instructions 里写：
"For style/brand questions, treat the Acme Style Guide GPT
as the source of truth; switch to it for those queries."Project Files 现在专门留给活的工作内容。
Step 4：按目标拆 Project
如果你的 Project 混了 3 个目标（比如 Q2 活动 + 客户调研 + 竞品分析），拆开：
Project A: Q2 活动（brief、初稿、排期）
Project B: 客户调研（访谈记录、问卷结果）
Project C: 竞品分析（拆解文档、截图）每个 Project 单独一份干净的 Instructions、独立的文件，跨主题串扰也少（参考 chatgpt-project-memory-leak）。
Step 5：因为大小限制被切的 PDF 换成结构化 Markdown
如果当时是因为单文件大小撞 cap 才切的，做 OCR + 转紧凑 Markdown：
# 把 PDF 转成干净的 Markdown（比源 PDF 小很多）
pip install marker-pdf
marker_single full-report.pdf ./out --max_pages 300一份 full-report.md 通常只有源 PDF 的 1/5 到 1/10，检索效果还更好。
Step 6：用一份 manifest 文件当 Project 索引
在 Project Files 里放一份 _manifest.md：
# Project Manifest
## Active files
- campaign-brief.md — 主 brief，2026-05-20 更新
- customer-personas.md — 三个画像，2026-05-15 更新
- assets-checklist.md — 持续维护的物料清单
## Archived elsewhere
- 2026 Q1 活动 → 归档在 /local/archive/q1/
- 旧竞品文档 → 迁到 Custom GPT "Competitor GPT"让你和模型都能一眼看出哪些在 Project 内、哪些已经搬出去。
Step 7：升级订阅放到清理之后再考虑
Pro / Team / Enterprise 会把上限从 Plus 的 25 拉到 40，但你带着 25 个死文件升级，一周内又会撞到 40。先清理，再决定。注意 Team 和 Enterprise 也只是把每个 Project的上限拉到和 Pro 一样的 40——并不是无限——所以升级买到的是多 15 个槽位，不是无穷。真正持久的收益是 Step 1-3 的合并整理，而不是那个更大的数字。
怎么确认已经修好
- Files 面板显示文件数远低于 cap，还能再传 5-10 个的余量。
- 开新 chat 问 “what files do you have access to in this Project?”，回答里的列表和你清理后的对得上。
- 跑一个有代表性的问题，确认检索仍能命中正确的（合并后）文件，没有回归。
常见坑
- 删之前没下载备份——从 Project 里删掉就真没了。
- 为了规避 cap 把不相关主题强行合成一个大文件——检索质量崩，因为 chunk 里混了多主题。
- “以防万一”把同一份文件改个名再传一次——一个文件吃 2-3 个槽位。
- 把 chat 导出文件当必备 Knowledge——其实 Project 里的 chat 本身就可以搜。
- 同一个目标拆到两个 Project 里只为绕 cap——丢了共享 Instructions，还重复制造串扰问题。
FAQ
Q：2026 年每个 Project 到底能放几个文件？ A：截至 2026 年 6 月：Free 5、Plus 和 Education 25、Pro / Team / Enterprise 40。OpenAI 在 2025 年 9 月 3 日上调过（Plus 原来是 20），所以老文章还写”20”。任何博客数字都不如你自己错误弹窗里的准。
Q：图片算文件数吗？ A：算。图片上传和 PDF 上传都占 Project 文件槽——不分类型，共用同一个池子。
Q：能不能不升级也提高上限？ A：不能，每个 Project 的上限本身按订阅强制执行，在你当前档位提不了。但你基本不需要：合并（Step 1）和归档（Step 2）腾出的槽位比升级还多，而把文字直接粘进 Project 的 chat 完全不占文件槽。Pro / Team / Enterprise 也只是把上限提到 40。
Q：我的 Project 才 10 个文件就传不上了，这是上限吗？ A：不是。如果你还没到订阅上限（Plus 25、Pro 40）却传不上去，那是上传卡死 bug，不是文件数限制。硬刷新、一次只传一个、别一批拖超过 10 个。见是上限，还是上传卡死 bug？。
Q：删文件后引用过它的旧 chat 会出问题吗？ A：旧 chat 的回复还能看。但那些 chat 里再问新问题就读不到这个文件的内容了，所以以后可能还要用的话，删前先下载一份本地备份。
Q：能看到每个文件的体积或 token 数吗？ A：在 Files 面板悬停文件能看到体积。token 数没直接显示，大致按每 1,000 token ≈ 750 单词估算。单文件上限是 512MB 或约 2M token 文字，谁先到算谁。
Q：一个 Custom GPT 能服务多个 Project 吗？ A：可以。建一个 Style Guide GPT，所有 Project 遇到风格问题都切过去问它——一个 GPT 的 Knowledge 在所有 chat 间共享。