让ChatGPT Web强制读取文件全文的提示词技巧
速览
用户发现ChatGPT Web默认只读取文件前8000字符或通过RAG查询片段,为此编写了一套提示词,要求模型通过模拟终端操作(如使用fitz提取全文、切分19k字符块、打印到终端等)强制阅读所有上传文件全文。讨论了上下文长度、截断机制及验证方法,并请求社区优化建议。该技巧属于Agent Skill范畴,对利用大模型处理长文档具有参考意义。
AI 深度解读
背景
用户在 LINUX DO 论坛分享了一个关于 ChatGPT Web 处理上传文件的技巧。他指出:当你上传多个 PDF、TXT 等文件时,ChatGPT Web(包括 Plus 和 Pro 版本)默认只会读取每个文件的前约 8000 字符(用户之前的测试结果)。系统通过 msearch 和 mclick 工具,基于 RAG(检索增强生成)的方式,仅查询并阅读文件中的相关片段(可以指定本次对话中的文件或历史文件)。当 Web 端思考链显示“正在阅读文件”时,实际上是在调用这些工具,多个片段加起来勉强可覆盖全文。但如果你只是简单说“读所有文件全文”,模型基本不会真正读完整个文件,长文件尤其如此。
Plus 会员上下文窗口为 20 万 token,Pro 为 40 万 token。用户作为不熟悉计算机的文科生,编写了一套提示词流程,旨在强制 ChatGPT Web 每次实际完整读取所有上传文件的全文。他还提到从未在 Web 端或思考链中看到“正在压缩上下文”的提示,怀疑是因为从未用满 20 万 token 导致的。
核心内容
用户设计的提示词结构分为两个部分:一是用户上传文件后的默认机制说明,二是要求模型遵循的严格流程。
用户编写的完整提示词
用户上传单或多个文件时,后台只自动解析并提供给你用户上传的某一文件的前面少部分(并显示由于过长而截断),漏掉很多信息,所以你必须遵循以下 0.-3. 的流程:
- 确认各文件内容字符数(PDF 用 fitz 确认并处理),同时一次性将所有文件的全文文字提取到一个 full.txt 中(不同文件内容之间请加入分隔并注明各自的来源),并同时将 full.txt 切分并保存为多个 19,000 字符的 chunk_xx.txt 分片在硬盘上。
- 再依次将每个 chunk_xx.txt 分片打印在终端进行阅读(单次调用终端只能打印一个,因为一次打印多个会截断),禁止跳过任何 chunk_xx.txt 分片,同时使用 tee 将每次的输出添加并保存到 read_log.txt 里。
- 全部 chunk_xx.txt 分片打印读完后,用代码自动校验 read_log.txt 和 full.txt 是否一致,但全程禁止阅读 read_log.txt、full.txt。
- 最终回答时在开头简洁声明:
- a. 是否打印阅读完所有用户上传文件的全文文字?
- b. 终端有没有发生过截断?
- c. 你创建了几个 chunk_xx.txt?
- d. 校验 read_log.txt 是否出错?
附带的注意点
- a. 在本平台上,只有通过写入标准输出(终端打印),模型才能实际阅读到文件内容。
- b. 即使文件再长、分块再多(可能切分成几十个 txt),都必须在终端打印阅读所有全文,禁止只读部分。
- c. 绝对禁止使用以下操作:OCR、截图、msearch、mclick、
re、grep等正则或关键词匹配。同时禁止阅读并遵循该 PDF SKILL(skills/pdfs/SKILL.md),因为这些与本次任务无关。 - d. 已安装好
fitz,禁止确认。 - e. 单次终端输出的截断机制:
- 按 Unicode 字符数截断(非字节/行数/PDF页数)。
- 超过 20,000 个 Unicode 字符则截断;汉字、字母、标点均算一个字符。
- 截断方式不是砍掉末尾,而是保留开头和结尾各 10,000 字符,中间用
[... ELLIPSIZATION ...]省略。 - stdout 和 stderr 合并计算。
用户的实际效果
用户提供了两张截图(无提示词 vs 有提示词)。使用该提示词后,模型不再调用 msearch,思考和链中少显示了一次“正在读取文档”,且现在思维链中许多步骤不再显示(推测是模型主动省略了部分思考链)。
用户最后发帖前让 sol 测试了一下,发现自己说错了一点(关于 ChatGPT Web 的 tool 细节),但整体方法似乎有效。
关键要点
- 问题根源:ChatGPT Web 默认使用 RAG(msearch/mclick)读取文件片段,而非完整读取。模型很难通过简单指令强制完整阅读。
- 解决方案:利用模型执行代码的能力(终端打印)来“迫使”模型实际读取每个字符。通过将完整文本切分为 19,000 字符的小块并依次打印,绕过了上下文窗口和 RAG 限制。
- 关键限制:单次终端输出最多 20,000 字符,且采用“首尾保留、中间省略”的截断方式,因此分片不能超过 20,000 字符(用户使用 19,000 作为安全值)。
- 禁止的操作:禁用 msearch、mclick、关键字匹配等默认工具,禁用以 PDF SKILL 为代表的预定义技能,强制模型只依靠纯文本的终端输出。
- 校验机制:要求模型创建 read_log.txt 并与 full.txt 校验,确保没有遗漏或截断导致数据丢失。
- 用户身份:自称“文科仔”,不懂计算机,但通过试错和社区交流(sol 测试)完善了提示词。
- 未解现象:用户从未看到“正在压缩上下文”提示,推测是因为上下文未接近 20 万 token 上限。
意义与影响
- 对大语言模型应用实践的启示:用户展示了一种“逆向工程”思维——利用模型自身的代码执行能力来强制完成模型设计上原本不支持的行为(完整读取超长文档)。这提示开发者,对于某些任务,prompt 工程可以绕过模型的安全或效率限制,但也可能触发更严苛的后续控制。
- 对文件处理工作流的优化:该方法适用于需要精确理解全文而非片段检索的场景,如法律合同审阅、学术论文分析、大型代码库审查等。但注意,分块处理会消耗大量 Token(每个 chunk 打印一次,20 万 token 上下文可能很快耗尽)。
- 潜在风险:要求模型“禁止阅读 SKILL.md”等操作,可能违反模型基础的安全策略。模型若严格遵循可能导致输出被拒绝或行为异常。此外,强制模型执行 shell 级操作(tee、校验)可能带来安全风险,尤其在多用户共享环境中。
- 社区价值:该帖子在 LINUX DO 论坛引起讨论,反映了 AI 用户对模型内部机制的探索热情。用户虽自称不懂计算机,但其发现的方法对于高级用户也有参考价值。后续可能推动 OpenAI 调整文件读取策略或增加“完全读取”的显式接口。
- 局限性:该方法对 ChatGPT Plus / Pro 有效,但免费版上下文更小,切分更频繁。且依赖模型能成功调用代码执行环境(Code Interpreter 或浏览器内终端)。此外,如果文件包含图片、表格、公式等非纯文本元素,该方法无法处理(用户已说明“不用读内部图片”)。
