過去三十天，AI coding 圈發生了兩件大事。4 月 16 日，Anthropic 發表 Claude Opus 4.7，把 SWE-bench Pro 從原本的 53.4% 一口氣推到 64.3%，重新拿回 coding 王座。一個禮拜後的 4 月 23 日，OpenAI 反擊，發表 GPT-5.5，主打「最聰明、最直覺、最 agentic 的模型」，在自主完成任務、跨工具操作、長時間工作這幾項上明顯超越 GPT-5.4 與 Opus 4.7。
於是，5 月份整個 AI coding 圈的對話從「哪個模型寫程式比較準」變成「哪個模型可以真的自己跑完一個 Jira ticket」。對接案、外包、in-house 小團隊來說，這條線的移動會直接改變我們每天的工作分配方式。
一、SWE-bench Pro 64.3% 是什麼意思
SWE-bench Pro 是業界目前最嚴格的「真實 GitHub Issue 解決能力」指標——把真實開源專案的 issue 給模型，看它能不能自己讀 codebase、自己寫 patch、自己跑測試、自己驗證。Opus 4.7 拿到 64.3% 代表：
- 中等難度的 bug fix（單檔案、單元測試已存在），模型自己跑完不需要人工介入的成功率超過七成。
- 跨檔案、跨模組的 refactor，成功率落在五成附近——還不能 fire-and-forget，但 review 比手寫快很多。
- 加新 feature（要寫測試、要動 schema、要改 migration），成功率約三到四成——這一塊還是工程師的主場。
GPT-5.5 在 SWE-bench 上的數字接近，但在「跨工具操作」這一塊更強：自動開 PR、自動跑 CI、自動回覆 reviewer comment、自動修 lint。OpenAI 自家的測試是「給一個 Linear ticket，全自動跑到 PR merge」。
二、5 月份「可以正式外包給 AI」的工作清單
根據實際在生產環境跑這兩支模型一個月的工程主管們的回報，下面這些任務現在可以放心交給 AI agent，工程師只負責 review：
- 單元測試生成：給一個 class，產 80% coverage 的 unit test，連 edge case 都會列。
- API client SDK 包：給 OpenAPI spec，產 PHP / Dart / TypeScript client。
- Laravel migration 與 seeder：給 schema 描述，產 migration、factory、seeder，整套到位。
- Flutter UI 元件骨架：給設計稿截圖加幾句敘述，產 widget 樹（不含複雜業務邏輯）。
- 錯誤訊息 i18n：給 zh-TW 字串，全自動產 en、ja、ko、zh-CN 翻譯與對應 key。
- 舊版 deprecated API 升級：例如 Laravel 11 → 13、Flutter 3.27 → 3.41 的 API 替換。
- PR description 與 changelog 自動生成：從 commit history 推回 PR 描述、release note。
三、5 月份「還不能外包給 AI」的工作清單
下面這些，agent 可以幫你「加速」，但還不能讓它「替你下決定」：
- 資料庫 schema 設計：模型很會生 SQL，但不會問「這個業務場景真的需要 normalize 到 3NF 嗎」。
- 權限模型設計：RBAC、ABAC、tenant isolation 一旦做錯，後面改要動全棧。
- 金流串接：邊界條件太多（部分退款、訂閱降級、跨幣別、3DS 失敗），任何幻覺都會直接變客訴。
- 效能調校：模型可以幫你看 EXPLAIN，但「這條 query 該加索引還是改架構」要人判斷。
- 資安決策：CSP 設定、CORS 政策、JWT vs session 的取捨，AI 給的答案常常「技術正確但業務錯誤」。
四、新的工作流：AI-first，但 human-checkpoint 不能省
我們觀察到一個共通模式：成功用 agent 提升 2-3 倍產能的團隊，工作流大概長這樣：
- 工程主管寫 ticket——比過去更明確、更具體，包含 acceptance criteria 與 schema 影響範圍。
- AI agent 接 ticket——自動 branch、自動實作、自動寫測試、自動開 PR。
- 人類 reviewer 把守 3 個 checkpoint：
- schema/migration 是否合理（不只是能跑）
- 權限與資安邊界是否被破壞
- 效能 regression（query 數、payload 大小、bundle size）
平均一張票從接到 ready-for-review，時間從 4-8 小時壓到 30-60 分鐘。工程師的工作從「寫」變成「定義 + 把關」。
我的觀點
「AI 會不會搶工程師飯碗」這個問題在 2026 年已經沒有意義了。新的問題是：「你願不願意花一個月把你的 ticket、你的 PR template、你的 CI pipeline、你的 review checklist 全部重寫成 AI-friendly 的格式？」
不願意的團隊，會繼續用 2024 年的速度開發；願意的團隊，會在同樣的人力下接到兩倍的案子。差距會在今年下半年拉開到無法忽視。
選 GPT-5.5 還是 Claude Opus 4.7？我的實務建議：寫程式碼本身用 Opus 4.7，跑 agent workflow（跨工具、長任務、自動 PR）用 GPT-5.5，兩個都要。月費加起來不超過一個初級工程師一天的薪水。