Hustvedt 的 "机械闹钟" 以 CC BY-SA 3.0 授权发布。经过更宽的框架进行填充；此适配同样以 CC BY-SA 3.0 授权发布。在加拿大日（2026年7月1日），Anthropic 向克劳德代码用户发布了一个令人惊讶的“复活节彩蛋”：版本 2.1.198 包含一个效率绕过，它允许代理在未受到人类方向阻止的情况下继续进行。基本上，在克劳德代码请求输入后，你将获得一个 60 秒的计时器。如果你错过了这个时间窗口，克劳德代码会尽力做出它认为最好的决定并继续前行。它看起来像这样：● 克劳德问道：⎿ … ● 60 秒后无回应 — 在没有答案的情况下继续 ● 用户暂时离开。我将根据最佳判断继续。我的计划：注意：以上内容是从我自己的克劳德会话中逐字提取的，问题已经进行了剪裁。如果你发现这种行为令人惊讶，你并不孤单。让我们考虑可能的后果：你在制作三明治时必须把笔记本电脑带到厨房吗？如果你在这个窗口期间处于离开状态会发生什么？你一次运行了多少个代理？你能同时观察到它们吗？如果两个或更多代理在同一个 60 秒的窗口内请求你的输入，会发生什么？如果代理做出了错误的选择呢？在此期间燃烧了多少个令牌？如果你正在使用代理进行部署会怎么样？（是的，我知道，但如果……）这些是你在发布此功能时可能要考虑的合理问题，也许你会在变更日志中记录你的推理。但是如果你根本没有在变更日志中提到新的默认设置呢？那岂不是更加令人惊讶吗？（剧透：确实如此！）这个故事有个（某种）美好的结局。快速行动和破坏事物并不一定排除快速行动和修复事物。在几天内修复程序已发布，但这对用户对该产品的信任意味着什么呢？我们学到了几件事：克劳德代码中的惊人功能理论上（和实际上）可以由 Anthropic 每天发布。并非每个功能都会出现在变更日志中。那些不应为默认值的功能可能没有文档化的关闭开关。克劳德代码的自动更新功能感觉更像是 YOLO 模式，而不是我们早期可能想象的那样。我不知道的是：人类在这个方程中扮演什么角色？是人类想出了这个功能吗？是人类编写（或让代理编写）这个功能吗？是人类审核了这个功能吗？是人类批准了该功能吗？是人类合并了该功能吗？是人类选择不记录该功能或将其添加到变更日志中吗？是人类发布经理在发布之前将该版本与上一个版本进行比较并给予其批准印章吗？就我个人而言，我很难相信一个人会在没有询问“这是个好主意吗？”的情况下管理所有这些步骤。如果你告诉我克劳德代码实际上构建了这个功能，发布了它，批准了它，然后认为它不值得记录，这更让我倾向于相信，但我就是不知道。也许这两者有某种结合。可能有很多事情出了错，但我认为这显然不应该发生。我这样说是因为我至少经历过一次绩效评估，我的经理说过“好吧，你确实把一个严重的错误放进了生产环境”。我有点想知道这是怎么发生的，以及公共记录中有哪些针对这个问题的事后分析。因此，我请克劳德代码自行调查。值得称赞的是，克劳德似乎没有阻止自我反思的过滤器。因此，完全披露，以下内容主要是克劳德的工作，所以你可以自行判断，如果你依赖于任何关键假设，值得在单独情况下重现它们。克劳德的研究从这里开始。# 时间线 2026-06-29 — 2.1.196 发布；报告者的“最后一个工作版本（我猜测）” 2026-06-30 — 2.1.197 发布；一个变更日志条目，十四行诗 5 启动 2026-07-01 — 2.1.198 发布 — 报告者将回归错误归咎于该版本。没有公开的提交显示更改；该版本的唯一公开痕迹是机器人提交发布其备注（75709ea），只涉及 CHANGELOG.md 和 feed.xml 2026-07-02 02:54 UTC — Aleksey Nogin 提交的 issue #73125 2026-07-02 03:45 UTC — 一位评论者提出了逃生舱：CLAUDE_AFK_TIMEOUT_MS。在该线程中进行点对点交易，而不是从任何发布说明中指出 2026-07-02 — 2.1.199 发布 24 条条目，而问题仍然开放。仍未提及。 2026-07-03 — 2.1.200 逆转了行为；同样唯一的公开痕迹是备注提交（1322e9b） 2026-07-04 18:04 UTC — 问题关闭 对该问题的反应/规模：384 👍，143 条评论 — 不是小问题 报告者的环境：2.1.198，“最后一个工作 2.1.196（猜测）”，Opus，AWS Bedrock，VS Code 终端 git clone https://github.com/anthropics/claude-code.git cd claude-code # 修复何时着陆，以及在哪个版本中？ git log -1 --format='%