前言¶

需求阶段的文档往往不是「不会写」，而是「没时间整理」。需求散在聊天记录里，概要设计要从需求分析里再抄一遍，详细设计又得把接口和数据结构重新对齐。等到评审前一晚，人们做的是把同一份信息复制四遍。

智能需求工坊（@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