prompt-optimizer

提示词优化器

概述

使用 EARS（需求语法简易方法）将模糊的提示词优化为精确、可执行的规范。EARS 是一种劳斯莱斯级的方法，可将自然语言转换为结构化、可测试的需求。

方法论灵感来源： 本技能将 EARS 与领域理论结合的方法，灵感来自 阿星AI工作室 (A-Xing AI Studio)，该工作室展示了 EARS 在提示词增强方面的实际应用。

四层增强流程：

1. EARS 语法转换 - 将描述性语言转换为规范性要求
2. 领域理论落地 - 应用相关行业框架（GTD、BJ Fogg、格式塔等）
3. 示例提取 - 提供包含真实数据的具体用例
4. 结构化提示词生成 - 使用角色/技能/工作流/示例/格式框架进行组织

适用场景

适用于：

• 用户提供了模糊的功能请求（“构建一个仪表盘”“创建一款提醒应用”）
• 需求缺少具体条件、触发因素或可衡量的结果
• 需要将自然语言描述转换为可测试的规范
• 用户明确请求优化提示词或细化需求

六步优化工作流

第 1 步：分析原始需求

找出不足之处：

• 范围过广 - “添加用户身份验证” → 缺少密码要求和会话管理
• 缺少触发条件 - “发送通知” → 缺少通知的触发时间和原因
• 操作含糊 - “让它更易于使用” → 没有可衡量的易用性标准
• 没有约束 - “处理付款” → 缺少安全与合规要求

第 2 步：应用 EARS 转换

将需求转换为 EARS 模式。完整语法规则请参阅 references/ears_syntax.md。

五种核心模式：

1. 通用模式：The system shall <action>
2. 事件驱动模式：When <trigger>, the system shall <action>
3. 状态驱动模式：While <state>, the system shall <action>
4. 条件模式：If <condition>, the system shall <action>
5. 非预期行为模式：If <condition>, the system shall prevent <unwanted action>

快速示例：

Before: "Create a reminder app with task management"

After (EARS):
1. When user creates a task, the system shall guide decomposition into executable sub-tasks
2. When task deadline is within 30 minutes AND user has not started, the system shall send notification with sound alert
3. When user completes a sub-task, the system shall update progress and provide positive feedback

转换检查清单：

• 找出隐含条件并明确说明
• 指定触发事件或状态
• 使用精确的动作动词（应当、必须、应该）
• 添加可衡量的标准（“30 分钟内”“至少 8 个字符”）
• 将复合需求拆分为原子化陈述
• 删除含糊的措辞（“易于使用”“快速”）

第 3 步：识别领域理论

将需求与成熟框架相匹配。完整目录请参阅 references/domain_theories.md。

常见领域映射：

• 生产力 → GTD、番茄工作法、艾森豪威尔矩阵
• 行为改变 → BJ Fogg 模型（B=MAT）、原子习惯
• UX 设计 → 希克定律、菲茨定律、格式塔原则
• 安全 → 零信任、纵深防御、隐私设计

选择流程：

1. 根据需求关键词识别主要领域
2. 匹配 2-4 个互补理论
3. 将理论原则应用于具体功能
4. 在增强后的提示词中引用理论，以增强可信度

第 4 步：提取具体示例

生成包含真实数据的具体示例：

• 用户场景：“当用户在移动设备上登录时……”
• 数据示例：“产品：‘笔记本电脑’，价格：$999，库存：15”
• 工作流示例：“任务：撰写报告 → 子任务：调研（2 小时）、起草（3 小时）、编辑（1 小时）”

示例必须真实可信、具体、多样（成功、错误和边界情况）且可测试。

第 5 步：生成增强提示词

使用标准框架组织：

# Role
[Specific expert role with domain expertise]

## Skills
- [Core capability 1]
- [Core capability 2]
[List 5-8 skills aligned with domain theories]

## Workflows
1. [Phase 1] - [Key activities]
2. [Phase 2] - [Key activities]
[Complete step-by-step process]

## Examples
[Concrete examples with real data, not placeholders]

## Formats
[Precise output specifications:
- File types, structure requirements
- Design/styling expectations
- Technical constraints
- Deliverable checklist]

质量标准：

• 角色具体性：“专注于时间管理应用的产品设计师” > “设计师”
• 理论依据：明确引用框架
• 可执行的工作流：明确输入、输出和决策点
• 具体示例：使用真实数据，而非“示例 1”“示例 2”
• 可衡量的格式：提出具体要求，而非“设计良好”

第 6 步：呈现优化结果

按结构化格式输出：

## Original Requirement
[User's vague requirement]

**Identified Issues:**
- [Issue 1: e.g., "Lacks specific trigger conditions"]
- [Issue 2: e.g., "No measurable success criteria"]

## EARS Transformation
[Numbered list of EARS-formatted requirements]

## Domain & Theories
**Primary Domain:** [e.g., Authentication Security]

**Applicable Theories:**
- **[Theory 1]** - [Brief relevance]
- **[Theory 2]** - [Brief relevance]

## Enhanced Prompt
[Complete Role/Skills/Workflows/Examples/Formats prompt]

---

**How to use:**
[Brief guidance on applying the prompt]

高级技巧

复杂场景请参阅 references/advanced_techniques.md：

• 多方利益相关者需求——为每种用户类型编写 EARS 陈述
• 非功能需求——为性能、安全性和可扩展性设定量化阈值
• 复杂条件逻辑——使用布尔运算符编写嵌套条件

快速参考

建议： ✅ 拆分复合需求（每项需求对应一条 EARS 陈述） ✅ 明确可衡量的标准（数字、时间范围、百分比） ✅ 包含错误和边界情况 ✅ 以成熟理论为依据 ✅ 使用包含真实数据的具体示例

避免： ❌ 避免模糊表述（“快速”“用户友好”） ❌ 不要假设读者掌握隐含知识 ❌ 不要在一条陈述中混合多个操作 ❌ 不要在示例中使用占位符

资源

按需加载以下参考文件：

• references/ears_syntax.md——完整的 EARS 语法规则、全部 5 种模式、转换指南和优点
• references/domain_theories.md——映射到 10 个领域（生产力、UX、游戏化、学习、电子商务、安全等）的 40 多种理论
• references/examples.md——四个完整的转换示例（拖延症应用、电子商务产品页面、学习仪表板、密码重置安全），包含转换前后对比和可复用模板
• references/advanced_techniques.md——多方利益相关者需求、非功能规格和复杂条件逻辑模式

何时加载参考文件：

• 需要澄清 EARS 语法 → ears_syntax.md
• 需要从大量选项中选择领域理论 → domain_theories.md
• 用户要求提供多个优化示例 → examples.md
• 需求复杂，涉及多方利益相关者或非功能规格 → advanced_techniques.md