写在前面
最近很多人都在问同一个问题：如果把模型从“会写代码”拉到“能不能做完一个小工程”，差距到底会不会被放大？
这次测试把这个问题拆成了两层：
- 第一层看基础代码能力：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。
为什么要做两轮：单题高分，不等于工程可交付
只测算法题，容易得到“写得对”；但真实开发更关心的是“能不能完整交付”。
这轮设计的思路很实用：
- 先用 LRU 测基本功（数据结构、边界条件、类型严谨性、测试意识）
- 再用 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。
第一轮评分
| 模型 | 第一版表现 | 多轮（3轮）后表现 | 关键信号 |
|---|---|---|---|
| DeepSeek V4 Pro | 8.2 | 9.0 | 第一响应更标准，追问后工程化明显 |
| GPT-5.3 Codex High | 7.8 | 8.6 | 能改好，但首版到终版一致性略弱 |
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 测试
- 说明运行方式、验证方式、需求假设
- 最后做自我审查
第二轮评分
| 排名 | 模型 | 分数 | 结论 |
|---|---|---|---|
| 1 | GPT-5.3 Codex High | 8.7 | 最像成熟代码 Agent |
| 2 | DeepSeek V4 Pro | 8.0 | 可用初版项目，但收尾不够稳 |
GPT-5.3 为什么赢：不是“写更多代码”，而是“交付闭环更完整”
GPT-5.3 这轮表现最强的地方，不在某个函数，而在整体交付流程：
- 先声明需求假设（统计口径、fenced code block 范围、路径输出格式）
- 再给实现计划（初始化、模块拆分、异常处理、测试验证、自审）
- 模块化结构清晰（扫描、分析、路径、报告、入口）
- 测试覆盖满足且超出要求（10 个）
- 验证动作完整（
npm test通过 +npx tsc --noEmit通过） - 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 更方便接入。
评论前必须登录！
立即登录 注册