Codex 做资料调研：怎样把 X、GitHub 与官方文档整理成可引用的研究笔记

这是 Codex 系列的第 14 篇。

前一篇把 Plugin、MCP 与外部系统接了起来。工具能访问更多资料以后，新的问题很快就会出现：Codex 找到了十几个链接，是否就等于完成了调研？

通常不是。

我见过最常见的失败并不是“完全没有资料”，而是：

搜索摘要说了一句话，正文里却没有；
GitHub issue 报告了一个 bug，文章把它写成所有用户都会遇到；
main 分支已经改了代码，本地安装的稳定版却还没有；
X 帖子把四种联网能力统称为“Codex 可以上网”；
文末放了二十条参考资料，正文的关键判断仍然不知道由哪一条支持。

所以，这一篇不教“让 AI 搜得更多”，而是完成一个更窄、也更实用的目标：

把 X、GitHub、官方文档和本地实验整理成一份按主张组织的 research note。读者不但能看到结论，还能知道每句话由什么证据支持、适用于哪个版本、哪里仍然不能确认。

贯穿全文的真实问题是：

Codex 到底能不能联网？

这个问题听起来简单，却至少会碰到 Web Search、Shell 网络、Browser、MCP 四个不同控制面。本文案例只验证前三项以及不同 provider 的外推边界；MCP 的网络、授权和服务端行为不在本次实验范围内，相关入口沿用第 13 篇的讨论。先把这条排除项写清，正是研究合同的一部分。

下载 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 原始 SVG放大查看。

图 1 最重要的变化，是在“找到来源”和“写出文章”之间增加了两层：Claim Register 和 Evidence Ledger。没有这两层，Codex 很容易按来源写摘要，却没有真正验证正文里的句子。

这篇只需要先记住四个状态：

第一次阅读可以先看哪里

• 想直接建立模板：读第 1、2、8 节。
• 经常从 X 和 GitHub 找资料：重点读第 4、5、9 节。
• 想复现本文案例：读第 3、6、7、13 节。
• 准备把 research note 写成文章：读第 10、11、14 节。

1. 调研不是先搜索，而是先写研究合同

“帮我调研 Codex”几乎必然得到一份宽泛摘要，因为任务没有定义完成条件。

一个够用的研究合同至少回答六个问题：

把它写成 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、本地实验与社区线索的来源分层

移动端可打开图 2 原始 SVG放大查看。

同一个网站也可能有不同证据等级。例如：

• github.com/openai/codex 中固定 commit 的测试，是实现证据；
• 同一仓库的开放 issue，只是报告和调查线索；
• README 是项目文档，但仍要检查它对应的是 main 还是已发布版本；
• 一个 maintainer 评论可能很有价值，但它的适用日期和上下文仍要保留。

所以不要给整个域名贴一个“可信 / 不可信”标签，而要问：

这个来源是否直接支持我正在写的这一个 Claim？

3. 先把“Codex 可以联网”拆成六个 Claim

原始问题不能直接验证，因为“联网”混合了不同能力。本文把它拆成：

拆完以后，答案不再是模糊的“能”或“不能”：

1. 官方文档将常规本地会话的 Web Search 默认模式写为 cached；使用 --yolo 或其他 full-access sandbox 配置时，默认值可能变为 live；
2. --search 将它切换到 live；
3. Web Search 不等于模型生成的 Shell 命令获得任意网络权限；
4. Browser 是另一项能力，当前官方文档明确说它不在 Codex CLI 和 IDE extension 中提供；
5. 至于所有 provider 和模型是否一致，现有证据不足，必须保留为 unverified。
6. 同一天的 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 链接，不要只摘一句正文。至少记录：

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 产品行为，本文采用的顺序是：

1. 先查当前 Codex 官方手册或明确的官方页面；
2. 需要页级引用时，打开具体页面正文；
3. 官方文档没有覆盖的实现细节，再查固定 commit；
4. 仍然缺失就保留 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 应这样记录：

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.

这次实验验证了两件事：

1. 当前环境在显式指定兼容模型后，--search 的确触发了 Web Search 工具；
2. 工具被调用不等于目标事实已经验证，直接来源打不开时仍应停在 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：每一条证据只承担它能承担的重量

一份够用的证据台账至少包含这些字段：

本文案例的核心台账是：

完整版本已经放进下载包的 example-codex-web-search.md，E08 的可复核事件摘录位于 runs/web-search-2026-07-22.sanitized.jsonl。

