DeepSeek V4 Pro 与GPT 5.3 Codex high同台PK，代码能力差距有多大？「一手测试」

写在前面

最近很多人都在问同一个问题：如果把模型从“会写代码”拉到“能不能做完一个小工程”，差距到底会不会被放大？

这次测试把这个问题拆成了两层：

• 第一层看基础代码能力：TypeScript 实现 LRU Cache
• 第二层看 Agent 工程能力：实现一个本地 Markdown 分析 CLI（md-inspector）

参与对比的是 DeepSeek V4 Pro（通过 Claude Code 调用）和 GPT-5.3 Codex High，评估模型是 GPT-5.5 thinking。最终观感很明确：LRU 环节 DeepSeek 首答更标准；工程任务环节 GPT-5.3 Codex High 更像成熟代码 Agent。

为什么要做两轮：单题高分，不等于工程可交付

只测算法题，容易得到“写得对”；但真实开发更关心的是“能不能完整交付”。

这轮设计的思路很实用：

1. 先用 LRU 测基本功（数据结构、边界条件、类型严谨性、测试意识）
2. 再用 CLI 工程任务测闭环能力（拆分模块、处理异常、测试覆盖、tsc 可通过、输出语义一致）

额外背景也有参考价值：测试时刚好碰上 DeepSeek API 2.5 折，整轮花费约 1.4。

第一轮：LRU Cache，DeepSeek 首答领先，双方追问后都能进化

题目要求是经典但不简单的组合：

• get / put 必须 O(1)
• 支持 capacity
• capacity 为 0 也要正确
• 给完整代码
• 给 5 个测试用例

这一题的筛选价值在于：弱模型很容易在“看起来能跑”与“边界真实正确”之间露破绽，比如 get 后不刷新顺序、更新已有 key 不刷新、capacity=0 处理错误、把 0/false/空串误判成未命中、测试只写 happy path。

第一轮评分

DeepSeek V4 Pro：首答“正统解”，追问后补齐工程能力

DeepSeek 第一版就走了标准路线：Map + 双向链表，并且把关键边界场景带上了。随后多轮追问里，它继续升级到工程版：

• 改成泛型实现
• constructor 做 capacity 非负整数校验
• 增加 size / has / clear
• 用 Vitest 补测试
• 明确复杂度

它还对类型模型做了改进：把“链表连接职责”和“数据节点职责”拆开，用 LinkEntry / DataEntry 思路避免哨兵节点被迫塞 null as unknown as K 这种不够干净的类型写法。

同时还处理了 API 语义：

• get 保持易用（返回 V | undefined）
• tryGet 提供严谨命中语义（found: true/false）

这个点在工程里很关键，因为当缓存值本身可为 undefined 时，单一 get 返回值无法区分“未命中”和“命中但值为 undefined”。

GPT-5.3 Codex High：可修正性强，但完整度略输一档

GPT-5.3 第一版也是标准实现，后续追问里也做了明显升级：

• 改 circular sentinel 设计
• 去掉 null as unknown
• capacity 非法值测试补齐（NaN / Infinity / 负数 / 浮点）
• 命中结果结构化（如 hit/value）

但它的扣分点也比较集中：

• 回归测试数量与覆盖面相对少
• 设计取舍解释不够充分
• 工程化叙述完整度略低

第一轮结论：DeepSeek 在“第一反应标准度 + 持续工程化推进”上更占优；GPT-5.3 能修到可用强档，但整体收束稍慢。

第二轮：Markdown CLI 工程任务，GPT-5.3 Codex High 反超

第二轮题目明显更接近真实开发：实现 md-inspector，递归扫描 Markdown 并输出质量报告。

任务不只是“做统计”，还给了不少“真实世界坑位”：

• 空目录
• 不存在目录
• 没有 H1 / 多个 H1
• 图片不能算普通链接
• 代码块里的链接和图片不能计数
• Windows 与 macOS/Linux 路径兼容
• 文件读取失败要进入 warnings，不能让程序崩溃

工程约束也给得很明确：

• TypeScript
• Node 内置模块
• 合理拆文件
• 至少 8 个 Vitest 测试
• 说明运行方式、验证方式、需求假设
• 最后做自我审查

第二轮评分

GPT-5.3 为什么赢：不是“写更多代码”，而是“交付闭环更完整”

GPT-5.3 这轮表现最强的地方，不在某个函数，而在整体交付流程：

1. 先声明需求假设（统计口径、fenced code block 范围、路径输出格式）
2. 再给实现计划（初始化、模块拆分、异常处理、测试验证、自审）
3. 模块化结构清晰（扫描、分析、路径、报告、入口）
4. 测试覆盖满足且超出要求（10 个）
5. 验证动作完整（npm test 通过 + npx tsc --noEmit 通过）
6. CLI 错误语义符合任务要求（不存在目录进入 JSON warning，而非直接崩）

