《Codex 使用手册》· 第 2 章（中）｜材料、工具与证据

CHAPTER 02 · 2.5–2.9

教材版本：v1.0 · 官方资料核验：2026-08-13 · 当前界面与账号可用性以读者实际状态为准。

2.5 Codex 怎样读取材料

官方来源： Projects in ChatGPT；Projects and chats；ChatGPT desktop app

本节要回答

一段粘贴文字、一个附件、ChatGPT 项目 中的文件来源、一个本地 project 文件夹，为什么不能混着说成“给了 Codex 资料”？怎样让它说明本次实际使用了什么？

先用白话解释

粘贴是你把一段文字直接放进对话；附件是你主动提供的文件；ChatGPT 项目 是一个产品面中的聊天、文件、指令或连接来源集合；本地 project/Codex 本地项目目录 是你选择的本机文件夹。它们可能在界面上相邻，却不是同一个材料来源，也不自动互通。

官方当前说明特别重要的一点是：ChatGPT 项目 不等于本机任意文件夹。即使某个桌面入口允许连接本地文件夹，也必须由人选择并确认范围，不能从“项目”两个字推断 Codex已经读过 Downloads、桌面或其他目录。本书的资料整理学习项目是教学结构，不是 OpenAI 官方 Project 的必备文件树。

图 2-3 · DIA-02-05。教学图，说明三种材料来源应分别确认范围；非产品界面。

你会看到/跟做

本章先采用最小方案：把通知与要求.md、零散记录.md明确列为白名单。要求 Codex在开头先说“本次允许使用两份文件”，在结尾再说“本次实际使用文件仍是这两份”。如果它写“我读取了项目资料”，你要追问具体名称；如果它说“我可以扫描目录”，要立即拒绝扩展。

做一个来源对照：

• 粘贴文字：检查复制是否完整，来源锚点由人保留。
• 附件：检查文件名和版本，不默认同名文件相同。
• ChatGPT 项目：检查项目中实际选定的来源，不等于本机目录。
• 本地 project：检查人选择的文件夹和 本地项目目录 范围，不等于整台电脑。

本轮不读取补充问题.md。它即使和两份材料放在同一个练习包里，也不属于本次白名单。

读取材料还要保留“来源锚点”。文件名只是第一层线索，最好再记下标题、小节名或条目开头。例如“通知与要求.md／活动目的”比“通知文件”更容易复查；“零散记录.md／猜测”比“记录里提到”更能提醒你这不是已确认事实。若同名文件存在多个版本，先暂停，记录版本或日期，让人决定哪一份属于本次范围。不要为了看起来完整而把“可能是最新的”当成事实。

在对话中要求 Codex 先列“本次实际使用文件”，还有一个作用：把没有被读取的材料变成可见的排除项。对于本案例，正确输出不仅要写两份文件，还要明确补充问题.md 未打开、未读取、未使用。这样，当后续章节真的允许加入第三份材料时，读者能看出范围发生了什么变化，而不是误以为 Codex 一开始就读过整包材料。

预期结果

你能用“来源类型+具体名称”描述材料，而不是说“我把项目给它了”。Codex的输出会列出实际使用文件；任何无法列出的“好像读过”都不当作证据。

最小练习与验收

在对话中要求 Codex 先复述材料范围，再给出一个不读取文件的计划。验收三点：复述只有两份；明确未读补充问题.md；计划不提出扫描目录、上传全部资料或联网补充。实际是否出现这些动作由人核对可见输入、工具活动和真实系统提示，缺少证据标待确认。

常见误区（预警 / 补救 / 证据）

• 常见坑：把同目录当成已读。预警：输出引用了补充问题.md里的专属问题，或无法列出使用文件。最小补救/停止点：停止任务，回到两份白名单并要求逐条来源。复查证据：第三份文件未被引用。
• 常见坑：把 ChatGPT 项目 当本地文件夹。预警：要求它“自动找到电脑上的所有相关资料”。最小补救/停止点：重新选择具体输入并写入任务卡。复查证据：材料来源和本地路径边界分开。

下一节

材料来源明确后，还要区分“读文件”和“做动作”。下一节把读取、创建、浏览器、插件、Computer Use 和命令拆开。

2.6 Codex 怎样使用工具

官方来源： Using the built-in browser in the ChatGPT desktop app；Plugins in ChatGPT and Codex；Using Codex with your ChatGPT plan

本节要回答

读取文件、创建文件、修改文件、浏览器访问、插件连接、Computer Use 和运行命令，为什么不是“工具开了就都能做”？普通读者怎样判断动作的风险？

先用白话解释

把工具想成不同的门：

