前言¶
給 Agent 接一個「幫我找幾本穿越文」的需求，多數實現只能做兩件事之一：要麼靠內置知識庫裏那幾十本常見書硬湊，要麼把用戶引到某個單一書站去搜。前者書單和當前連載狀態脫節，後者丟掉了「跨平臺比對口碑」這個核心動作。書荒拯救者走的是另一條路：把檢索範圍攤到網文站和傳統文學書單兩類來源，再把書名、評分、簡介、讀者評價、閱讀鏈接整理成一份可直接看的推薦方案。
下面介紹這個 Skill 的定位、能力和啓用方式。
這是什麼¶
書荒拯救者是一個小說推薦助手 Skill，輸入想看的小說類型或偏好，它會全平臺搜索並生成推薦方案。座標爲 @user_66f29720/a-savior-of-book-drought，版本 1.0.0，由 user_66f29720 發佈，來源標記爲 community，分類屬於 knowledge-management。它解決的是「用戶表達不清、來源又分散」的找書問題：用戶只需說一句類型偏好或一個模糊方向，Skill 負責跨平臺取數並收斂成清單。
核心功能¶
- 按小說類型或偏好做檢索，而不是按固定書名列表回答。
- 跨平臺搜索，同時覆蓋網文與傳統文學兩側。
- 輸出結構化推薦方案，每項包含書名、評分、簡介、讀者評價和閱讀鏈接。
- 在用戶沒有給出明確類型時，通過觸發詞識別找書意圖並主動追問偏好。
觸發詞爲：推薦小說、書荒、找小說、想看小說、novel、book、推書、求書單、小說推薦。
覆蓋範圍與信息字段¶
來源分兩類，這一點值得先看清，因爲它直接決定書單的可信度邊界。
網文側覆蓋起點、番茄、七貓，這類來源的優勢是書目全、連載狀態新，評分和評價更貼近當前在讀人羣。傳統文學側覆蓋豆瓣和知乎書單，這類來源的優勢是長評和口碑沉澱，適合判斷一本書是否經得起長期評價。
輸出字段固定爲五項：書名、評分、簡介、讀者評價、閱讀鏈接。評分來自各平臺的展示值，並非統一換算到同一量表，跨平臺直接比較分數時需要留意這一點。
安裝與啓用¶
資料中未給出獨立的安裝命令、npm 包名或配置文件字段。從 SkillHub 頁面看，requires_api_key=false，即啓用不需要額外申請 API Key。
獲取路徑：
SkillHub 頁面：https://www.skillhub.cn/skills/user_66f29720/a-savior-of-book-drought
API 端點：https://api.skillhub.cn/user_66f29720/a-savior-of-book-drought
在支持通用 SKILL.md 格式的 Agent 環境中，按上述座標引入後，觸發詞即可被識別。Cursor、Codex CLI、Claude Code 之間的安裝命令差異，資料中沒有對應說明，這裏不做推測。
頁面指標：評分 100000，下載 914 次，安裝 0 次。
典型用法¶
官方簡介給出的用法是「輸入想看的小說類型或偏好」，所以最直接的復現方式是用觸發詞發起請求。
輸入示例：
推薦小說，穿越架空類，不要太長，最近完結的最好
書荒，想看科幻，帶點懸疑的
novel，類似無限流但節奏慢一點的
預期輸出是一份推薦方案，每本書給出書名、評分、簡介、讀者評價和閱讀鏈接。第三個示例是模糊偏好，需要 Skill 先識別爲找書意圖，再根據「無限流」「節奏慢」這兩個約束去收斂範圍。
適用場景與注意¶
適合的場景：
- 用戶表達的是類型、題材、情緒或篇幅偏好，而不是具體書名。
- 需要同時參考網文站熱度和傳統文學口碑。
- 希望拿到能直接跳轉的閱讀鏈接，而不是隻拿到書名清單。
需要注意的地方：
- 評分跨平臺不可直接比大小。起點、番茄、七貓的評分體系與豆瓣不同，同一分數在兩個平臺上的含義差別很大，輸出時應保留來源標籤。
- 讀者評價是平臺側展示內容，質量取決於各站點的評論環境，知乎書單的評價尤其依賴單條長評，樣本量天然較小。
- 閱讀鏈接指向各平臺原站，部分平臺對未登錄用戶有章節限制，這不是 Skill 能控制的。
- 下載量爲 914、安裝爲 0，社區驗證還不夠充分，接入前建議先用一組真實偏好跑一遍，確認輸出結構符合預期。
結尾¶
書荒拯救者的價值在於把「找書」這件事從單站搜索升級爲跨平臺收斂：用戶只需要說一句偏好，剩下的檢索、比對、字段整理都由 Skill 完成。它的覆蓋面比內置書單廣，但評分和評價的可比性需要使用者自己把關。
官方地址：https://api.skillhub.cn/user_66f29720/a-savior-of-book-drought
