本篇会完成一次带来源的网页搜索。最终产物是一份简短结论、至少三个可以打开的原始链接，以及每条关键判断对应的来源。你会亲自打开链接，确认标题、日期和正文确实支持结论。
前置条件
选一个会随时间变化的问题，例如某个工具的最新安装方法、版本要求或功能状态。先写下你要核对的时间范围。若问题涉及 Codex，优先要求搜索 OpenAI 官方文档，社区帖子可以帮助发现问题，不能替代当前产品说明。
网页内容可能包含错误或诱导指令。搜索结果应当当作待检查材料，不能因为页面排在前面就直接照做。涉及下载、登录、付款或执行命令时，停下来单独核对。
第一步把检索标准写进问题
提示里写清四件事。要回答什么，信息要新到什么时间，哪些来源优先，缺证据时怎样处理。可以这样发起。
搜索 Codex 当前的图片输入方式。优先使用 OpenAI 官方文档，核对到今天。给出桌面端和 CLI 的差异，每条操作都附原始链接。找不到官方说明的地方请标明未知，不要用搜索摘要补结论。
可见结果应包含检索过程或工具记录。桌面端会把搜索活动和其他工具调用一起留在聊天中。CLI 单次需要实时搜索时，可以用 codex --search 发起运行。
第二步检查来源有没有回答问题
先看来源身份。产品入口、命令和权限应优先由官方页面证明。再看日期和适用界面，同一个功能在桌面端、网页、CLI 与 IDE 中可能不同。最后把正文中的具体句子与文章结论对照。
搜索摘要只能帮你决定要打开哪一页。来源页打不开、正文没有相关信息，或只出现一段转述时，这条证据仍不够。让 Codex 替换来源或把结论降为待确认。
第三步处理来源冲突
两页说法不一致时，要求 Codex 列出各自发布日期、适用产品和原句含义。新版官方功能页通常比旧教程更适合说明当前入口，更新日志适合解释某项变化从何时出现。若官方页面也没有说清账户范围或推出进度，保留这个缺口。
让结论旁边紧跟链接。只在文末堆五个网址，读者仍然不知道哪一页支持哪句话。完成后随机抽两条关键结论，亲自点击并核对。
留下一份以后还能复查的记录
每个采用的来源至少记下页面标题、原始网址和访问日期。当前功能页用来说明今天怎样操作，更新日志用来说明入口何时变化。两者用途不同，记录时也应分开，免得以后把旧变化当成当前步骤。
例如核对图片输入时，把结论按使用界面拆开。桌面端和 IDE 的加入方式写在一项，CLI 的粘贴与启动参数写在另一项。每项后面紧跟支持它的官方页面。若来源只写了某一个界面，就不要把动作推广到全部界面。
最后再加一行复查提醒，写明哪类变化会触发重新核验。菜单位置、命令名称、权限范围和推出状态都容易变化。读者看到访问日期与触发条件，就知道这份记录还能直接采用，还是需要重新打开来源。
引用还要贴近它支持的句子。一个页面只证明桌面端入口时，就把链接放在桌面端说明后面。另一页若只解释 CLI 参数，单独引用。这样复查者打开一条链接就知道要找什么，也能及时发现某个结论其实还没有一手依据。
常见失败与恢复
没有出现搜索记录时，先明确要求使用网页搜索，并检查当前账户与工作区是否提供这项托管工具。Web Search 与本地命令的网络权限、代理和域名白名单分开，不能根据 permission profile 的联网状态推断搜索是否可用。结果仍停在旧版本时，把查询改成官方域名、功能名和当前日期。链接很多却没有直接证据时，要求删去聚合页，只保留实际打开的原页。
页面要求登录、触发验证码或拒绝自动访问时，不要绕过。记录访问限制，换用另一份公开一手来源，或把该项写成尚未确认。
完成检查
摘要应回答原问题并标出核验时间。至少三个来源可以正常打开，关键结论附近有对应链接。你能从来源正文找到支持内容，也能指出仍缺证据的地方。