• 读取：把指定材料拿来理解，通常是输入动作。
• 创建：产生一个新文件，已经改变本地状态。
• 修改：改变已有文件，风险比读取高。
• Browser：访问网页，可能涉及网络、host（网站的地址归属）许可和不可信内容。
• Plugins：从可见目录到安装、连接、调用是不同状态，可能涉及 OAuth 或外部数据。OAuth 可以先理解成“把一个外部服务的登录或授权交给连接流程处理”，不等于你已经允许它读取或发送所有数据。
• Computer Use：操作屏幕和应用，需要 macOS 系统权限、应用许可和另外的文件/命令边界。
• 命令：运行本地指令，可能读取、写入、删除或触发其他程序，不能只看命令名字。

图 2-4 · CUR-02-06A。当前官方公开页面素材，用于区分插件可见、可安装、已连接和可调用；不表示读者账号已获得任一状态。

图 2-5 · CUR-02-06B。当前官方公开页面素材，用于认识内置浏览器、网站访问和审阅边界；不表示读者已有登录状态或访问许可。

内置 Browser 使用独立于 Chrome 的浏览器状态。按 2026-08-13 的官方说明，它支持登录、自动填充、密码管理、扩展、下载和多标签导航；如果任务需要既有 Chrome profile、登录会话、已打开标签或 Chrome 扩展，应使用 Codex Chrome 扩展并先核对当前账号。host 可以先理解成“网站的地址归属”；首次使用新网站通常会要求审阅，除非该 host 已被允许或采用了更宽松的权限设置。任何凭证都只在浏览器页面中输入，不要发进聊天。

你会看到/跟做

把本案例的动作表写成“本次允许/本次禁止”：

• 允许：读取两份虚构材料，在对话中分类和引用。
• 禁止：创建或修改任何文件，访问补充问题.md，联网，打开真实站点，连接插件，运行未知命令。
• 暂缓：如果 Codex提出浏览器、插件或 Computer Use，先停下来询问是否改变任务。

不要把“我有一个浏览器”当成“我已经允许它上网”；不要把“插件可见”当成“插件能访问数据”；不要把“Computer Use可用”当成“已经获 macOS 控制权”。

可以用风险由低到高的顺序训练判断：先读一段已给出的文字，再读指定本地文件，然后才是创建本地草稿；访问网页、连接外部服务、操作屏幕和运行可能改变状态的命令，都应单独确认。风险不是由工具名称决定的，同一个命令如果只输出目录信息，和如果会删除文件，后果完全不同。因此每次看到动作提议，都追问三个问题：输入在哪里，状态会不会改变，结果会不会离开当前范围。

如果 Codex 把多个动作包装成一句“我先整理，顺便查资料并生成文件”，不要只回答“可以”或“不可以”。把它拆回动作清单，逐项标注允许、禁止或待确认；只要其中一项越过本章边界，就先暂停整组动作。这样做不是故意拖慢，而是避免一个看似便利的组合动作把联网、写入和外发一起带进来。

预期结果

你能在动作发生前说出它属于读取、写入、网络、外部连接或屏幕控制中的哪一类，并能指出停止点。即使 Codex说“这只是顺手查一下”，你也会把它看成范围变化，而不是默认同意。

最小练习与验收

给下面六个动作贴标签：读通知与要求.md；新建摘要.md；修改零散记录.md；打开未允许host；安装插件；运行删除文件的命令。验收是：只有第一个属于本章允许动作，其余都要暂缓或拒绝，并写出原因。

常见误区（预警 / 补救 / 证据）

• 常见坑：把不同工具当一个“自动化能力”。预警：一句“用工具完成”没有动作类型。最小补救/停止点：要求逐项列出动作和目标。复查证据：每个动作都有范围、权限和结果。
• 常见坑：把网页或插件的可见内容当可信材料。预警：没有来源、host或授权记录。最小补救/停止点：停止网络/连接动作，回到本地白名单。复查证据：人核对本次可见输入、工具活动和真实系统提示；未见时如实记录，缺少可观察证据标待确认。

下一节

工具动作有了分类，还要知道谁能决定它们。下一节讲权限的三层边界，以及本书教材方法 M 和系统提示的区别。

2.7 权限为什么是工作闭环的一部分

官方来源： Permissions；Computer Use

本节要回答

为什么读取、创建、修改、联网和外部动作不能用一个“允许”概括？系统权限提示出现时人要看什么？为什么一次允许不等于永久授权？

先用白话解释

本书把权限分成三层：

1. macOS 系统权限，例如屏幕录制（Screen Recording，允许应用读取屏幕画面）和辅助功能（Accessibility，允许应用在系统许可范围内与界面交互）。这两项是系统给应用的许可，不等于全盘读写。
2. Computer Use 的应用许可，例如允许它操作哪个应用。
3. 文件/命令沙箱与审批。沙箱可以先理解为“把文件和命令限制在某个范围内的围栏”，例如当前本地项目目录 能读写什么，联网或越界时是否需要审阅。Ask for approval 可以先理解为“在真实触发条件下，请人审阅即将发生的动作范围”，不是本书任务卡，也不保证每个文件都会弹窗。