9. 证据冲突时，不要投票，先缩小作用域

图 3：证据冲突的缩小范围与状态更新流程

移动端可打开图 3 原始 SVG放大查看。

调研里最危险的一句话是：

大多数资料都这么说，所以应该是真的。

来源不是选票。官方文档、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 首页；
• PR / issue：保留编号、状态和核对日期；
• 日后复核：重新看链接状态，不假设它永远不变。

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，关键主张都应该：

1. 打开直接来源；
2. 记录提取问题；
3. 对否定性结论换一个更具体的提取角度；
4. 必要时读取原始 Markdown、源码或 API 响应；
5. 把工具限制写进 remaining gap。

可以借鉴的是证据方法，不要把 Claude Code 的工具名、权限规则或限制直接复制成 Codex 配置。

13. 45-60 分钟跟做练习

练习目标不是“搜到十个链接”，而是产出一份能通过模板校验、并由你人工审查过的 research note。

0-10 分钟：选一个容易说错的问题

例如：

• Codex 默认会不会实时搜索网页？
• 某个 Plugin 是否在 IDE extension 中可用？
• 一个新命令是否已经进入 stable？
• 某个 GitHub issue 是否已经修复？

写清读者、用途、日期、版本范围和明确排除项。

10-20 分钟：拆成 3-5 个 Claim

每个 Claim 只写一件事，并定义什么证据足以支持。若一个 Claim 同时出现“并且”“所有”“默认”“任何”，通常还可以继续拆。

20-35 分钟：收集三层证据

至少包含：

1. 一个官方产品页面；
2. 一个固定 commit、release 或本地版本输出；
3. 一个社区来源或 issue，作为线索或反例。

使用 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. 收藏清单

研究合同

• 问题、读者、用途和时间边界明确。
• 产品、版本、入口、平台和排除范围明确。
• 已先拆 Claim，再开始大量搜索。
• 每个 Claim 都有验收标准。

来源

• X 和社区教程主要用于发现关键词、案例和争议。
• 搜索摘要已经追到直接页面。
• 官方产品事实由当前官方文档支持。
• GitHub 源码固定到 commit，release 固定到版本。
• issue / PR 的状态、日期和维护者结论已经区分。
• 本地实验记录了 CLI、系统、配置和日期。

证据

• 每个关键结论都有 Claim ID 和 Evidence ID。
• supported、partially_supported、contradicted、unverified 使用一致。
• 没有用来源数量代替冲突分析。
• 已检查版本、入口、provider、账号和日期差异。
• 搜索成功、页面读取成功和事实验证成功分别记录。

发布

• 引用出现在它支持的主张附近。
• 时间敏感结论带核对日期。
• 本地观察没有扩大成普遍事实。
• unverified 没有被写成肯定句。
• 参考资料列表和 Evidence Ledger 可以互相追溯。
• 最终关键判断由人重新打开来源核对。

写在最后

Codex 做资料调研，真正节省时间的地方不是替你打开更多标签页，而是把混乱来源变成一条可复核的判断链：

问题边界 → Claim → 来源 → 证据 → 冲突 → 结论 → 引用

X 负责让你更早看见问题，GitHub 让你追到代码、变更和异常，官方文档给出公开产品边界，本地实验则回答“在我的环境里到底发生了什么”。它们不是互相替代，而是承担不同重量。

当一份 research note 能清楚写出“我知道什么、为什么知道、在哪个范围内成立、还有什么不知道”，它才真正适合进入文章、决策或团队文档。

下一篇进入第 15 篇：Codex 写作工作流：从 research note 到草稿、审稿、配图与发布。届时会直接复用本文的 Claim Register 和 Evidence Ledger，把证据链转成适合博客阅读的长文，同时保留人工审稿和发布边界。

参考资料

OpenAI 官方

• OpenAI：Prompting
• OpenAI：Config basics - Web search mode
• OpenAI：Agent approvals & security
• OpenAI：Sandbox
• OpenAI：Browser
• OpenAI：MCP
• OpenAI Codex repository
• Web Search tests at 678157a
• @openai/codex on npm

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
• CodexGuide
• openai/codex issue #33250

社区资料用于发现术语、案例和异常线索；本文中的 Codex 默认值、入口和权限结论均以 OpenAI 当前官方资料、本地 CLI 输出和固定 commit 为准。