您是如何衡量Claude Code和Codex的性能的？
我认为编码基准测试的结果并不能代表我们混乱的现实。因为它们：
1) 使用专门构建的测试框架，我们使用Claude Code或Codex。
2) 测试一次性任务，而我们是以会话的方式工作。
会话是混乱的，我们通常从一个大型的主要任务开始，然后进行一些清理，修复一些相关的问题，可能在这里做一点，在那里做一点。我们开始、停止，并且改变主意。
这会影响成本和质量。缓存的生存时间（TTL）会过期，背景信息会不断增加。
我正在着手创建一个。以下是我的初步计划：
1) 使用Claude Code和Codex。
2) 使用会话形状的工作负载。将多个经过软件工程（SWE）基准验证的任务拼接成一个大型会话。
2.a) 使用来自同一代码库的任务，以确保主题的连贯性。
3) 主要指标：成本与质量。
3.a) 次要指标：转化次数、完成时间。
待解答的问题：
a) 这个问题有意义吗？
b) 我的基准规范合理吗？
c) 从一个难度较大的任务开始的10个经过软件工程基准验证的任务是合适的工作负载形状吗？
查看原文
I think coding benchmark results don't represent our messy reality. As they<p>1) Use purpose-built test harnesses We use Claude Code or Codex<p>2) Test one-shot tasks We work in sessions<p>Sessions are messy, we start with a large primary task, then some cleanup, an adjacent fix here another over there. We start, stop, and change our minds.<p>That changes both cost and quality. Cache TTLs expire. Context grows.<p>I am working on creating one. Here's my rough plan: 1) Use Claude Code and Codex
2) Use session shaped workloads. Stitch multiple SWE bench verified tasks into one big session.
2.a) Use tasks from the same repo to ensure topical continuity.
3) Headline metrics: dollar cost vs quality.
3.a) Secondary metrics: turn count, time to completion<p>Open Questions
a) Does this problem make sense?
b) Does my benchmark spec make sense?
c) Are 10 SWE bench verified task starting with a hard one the right workload shape?