三层互相独立。给了屏幕录制，不代表可以读写全盘；允许某个应用，不代表允许发送外部信息；Ask for approval 下本地项目目录内例行读写也不承诺逐文件系统弹窗。只有真实出现联网、越出 本地项目目录、未知命令或其他系统提示时，才按实际提示审阅。

图 2-6 · DIA-02-07A。教学图，区分任务级人工范围确认与系统权限提示；非产品界面。

图 2-7 · DIA-02-06。教学图，区分系统权限、应用许可与文件/命令沙箱；非产品界面。

你会看到/跟做

给本次练习写一条人工范围确认：

“我确认本次只读通知与要求.md和零散记录.md，只在对话中输出盘点；不得读取其他文件、联网、创建或修改文件；如出现系统权限提示或请求外部动作，立即停下让我审阅。”

这句话是教材方法 M，不是等待产品弹窗。若系统真的弹出提示，记录提示内容、触发动作和人作出的决定；若当前工作面未提供提示，写“在本次可见输入、工具活动和真实系统提示中未见；缺证据标待确认”，不要模拟一个。

预期结果

你能区分“我事先规定的任务范围”和“产品运行时实际出现的系统提示”。你不会因为没有弹窗就认为没有边界，也不会因为有弹窗就认为所有动作都已批准。

最小练习与验收

把三种请求分类：读两份文件；访问未允许host；删除原始文件。验收：第一项可在本次范围内执行；第二项必须停下审阅；第三项在本章明确拒绝。每项都写出人要检查的证据。

常见误区（预警 / 补救 / 证据）

• 常见坑：把任务确认说成系统批准。预警：正文出现“产品会逐文件询问”。最小补救/停止点：改写为“任务级人工范围确认”，只记录真实提示。复查证据：没有假弹窗，任务记录中有输入和停止点。
• 常见坑：一次批准被理解为永久授权。预警：后续任务自动扩大到网络、外部应用或全盘。最小补救/停止点：每次变化重新确认范围。复查证据：批准/提示对应具体动作和日期。

下一节

权限只说明动作能否发生，不能说明任务是否完成。下一节学习怎样看计划、工具活动、结果和人工验收四层过程信息。

2.8 怎样看过程信息

官方来源： Permissions

本节要回答

计划、工具活动、运行状态、等待提示、文件变化和最终总结分别说明什么？为什么过程看起来很完整，结果仍可能不正确？

先用白话解释

把过程信息分成四层：

1. 计划：Codex打算怎样做，是路线图。
2. 工具活动：它实际调用了什么，是过程线索。
3. 结果：它交回了什么文字或文件，是输出证据。
4. 人工验收：人是否打开、对照、检查并作出通过/退回/待确认，是可用性判断。

四层互不替代。计划不是完成；工具活动不是正确；文件存在不是验收；模型说“完成了”不是人的结论。

图 2-8 · DIA-02-08。教学图，说明计划、工具活动、结果与人工验收是不同证据；非产品界面。

你会看到/跟做

当 Codex开始工作时，按顺序记四行观察；只有工作面实际提供了计划或工具活动时才记录这些内容。如果当前工作面没有显示计划、工具活动或系统提示，就原样写“当前工作面未提供这类可观察证据”，不要用猜测补齐：

• 计划：它说要读哪两份，是否写明不做文件动作。
• 工具活动：若工作面提供了这类记录，检查是否真的只读了两份，是否出现联网或其他动作；若没有提供，就写未提供可观察证据。
• 结果：输出是否有来源、缺失、待确认和实际使用文件。
• 验收：你打开原文，是否逐项对照并写下结论。

如果某层没有证据，不要用上一层代替。例如“它列出了漂亮的计划”不能代替“它实际读了正确文件”；“它创建了一个文件”不能代替“内容正确且人已经打开核对”。对没有发生文件、网络、外发或真实应用动作的结论，使用更严谨的表述：“在本次可见输入、工具活动、真实系统提示中未见；缺证据标待确认。”

遇到过程信息不完整时，可以用一句固定追问把它拉回证据：“请分别列出你计划做的事、已经实际做的事、交回的结果，以及仍需要我验收的地方；不要用‘已完成’概括。”这句话的价值在于把状态词改成可检查的名词。若它无法列出实际使用文件，说明读取证据不足；若它列出文件却没有结果，说明执行链未闭合；若结果存在却没有人工核对，说明仍停在交付线索，不应进入下一步。实际使用文件清单只是人工复核线索，不是模型自证“确实读过”的证明，仍要由人回到原文和工作面检查。

