為什麼 coding agent 依然很笨：模型在進步，agent 卻拖後腿
一位開發者認為 AI 程式設計的瓶頸是 agent 而不是模型：模型生成程式碼的能力持續提升，agent 卻停在原地。他區分了模型（GPT Astra、Claude Sonnet、GLM-5.3）與 agent（Claude Code、Codex），並列舉四類問題：OpenCode 把約 1.5k 行的改動拆成 10 個子任務卻逐個序列執行；agent 不會按任務難度切換更便宜或更強的模型；Claude Code 說不清自身功能，只能聯網搜尋；Plan 模式產出的計劃零散、難讀。
以 1.5k 行改動被拆成 10 個序列子任務、需聯網查自己功能等具體例項，指出 agent 在並行、委派與計劃表達上的短板，對 Claude Code、Codex、OpenCode 的使用者有參考價值。
原標題：Why Are Coding Agents So Dumb?
閱讀原文
| 評分 | 55 / 58（平均 56，門檻 76） |
|---|---|
| 狀態 | 未入選 |
相關報導
開發者稱用 Claude Code 後不再手寫程式碼
一位寫了 18 年程式碼的開發者表示，自去年在 Claude Code 中使用 Opus 4.5 後，用自然語言描述需求比手寫程式碼更快，於是徹底停止了手寫程式碼。他所在的 Filestage 團隊月合併 PR 從約 200 增至 300，bug 報告未增加，每位開發者每月 AI 訂閱費 20 美元，工具可自選 Codex、Claude Code 或 Cursor。
AI 程式設計模型集體滿口黑話：思維鏈壓縮省 70% Token
量子位發文吐槽，Fable、Sol 等與 Coding 沾邊的模型普遍輸出「15/15 全綠」「單腿啞火」這類黑話。文中分析，除 Coding 過擬合外，更主要的原因是廠商為省 Token 把思維鏈壓縮成「穴居人語」，OpenAI 最早這麼做，同樣一句話的 Token 消耗比白話文少 70%；Claude 自 Opus 4.6 起也開始如此。作者稱最新 Opus 5.5 語言能力回升明顯，而 Gemini 因輸出風格正常、排版層級清晰，被社群視為少數還能正常溝通的 AI。
研究：AI 程式設計代理生成更多程式碼，軟體產出未增加
哈佛大學研究者在 700 多家公司、70 萬名員工、3 億條工作事件的資料中發現，AI 程式設計工具並未讓企業軟體產出增加或減少用人，編碼階段省下的時間被下游環節吸收。程式碼審查時長明顯增加，pull request 更常需要返工，審查者留下的評論也更多。研究據此認為人工程式碼審查是 AI 編碼效率的主要瓶頸。
Claude Code 新增建議訊息功能，作者稱真正客戶是模型
Claude Code 會在任務完成後於輸入框預填一條建議的下一條訊息，例如 run the tests 或 commit this，使用者可直接傳送或先行編輯。作者認為該功能的真正受益方是模型：原樣傳送等於正樣本，編輯後的原文與改後版本構成偏好對，diff 顯示出預測錯在哪裡，從而在使用者正常工作中低成本產出 RLHF 所需資料，且來自真實程式碼庫而非合成基準。作者同時宣告這只是猜測，Anthropic 如何使用該訊號、會話是否用於訓練取決於套餐與隱私設定。
Claude Code 發布 v2.1.288 修復大量會話與外掛問題
Claude Code 更新至 v2.1.288，修復了長對話因「Prompt is too long」而不自動壓縮、--resume 丟失檔案與上下文、恢復會話時丟失模型思考內容等問題。新增 Ctrl+C 清空提示後按上鍵恢復草稿、/code-review 的 --max-findings 引數、MCP 伺服器請求更多 OAuth 權限時重新認證提示，以及 agents 檢視的 Ctrl+F 查詢與 Alt+↑/↓ 分組跳轉。