它的扣分点也被明确指出了：

• Markdown 解析偏正则，不是 AST 级解析
• wordCount 口径有自定义假设
• 部分权限失败测试跨平台鲁棒性一般
• 扫描阶段的局部失败容错还可更细

但即便有这些，整体仍然最接近“可直接交付的小型工程 Agent”。

DeepSeek 为什么落后：主体能跑，但验收语义和类型收口没完全到位

DeepSeek 在第二轮并不弱，项目结构和测试数量甚至很积极（14 个测试），也有明确的自我审查条目。

但差距主要出在最后 20% 的工程收口：

1) TypeScript 工程闭环不完整

npm test 虽通过，但 npx tsc --noEmit 失败（缺少 @types/node，导致 node:fs/promises / process 等类型识别问题）。

对 TypeScript CLI 项目来说，这属于明显扣分项。

2) 错误语义与题目要求不完全对齐

题目要求“不存在目录进入 warnings”；DeepSeek 方案更偏向 stderr + exit，没有完整落到 JSON report warnings 语义。

3) 扫描阶段局部容错不足

单文件读取失败有处理，但扫描阶段异常（如目录读取）仍可能放大为整体失败。

4) CLI 端到端行为测试偏少

测试更多集中在内部模块，对真实命令行行为（stdout / exit code / 参数缺失 / 不存在目录路径）覆盖不够完整。

这也是为什么它在这轮被评价为：可用初版项目，但收尾不如 Codex 稳。

把两轮合在一起看，结论更有参考价值

如果只看 LRU，会得到“DeepSeek 更强”的印象；如果只看 CLI 工程，会得到“GPT-5.3 更强”的印象。两轮叠加后，更准确的说法是：

• 基础代码生成与标准题首答：DeepSeek V4 Pro 更亮眼
• 工程任务闭环与交付稳定性：GPT-5.3 Codex High 更占优

最终排序是 GPT-5.3 Codex High > DeepSeek V4 Pro，但差距不是断层级别，属于“工程收尾质量差异”而不是“基础能力碾压”。

同时也要注意边界：这轮更偏“小型 TypeScript CLI 工程能力”，还不能直接外推到所有 Agent 场景。

还未充分覆盖的维度包括：

• 工具调用策略
• 网络检索链路
• 长链路任务稳定性
• 大型真实仓库改造
• 依赖冲突处理
• 测试失败后的多轮修复
• PR 质量与 Git 操作流程
• 中途环境变化下的恢复能力

Claude Code 到底是什么？为什么这种测法会越来越重要

Claude Code 不是传统补全插件，而是一个可以在真实项目中连续执行任务的代码 Agent：

• 能读写项目文件并跨文件修改
• 能执行命令并联动测试/构建
• 能在上下文里持续迭代修复
• 能在较长任务链路里保持目标一致性

这也是为什么“单条回答质量”已经不够了。真正决定开发体验的，是模型能否在多步链路里稳定推进，最后把活收住。

订阅路径通常有两种：官方订阅与 API 按量计费（以官方实时页面为准）。不过对国内用户来说，常见门槛还是支付和网络环境。如果想省掉这部分折腾，可以看看 Code80，真实订阅账号转 API，改 endpoint 就能接进现有工作流。详情见 code.ai80.vip。

常见问题

Q1：这轮结果能不能直接下结论“谁绝对第一”？

A：不能。这轮是两类任务下的横截面结论，不是全场景榜单。更准确说法是：DeepSeek 在基础代码首答上更强，GPT-5.3 在工程闭环上更稳。

Q2：为什么 LRU 分差不大，但工程任务差距更明显？

A：因为工程题会放大“异常处理、类型检查、测试收口、CLI 语义一致性”这些交付细节。很多模型能写出主流程，但收尾质量会拉开差距。

Q3：这次测试里最关键的验收信号是什么？

A：不是“代码能跑一次”，而是“测试通过 + tsc 通过 + 错误语义符合题目 + 自我审查能指出真实短板”。这几个信号同时成立，才接近可交付。

Q4：对开发团队选型最实用的建议是什么？

A：不要只看 benchmark 分数，直接做你们自己的双层评测：一道基础题 + 一道小工程任务。重点看多轮迭代后是否稳定变好，以及是否会引入新问题。

Q5：国内开发者怎么更顺畅接入 Claude Code 工作流？

A：如果不想处理复杂的支付和网络配置，国内用户可以通过 Code80 更方便接入。