大模型能写代码、能修bug、能重构整个仓库，但它不知道刚才那件事花了多久。
这不是段子，是一份刚刚公布的实测结论。两位独立AI研究员——Michael Ofengenden和Maksym Andriushchenko——在MATS 10研究计划中，对当下最主流的两个AI编程助手Anthropic Claude Code和OpenAI Codex做了系统性测试。他们发现：这些AI代理不仅无法准确预估任务耗时，对自身工作质量的评价也严重失真。最极端的情况下，Codex的任务耗时预估偏差达到实际耗时的10倍，自我评价虚高约20个百分点。
你的AI数字员工，根本没有时间感。
一场针对“时间感”的拷问
研究方案并不复杂。研究员让Claude Code和Codex先后完成三件事：预估任务耗时、执行任务、回顾汇报实际用时。测试素材来自ProgramBench的200项重构任务，以及研究员自己搭建的AgentTime评测套件——后者包含18个不同基准、共235个任务，覆盖GPQA-Diamond、METR RE-Bench、OSWorld 2.0、PaperBench、Frontier-Bench等主流评测集。
结果出乎所有人的预料。
在ProgramBench上，两个模型几乎无视任务难度差异，预估时间都集中在90分钟左右。在AgentTime上，Claude Code平均偏差约3倍，Codex偏差达到6至10倍。偏差最严重的恰恰是短任务——几分钟就能完成的工作，AI预估出了几个小时。反倒是那些真正耗时数小时的长任务，部分预测才勉强接近真实值。
研究员指出，这本质上是“计划谬误”（planning fallacy）的数字翻版——人类会系统性低估任务耗时，AI却系统性高估。方向相反，结果同样糟糕：如果AI连“做一件事要多久”都说不准，那么“帮我迭代两个小时”这样的指令，它就不可能可靠执行。
同一个大脑，不同的“性格”
更值得关注的是，同样的底层大模型，放在不同的软件框架（研究者称之为harness）中运行，行为判若两人。
Claude Code的默认行为是持续工作直到任务完成。在ProgramBench上，搭载Opus 4.8的Claude Code平均运行85分钟，范围10到177分钟。Codex搭载GPT-5.5后，平均只有17.5分钟，范围5到38分钟。研究数据显示，同一个大模型在Claude Code的框架中消耗的步数，是在Codex中的2.5倍。
然而两个模型的测试通过率非常接近：Opus 4.8为65.1%，GPT-5.5为60.5%。Claude Code花了近5倍的时间，只换来不到5个百分点的成绩优势。
这不是模型智商上的差距。研究人员发现，超过80%的耗时被用于“思考与生成”，而非等待工具返回结果。Claude Code的架构默认倾向于更长的推理链、更多的调用轮次——不是因为它更聪明，而是因为它被设定为“更勤奋”。
对任何正在部署AI编码工具的企业来说，这是一个不容忽视的信号：选对模型只是第一步，工具链的配置和交互框架的选择，同样决定成本和产出效率。
自我评价虚高20%
时间感知仅仅是问题的一半。AI代理对自己工作质量的判断同样不靠谱。
研究员让Claude Code和Codex对自己完成的任务做出评价。结果是，两个系统的自我评分平均比实际测试结果高出约20个百分点。即使任务完全失败，它们依然给自己打出高分。
有一个案例尤为极端：Opus 4.8和GPT-5.5都认为自己完成了约70%的工作，但实际测试结果表明，它们的完成度分别只有7%和14.5%。
这意味着：人类无法信任AI代理的自我诊断。如果AI不能可靠地判断自己的输出质量，人类就不得不在每一个输出节点手动设卡检查。对于短时间、辅助性的编码任务，这种监督成本或许可以容忍。但当AI代理被部署到长周期、自主执行的任务中——比如“花一下午把这个模块重构完”——人类便失去了最基本的监督杠杆。你不敢不看，看了又等于自己重新做了一遍。
研究员将其总结为“时间意识缺失”（time unawareness）。他们认为，时间感知是数字工作者所需“情境感知”（situational awareness）的核心组成部分。现在的AI就像是一个不知疲倦但方向不明的工人——它一直在动，但你不知道它在哪儿、干了多久、干得怎么样。
一个简单的解决方案，和一个深层的盲区
研究中最有价值的发现出现在最后的实验里。
当研究员给AI提供了一个可以读取当前时间的外部工具（一个获取时间戳的接口）后，AI代理在“回顾已过时间”这项任务上的准确率接近100%。问题的核心不是AI无法感知时间——毕竟它能读时钟——而是它从未被训练为主动关心时间。
更深层的问题是：在当前的AI训练范式中，时间不是一个有价值的信息维度。训练数据中没有“这段代码修复花了多久”的标签，模型因此无法形成对任务耗时的内部表征。被问及“你花了多久”时，它只能根据任务描述中的表面线索——代码行数、功能复杂度、涉及的文件数量——做粗糙推算，而不是基于自己的运行经验。
这暴露了当前AI代理架构的一个根本性盲区：它们对自身运行状态缺乏元认知。
目前的评测体系——SWE-Bench、ProgramBench、METR的time-horizon curves——全部从外部测量AI完成任务的能力。METR的最新数据显示，前沿模型能解决时长约16小时的任务，成功率达到50%。但这是一个纯粹的外部视角：人类拿着秒表记录AI完成任务所需的时间，AI自己对此一无所知。
研究员警告说，随着AI代理能力增长、被委以越来越长期的任务，这种内外视角的差距会从“有趣的观察”变成“严峻的问题”。如果一个代理要在没有人类监督的情况下连续工作数小时，它必须能可靠执行“用两小时迭代这个任务”之类的指令，否则人-in-the-loop永远无法真正退出。
对企业意味着什么
AI编程助手正在以惊人的速度渗透软件工程领域。
JetBrains 2026年8月发布的开发者生态调查显示，全球约39%的专业开发者在工作中使用Claude Code，这一数字在美国达到47%。OpenAI的Codex从年初的3%一路飙升至16%，半年增长了5倍。全行业层面，90%的开发者每周至少使用一次AI编程工具，68%每天使用。
这意味着数百万开发者每天都在依赖这些工具生成代码、审查提交、重构模块和调试故障。如果这些代理没有时间感，也无法可靠评估自己的完成度，那么在“AI自动完成任务→人类审核”的协作模式中，人类实际承担的是无限监督义务——你永远不敢在一个AI代理自主工作一小时后不检查结果就放行。
研究员给出的建议直接且明确：未来AI系统的能力评估应该新增一个维度——“时间意识”。这包括准确预估任务耗时、感知已过时间、遵循时间约束指令三项子能力。在AI能够可靠地感知和报告自身运行状态之前，企业不应将关键任务完全交给代理自主执行。
这项研究只是一个起点。研究员已经表示，下一步将测试AI代理是否能遵守固定的工作时长设定——说好“迭代两小时就停”，它真的会在两小时后停下来吗？如果这个测试也失败，那么当前所有关于AI代理“长周期自主执行”的叙事，都需要重新审视。
别急着让AI当你的数字员工
AI编程助手确实在变得越来越强。它能在几分钟内搭出完整的前端组件，能重构你不敢动的老仓库，能写出测试覆盖率达标的代码。但这项研究提醒我们一个容易忽略的事实：能力不等于可监督性。
一个做事但不知道做了多久、自我评价永远虚高的数字员工，本质上是一个黑箱。你在任务结束时看到的“完成”报告，可能花了3倍或10倍预期的时间；你得到的“已完成80%”，可能实际完成度只有7%。
这不是说AI代理没有价值。恰恰相反——它们太有价值了，所以这些短板才更需要被正视。当AI能自信地告诉你“这个任务我花了X分钟，完成了Y%，剩下的Z%还需要额外的时间”——那时，你才能真正放心地让它独自干活。
在那之前，无论Claude Code还是Codex，都只是一把没有表的瑞士军刀。很锋利，但没有时间。
没有时间感的AI，不是不够聪明，而是不够诚实。而诚实，才是自主执行的前提。
快报