前言¶

需求階段的文檔往往不是「不會寫」，而是「沒時間整理」。需求散在聊天記錄裏，概要設計要從需求分析裏再抄一遍，詳細設計又得把接口和數據結構重新對齊。等到評審前一晚，人們做的是把同一份信息複製四遍。

智能需求工坊（@user_1f5261c9/spec-craft）是一個交互式的需求分析與文檔生成工具，目標是把上述四份文檔放進同一條流程裏產出。下面介紹它的定位、能力、用法和邊界。

這是什麼¶

一句話定位：需求分析 → 需求設計 → 概要設計 → 詳細設計四類文檔的交互式生成工具。

• 出品方：發佈者 user_1f5261c9，來源標註爲 community。
• 版本：1.0.0。
• 分類：office-efficiency。
• 性質：SkillHub 上的通用 SKILL.md 格式 Skill，不需要 API key（標籤 requires_api_key=false）。

它解決的核心問題是：用戶手上有需求但還沒有結構化文檔時，先通過問答把關鍵信息補齊，再按內置模板輸出 markdown，減少從零起草的成本。

核心功能¶

1、觸發場景明確。當用戶需要進行需求分析、生成需求文檔、設計文檔、概要設計或詳細設計文檔時觸發。

2、支持四類文檔，且是四類不同的文檔，不是同一份模板的四個名字：

• 需求分析文檔
• 需求設計文檔
• 概要設計文檔
• 詳細設計文檔

3、工作模式是「智能推斷 + 精簡問答」。即先用已有信息推斷能確定的部分，只就缺失的關鍵信息提問，而不是完整訪談一輪。

4、輸出形態基於內置模板生成 markdown 文檔。

5、可引導用戶用 /docx skill 生成 docx 格式，也就是文檔生成完成後可以繼續轉成 Word，屬於協作鏈而非內置功能。

安裝與啓用¶

已抓取的官方資料（SkillHub 頁面與 API 記錄）中沒有給出安裝命令或目錄路徑，因此這裏不寫未經覈實的命令。

可以確認的配置項是標籤 requires_api_key=false，即使用前不需要申請或填入 API key。

啓用方式以官方頁面爲準：https://www.skillhub.cn/skills/user_1f5261c9/spec-craft

官方地址：https://api.skillhub.cn/user_1f5261c9/spec-craft

典型用法¶

資料給出的是觸發條件，而非完整可復現腳本，因此這裏按官方描述還原調用路徑。

直接用需求描述觸發：

幫我做一份需求分析文檔，需求是：一個內部報銷審批流程，需要支持多級審批和預算校驗。

需要概要設計時：

基於上面的需求生成概要設計文檔，給出模塊劃分和接口邊界。

需要詳細設計時：

繼續生成詳細設計文檔，包含數據結構和關鍵接口定義。

流程上是連續的：先在一次對話裏澄清需求，再按需要逐份生成文檔。生成結果是 markdown，需要交付 Word 時再調用 /docx skill 轉換。

適用場景與注意¶

適合：

• 個人或小團隊在項目啓動階段，需要把需求快速固化成結構化文檔。
• 需求已經大致清楚、但還沒有寫成文檔的場景，智能推斷可以減少提問輪次。
• 需要在同一輪流程裏產出需求分析與後續設計文檔的場景。

需要注意：

1、輸出質量取決於餵給它的需求描述。描述越具體，推斷出的結構越可用；只有一句「做個管理系統」時，推斷結果需要人工補齊。

2、四類文檔之間存在依賴關係。概要設計基於需求分析，詳細設計基於概要設計，跳躍生成容易出現前後不一致，建議按順序產出後人工通讀。

3、內置模板是固定結構，遇到公司自有的文檔規範（章節編號、評審記錄、變更歷史）時，需要自行調整，不要指望模板直接匹配。

4、當前資料顯示安裝量爲 0，屬於新發布的社區 Skill，遇到問題時沒有成熟的社區反饋可參考。

5、docx 生成依賴 /docx skill，需要確認該 Skill 已單獨啓用。

結尾¶

智能需求工坊的價值在於把需求到設計的四份文檔放進同一條問答流程，用智能推斷減少提問成本，用內置模板保證文檔結構完整。它不是需求管理工具，也不替代評審，適合作爲項目啓動階段的起草輔助。

官方地址：https://api.skillhub.cn/user_1f5261c9/spec-craft