DeepSeek 终于长眼睛了。以前我用 Codex 写代码最憋屈的就是它只能读文本出个前端样式问题得把截图里的文字手打出来给它看设计稿要转代码得自己先把图层描述搞清楚。现在 DeepSeek 的视觉能力接进 Codex 和 Harness 之后整个流程顺了一大截它能直接看截图、读设计稿、认报错页面还能把看见了什么转成可执行的修改任务。这篇文章就把我的接入过程和实测记录完整放出来给正在折腾 DeepSeek Codex Harness 这套组合的读者当个参考。1. 为什么说长眼睛DeepSeek Vision到底解决了什么1.1 编码智能体最缺的不是嘴是眼睛用过 Codex 这类编程智能体的人应该都有同感它理解指令、改代码、跑命令的能力已经很强但整个工作流里最别扭的一环是模型看不见界面。报错日志是文本它能直接分析但前端布局错乱、按钮错位、弹窗遮挡这类问题靠文字描述往往说不清楚。你只能说左上角那个按钮跑到右边去了至于具体偏移多少、颜色对不对、和其他元素有没有重叠全靠它猜。这其实暴露了单模态模型的根本短板。文本是对现实世界的二次抽象而截图、设计稿、流程图、手绘草图这些视觉信息是人类协作里最直接、信息密度最高的表达方式。Vision 接进来之后Codex 的输入不再局限于纯文本它能直接读取一张 PNG把图片里的结构、文字、颜色、位置关系全部转成语义化的描述再基于这些描述去做代码修改。所以长眼睛这个说法本质上指的是 DeepSeek 视觉语言模型让原本只能处理文字的智能体获得了视觉上下文理解能力。它对开发流程的改变不是锦上添花而是把人看图、人转述、AI写码这个旧链路压缩成AI直接看图、AI直接写码。1.2 DeepSeek Vision 的能力边界它能看见什么不能看见什么先说原理视觉语言模型VLM并不是真的在看图而是把图像切成固定大小的 Patch类似把一张图切成很多小方块然后通过视觉编码器转成向量序列再交给语言模型做注意力计算。这套思路来自 Vision Transformer 的核心设计图像和文本最终都被表示成了 token所以模型能统一处理两种模态。DeepSeek 的视觉能力也遵循这个范式优势在于它对中文场景、代码界面、复杂表格的识别更贴合国内开发者的使用习惯。实测下来它能稳定处理的场景包括控制台报错截图能把堆栈信息里的关键错误行准确摘出来设计稿转页面能识别布局层级、主色调、按钮文案手绘流程图或架构草图能转成结构化文字甚至代码注释页面截图对比能说出标题字号不一致右侧边栏少了筛选按钮但它也不是万能的。像素级精确比对、极小字号识别、视频流动态分析这类任务视觉模型的稳定性会明显下降尤其是模糊截图和小尺寸文字经常会出现漏字或错字。所以接入时要有个预期管理它擅长的是看图说话级别的结构化理解不是图像测量工具。2. 接入前的准备API、工具和它们的关系2.1 需要准备的材料清单接入这套组合需要的资源并不复杂基本都是开发者手头已有的东西。一个 DeepSeek 开放平台账号开通 API 服务并创建 Key一个支持运行 Codex CLI 的终端环境可以是 macOS、Linux 或 WindowsHarness 运行环境根据你选的版本可能是开源仓库克隆后本地启动也可能直接用桌面版至少一张测试用的截图建议是包含报错信息的终端截图或前端页面截图环境变量配置工具比如.env文件或者 shell profile用来安全存放 API Key这里面最容易忽略的是环境变量。很多人喜欢把 API Key 直接写进代码或配置文件结果一提交到 Git 就泄露。我的习惯是单独建一个.env文件启动工具前 source 一下Key 只存在于进程环境里不落盘、不进版本库。2.2 Codex 和 Harness 到底是什么关系别再混了很多同学看到标题会问Codex 和 Harness 是不是同一个东西不是。它们在这次接入里扮演的是不同层级。Codex 是面向终端的编码智能体你给它一句帮我修一下这个 bug它会分析代码库、写修改方案、调用命令、运行测试再告诉你结果。它更像一个坐在你旁边的结对程序员。Harness 是工作流编排框架它关心的是怎么把多个步骤自动串起来比如截图 → 调模型分析 → 触发 Codex 改代码 → 重新构建 → 再次截图验证。它不直接写代码但知道什么时候该调用谁、按什么顺序执行、出错怎么回退。我用一个仓库管理的类比Codex 是干活的人Harness 是项目经理DeepSeek Vision 是现场勘察员。勘察员拍照回来项目经理判断需要改哪里让干活的 Codex 动手改完再派勘察员复验。三者各干各的活配合起来才是完整的自动化闭环。工具定位典型输出是否直接改代码Codex终端编码智能体代码修改、命令执行结果是Harness工作流编排框架任务状态、节点输出、链路日志间接触发DeepSeek Vision视觉语言模型图片描述、结构化分析文本否3. 把Vision接进Codex配置步骤与原理讲解3.1 修改 Codex 配置让 DeepSeek 成为可用模型Codex CLI 支持通过配置文件注册第三方模型提供商核心思路是让 Codex 的模型调用层指向 DeepSeek 的接口。默认配置文件位置在~/.codex/config.tomlWindows 下路径略有差异但格式一致。核心配置项长这样model deepseek-vision model_providers [ { name deepseek, base_url https://api.deepseek.com/v1, env_key DEEPSEEK_API_KEY } ]配置完保存后在终端里启动 Codex它就会用deepseek这个 provider 去请求 DeepSeek 的接口。注意model deepseek-vision里的模型名是个占位写法具体要用什么模型名以你账号控制台里实际能看到、能调用的名称为准。不同阶段开放的视觉模型代号可能不同把名字填错会直接报model is not supported。这里解释一下各字段的意思name给这个提供商起个内部名字便于 Codex 识别base_url接口根地址DeepSeek 兼容 OpenAI 格式所以/v1这个路径不能漏env_key指定从哪个环境变量读取 API KeyCodex 启动时会自动读取3.2 为什么 Codex 能对接第三方模型很多人不理解Codex 不是 OpenAI 自家的工具吗为什么能接 DeepSeek根本原因是接口协议兼容。Codex 在调用模型时走的是 OpenAI 定义的chat/completions风格的接口规范只要模型提供方实现了同一套协议工具层就不用做额外适配。DeepSeek 的 API 在设计上兼容这套规范所以只需改 base_url 和 KeyCodex 就能把它当成一个普通的模型端点来用。这种方式对开发者非常友好。它意味着你不需要改 Codex 的源码也不需要用中间转换层几行配置就能完成切换。但也别把兼容理解成完全一致不同模型在工具调用格式、上下文长度、响应结构上仍有细微差异遇到奇怪问题时要想到是兼容层导致的。3.3 让视觉真正在编码场景生效的三种方式配置好模型只是第一步真正让视觉能力在开发流里发挥作用我实践下来有三种有效姿势。方式一直接把截图喂给对话。这是最直接的使用方式。Codex 会话里给出图片路径或粘贴截图模型会基于图片内容理解问题。比如我把一个控制台报错截图发过去它直接定位到第 23 行空指针省去了我复制粘贴堆栈的步骤。方式二在 Agent 循环里引用图片文件。适合批量处理。你构造任务时把图片路径作为参数传进去Codex 会在工作过程中自动读取图片、解析内容、输出分析结果。这种方式适合一堆报错截图等着分类整理的场景。方式三由 Harness 定时截图并触发视觉分析。这是自动化程度最高的方式。页面在跑自动化测试时Harness 负责截图保存DeepSeek Vision 负责分析截图内容再把分析结果交给 Codex 处理。整个过程中人不需要盯屏出问题自动进入修复链路。4. Harness 接入实战把视觉能力编排进工作流4.1 在 Harness 里注册一个 Vision 模型节点Harness 的配置通常以工作流描述文件的形式存在你需要在里面注册一个模型调用节点告诉 Harness这个节点负责调用 DeepSeek 视觉模型。我第一次接入时用的是 YAML 格式的编排文件核心配置大概是nodes: - id: vision_analyze type: model_call provider: deepseek model: deepseek-vision input: ${steps.capture_screenshot.output} output_key: vision_result这段配置的意思是把上一个节点截图节点的输出作为图片输入调用 DeepSeek 视觉模型分析结果存到vision_result里供后续节点使用。这里有个容易忽略的细节model_call类型的节点需要提前把 provider 注册好否则 Harness 不知道deepseek指向哪里。注册方式和 Codex 类似在 Harness 的配置里维护一个模型供应商列表填好 base_url 和 Key 的环境变量名即可。4.2 一个完整链路截图理解 → 代码修改 → 视觉验证这一节是我个人认为整个接入里最有价值的部分因为它把看和改真正闭环了。我搭了一个自动修复前端样式问题的小链路流程如下第一步Harness 启动目标页面用无头浏览器截图保存为page_before.png。第二步Vision 节点读取这张截图输出结构化的问题描述比如导航栏右侧间距异常CTA 按钮颜色与设计稿不一致底部缺少版权信息。第三步Harness 把这段描述作为任务传给 CodexCodex 定位到前端源码修改样式和布局。第四步Harness 重新构建并启动页面再次截图保存为page_after.png。第五步Vision 节点第二次运行对比修改前后的效果确认问题是否解决。如果还有偏差就把新的描述再次传给 Codex形成循环。这套链路跑通之后我最大的感受是以前截图看效果这个需要人亲力亲为的动作现在被 Harness 接管了。开发者只需要在最开始设定判断标准后面整个循环可以无人值守跑很多次。当然前提是每次截图的环境要稳定页面加载等待时间要设置合理否则很容易拿一张没渲染完的截图去分析得出错误结论。5. 实测记录任务设计、参数和真实表现5.1 我设计的 4 类测试任务为了验证这套组合到底行不行我设计了 4 类有代表性的测试任务覆盖了日常开发里最常遇到的看图需求。任务输入预期输出实测结果A. 报错截图求修复终端里的异常堆栈截图根因分析和修复代码稳定识别定位准确B. 设计稿转页面一张后台管理页设计图可运行的 HTML/CSS 结构整体可用细节需微调C. 手绘草图转结构化描述手画的登录流程草图分步骤的文字说明能转但复杂箭头易忽略D. 样式回归对比修复前后两张页面截图差异清单和是否符合预期能指出差异但对细微色差不敏感整体看下来任务 A 和 D 最贴近实际开发场景实用价值最高任务 B 适合快速搭原型但离像素级还原还有距离任务 C 属于锦上添花适合整理思路不适合精密需求。5.2 关键参数怎么调直接抄作业实测中我把几个关键参数试了个遍这里直接给结论。temperature建议调到 0.2 到 0.4 之间。它是控制随机性的参数编码和图像描述类任务都希望输出稳定温度太高容易产生幻觉比如给报错截图编造一个不存在的错误原因。我喜欢用 0.2基本不会出现一本正经胡说八道的情况。max_tokens要记得调大一些。视觉任务的分析结果往往比纯文本对话长因为模型要先描述图片内容再给出结论输出长度很容易超过默认值。建议不低于 1024遇到复杂截图直接设 2048。图片输入需要预处理。实测下来超过 1MB 的截图响应时间明显变长超过 2048 像素的长边会让模型识别小字变得更吃力。我的做法是截图后先压缩保证文件大小在 500KB 到 1MB 之间长边不超过 2048 像素信息损失可以接受速度和成本都能优化。延迟方面单张截图的完整分析一般在 5 到 15 秒之间具体取决于图片大小和接口负载。这个速度在交互式对话里能接受但跑自动化循环时要注意超时设置别让 Harness 因为等待时间过长而误报失败。5.3 实测中的亮点和翻车点先说亮点。DeepSeek Vision 对控制台报错的识别准确率高得有点超出预期即使是带着颜色高亮、行号错位、VSCode 主题背景的截图它也能准确提取出核心错误信息。这和它训练数据里大量代码界面截图有关属于专业对口。设计稿转页面也很惊喜。我拿一张带深色侧边栏、卡片式布局的后台设计图测试它生成的结构基本正确配色也抓得准生成的 HTML/CSS 可以直接作为初稿使用。翻车的地方也不少。最明显的是 UI 元素重叠时模型会有点犹豫。比如弹窗遮住底层内容、两个按钮间距极小它可能会漏描述其中一个。另一个翻车点是极小字号的中文当字体小于 12 像素时OCR 漏字概率明显上升导致对文案的理解出错。这些翻车点提醒我视觉模型的分析结果应该作为参考而不是最终结论尤其是在自动化链路里要设计人工确认节点或者搭配截图裁剪放大之类的预处理来提升准确率。6. 常见问题与排查技巧实录6.1 model is not supported 这类报错怎么查这是接入时最常见的报错字面意思是模型名不被支持但实际原因通常有两个。第一模型名确实写错了比如多打了一个空格、大小写不对、或者用了还没对外开放的模型代号。第二模型本身没问题但 base_url 指错了环境导致请求打到了不包含该模型的旧接口上。排查顺序我建议这样先登录平台控制台确认账号下实际可用的模型列表里有没有你填的模型名再对比代码里的模型名和列表是否完全一致最后检查 base_url 指向的环境是否和模型所在环境匹配。大部分model is not supported都能在这三步里解决。6.2 鉴权失败、接口地址写错的检查顺序遇到 401 鉴权失败时不要急着怀疑账号被封先检查环境变量。Codex 和 Harness 都是从环境变量读 Key如果变量名和配置里的env_key不一致或者变量没被正确加载到当前进程就会拿空 Key 去请求必然 401。遇到 404 或者连接类报错时十有八九是 base_url 的问题。最常见的是漏写/v1路径或者多写了一个斜杠。这两种情况都会让接口请求打到不存在的端点。我习惯把 base_url 复制到浏览器里直接访问能打开说明地址没问题打不开就说明路径写错了。再补充一个容易忽略的点配置修改后要重启进程。Codex 和 Harness 都是在启动时加载配置的改了 config 文件不重启模型列表还是旧的排查半天才发现是没重启非常浪费感情。6.3 控制视觉成本的三个思路视觉模型调用比纯文本贵因为图片要切 patch、转 token一张普通截图可能产生上千个视觉 token。实测下来我有三个控制成本的思路都很实用。第一压缩图片再上传。把长边控制在 1024 到 2048 像素之间文件压缩到 500KB 左右视觉 token 数可以降不少分析质量几乎不受影响。第二截图裁剪局部。比如只需要分析报错区域就把截图裁成那一小块再调用成本可能只有整图的四分之一。第三缓存分析结果。同一张截图只要内容没变就不要反复调用模型Harness 里可以给每个截图文件算一个哈希哈希一样就直接用上一次的分析结果。这三招叠加下来我用视觉模型的成本比刚开始下降了接近一半分析效果没有明显退化。本内容配套的接入方案是我在当前版本下反复验证过的版本更新后字段可能有变化但整体思路不受影响。最后再分享一个小技巧给 Harness 的截图目录设置固定路径并开启自动清理否则跑几十轮自动化之后磁盘上会堆满测试截图找起问题来非常痛苦。这套截图-分析-修改-复验的循环是我目前用过的 AI 编码组合里最顺手的希望这篇记录能帮你少走几步弯路。