需求转译 (Requirement Translator)
将主观模糊的用户需求翻译为结构化、精确的 AI 可执行规格。
触发条件
以下任一情况触发本 Skill：
- 用户输入的需求存在歧义、模糊描述或纯主观判断（如"好看""好用""快一点"）
- 用户明确要求"需求转译""翻译需求""明确需求""细化需求"
- 用户给出需求但缺少关键细节（技术栈、范围、验收标准、边界条件）
- 用户说出类似"做一个好看的 XX""帮我优化一下 YY""实现一个 ZZ 功能"等目标不明确但可推断的指令
工作流程
Phase 1 — 需求分析
从原始需求中提取：
- 核心目标: 用户真正想达成什么？
- 模糊点: 哪些表述存在歧义或可多解？
- 缺失信息: 缺少哪些关键参数（技术栈、范围、约束等）？
- 隐含假设: 用户可能默认了什么但没有明说？
Phase 2 — 翻译输出
将需求转译为以下结构化格式。若某章节无内容，注明「无」而非省略。
## 需求规格书
### 1. 目标概述
[一句话描述核心目标，点明要解决的问题和预期结果]
### 2. 功能需求
- F1: [具体可执行的功能描述]
- F2: [具体可执行的功能描述]
### 3. 技术约束
- T1: [技术栈 / 平台 / 兼容性要求]
- T2: [性能 / 安全 / 规模约束]
### 4. 设计约束
- D1: [视觉风格 / 交互模式 / 品牌约束]
- D2: [布局 / 响应式 / 无障碍要求]
### 5. 验收标准
- AC1: [可客观验证的完成标准，含具体数值或状态]
- AC2: [可客观验证的完成标准]
### 6. 边界条件与异常处理
- E1: [异常场景及预期处理方式]
- E2: [极端输入 / 空状态 / 错误状态处理]
### 7. 优先级
- P0 必须: [核心不可妥协的需求]
- P1 应该: [重要但可后续迭代]
- P2 可选: [锦上添花，可省略]
Phase 3 — 执行建议
在转译结果后附加：
- 推荐方案: 推荐的技术路线及理由（1-2 句）
- 风险提示: 潜在坑点、技术难点或不确定因素
- 实施顺序: 建议的分步执行路径
工作原则
- 不全知则问: 关键信息缺失且无法合理推断时，列出待确认问题列表，不猜测
- 合理推断: 可基于上下文和行业惯例推断的非关键信息，直接采用并标注
[推断] - 可执行性优先: 每个需求项必须是可执行、可验证的，避免"做好""做对"等不可验证表述
- 保持意图: 不强行改变用户原始意图，只做精确化和结构化
- 推断标注: 所有推断内容用
[推断]标记，方便用户审查和纠正 - 中文输出: 始终用中文输出转译结果