HOW I AI · 原始發表日期 2026 年 7 月 24 日模型評測不該只看第一輪
真正要測的是
它怎麼修正
How I AI 的 Opus 5 實作評測指出，能不能寫出第一版程式碼只是入口。可靠協作取決於模型收到具體回饋後，能否辨認問題、保留有效部分並完成修正。
來源：How I AI〈I hate Opus 5. It’s the best model, anyway.〉SCROLL ↓HOW I AI · 原始發表日期 2026 年 7 月 24 日How I AI 的 Opus 5 實作評測指出，能不能寫出第一版程式碼只是入口。可靠協作取決於模型收到具體回饋後，能否辨認問題、保留有效部分並完成修正。
來源：How I AI〈I hate Opus 5. It’s the best model, anyway.〉SCROLL ↓PART 1 · 不是每週一個排行榜
影片從一個熟悉的疲乏感開始：新模型、新基準和新宣稱不斷出現。這種節奏讓「哪個模型最好」看似是最重要的問題，但它很容易把評測縮成一張單次分數表。
作者採用的標準更接近真實開發工作。模型不只要接受任務，還要在限制、既有程式與失敗訊號之間工作。一次漂亮的輸出不能說明它在第二輪是否知道該改哪裡。
PART 2 · 第一版不是交付
程式任務常有兩個層次：表面上是否執行，以及它是否真的滿足使用者的規格。模型可能迅速生成一個看似合理的介面或功能，卻漏掉邊界條件、破壞原本的結構，或把需求理解成另一件事。
因此評測應把第一版當成可檢查的假設。測試、錯誤訊息與人類的具體評論不是「模型失敗後的補丁」，而是協作本身的一部分。
PART 3 · 修正能力比自信重要
影片的實作比較關注模型面對批評時的行為。有些系統會用更多文字解釋原本的選擇，卻沒有改到問題；有些會大幅重寫，反而刪掉已經可用的部分。較可靠的行為是把回饋對應到程式中的具體位置，再用最小但足夠的修改驗證。
這讓模型能力從「一次猜中」變成「是否能加入工程迴路」。對團隊而言，後者通常更有價值，因為需求本來就會逐步清楚。
PART 4 · 規格是共同語言
如果只說「做一個好看的頁面」或「修好這段程式」，模型只能用最常見的模式補空白。可檢查的規格則把工作變成可討論的對象：哪些功能必須存在、哪些行為不能改、怎樣算通過測試。
這不代表人要預先寫完所有答案。比較有效的方式是先寫出最重要的限制，讓模型產生中間結果，再把觀察到的差距回饋進下一輪。
PART 5 · 把模型放進可驗證的流程
影片沒有把任何模型描述成不需要檢查的代理人。即使某個模型在特定任務表現突出，使用者仍需要版本控制、測試、差異檢查與可以回復的變更範圍。
模型選型也應隨工作類型而變：探索、重構、除錯和長任務需要的能力不同。把任務、輸入、回饋和結果留下來，團隊才能知道工具在哪裡可靠，而不是只記得一次令人印象深刻的示範。
模型的第一份答案不是結論。它收到具體回饋後如何修正，才更接近真實協作能力。
本頁依 How I AI 的 Opus 5 實作評測整理；此句為本頁歸納，非逐字引述。這不是測驗。選擇你想先建立的協作控制點。