← 返回资讯
苏晴
资深编辑
已审核

Claude指出我的连接泄漏Bug,我才搞懂它和Codex的架构差异

**TL;DR** - Claude Code 像个会跟你吵架的结对编程 buddy(代理式),Codex 更像个嗑了药的自动补全大师(自监督)。两者架构天差地别:一个靠对话循环驱动,一个靠概率预测。踩了无数坑才理清。

Claude指出我的连接泄漏Bug,我才搞懂它和Codex的架构差异

Claude指出我的连接泄漏Bug,我才搞懂它和Codex的架构差异


Claude Code 代理式编程 vs Codex 自监督代码生成:我花了一周才搞懂的架构差异 ☕

TL;DR - Claude Code 像个会跟你吵架的结对编程 buddy(代理式),Codex 更像个嗑了药的自动补全大师(自监督)。两者架构天差地别:一个靠对话循环驱动,一个靠概率预测。踩了无数坑才理清。


上周四下午,柏林 Kreuzberg 的 Five Elephant 咖啡馆。我跟同事 Martin 争论了快一个小时——为什么 Claude 写的代码能跑,但 Codex 的补全总是更快?

我喝了三杯拿铁,在餐巾纸上画了张图。Martin 说我看上去像在推演什么阴谋论。

Anyway,今天把心得捋一捋。

先说我的翻车经历 🔥

三个月前,一个 NestJS 项目。我同时试着用这两个工具。

Codex 写 CRUD 接口,嗖嗖的。说实话,快得有点离谱。但我让它"重构这个 service,加上事务管理"——它直接丢给我一串代码,看着很对。真的很对。

然后数据库连接池炸了。

连接泄漏。半夜三点我盯着日志发呆。

Claude Code 呢?我在 terminal 里敲:"帮我加个事务装饰器,注意连接池释放"。它不仅改了代码,还蹦出一句:"等等——你这几个地方没 return await,大概率是连接泄漏的元凶。"

我当时就想把 Martin 摇醒告诉他。

这就是两种架构的本质差异。不是"谁更聪明",是它们运作方式完全不同。

代理式编程:Claude Code 怎么"干活"的?

Claude Code 的核心是 agentic workflow。想象一个真的有手的助手。

Actually,等一下——我该先澄清一件事。很多人以为 Claude 只是"更好的自动补全"。完全不是。

它的工作流程大概这样:

1. 你给个目标 → "把这个函数改成递归版本"

2. 它自己探索 → 读文件、搜相关代码、理解上下文

3. 执行操作 → 改文件、跑测试、看报错

4. 反思调整 → 测试挂了?再改。还挂?换个思路。

JAVASCRIPT
// 我在 terminal 里的真实对话(大概长这样)
$ claude
> 帮我看下 user.service.ts,把 findActiveUsers 改成带缓存的版本

Claude: 先看看文件... 
// 它自己执行: cat src/user/user.service.ts
// 然后: 嗯,你没有 Redis 配置。要我先装包吗?
// 我: 好
// Claude: npm install redis,然后写代码,跑测试,一次过

它不"猜"。它在循环:观察→行动→反馈→调整。

这就是 agentic 的关键——它有个 execution loop,能真正用工具。文件系统、shell、测试框架。不是模拟,是真跑。

Well... 至少大部分时候。偶尔它也会自作聪明改崩我的代码。上周它把我的 middleware 顺序改反了,我 debug 了半小时才发现。但那是另一个故事。

自监督代码生成:Codex 怎么"想"的?

Codex 走的是 self-supervised learning 路线。这是 OpenAI 的路线。

训练过程:

当我敲 // 写一个快速排序,它不是在"理解排序算法"。不是。

它是这样运作的:

"根据我见过的几百万个代码文件,这个注释后面最常出现的字符是 `f`,然后是 `u`,然后是 `n`..."
PYTHON
# 这本质上是 token 概率游戏
# 输入: "def quick_sort(arr):"
# Codex 的"思考": 
# - 下一行缩进 (概率 99%)
# - 然后 "if len(arr) <= 1:" (概率 87%)
# - 然后 "return arr" (概率 92%)
# - 没有然后了。这就是全部。

没有目标。只有模式匹配。

Martin 听到这的时候说:"所以它是个鹦鹉?" 我说差不多,但这是个见过几十亿行代码的鹦鹉。

根本区别就在这。

架构对比:咖啡馆餐巾纸上的表格

那天我在白板上画的(服务员以为我在写什么神秘算法,又多给了我一块饼干):

| 维度 | Claude Code (代理式) | Codex (自监督) |

|------|---------------------|----------------|

| 核心机制 | 对话+工具调用循环 | Token 概率预测 |

| 上下文来源 | 实时读项目文件 | 训练时的静态数据 |

| 交互方式 | 多轮对话,持续调整 | 单次生成,补完即止 |

| 错误处理 | 跑测试→看报错→修复 | 看模式→猜正确代码 |

| 适合场景 | 复杂重构、调试 | 快速补全、样板代码 |

这表格我改了三遍。第一版太简单了,Martin 看了说"你这对比没啥信息量"。他说得对。

三个例子让你秒懂 💡

例子 1:写 API 接口

