何時使用: 你找到無付費牆的文章、文件頁面或部落格文章,想要摘要和意見但不想自己讀。
步驟
-
以 Markdown 輸出方式取得
取得 https://example.com/blog/post 並給我前約 3000 字元的乾淨 Markdown。✓ 已複製
→ 內容到達時標題正常且沒有導航垃圾
-
摘要並提取重點
用 5 點摘要。列出作者提到的任何具體數字或主張,並附上他們出現的句子。✓ 已複製
→ 有項目符號的摘要加上引用,不是意譯
-
批評
→ 真實的批評,不是「另一方面...」那種模棱兩可的東西
結果: 30 秒內有用地讀完文章,包含可驗證的引用。
注意事項
- 網頁是 JS 渲染的,取得返回幾乎空的 shell — 先檢查第一次取得的輸出 — 如果看起來短得離譜或寫著「Loading...」,切換到 Firecrawl 或 Chrome DevTools MCP
- 長網頁被 max_length 截斷 — 使用
start_index 分頁:第二次呼叫時設 start_index: 5000 從第一次的結束處繼續
何時使用: 你依賴的函式庫在靜態頁面發佈發佈備註,已經一個月沒檢查了。
步驟
-
取得變更紀錄頁面
取得 https://vendor.com/changelog 並列出自 2026-03-01 以來的每個發佈,包含日期和該版本改動的單行摘要。✓ 已複製
→ 按時間順序排列的清單,附上日期
-
按影響分類
將每個分類為:破壞性改動、新功能、bug 修復、內部。標記任何標示為破壞性或已棄用的項目。✓ 已複製
→ 每個發佈都有標籤,破壞性項目都被標記
-
指出對我們的影響
我們主要用這個函式庫來實現 <功能 X>。這些改動中哪些影響我們的使用,以及我們應該採取什麼行動(如果有的話)?✓ 已複製
→ 可行動的清單,不是籠統的「檢查備註」
結果: 2 分鐘內知道你是否需要更新版本並測試,或者完全跳過這個發佈。
注意事項
- 變更紀錄分頁 — 首頁只有最近 2 個月 — 用
start_index 捲動或明確取得存檔 URL - GitHub 發佈頁面現在透過 JS 渲染 — 改用原始 API:
https://api.github.com/repos/owner/repo/releases 回傳 JSON 不需要 JS
何時使用: 你在針對公開規範編寫程式碼(OAuth、RFC 9457 問題詳情、REST API 參考文件),希望 Claude 有權威來源。
步驟
-
取得規範頁面
取得 https://datatracker.ietf.org/doc/html/rfc9457 為 Markdown。只回傳第 1-4 節。✓ 已複製
→ 規範性章節的乾淨 Markdown
-
根據它實作
以那份 RFC 為真理來源,寫給我 TypeScript 型別加驗證器用於問題詳情物件。在註解中引用具體的節號。✓ 已複製
→ 含有內聯 // per RFC 9457 §3.1 引用的程式碼
-
邊界情況檢查
根據同一份 RFC,我的實作沒有處理哪些邊界情況或可選欄位?決定是否要處理或記錄選擇。✓ 已複製
→ 針對規範的誠實缺口分析
結果: 一個忠實於規範的實作,具有可在代碼審查中舉證的可追蹤引用。
注意事項
- IETF 頁面很大 — 整份 RFC 可能超過上下文預算 — 只用錨點連結或 start_index 取得你需要的章節,不要取全份文件