Codex CLI 怎么上传截图并联网搜索？--image、粘贴图片与 --search 实用指南

先说结论：图片解决“你看到什么”，搜索解决“现在是什么”

Codex CLI 可以把截图、架构图或设计参考作为视觉上下文，也可以在任务依赖当前版本、最新文档或外部行为时启用实时网页搜索。官方当前 CLI 页面列出 codex --image 用于在第一个提示中传入图片，也支持把图片粘贴到交互式编辑器；codex --search 则为一次运行开启实时搜索。

两者用途不同：图片提供本地证据，例如报错界面、布局问题和流程图；搜索提供会变化的外部信息，例如新版本文档和服务行为。高质量任务通常先给最小必要证据，再清楚说明目标、限制和验收标准，而不是一次塞入大量截图或让搜索漫无目的。

一、哪些问题适合上传截图

界面错位、浏览器错误弹窗、设计稿还原、终端图形输出和架构图都适合用图片补充。截图能保留空间关系和视觉层级，避免用文字描述“右边那个按钮偏了一点”造成歧义。对于多步骤错误，最好同时提供错误发生前后的关键画面。

不适合上传的内容包括密码、验证码、API Key、访问令牌、完整银行卡号、客户隐私和未经授权的内部数据。提交前先裁剪无关区域并打码敏感信息；如果文字错误可以复制，仍应把原始错误文本一并提供，便于搜索代码和日志。

二、怎样用 --image 提供首轮视觉上下文

启动 Codex CLI 时可使用 codex --image 把图片带入第一个提示，适合从截图直接开始排查。提示中应指出图片来源、要关注的区域和期望结果，例如“这是 1440 像素宽页面，检查红框卡片溢出，保持移动端不变”。

不要只上传图片说“帮我改”。应同时告诉 Codex 对应仓库、页面入口、相关组件和不能改变的行为。若有多张图，给每张编号并说明用途：现状、目标、移动端和错误状态。这样模型更容易建立图片与代码之间的映射。

三、交互式会话中直接粘贴图片

官方 CLI 说明也支持把图片粘贴到交互式编辑器。它适合任务进行中补充新证据，例如修改后发现另一个断点有问题，或运行测试时出现新的图形化错误。补图时说明它与前一张的差异，不要让模型自行猜测版本顺序。

图片输入并不替代可复现步骤。前端问题仍应提供浏览器、窗口尺寸、路由、登录状态和操作步骤；桌面应用问题应说明系统版本和缩放比例；终端截图最好附可复制的命令与输出。视觉证据和文本证据结合最可靠。

四、什么时候应该使用 --search

当任务取决于当前事实时再启用搜索，例如第三方库最新版本、今天的官方文档、服务状态、近期变更或外部接口行为。官方说明中，codex --search 会为该次运行开启实时网页搜索，并让搜索活动保留在会话记录中，方便复核来源。

仓库内部问题通常先搜索本地代码，不必立刻联网。若错误来自固定版本依赖，应优先读取 lockfile、安装包文档和本地类型定义，再把网页资料作为补充。否则搜索到的最新版答案可能与项目实际版本不一致。

五、如何限制搜索范围和判断来源

在提示中写清楚要查什么、允许哪些来源和时间范围。例如要求优先官方文档、发布说明或原始仓库，而不是只搜“怎么修”。对安全、付费、法律和生产配置等高风险问题，应打开来源确认原文，不要只依赖搜索摘要。

搜索结果可能过时、互相矛盾或针对不同版本。让 Codex列出关键结论、发布日期、适用版本和不确定项，再与当前项目配置对照。若官方资料没有说明，就明确标注推断，不要把社区经验包装成确定事实。

六、截图加搜索的组合工作流

第一步提供裁剪后的错误截图和可复制错误文本；第二步让 Codex 在仓库中定位相关组件和依赖版本；第三步只在确认问题依赖外部变化时启用搜索；第四步比较官方资料与本地版本；第五步先给修复计划，再做最小改动并运行测试。

例如浏览器提示某 API 已弃用，截图说明用户看到的现象，本地 lockfile 确认当前 SDK 版本，官方发布说明核实弃用时间，最后再修改代码。这样比直接根据一篇搜索结果升级全部依赖更安全，也更容易回滚。

七、避免上下文过载的整理方法

一张截图只回答一个主要问题，长日志放入文本文件而不是连续截图，网页研究只保留与当前版本直接相关的来源。需要比较设计稿时，统一尺寸和标注；需要比较错误前后状态时，使用相同视口并给出时间顺序。

如果任务很长，把已确认事实、待验证假设、关键文件和验收结果写入任务笔记。后续补图或搜索时引用这份笔记，避免每轮重复上传全部材料。更多 Codex 实践可访问 https://gptupcn.com/codex/ ，具体命令以当前 CLI 帮助和官方文档为准。

八、提交前的安全与质量检查

确认图片中没有敏感信息，搜索来源可访问且与项目版本匹配，代码改动没有把截图或临时下载文件误提交，测试覆盖了图片所示场景。涉及界面时同时检查桌面和移动视口，涉及外部 API 时准备失败路径与回退方案。

最后查看 Git diff，运行项目规定的测试、lint 和类型检查，再进行独立代码审查。图片和搜索能改善输入，但不会自动保证输出正确；真正可发布的结果仍需要可复现、可测试和可回滚。

九、一个完整的前端排障示例

假设移动端结算按钮被底部工具栏遮挡。先上传同一页面在正常与异常视口下的截图，标注浏览器、宽高和复现步骤；再让 Codex读取布局组件、全局样式和安全区域处理，不要一开始就改 CSS。若问题可能来自浏览器新行为，再启用搜索核对对应版本的官方说明。

确认原因后，只修改最小范围，并让 Codex在多个视口运行页面检查或测试。对比修复前后截图，检查按钮可点击、文字没有溢出、键盘弹出时布局仍稳定。最后查看 diff，确保没有把本地截图、下载的网页或调试日志提交进仓库。

这个流程的关键是证据顺序：截图说明现象，本地代码说明实现，搜索说明外部变化，测试说明修复有效。若三类证据结论冲突，应暂停修改并重新核对版本，而不是选择最符合预期的一条答案。

结语

--image 让 Codex看见本地视觉证据，--search 让它核验变化中的外部事实。把两种能力放在明确范围、可信来源和版本控制之内，才能既提高沟通效率，又避免敏感信息泄露和错误升级。