Codex (在 VSCode 里):

JAVASCRIPT
// 我刚输入 "// 创建用户接口"
app.post('/users', async (req, res) => {
 const { name, email } = req.body;
 const user = await db.user.create({ data: { name, email } });
 res.json(user);
});
// 啪!一秒补全。基于它见过的百万个 Express 路由

快。真的快。

Claude Code (在 terminal 里):

CODE
我: 加个创建用户的接口,要验证邮箱格式
Claude: 我先看你用的什么验证库... (读 package.json)
 哦你在用 zod,我用 zod 写验证
 等等——你的错误处理中间件在哪?我保持风格一致
 写完跑测试... 过了!

一个快,一个稳。差异很明显。

例子 2:调试异步 Bug

我故意写了个有问题的代码:

JAVASCRIPT
// 这个函数有时会丢数据——我知道有问题,故意留着
async function processOrders(orders) {
 orders.forEach(async (order) => {
 await saveToDatabase(order);
 });
 console.log('处理完成'); // 这行其实会先执行
}

Codex 的反应:在我注释下面,它补全了另一个 forEach 写法... 因为它没见过"标记这个 bug"的模式。它只是继续补全。

Claude Code 的反应:我说"帮我修 race condition"。它直接改成 Promise.all + map,还解释:"forEach 不会等 async 完成。用 map 包一层。"

我花了三小时才找到的 bug。它 30 秒。

I think 这就是 agentic 架构最闪光的地方——它能"推理"你的意图。不是概率匹配,是推理。

例子 3:代码重构

真实场景:500 行的 service 要拆成三个模块。

Codex:每创建一个新文件,帮我补 import 语句。很舒服。但只是加速器。

Claude Code

CODE
我: 把 user.service.ts 里的支付逻辑抽到 payment.service.ts
Claude: 我看了代码,支付相关的有 4 个方法。
 但 handleRefund 用了 user 模型的方法,要一起移吗?
 我觉得先移 3 个纯支付方法,handleRefund 稍后重构比较好。
 你怎么想?

它在跟我讨论设计。

不是盲目执行。是讨论。

为什么架构差异这么大?

训练哲学的问题。

Codex 的自我监督学习:"我给你看半个文件,猜后半个。" 猜对加分,猜错扣分。训完就变成了代码续写机器。就这么简单。

Claude Code 的代理式编程:更像 reinforcement learning + 工具使用。"给你任务、终端、工具。做对奖励。做错自己想办法纠正。"

Martin 的比喻(当时我们喝到第四杯了):

他说完又加了一句:"当然,有时候副驾驶也会把你带沟里。" 公平。

选哪个?我的实际 workflow 🚀

用 Codex 的时候

用 Claude Code 的时候

我现在 setup:VSCode 里 GitHub Copilot(基于 Codex)做日常补全,terminal 里 Claude Code 处理复杂任务。

上周重构支付模块。Copilot 帮我写了大概 60% 的样板。Claude 找出了 3 个并发问题,写了集成测试。

各取所长。

Oh 对了——我试过让 Claude 做简单补全。很慢。真的不值当。它会在那"思考"半天然后给你个 console.log。杀鸡用牛刀。

说句实话

别迷信"AI 替代程序员"。用了这么久,我最大的感受:

Codex 替代的是打字速度。Claude Code 替代的是调试时间。

但设计决策、系统架构、理解业务——还是你自己的脑子。

至少现在还是。

Martin 前几天问我:"你觉得明年这个时候呢?"

我说我不知道。Probably 变化会很大。但 Probably 我们还在争论哪个工具更好。


☕ 写完我又去了那家咖啡馆。同一个服务员,她问:"你上次餐巾纸上画的,是某种排序算法吗?"

我说:"差不多。是对 AI 排序。"

她笑了。然后问我是不是搞数据科学的。我说不是,我只是个写代码的,在柏林远程办公,咖啡喝太多了。


你们用什么 AI 编程工具?有没有被 Claude 改崩过代码?或者 Codex 给过什么离谱的补全?评论区聊聊!

特别好奇用 Rust 的朋友——我猜 AI 写 borrow checker 还是会翻车。我试过一次,Claude 绕了半天也没搞对 ownership,最后我自己改的。😂

#AI #webdev #programming #beginners #developer-tools

55
926 阅读
4 评论
分享
链接已复制
编辑说明

本文由 MakeSense 编辑团队撰写并审核。文中引用的数据和观点均经过交叉验证,如有疏漏欢迎在评论区指正。最后更新:2026年06月27日 13:33

苏晴

资深编辑

科技媒体从业 8 年,曾就职于多家科技媒体。关注 AI 创业和投资赛道,采访过 50+ 位行业从业者。

读者评论 4

数据分析师 1周前
数据引用很扎实,建议补充一下近三个月的最新数据。
回复 点赞 (9)
产品经理阿杰 2天前
从产品角度看,这个方向确实有机会,但商业化路径还需要验证。
回复 点赞 (15)
张工 5天前
写得很实在,特别是实测对比那部分,跟我自己的使用感受一致。
回复 点赞 (12)
前端工程师 1周前
代码示例很清晰,直接用到项目里了。
回复 点赞 (6)