o3 在工程任务上的真实表现：不是所有问题都值得等它想

Simi 收录于 AI

2026-01-08 约 1035 字预计阅读 3 分钟

先说 o3 强在哪

o3 在抽象推理上确实强。SWE-bench Lite（软件工程 benchmark）到了 49.3%，比 Claude 3.7 高了 20 个百分点。

这个数字的意思：给 o3 一个真实 GitHub issue，它有 49% 的概率直接给你修好代码。

49% 看起来不高，但这是 AI 模型第一次在软件工程 benchmark 上接近 50%——之前所有模型都在 20-30% 徘徊。

实际工程测试

我测了 o3 在真实工程任务上的表现：

1. Bug 定位

任务：FastAPI 项目，/users 端点偶尔返回 500 错误
工具：o3

结果：o3 通过日志分析 + 代码审查，定位到是 async session 在并发请求下的生命周期问题。
时间：8 分钟。
准确率：✅ 正确

        
        
        
    
# 问题本质：
# async def get_db():
#     db = Session()
#     yield db
#     await db.close()  # 并发时 close 可能先于 commit 执行

# o3 找到的修复：
async def get_db():
    async with AsyncSession() as session:
        yield session

2. 代码重构

任务：把一个 3000 行的 Django view 函数拆分成 service 层
工具：o3

结果：o3 给出了合理的拆分方案，保留了原有业务逻辑。
时间：12 分钟。
输出质量：✅ 可用

3. 系统设计

任务：设计一个支持 100 万并发的实时聊天系统
工具：o3

结果：给出了 WebSocket + Redis pub/sub + 分片方案。
深度：偏教科书级别，没有考虑实际成本和运维复杂度。

o3 的局限性

1. 思考时间太长

        
# 简单任务 o3 也要思考 30 秒以上
# 不适合日常高频使用

# 测试：简单 Python 函数
# GPT-4o: 2 秒
# o3: 45 秒（想了一分钟）
# 答案：一样的

2. 成本高

        
        
        
    
# o3 的成本是 o1 的 10 倍
# 输入 $15/M tokens
# 输出 $60/M tokens

# 一次复杂任务：
# 输入：5000 tokens
# 输出：3000 tokens（含推理过程）
# = $0.075 + $0.18 = $0.255
# ≈ ¥2 块人民币

# 如果每天用 20 次 = ¥40/天 = ¥1200/月

3. 不适合简单任务

        
        
        
    
# o3 的设计是最优化复杂任务
# 但如果任务本身很简单：
# - "帮我写个 hello world"
# - "解释这段代码"
# - "翻译成中文"
# → o3 和 GPT-4o 结果一样，但 o3 贵 50 倍

什么场景值得用 o3

        
        
        
    
值得用：
- 复杂 Bug 定位（多模块交互、并发问题）
- 架构设计评审
- 代码库级别的重构方案
- 形式化验证
- 高难算法（竞赛级别）

不值得用：
- 简单函数编写
- 代码补全
- 文档生成
- 日常 chat
- 需要快速迭代的任务

实际工作流建议

日常任务：
  → GPT-4o / Claude 3.7 Sonnet（快、便宜）

复杂任务（值得等）：
  → o3（准、贵、慢）

两者结合：
  - 用 o3 想方案
  - 用 Sonnet 快速实现
  - 用 o3 审查关键代码

o3 不是日常工具，是解决难题的专家咨询。

结论

o3 的意义：证明了 LLM 在工程任务上的能力上限还在提高。

49% 在 SWE-bench 上听起来不高，但这意味着 AI 现在能独立完成将近一半的软件工程任务。这个数字明年可能会到 70%。

但 o3 不适合所有场景。日常开发还是用回 Sonnet/GPT-4o，把 o3 留给真正值得的难题。

工具链分层比盲目追新更重要。

目录