Claude Opus 4.7 最適合咩工作？幾時值得用、幾時唔使急住轉

相反，如果只係普通問答、短文潤飾、簡單資料抽取，或者低風險 brainstorming，Opus 4.7 未必係最有理據嘅預設選擇。唔係話佢做唔到，而係「用更高階模型」嘅收益，通常要喺多步驟、易出錯、要求高一致性嘅工作入面先最明顯。

1. 大型程式碼庫同專業軟件工程

進階 coding 係 Opus 4.7 最清晰嘅定位之一。Anthropic 形容 Opus 4.7 面向專業軟件工程，重點包括較大型 codebase、生產級程式碼，以及相比 Opus 4.6 更複雜、持續時間更長嘅 coding 任務。

所以，評估 Opus 4.7 唔應該只靠一條 coding puzzle。更實際嘅做法，是用自己公司或團隊嘅 repo 測試：

• 跨多個檔案加入新功能
• 修復難重現 bug
• 做 refactor 而唔破壞既有行為
• 產生或修補測試
• 做 code review
• 在 coding-agent loop 入面多輪修改

重點唔係佢可唔可以即場寫一段順眼嘅 snippet，而係佢能唔能夠喺好多細決定之間維持正確性。

2. 長流程 Agent 同自動化工作

Anthropic 亦將 Opus 4.7 放喺長流程 Agent 工作入面，包括多步驟 workflow、工具使用，以及需要大量記憶或上下文嘅任務。 呢類 Agent 可能要先檢查資料、呼叫工具、修正計劃、處理中途失敗，最後再交付一份可用成果。

但 Agent 愈自主，愈要有護欄。特別係重要流程，最好一開始就定清楚：

• 成功標準係咩
• 每次 tool call 點記錄
• 常見 failure mode 點追蹤
• 邊啲高影響操作一定要人手覆核

換句話講，Opus 4.7 可以係強候選，但唔代表可以放任佢無監督地改系統、改資料、改生產環境。

3. 企業知識工作：重點係交付物，而唔係摘要表演

Anthropic 表示 Opus 4.7 面向高風險企業任務同專業知識工作，包括複雜、可跨多日嘅項目，以及 spreadsheet、slides、documents 等輸出。

企業場景入面，最好用「交付物」來測試，而唔係只叫模型總結一份文件。較貼近實戰嘅測試包括：

• 整合大量文件後產生可用 briefing
• 保持項目歷史同早前決策一致
• 將研究材料轉成商業簡報、表格或文件
• 比對不同資料來源入面嘅矛盾
• 在多輪修改後仍保留原本限制同目標

簡單摘要通常太窄，未必測到 Opus 4.7 呢類長流程模型定位最關鍵嘅地方。

4. 視覺、記憶同長上下文分析

Anthropic 表示 Opus 4.7 相比 Opus 4.6 有更好嘅視覺能力，支援更高解像度嘅圖像理解；早期測試者亦提到佢可用於閱讀技術圖表同化學結構。 Anthropic 嘅遷移指南亦點名知識工作、視覺任務同記憶任務，並指 Claude Opus 4.7 支援 100 萬 token 上下文視窗。

呢個定位指向一批比較專業嘅使用場景，例如：

• 技術圖、系統架構圖、流程圖
• screenshot 入面嘅細節分析
• chart、schematic、科學圖像
• 很長嘅項目紀錄
• 政策文件集、合約集、研究 dossier

較強嘅 use case 唔係「幫張相加句 caption」，而係圖像或長上下文理解會影響下一步決策嘅工作。

5. 合法網絡安全工作：可以用，但界線要清楚

網絡安全係一個真實但較窄嘅場景。Anthropic 表示 Opus 4.7 可支援合法安全工作，例如漏洞研究、滲透測試同 red-teaming；同時亦表示系統有防護措施，會阻擋被禁止或高風險嘅網絡用途，而部分合法安全 use case 亦可能需要驗證。

對安全團隊來講，較穩陣嘅定位係「受監督、獲授權嘅輔助」：協助 triage、分析、寫 documentation、在已批准範圍內測試。唔應該將佢當成無限制 offensive automation。

邊啲情況未必需要 Opus 4.7？

按 Anthropic 對 Opus 4.7 嘅定位，以下工作較難證明一定要用佢做預設：

• 日常 Q&A 或普通聊天
• 短文 copy edit
• 低風險 brainstorming
• 小型輸入入面嘅簡單資料抽取
• 大量、標準化、但未量度到明顯質素提升嘅流程
• 無人覆核、但會作出高影響改動嘅自動化

最安全做法，是先用自己真實樣本同現有模型並排測試，而唔係睇完產品定位就全面轉用。

開發者 API 遷移要留意

如果你打算將 API workload 轉到 Opus 4.7，唔好直接假設可以無痛 drop-in replacement。Anthropic 嘅遷移指南指出，Claude Opus 4.7 已不再支援舊式 extended-thinking budget_tokens 設定；使用該設定嘅 request 會回傳 400 error，指南要求遷移至 adaptive thinking。

同一份指南亦表示，如果團隊使用 max 或 xhigh effort，應設定較大嘅 max_tokens 輸出 budget；同時，Claude Opus 4.7 使用更新嘅 tokenizer。 因此，遷移時要重新檢查 token count、輸出 budget 同 regression test，唔好只沿用 Opus 4.6 時代嘅設定。

推出前點樣測試？

唔好只睇 demo，要用真實工作樣本。較實用嘅測試計劃可以包括：

• Coding： 多檔案修改、修復 failing tests、refactor、code review、是否跟到 repo 既有慣例。
• Agent： tool-call 準確度、工具失敗後能否恢復、會否修正計劃、完成率、需要人手介入嘅位置。
• 企業工作： 多文件之間嘅事實一致性、spreadsheet 或 slide 輸出質素、最終交付物是否可直接使用。
• 視覺： 技術圖、screenshot、chart、schematic 或科學圖像；尤其係細節會影響判斷嘅情況。
• 安全： 是否在授權範圍內、是否符合政策、audit log 是否足夠，以及是否涉及任何驗證要求。

結論

Claude Opus 4.7 最有理據用喺一類工作：推理、上下文、工具使用同輸出質素，需要喺多個步驟之間一齊保持穩定。最值得首先試嘅場景，包括進階軟件工程、長流程 Agent、企業文件整合同交付物、技術視覺分析，以及長上下文或記憶密集型任務。

至於日常工作，現有資料未足以證明 Opus 4.7 應該成為所有 prompt 嘅預設。比較務實嘅做法，是將 Anthropic 嘅定位當成 shortlist，然後用自己嘅 codebase、文件、圖片、工具鏈同審核流程做 side-by-side 評估。