在自己的学习记录里，尽量使用“观察到”“原文写明”“我决定”三种句式。比如“观察到对话只列两份文件”“原文写明时间尚未确认”“我决定不让任务进入联网”。这三种句式能把产品行为、材料事实和人的决定分开，日后迁移到另一台设备或另一个账号时，不会把一次偶然表现误写成通用规律。

预期结果

你能指出一句状态话术属于哪一层，也能指出它不能证明什么。看到“已完成”时，你会追问结果在哪里、材料依据在哪里、人工验收是否完成。

最小练习与验收

拿一段模拟过程消息，分别标上计划、工具活动、结果或验收。验收要求：至少有一句属于“不能证明正确”，并能说出下一步人工动作；不把计划或工具日志直接写成结论。

常见误区（预警 / 补救 / 证据）

• 常见坑：过程线索太多，反而没有验收。预警：记录全是“读取中、处理中、完成”，没有原文核对。最小补救/停止点：暂停扩展，先拿结果回原文检查。复查证据：验收记录指出材料和核对点。
• 常见坑：把菜单可见当成实际运行。预警：只截图模型或工具选项，没有任务结果。最小补救/停止点：把菜单标为“可见选择”，等待实际任务证据。复查证据：运行条件、输出和人工结论分开。

下一节

过程四层之后，我们要进一步区分 Codex可能交回的不同结果，以及每种结果应该怎样验收。

2.9 Codex 可能产生哪几类结果

官方来源： Work with files；Permissions

本节要回答

一段对话文字、一个结构化清单、一个文件、一个修改建议、一个待确认问题和一条风险提示，验收方法为什么不同？

先用白话解释

结果不是只有“成功/失败”两种。常见结果至少有六类：

1. 对话文字：适合直接阅读，但要回原文逐句核对。
2. 结构化清单：适合检查覆盖和缺口，但要检查每项是否有来源。
3. 文件：要真正打开，检查路径、命名、内容和版本。
4. 修改建议：先看差异，决定是否接受，不能只看总结。
5. 待确认问题：要看是否从材料缺口推导，而不是模型自己发明。
6. 风险提示：要看是否具体到预警、停止点和补救，而不是一句“可能有风险”。

本章最终的只读盘点属于第一类和第二类：结果只在对话里出现，不能冒充已建立的资料盘点文件。

你会看到/跟做

把同一个“资料里没有时间和场地”分别写成三种结果：一句对话说明、待确认问题清单中的一条、风险提示中的一条。然后分别验收：

• 对话说明：能不能回到两份材料的“尚未确认”。
• 问题清单：是不是具体、可回答，而不是“请补充信息”。
• 风险提示：是否写明如果有人准备发布，就必须停下。

如果 Codex额外给出一页摘要、待办文件或联网建议，在本章都视为超出输出范围，要求它停止，不因为内容看起来有用就默认接受。

验收时还要检查“结果有没有偷偷改变问题”。原问题是盘点资料，结果却替你确定了活动时间；原问题是列待确认项，结果却替某个角色承诺准备物资；原问题只允许对话输出，结果却出现“已保存到某路径”。这些内容即使写得流畅，也不能算本次可接受结果。先标为越界，再回到任务的目标、材料和禁止项，要求它只保留有来源的部分。

一个实用的结果标签是“可直接使用”“需人工补证”“退回重做”。“可直接使用”只表示已经通过本次人工验收，不表示产品永远正确；“需人工补证”表示内容可能有用，但还缺来源或核对动作；“退回重做”表示范围、材料或输出形式已经偏离。把这三个标签写在人的验收记录里，比让模型自己选择“成功”更可靠。

预期结果

你知道“结果类型”决定“验收动作”：文字回原文，清单看覆盖，文件打开看内容，修改看差异，风险看停止条件。你不会用“读起来不错”替代适合该结果类型的检查。

最小练习与验收

为六类结果各写一个验收动词：回原文、逐项比对、打开、看差异、追来源、找停止点。验收标准是每个动词都能对应一个具体动作，不出现“相信模型”“看起来完整”。

常见误区（预警 / 补救 / 证据）

• 常见坑：把不同结果混成一个“报告”。预警：对话、文件和建议没有分别标注。最小补救/停止点：重新列出结果类型和对应验法。复查证据：输出标题能说明结果性质，人工结论不越权。
• 常见坑：把待确认问题当成缺陷。预警：材料没有答案却被要求模型直接决定。最小补救/停止点：保留待确认标签，交给有权限的人。复查证据：每个问题有材料缺口来源。

下一节

下一节先拆解 Codex 出错的六种常见原因，再决定应该修任务、补证据，还是停下。