这是 Codex 系列的第 14 篇。
前一篇把 Plugin、MCP 与外部系统接了起来。工具能访问更多资料以后，新的问题很快就会出现： Codex 找到了十几个链接，是否就等于完成了调研？
通常不是。
我见过最常见的失败并不是“完全没有资料”，而是：
提示词
搜索摘要说了一句话，正文里却没有； GitHub issue 报告了一个 bug，文章把它写成所有用户都会遇到； main 分支已经改了代码，本地安装的稳定版却还没有； X 帖子把四种联网能力统称为“Codex 可以上网”； 文末放了二十条参考资料，正文的关键判断仍然不知道由哪一条支持。
所以，这一篇不教“让 AI 搜得更多”，而是完成一个更窄、也更实用的目标：
把 X、GitHub、官方文档和本地实验整理成一份按主张组织的 research note。读者不但能看到结论，还能知道每句话由什么证据支持、适用于哪个版本、哪里仍然不能确认。
贯穿全文的真实问题是：
这个问题听起来简单，却至少会碰到 Web Search、Shell 网络、Browser、MCP 四个不同控制面。本文案例只验证前三项以及不同 provider 的外推边界；MCP 的网络、授权和服务端行为不在本次实验范围内，相关入口沿用第 13 篇的讨论。先把这条排除项写清，正是研究合同的一部分。
会使用 Codex，准备写技术文章、做工具选型或核对当前产品能力的人
Codex CLI（第 7 节实验）；只做资料整理可用 App；浏览器；Node.js 18+（结构校验）；GitHub CLI 可选
速读约 15 分钟，完整阅读约 20-25 分钟，跟做约 45-60 分钟
Research note 模板、Evidence Ledger、4 组 Prompt、示例笔记和校验脚本
Codex 本地 Web Search 默认怎样工作
Windows PowerShell， codex-cli 0.132.0
2026-07-20： openai/codex@678157a ；npm stable 0.144.6
2026-07-22： openai/codex@bdd3118 ；npm stable 0.145.0
官方文档、固定 commit 源码与测试、本地 CLI 参数、三次只读实验、脱敏 JSONL、模板校验脚本
没有验证所有模型、provider、账号、企业策略和入口；没有把 GitHub issue 当成已确认缺陷
下载 codex-research-note-kit 示例包
示例包包含一份空模板、一份填好的 Codex Web Search 研究笔记、CSV 证据台账、4 组 Prompt、一份真实运行后脱敏的 JSONL，以及一个只做结构检查的 Node.js 脚本。
版本说明
Codex、Claude Code、GitHub 和 X 的工具入口都会变化。本文最初核对于 2026-07-20，并在 2026-07-22 重新检查；涉及 Codex 当前行为时，以 OpenAI 官方文档为主，GitHub 固定 commit 用于解释实现，issue、X 和社区教程用于发现线索。发布或收藏后重新使用，都应更新核对日期。
2026-07-22 复核： npm stable 已从 0.144.6 前进到 0.145.0 ， openai/codex 的 main HEAD 也从 678157a 前进到 bdd3118 ，issue #33250 仍为 open。7 月 20 日的命令与输出继续作为历史实验保留，不用今天的结果覆盖当时真正发生的事。
一分钟概览 整套方法可以压缩成六步：
提示词
先写问题边界 ↓ 把问题拆成原子 Claim ↓ 用 X / 社区资料发现关键词和争议 ↓ 用官方文档、固定 commit、release 和本地实验取证 ↓ 把证据写进 Evidence Ledger，处理冲突和 unverified ↓ 只把通过验收的 Claim 改写成正文，并把引用放在主张旁边
图 1：Codex 资料调研证据流水线 图 1 最重要的变化，是在“找到来源”和“写出文章”之间增加了两层： Claim Register 和 Evidence Ledger 。没有这两层，Codex 很容易按来源写摘要，却没有真正验证正文里的句子。
这篇只需要先记住四个状态：
supported
含义： 来源直接支持当前范围内的表述
正文应该怎样写： 可以写成结论，同时保留日期和范围
partially_supported
含义： 只支持一部分
正文应该怎样写： 收窄到证据实际覆盖的版本、入口或条件
contradicted
含义： 更强证据与当前表述直接冲突
正文应该怎样写： 不发布原句，解释冲突或重新调查
unverified
含义： 没有足够证据
正文应该怎样写： 明确写“尚未确认”，不要补全一个听起来合理的答案
第一次阅读可以先看哪里
经常从 X 和 GitHub 找资料：重点读第 4、5、9 节。
准备把 research note 写成文章：读第 10、11、14 节。
1. 调研不是先搜索，而是先写研究合同 “帮我调研 Codex”几乎必然得到一份宽泛摘要，因为任务没有定义完成条件。
一个够用的研究合同至少回答六个问题：
Codex 本地会话的 Web Search 默认怎样工作？
使用 Codex CLI 或 App 做当前资料调研的人
首次核对 2026-07-20；补充复核 2026-07-22
官方 Codex；必要时说明 CLI 版本、入口和 provider
不推断所有自定义 provider、模型和企业策略都表现一致
把它写成 Prompt：
提示词
围绕“Codex 本地会话的 Web Search 默认怎样工作”制作 research note， 先不要写文章。 用途：为技术教程提供可引用事实。 读者：使用 Codex CLI 或 App 做当前资料调研的人。 核对日期：2026-07-22；保留 2026-07-20 的历史实验记录。 范围：官方 Codex；结论必须标明入口、版本或配置条件。 排除：不推断所有自定义 provider、模型和企业策略都表现一致。 先把问题拆成原子 Claim。每个 Claim 写清： 1. 为什么重要； 2. 什么证据足以支持； 3. 什么情况下必须标记 unverified。 先输出研究计划和 Claim Register，不要直接给最终答案。
这里的关键不是 Prompt 写得长，而是 把不能外推的范围提前写出来 。否则 Codex 即使引用了真实资料，也可能把一个局部观察扩大成全局结论。
2. 来源不是按网站排名，而是按主张匹配 “官方来源优先”是对的，但还不够。不同来源回答的问题并不相同。
图 2：官方文档、固定 commit、本地实验与社区线索的来源分层
官方产品文档
最适合证明： 当前公开功能、配置字段、入口和安全边界
不能单独证明： 每个环境都没有 bug
官方仓库固定 commit
最适合证明： 某个 revision 的源码、测试和实现意图
不能单独证明： 这段代码已经发布给所有用户
Release / changelog
最适合证明： 某项变更进入了哪个发布版本
不能单独证明： 用户环境已经升级且配置相同
Merged PR
最适合证明： 代码已经合入某个分支
不能单独证明： 已进入稳定版，或线上一定启用
GitHub issue
最适合证明： 某人报告了什么、怎样复现、维护者如何回应
不能单独证明： 报告一定正确，或所有用户都会遇到
X 帖子 / 社区教程 / 视频
最适合证明： 关键词、案例、争议、经验和继续追踪的链接
不能单独证明： 当前官方产品行为
本地可重复实验
最适合证明： 当前版本、系统和配置下实际发生了什么
不能单独证明： 其他平台、版本、账号都相同
同一个网站也可能有不同证据等级。例如：
github.com/openai/codex
README 是项目文档，但仍要检查它对应的是 main 还是已发布版本；
一个 maintainer 评论可能很有价值，但它的适用日期和上下文仍要保留。
所以不要给整个域名贴一个“可信 / 不可信”标签，而要问：
提示词
这个来源是否直接支持我正在写的这一个 Claim？
3. 先把“Codex 可以联网”拆成六个 Claim 原始问题不能直接验证，因为“联网”混合了不同能力。本文把它拆成：
C01
待验证主张： 常规本地会话的 Web Search 默认使用缓存索引；full-access 配置可能默认使用 live
合格证据： 当前官方配置与安全文档
C02
待验证主张： --search 会切换到 live Web Search
合格证据： 官方 CLI / 配置文档 + 本地 --help
C03
待验证主张： Web Search 与 Shell 网络访问是不同控制面
合格证据： 官方安全与 sandbox 文档
C04
待验证主张： Browser 与 Web Search 不是同一入口
合格证据： 官方 Browser 入口说明
C05
待验证主张： 所有 provider 和模型下 --search 都表现一致
合格证据： 跨 provider 的官方承诺或足够测试
C06
待验证主张： 2026-07-22 本文环境中，Web Search 候选版本与直接 npm 查询不一致
合格证据： 当日脱敏 JSONL + npm view 输出
拆完以后，答案不再是模糊的“能”或“不能”：
官方文档将常规本地会话的 Web Search 默认模式写为 cached ；使用 --yolo 或其他 full-access sandbox 配置时，默认值可能变为 live ；
--search
Web Search 不等于模型生成的 Shell 命令获得任意网络权限；
Browser 是另一项能力，当前官方文档明确说它不在 Codex CLI 和 IDE extension 中提供；
至于所有 provider 和模型是否一致，现有证据不足，必须保留为 unverified 。
同一天的 Web Search 候选结果和直接 registry 查询也可能不一致，工具显示为 live 不等于目标事实已经新鲜、完整地验证。
前三项可由官方文档直接支持。OpenAI：Config basics – Web search mode、OpenAI：Agent approvals & security 第四项来自 OpenAI：Browser。这里的“默认”必须带上权限范围，不能脱离 sandbox 配置单独引用。C06 只是固定到日期、版本和本机环境的实验观察，不是 OpenAI 对所有搜索结果的产品承诺。
这就是 Claim 拆分的价值： 不是让答案更复杂，而是让每个结论终于有合适的证据。
4. X：用来发现问题，不要急着完成问题 X 的优势是快。新功能截图、失败案例、隐藏入口、命令片段和使用体验，通常比长文更早出现。它的弱点也来自同一件事：帖子短、上下文不完整、旧帖仍会被搜索出来，转帖和引用帖还可能改变原作者的意思。
4.1 使用高级搜索缩小范围 X 官方高级搜索支持按精确短语、账号、语言和日期范围组合筛选，但需要登录 X.com。X Help：How to use advanced search
研究 Codex Web Search 时，可以在高级搜索界面填写：
提示词
精确短语："Codex" "web search" 来自账号：openai、OpenAIDevs，或你正在核对的作者 日期范围：最近 30 天 语言：中文或英文
如果用户直接给你一条 X 链接，不要只摘一句正文。至少记录：
以后才能回到 Evidence Ledger 核对
4.2 给 X 来源一个明确状态 如果帖子说“Codex 现在默认可以实时搜索网页”，先把它记录成：
提示词
Claim：本地 Codex 默认使用实时 Web Search。 来源类型：community-post。 状态：unverified。 下一步：核对当前 Config docs、CLI help 和对应版本源码。
不要在这一步争论作者对不对。先把它变成可以继续调查的主张。
像 CodexGuide、codex-orange-book 或一条经验帖，都很适合帮助读者找到术语和实践路径；当文章要写当前命令、默认值和权限边界时，仍应回到当前官方资料。
5. GitHub：先分清代码、PR、release 和 issue GitHub 是调研 Codex 的重要来源，因为 CLI 本身开源。但“我在 GitHub 找到了”仍然不是结论。
5.1 先搜索代码，再固定 commit GitHub Code Search 支持 repo: 、 path: 、 language: 和布尔组合。GitHub：Understanding GitHub Code Search syntax
在网页中可以搜索：
提示词
repo:openai/codex web_search path:codex-rs repo:openai/codex "WebSearchMode::Cached" repo:openai/codex "--search" path:codex-rs/cli
安装了 GitHub CLI 时，也可以输出结构化结果：
代码
gh search code web_search ` --repo openai/codex ` --json path,url,sha ` --limit 20
命令
gh search code web_search \ --repo openai/codex \ --json path,url,sha \ --limit 20
GitHub CLI 官方文档提醒， gh search code 当前使用的仍是 legacy code search engine，结果可能与 GitHub 网页的新搜索不同。因此，无结果只代表这次查询没找到，不能直接证明代码不存在。GitHub CLI： gh search code
找到文件后，不要只链接 main ：
提示词
不稳定： https://github.com/openai/codex/blob/main/codex-rs/core/tests/suite/web_search.rs 可复核： https://github.com/openai/codex/blob/678157acaa819d5510adfe359abb5d0392cfe461/ codex-rs/core/tests/suite/web_search.rs
本文核对时， openai/codex 的 main HEAD 是 678157a ，提交时间为 2026-07-19。该 revision 的测试覆盖：
cached 模式设置 external_web_access=false ；
未显式设置且不处于 full-access profile 时按 cached 处理；
permission profile 变化时，默认模式可以随环境变化；
config.toml 可以明确写 web_search = "live" 或 "indexed" 。
对应证据固定在 Web Search tests at 678157a 。这能解释该 revision 的实现，但不能证明本地 0.132.0 已包含完全相同的代码。
5.2 issue 是报告，不是判决 搜索近期 issue：
代码
gh issue list ` --repo openai/codex ` --state all ` --search '"--search" created:>=2026-07-01' ` --limit 30
GitHub 官方说明 gh issue list --search 可以使用 issue / PR 搜索限定词。GitHub：Filtering and searching issues and pull requests
本文找到一个 2026-07-15 创建的开放 issue：报告者称在一个 Responses-compatible custom provider 下，不同模型的 --search 工具注入表现不一致，并提供了请求体对比。openai/codex#33250
这条 issue 能证明的是：
提示词
有人在明确环境中报告了一个可调查的差异，并提供了复现材料。
它不能直接证明：
提示词
所有 Codex 用户都会遇到； 问题已被维护者确认； 官方支持这些帖子中的模型或 provider 组合； 问题已经修复或一定属于 Codex。
因此 Evidence Ledger 里应写 github-issue / unverified ，而不是把标题复制进正文当事实。
6. 官方文档：拿到页面正文，不要停在搜索摘要 对于 Codex 产品行为，本文采用的顺序是：
官方文档没有覆盖的实现细节，再查固定 commit；
仍然缺失就保留 unverified ，不继续用更多弱来源“投票”。
让 Codex 调研时，可以直接限定来源：
提示词
核对以下 Claim，只使用 OpenAI 当前官方资料： C01：常规本地会话的 Codex Web Search 默认使用缓存索引；full-access 配置可能默认使用 live。 C02：--search 会切换到 live Web Search。 C03：Web Search 与 Shell 网络访问是不同控制面。 C04：Browser 是否在 Codex CLI 和 IDE extension 中可用。 对每个 Claim 输出： - supported / partially_supported / contradicted / unverified； - 直接页面 URL； - 页面实际支持的最窄结论； - 核对日期； - 仍未覆盖的范围。 不要只引用搜索结果页，不要使用社区文章证明 OpenAI 产品行为。
OpenAI 当前 Prompting 文档本身也建议：当答案依赖当前信息时使用 Web Search，需要检查结果时要求来源；当信息缺失时，标记缺口而不是猜测。OpenAI：Prompting
6.1 搜索、读取和引用是三步
提示词
Search：发现候选页面。 Fetch / Open：确认页面正文是否真的包含证据。 Citation：把直接页面放到它支持的主张旁边。
搜索摘要可能截断上下文，也可能来自旧缓存。即使摘要完全正确，它仍然只是发现入口，不是文章的最终引用对象。
7. 本地实验：记录失败层，而不是只记成功或失败 本文先核对本地版本和参数：
代码
codex --version codex --help | Select-String -Pattern '--search|web search' -Context 1,2
实际环境返回：
提示词
codex-cli 0.132.0 --search Enable live web search. When enabled, the native Responses web_search tool is available to the model.
截至 2026-07-20，npm 的 stable tag 是 0.144.6 。我在写作环境中通过下面的直接 registry 查询独立核对；这一步不是由下方 Codex 会话执行的：
代码
npm view @openai/codex version dist-tags --json
这说明本地 CLI 已经落后于 stable，但“版本旧”仍然不能直接推出某个功能一定不可用。还要实际运行。
7.1 第一次运行：任务在搜索前失败 我先用默认模型执行只读、无持久会话的搜索。下面命令使用 PowerShell 续行符；在 macOS / Linux 的 Bash 中可改成反斜杠 \ ，或写成一行：
代码
$prompt = @' Use only the native web search tool. Do not use shell, browser, MCP, or local commands. Find the latest stable version of the npm package @openai/codex as of 2026-07-20. Return the exact version, direct source URL, and verification date. If the direct source cannot be checked, say unverified. '@ codex --search ` --sandbox read-only ` --ask-for-approval never ` exec --skip-git-repo-check --ephemeral --json ` $prompt
结果并不是“Web Search 不能用”，而是默认模型要求更新版本的 Codex。也就是说，失败发生在运行时兼容层，搜索工具还没有完成一次有效调用。
Evidence Ledger 应这样记录：
runtime / model compatibility
指定本地 CLI 明确支持的模型重试，或先升级后复测
7.2 第二次运行：工具执行了，结论仍然 unverified 指定兼容模型后复用上一段 $prompt 再次运行：
代码
codex --search ` --model gpt-5.4 ` --sandbox read-only ` --ask-for-approval never ` exec --skip-git-repo-check --ephemeral --json ` $prompt
这里的 gpt-5.4 只记录本文环境当时可用的兼容模型，不是跨账号、套餐和版本的固定推荐。若你的环境不提供它，应使用当前账号与 CLI 明确支持的模型，或先升级 CLI；不要为了复现实验照抄一个不可用的模型名。
JSONL 中出现了多次 web_search 事件。搜索结果指向 0.144.6 ，但工具直接打开 npm 页面时得到 403 。最终回答没有把搜索摘要当成已核对页面，而是输出：
提示词
Exact version: 0.144.6 Status: unverified Reason: search snippets surfaced the version, but the direct source page could not be opened.
这次实验验证了两件事：
当前环境在显式指定兼容模型后， --search 的确触发了 Web Search 工具；
工具被调用不等于目标事实已经验证，直接来源打不开时仍应停在 unverified 。
这恰好是整篇文章最想保留的判断： 工具成功和证据成功不是同一件事。
7.3 两天后复核：live 搜索也可能落后于直接来源 2026-07-22，我用相同的 codex-cli 0.132.0 、兼容模型和只读参数复跑，只把 Prompt 中的核对日期改为 2026-07-22。native Web Search 再次被调用，最终仍返回：
提示词
Exact version: 0.144.6 (unverified) Reason: the npm versions page could not be fetched directly, and the accessible registry result contained inconsistent older metadata.
但同一写作环境直接查询 npm registry：
代码
npm view @openai/codex version dist-tags --json
返回的 stable / latest 已是 0.145.0 。这不是要证明 Web Search “不可靠”，而是记录一个范围很窄、却足够反驳过度外推的事实：
提示词
在 2026-07-22 的本文环境中，live Web Search 给出的候选版本 与同日直接 npm registry 查询不一致。
下载包中的 runs/web-search-2026-07-22.sanitized.jsonl 来自这次真实运行。文件保留搜索动作、直接页面尝试和最终回答，删除了线程 ID、工具调用 ID、token 用量，以及与研究问题无关的本机 Plugin / MCP 启动警告。它能让读者复核“工具做了什么”，但仍不能替代直接 npm 查询对版本事实的确认。
8. Evidence Ledger：每一条证据只承担它能承担的重量 一份够用的证据台账至少包含这些字段：
official-doc、official-source、release、issue、X、local-test
supported / partially_supported / contradicted / unverified
本文案例的核心台账是：
E01
Claim ID： C01 / C02
来源： OpenAI Config docs
证据摘要： 常规本地会话默认 cached；full access 可默认 live； --search 等价于 live
状态： supported
E02
Claim ID： C03
来源： OpenAI security docs
证据摘要： Web Search 与命令网络权限可分开控制
状态： supported
E03
Claim ID： C04
来源： OpenAI Browser docs
证据摘要： Browser 不在 Codex CLI / IDE extension 中提供
状态： supported
E04
Claim ID： C01 / C02
来源： openai/codex@678157a tests
证据摘要： 该 revision 测试 cached、live、indexed 和 profile 变化
状态： supported
E05
Claim ID： C05
来源： GitHub issue #33250
证据摘要： 报告者提供 custom provider 异常线索
状态： unverified
E06
Claim ID： C02
来源： 本地 CLI help
证据摘要： 0.132.0 暴露 --search 并描述 live search
状态： supported
E07
Claim ID： C02
来源： 2026-07-20 作者观察（原始 JSONL 未留存）
证据摘要： 搜索工具执行，但 npm 直接页 403
状态： partially_supported
E08
Claim ID： C06
来源： 2026-07-22 脱敏 JSONL
证据摘要： live Web Search 返回候选 0.144.6 ，并主动保留为 unverified
状态： supported
E09
Claim ID： C06
来源： 2026-07-22 npm view
证据摘要： 同日直接 registry 查询返回 stable 0.145.0
状态： supported
完整版本已经放进下载包的 example-codex-web-search.md ，E08 的可复核事件摘录位于 runs/web-search-2026-07-22.sanitized.jsonl 。
9. 证据冲突时，不要投票，先缩小作用域
图 3：证据冲突的缩小范围与状态更新流程 调研里最危险的一句话是：
来源不是选票。官方文档、 main 源码、本地稳定版和开放 issue，可能都在各自范围内正确。
9.1 文档与 issue 冲突 官方文档描述标准行为，issue 报告某个 custom provider 下的异常。处理方式不是选一个，而是拆成：
提示词
官方支持的默认行为：supported。 特定 provider 是否存在异常：unverified / reported by user。
9.2 main 与本地版本冲突 main 代表当前开发分支，本地 codex-cli 0.132.0 代表已安装版本。正确写法是：
提示词
在 commit 678157a 中，测试覆盖了…… 在本地 0.132.0 中，--help 显示……
不要写成“Codex 源码已经证明我的版本一定这样工作”。
9.3 搜索摘要与直接页面冲突 在 7 月 20 日的实验中，搜索摘要显示版本号，直接 npm 页面返回 403 。若没有第二条直接渠道，状态应保持 unverified ；当日另外用 npm view 直连 registry 得到 0.144.6 ，才形成独立的本地观察。
7 月 22 日的复核更进一步：Web Search 仍给出候选 0.144.6 (unverified) ，直接 npm view 已返回 0.145.0 。因此冲突处理不能停在“页面打不开”，还要记录同日直接来源与搜索候选是否一致。
9.4 X 新帖与旧官方文档冲突 先检查 X 帖子是否链接到 release、文档或 PR，再检查官方文档更新时间。若没有一手来源，不要因为帖子更新就自动覆盖文档；把它登记为“可能发生变化，需要重新核对”的线索。
10. 从 research note 到文章引用 好的引用不是“参考资料很多”，而是读者能在关键句旁边完成验证。
10.1 一个主张对应直接来源 不够好的写法：
提示词
Codex 默认能联网，而且支持浏览器和实时搜索。[参考资料合集]
更准确的写法：
提示词
截至 2026-07-20，Codex 官方文档将常规本地会话的 Web Search 默认模式 写为 cached；full-access 配置可能默认使用 live，使用 --search 也会切换 到 live。[Config basics] Browser 是另一项能力，当前不在 Codex CLI 和 IDE extension 中提供。 [Browser docs]
10.2 引用要保留范围词 这些词不是拖沓，而是证据边界：
提示词
截至 2026-07-20 在 Codex CLI 0.132.0 中 在 openai/codex commit 678157a 中 根据一个仍开放的 issue 报告 在本文 Windows PowerShell 环境中
10.3 GitHub 链接尽量可复现
源码和测试：固定 commit，并尽量链接到具体行；
release：链接具体 tag / release，不只链接 Releases 首页；
10.4 不要让引用列表代替证据台账 文末参考资料用于集中导航，Evidence Ledger 用于作者审查，两者职责不同。读者看到的是简洁引用，作者背后应该能追溯 Claim、证据、日期和剩余缺口。
11. 四组可以直接复用的 Codex Prompt 11.1 建立 Claim Register
提示词
围绕“[研究问题]”制作 research note，先不要写文章。 用途：[文章 / 决策 / 教程] 读者：[读者] 核对日期：[YYYY-MM-DD] 范围：[产品、版本、入口、平台] 排除：[不研究什么] 先拆成原子 Claim。每个 Claim 写明重要性、验收标准，以及什么情况 必须标记 unverified。不要在这一轮给最终答案。
11.2 提取单一来源
提示词
阅读这个来源：[URL] 只输出： 1. 标题、作者 / 组织、发布日期或 commit； 2. 它直接支持哪些 Claim； 3. 不扩写的证据摘要； 4. 它不能证明什么； 5. 需要继续追踪的原始链接； 6. 建议状态。 不要根据搜索摘要判断，不要把 issue 报告写成官方结论。
11.3 审查冲突
提示词
审查 research note 中所有 partially_supported、contradicted 和 unverified 项。 检查冲突是否来自不同版本、入口、平台、账号、provider、日期， 或者 main 分支与稳定版的差异。不要投票。给出证据允许的最小 可发布表述，以及仍需补充的证据。
11.4 做引用审计
提示词
对照 research note 审查文章草稿。 输出：正文主张、Claim ID、当前引用、是否直接支持、时间范围、 建议修改。 重点找： - 引用只出现在文末； - 一个链接承担多个不相干主张； - 用 X、issue 或搜索结果证明官方行为； - main 分支没有固定 commit； - unverified 被写成肯定句； - 本地实验被扩大成所有环境都成立。
下载包的 prompts.md 已经收录完整版本。
12. Claude Code 给这套流程的一个重要提醒 Claude Code 的官方 Tools reference 把 WebSearch 和 WebFetch 分开：WebSearch 返回结果标题和 URL，不读取结果页面；找到页面后还要用 WebFetch。更值得注意的是，官方文档明确说明 WebFetch 会把页面转换为 Markdown，再用一个较小模型按提取 Prompt 处理，多数情况下 Claude 看到的是提取结果而不是原始页面，因此它“按设计就是有损的”。Claude Code：Tools reference
这不是 Codex 命令的证据，但它提供了一个跨工具都成立的研究原则：
提示词
搜索结果不是页面； 提取结果也不一定等于完整页面； “页面没提到”有时只是提取 Prompt 没有问到。
因此，无论使用 Codex 还是 Claude Code，关键主张都应该：
必要时读取原始 Markdown、源码或 API 响应；
可以借鉴的是证据方法，不要把 Claude Code 的工具名、权限规则或限制直接复制成 Codex 配置。
13. 45-60 分钟跟做练习 练习目标不是“搜到十个链接”，而是产出一份能通过模板校验、并由你人工审查过的 research note。
0-10 分钟：选一个容易说错的问题 例如：
某个 Plugin 是否在 IDE extension 中可用？
写清读者、用途、日期、版本范围和明确排除项。
10-20 分钟：拆成 3-5 个 Claim 每个 Claim 只写一件事，并定义什么证据足以支持。若一个 Claim 同时出现“并且”“所有”“默认”“任何”，通常还可以继续拆。
20-35 分钟：收集三层证据 至少包含：
一个固定 commit、release 或本地版本输出；
使用 X 时记录原帖和时间；使用 GitHub 源码时固定 commit；使用 issue 时记录 open / closed、maintainer 回应和核对日期。
35-45 分钟：做一次本地实验 记录：
提示词
环境 起始状态 命令 / Prompt 预期结果 实际结果 失败层 这次实验不能证明什么
失败也可以成为证据，只要你没有把“运行时没启动”误写成“功能不存在”。
45-55 分钟：处理冲突并写 citation-ready statements 把冲突按版本、入口、provider、日期和发布状态拆开。只把 supported 或已经收窄范围的 partially_supported 改写成正文句子。
55-60 分钟：运行结构检查 解压示例包后：
代码
node scripts/check-research-note.mjs example-codex-web-search.md
预期结果的关键字段：
代码
{ "ok": true, "errors": [], "warnings": [] }
脚本只检查章节、日期、状态词、URL、Claim ID、Evidence ID 和未清理占位符。它不能判断一个来源是否真的支持主张；这一步仍然要由人完成。
14. 收藏清单 研究合同 来源
[ ] X 和社区教程主要用于发现关键词、案例和争议。
[ ] GitHub 源码固定到 commit，release 固定到版本。
[ ] issue / PR 的状态、日期和维护者结论已经区分。
[ ] 本地实验记录了 CLI、系统、配置和日期。
证据
[ ] 每个关键结论都有 Claim ID 和 Evidence ID。
[ ] supported 、 partially_supported 、 contradicted 、 unverified 使用一致。
[ ] 已检查版本、入口、provider、账号和日期差异。
[ ] 搜索成功、页面读取成功和事实验证成功分别记录。
发布
[ ] 参考资料列表和 Evidence Ledger 可以互相追溯。
写在最后 Codex 做资料调研，真正节省时间的地方不是替你打开更多标签页，而是把混乱来源变成一条可复核的判断链：
提示词
问题边界 → Claim → 来源 → 证据 → 冲突 → 结论 → 引用
X 负责让你更早看见问题，GitHub 让你追到代码、变更和异常，官方文档给出公开产品边界，本地实验则回答“在我的环境里到底发生了什么”。它们不是互相替代，而是承担不同重量。
当一份 research note 能清楚写出“我知道什么、为什么知道、在哪个范围内成立、还有什么不知道”，它才真正适合进入文章、决策或团队文档。
下一篇进入第 15 篇： Codex 写作工作流：从 research note 到草稿、审稿、配图与发布 。届时会直接复用本文的 Claim Register 和 Evidence Ledger，把证据链转成适合博客阅读的长文，同时保留人工审稿和发布边界。
参考资料 OpenAI 官方
OpenAI：Config basics – Web search mode
OpenAI：Agent approvals & security
Web Search tests at 678157a
@openai/codex
GitHub 与 X 官方
GitHub：Understanding GitHub Code Search syntax
GitHub：Filtering and searching issues and pull requests
GitHub：REST API endpoints for repository contents
GitHub CLI： gh search code
X Help：How to use advanced search
Claude 官方对照
Claude Code：Tools reference
Claude Code：Extend Claude Code
社区资料与案例线索
bozhouDev/codex-orange-book
openai/codex issue #33250
社区资料用于发现术语、案例和异常线索；本文中的 Codex 默认值、入口和权限结论均以 OpenAI 当前官方资料、本地 CLI 输出和固定 commit 为准。
