需求锻造

解决的需求痛点

很多团队启动新特性时，常面临需求模糊的困境：老板一句“做个会员中心”、产品经理一句“加个搜索功能”，模糊想法未结构化就直接进入开发，结果要么验收标准混乱，要么需求反复修改，甚至代码-review时才发现缺失项或冲突。这种“口头需求直接驱动开发”的模式，是导致项目延期、返工的常见原因。

核心能力与工作逻辑

需求锻造 以“需求工程师”为角色定位，核心是把模糊想法结构化为可落地的需求工件，核心能力包括：拆解用户故事与验收标准、用EARS格式生成功能需求、输出标准化FeatureSpec。

关键工作流分5步：

• 步骤1明确目标：对齐“解决什么问题、给谁用”，避免需求偏离核心；
• 步骤2工作坊拆解：将模糊想法拆为具体用户故事，同步定义验收标准；
• 步骤3需求化：用EARS规范将用户故事转化为功能需求；
• 步骤4自检：核对需求的可测性、缺失项与逻辑冲突；
• 步骤5输出工件：返回结构化FeatureSpec，包含feature、stories、requirements、acceptance等字段。

互操作上，支持接收自然语言需求、约束或（可选）代码片段输入，也可对已有FeatureSpec做二次优化；输出的FeatureSpec可直接下游消费，交接给code-reviewer或对应开发skill实现。

适用边界与注意点

该技能聚焦需求结构化与规范化，不适用于纯技术实现细节（如算法优化、性能调优等），这类场景需搭配对应的开发专家技能；同时，它不替代业务方对需求价值的判断，仅负责将需求“结构化”，而非决定“要不要做”。