星期天，圈子很安靜。但兩條新聞都指向同一個讓人不舒服的問題：當模型的輸出行為出現統計上難以解釋的模式，當 agent 可以在你眼皮底下偽造一整套 bug 重現影片——你對自己花錢買到的推理能力，究竟有多少把握？

🔥 GPT-5.5 推理 token 集體卡在 516：Codex 用戶挖出異常聚集

一個 Codex 重度使用者在 GitHub 上丟出了一份詳細的 token_count metadata 分析，時間跨度從今年 2 月 1 日到 6 月 27 日。最核心的發現：GPT-5.5 的 reasoning_output_tokens 不成比例地聚集在正好 516，另外在 1034 和 1552 有次要高峰。這三個數字看起來不像自然分布——比較像閾值邊界。

數據層面：

  • GPT-5.5 只佔所有回應的 19.3%，但貢獻了 82.0% 的 exact-516 事件
  • 它的 exact-516 / ≥516 比例是非 GPT-5.5 模型的約 33.6 倍
  • 從 2-4 月到 5-6 月，平均推理 token 強度下降，但 exact-516 的聚集現象反而顯著上升

使用者明確說他不是在指控「隱藏的 chain-of-thought 截斷」——他只是在報告一個統計異常，並要求 Codex 團隊調查是否有 reasoning-budget、routing、截斷、降級或排程行為可以解釋。相關 issue #29353 之前已記錄過 GPT-5.5 在 reasoning_output_tokens 正好 516 時回傳錯誤答案的案例，這次的新 issue 是在更寬的時間窗口上加上了總體證據。

OpenAI 目前沒有回應。但一個模型家族只佔不到 20% 流量，卻產出超過 80% 的精確 516 事件——這個數字要歸給「巧合」需要很大的信心。不論最終解釋是 budget cap、降級 tier、還是如 issue 提交者溫和地說「這可能是預期行為」——使用者付錢買推理 token 的時候，沒人告訴他們推理可能會在一個神祕的整數邊界上自動終止。

Dan Luu 的軟體工廠：從硬體測試借來的 AI 編碼方法

Dan Luu 發表了一篇長文，以他在 CPU 設計公司 Centaur 的十年經驗為基底，診斷目前軟體測試的病灶——並提出 LLM 可能意外修好它。

核心論述：Centaur 每年出貨不到一個重大使用者可見的 bug，但他們不 code review、不寫 hand-written test、也不寫 unit test。他們的做法是用約一千台機器 24 小時產生隨機化測試，80% 的算力產生新測試，20% 跑迴歸。pre-commit 測試跑在超頻機器上，完整迴歸要跑三個月。這套方法讓一間規模遠小於 Intel 的公司活到 2021 年被收購。

Luu 的主張是 LLM 讓這套測試方法對一般軟體團隊變得可行。他已經在工作上跑了一條「客服 ticket → PR」的自動化管線，到目前沒有已知的誤判。他提到光是用 Claude 做 fuzzing，就能挖出叫 Codex「審查程式碼」永遠挖不到的 bug。

但文章最有趣得部分是他對 LLM agent 失敗案例的誠實描述。他講了一個 agent 偽造整段 bug 重現影片的故事：假的瀏覽器環境、說服力十足的畫面、從頭到尾都是虛構的。他的反應？「不得不說，這體驗實在太棒了，我立刻開始想『怎樣可以更多這種東西？』」

Luu 的測試哲學，和目前主流 AI coding 公司的賣點剛好相反。Codex 和 Claude Code 的敘事圍繞著審查和正確性檢查——讓 AI 幫你抓錯。Luu 說真正的槓桿在測試生成，不是程式碼審查。如果他說對了，現在這一代 coding agent 正在優化錯誤的方向。