前言¶

接到新任务时，原始需求常常是模糊、残缺、多目标混杂，甚至带着矛盾约束。直接开工容易做错方向；反过来，如果问得太细，又会把简单任务拖成长谈。下面介绍 requirement-analysis：它先对输入做预检和缺口分析，最多追问 2 轮，再输出可验收的需求单，并按本地已有资产决定是自己接、让用户选，还是拆成多任务分发。

这是什么¶

requirement-analysis 是一个基于通用 SKILL.md 格式的需求解析与分发 Skill，用于在新任务起始阶段把任意形态的原始需求收敛成标准需求单。官方页面显示版本 1.0.1，来源 community，分类 ai-agent，发布者 user_32a66f02，坐标 @user_32a66f02/requirement-analysis。

资料里存在一处地址冲突：任务线索给出的官方地址是 https://api.skillhub.cn/user_94a41d65/requirement-analysis，而可核实页面是 https://www.skillhub.cn/skills/user_32a66f02/requirement-analysis。本文以可核实页面为准。页面当前显示评分 100000、下载 22、安装 0；线索中提到的 99497 与 1364 未在页面核对到，不采信。

核心能力¶

输入预检¶

接收异常输入：模糊、残缺、多目标混杂、零信息、纯附件或链接、矛盾约束。预检的目的不是纠错，而是先判断这轮该出单、该追问，还是根本不适用。

五维缺口分析¶

按目标、预算、时间、平台、产品五个维度检查缺口。这五个维度来自官方简介；缺哪维就追问哪维，不展开无关问题。

分层追问¶

追问分两层：L1 定位问题，L2 收敛选项，最多 2 轮。若指令已经极清晰，直接出单，不再追问。

输出需求单¶

输出可量化、可验收的标准需求单。文档没有给出固定模板字段；可以把它理解为一份包含目标、约束、验收口径和分发结论的结构化清单。

候选召回与分发¶

清点本地 skill、agent、connector，召回 1–3 个候选，每个候选附一句话理由。分发规则如下：

1、只有 1 个候选，且没有不可逆声明，自动接棒。
2、候选不少于 2 个，列出清单让用户点选，不擅自决定。
3、候选为 0 时，按「是否需要专用资产」分流：不需要，直接处理，不检索市场；需要或判不准，检索市场给替代路径。

多任务拆解¶

多目标澄清后仍然并行，或任何单一资产都做不完时，产出 task_plan 多任务拆解清单。先让用户确认顺序，再逐项分发。

安装与启用¶

已核实资料没有给出安装命令、依赖或配置字段，也没有说明 Cursor、Codex CLI、Claude Code 的差异。Skill 本体是 SKILL.md，启用方式就是把该文件交给支持 SKILL.md 的编辑器或 agent 加载。

# 官方页面未提供安装命令与配置项；以 SKILL.md 加载为准

典型用法¶

下面用一个符合官方描述的零信息输入做示例。输入只有目标和一句模糊要求，预算、时间、平台、产品都缺。

输入：帮我搞个东西，能赚钱，越快越好，预算你定。

处理过程：

1、预检识别出目标可用性、时间、预算、平台、产品形态缺口。
2、L1 定位：先确认要做的是什么形态，是网站、移动应用，还是内部系统。
3、L2 收敛：把预算和时间压到可执行区间，并确认目标平台。
4、输出需求单：目标、预算区间、截止时间、平台、产品形态、验收口径。
5、清点本地 skill / agent / connector，召回 1–3 个候选；唯一且无不可逆声明则接棒，多个则列出待点选，为零则按是否需要专用资产分流。
6、若仍并行或单一资产做不完，产出 task_plan，用户确认顺序后逐项分发。

适用场景与注意¶

适合新任务起始阶段的需求澄清。指令已经极清晰时直接出单，不追问。问候、单步操作、纯事实查询不适用。

约束要记住：不打分、不臆造核心项、不静默结束、只推荐不代装。也就是说，它可以帮你把需求问清楚并给出路径，但不替代你确认验收标准，也不会未经确认就替用户安装或执行不可逆操作。

结尾¶

requirement-analysis 的价值不在写需求文档，而在新任务刚开始时快速识别缺口、控制追问轮次，并把后续路径分流清楚。可核实地址：https://www.skillhub.cn/skills/user_32a66f02/requirement-analysis；线索地址：https://api.skillhub.cn/user_94a41d65/requirement-analysis。