Back to Details

prompt-optimizer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Prompt Optimizer

提示词优化器

Overview

概述

Optimize vague prompts into precise, actionable specifications using EARS (Easy Approach to Requirements Syntax) - a Rolls-Royce methodology for transforming natural language into structured, testable requirements.
Methodology inspired by: This skill's approach to combining EARS with domain theory grounding was inspired by 阿星AI工作室 (A-Xing AI Studio), which demonstrated practical EARS application for prompt enhancement.
Four-layer enhancement process:
  1. EARS syntax transformation - Convert descriptive language to normative specifications
  2. Domain theory grounding - Apply relevant industry frameworks (GTD, BJ Fogg, Gestalt, etc.)
  3. Example extraction - Surface concrete use cases with real data
  4. Structured prompt generation - Format using Role/Skills/Workflows/Examples/Formats framework
使用EARS（Easy Approach to Requirements Syntax）——这一将自然语言转换为结构化、可测试需求的顶级方法论，将模糊的提示词优化为精确、可执行的规范。
方法论灵感来源：本技能将EARS与领域理论结合的方法灵感来自阿星AI工作室 (A-Xing AI Studio)，该工作室展示了EARS在提示词优化中的实际应用。
四层增强流程：
  1. EARS语法转换 - 将描述性语言转换为规范性规格说明
  2. 领域理论落地 - 应用相关行业框架（GTD、BJ Fogg、格式塔等）
  3. 示例提取 - 结合真实数据呈现具体用例
  4. 结构化提示词生成 - 使用角色/技能/工作流/示例/格式框架进行格式化

When to Use

使用场景

Apply when:
  • User provides vague feature requests ("build a dashboard", "create a reminder app")
  • Requirements lack specific conditions, triggers, or measurable outcomes
  • Natural language descriptions need conversion to testable specifications
  • User explicitly requests prompt optimization or requirement refinement
适用于以下情况：
  • 用户提供模糊的功能请求（如“构建一个仪表盘”“创建一个提醒应用”）
  • 需求缺少特定条件、触发机制或可衡量的结果
  • 需要将自然语言描述转换为可测试的规格说明
  • 用户明确请求提示词优化或需求细化

Six-Step Optimization Workflow

六步优化工作流

Step 1: Analyze Original Requirement

步骤1：分析原始需求

Identify weaknesses:
  • Overly broad - "Add user authentication" → Missing password requirements, session management
  • Missing triggers - "Send notifications" → Missing when/why notifications trigger
  • Ambiguous actions - "Make it user-friendly" → No measurable usability criteria
  • No constraints - "Process payments" → Missing security, compliance requirements
识别不足之处：
  • 过于宽泛 - “添加用户认证” → 缺少密码要求、会话管理相关内容
  • 缺少触发机制 - “发送通知” → 未说明通知触发的时间/原因
  • 动作模糊 - “让它对用户友好” → 没有可衡量的可用性标准
  • 无约束条件 - “处理支付” → 缺少安全、合规要求

Step 2: Apply EARS Transformation

步骤2：应用EARS转换

Convert requirements to EARS patterns. See 
references/ears_syntax.md
for complete syntax rules.
Five core patterns:
  1. Ubiquitous: 
    The system shall <action>
  2. Event-driven: 
    When <trigger>, the system shall <action>
  3. State-driven: 
    While <state>, the system shall <action>
  4. Conditional: 
    If <condition>, the system shall <action>
  5. Unwanted behavior: 
    If <condition>, the system shall prevent <unwanted action>
Quick example:
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
Transformation checklist:
  • Identify implicit conditions and make explicit
  • Specify triggering events or states
  • Use precise action verbs (shall, must, should)
  • Add measurable criteria ("within 30 minutes", "at least 8 characters")
  • Break compound requirements into atomic statements
  • Remove ambiguous language ("user-friendly", "fast")
将需求转换为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
转换检查清单：
  • 识别隐含条件并明确说明
  • 指定触发事件或状态
  • 使用精确的动作动词（shall、must、should）
  • 添加可衡量的标准（如“30分钟内”“至少8个字符”）
  • 将复合需求拆分为原子化陈述
  • 移除模糊语言（如“用户友好”“快速”）

Step 3: Identify Domain Theories

步骤3：识别领域理论

Match requirements to established frameworks. See 
references/domain_theories.md
for full catalog.
Common domain mappings:
  • Productivity → GTD, Pomodoro, Eisenhower Matrix
  • Behavior Change → BJ Fogg Model (B=MAT), Atomic Habits
  • UX Design → Hick's Law, Fitts's Law, Gestalt Principles
  • Security → Zero Trust, Defense in Depth, Privacy by Design
Selection process:
  1. Identify primary domain from requirement keywords
  2. Match to 2-4 complementary theories
  3. Apply theory principles to specific features
  4. Cite theories in enhanced prompt for credibility
将需求与已确立的框架匹配。完整目录请参考
references/domain_theories.md
。
常见领域映射：
  • 生产力 → GTD、番茄工作法、艾森豪威尔矩阵
  • 行为改变 → BJ Fogg模型（B=MAT）、原子习惯
  • UX设计 → 希克定律、费茨定律、格式塔原则
  • 安全 → 零信任、纵深防御、隐私设计
选择流程：
  1. 从需求关键词中识别主领域
  2. 匹配2-4种互补性理论
  3. 将理论原则应用于具体功能
  4. 在优化后的提示词中引用理论以提升可信度

Step 4: Extract Concrete Examples

步骤4：提取具体示例

Generate specific examples with real data:
  • User scenarios: "When user logs in on mobile device..."
  • Data examples: "Product: 'Laptop', Price: $999, Stock: 15"
  • Workflow examples: "Task: Write report → Sub-tasks: Research (2h), Draft (3h), Edit (1h)"
Examples must be realistic, specific, varied (success/error/edge cases), and testable.
结合真实数据生成具体示例：
  • 用户场景：“当用户在移动设备上登录时...”
  • 数据示例：“产品：'Laptop'，价格：$999，库存：15”
  • 工作流示例：“任务：撰写报告 → 子任务：调研（2小时）、起草（3小时）、编辑（1小时）”
示例必须真实、具体、多样（成功/错误/边缘案例）且可测试。

Step 5: Generate Enhanced Prompt

步骤5：生成优化后的提示词

Structure using the standard framework:
markdown
undefined
使用标准框架进行结构化：
markdown
undefined

Role

Role

[Specific expert role with domain expertise]
[Specific expert role with domain expertise]

Skills

Skills

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

Workflows

Workflows

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

Examples

Examples

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

Formats

Formats

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

**Quality criteria:**
- **Role specificity**: "Product designer specializing in time management apps" > "Designer"
- **Theory grounding**: Reference frameworks explicitly
- **Actionable workflows**: Clear inputs/outputs and decision points
- **Concrete examples**: Real data, not "Example 1", "Example 2"
- **Measurable formats**: Specific requirements, not "good design"
[Precise output specifications:
  • File types, structure requirements
  • Design/styling expectations
  • Technical constraints
  • Deliverable checklist]

**质量标准：**
- **角色具体化**：“专注于时间管理应用的产品设计师” > “设计师”
- **理论落地**：明确引用框架
- **可执行工作流**：清晰的输入/输出和决策点
- **具体示例**：使用真实数据，而非“示例1”“示例2”
- **可衡量格式**：明确的要求，而非“良好设计”

Step 6: Present Optimization Results

步骤6：呈现优化结果

Output in structured format:
markdown
undefined
以结构化格式输出：
markdown
undefined

Original Requirement

Original Requirement

[User's vague requirement]
Identified Issues:
  • [Issue 1: e.g., "Lacks specific trigger conditions"]
  • [Issue 2: e.g., "No measurable success criteria"]
[User's vague requirement]
Identified Issues:
  • [Issue 1: e.g., "Lacks specific trigger conditions"]
  • [Issue 2: e.g., "No measurable success criteria"]

EARS Transformation

EARS Transformation

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

Domain & Theories

Domain & Theories

Primary Domain: [e.g., Authentication Security]
Applicable Theories:
  • [Theory 1] - [Brief relevance]
  • [Theory 2] - [Brief relevance]
Primary Domain: [e.g., Authentication Security]
Applicable Theories:
  • [Theory 1] - [Brief relevance]
  • [Theory 2] - [Brief relevance]

Enhanced Prompt

Enhanced Prompt

[Complete Role/Skills/Workflows/Examples/Formats prompt]
How to use: [Brief guidance on applying the prompt]
undefined
[Complete Role/Skills/Workflows/Examples/Formats prompt]
How to use: [Brief guidance on applying the prompt]
undefined

Advanced Techniques

高级技巧

For complex scenarios, see 
references/advanced_techniques.md
:
  • Multi-stakeholder requirements - EARS statements for each user type
  • Non-functional requirements - Performance, security, scalability with quantified thresholds
  • Complex conditional logic - Nested conditions with boolean operators
针对复杂场景，请参考
references/advanced_techniques.md
：
  • 多干系人需求 - 为每种用户类型制定EARS陈述
  • 非功能性需求 - 带有量化阈值的性能、安全、可扩展性要求
  • 复杂条件逻辑 - 包含布尔运算符的嵌套条件

Quick Reference

快速参考

Do's: ✅ Break down compound requirements (one EARS statement per requirement) ✅ Specify measurable criteria (numbers, timeframes, percentages) ✅ Include error/edge cases ✅ Ground in established theories ✅ Use concrete examples with real data
Don'ts: ❌ Avoid vague language ("fast", "user-friendly") ❌ Don't assume implicit knowledge ❌ Don't mix multiple actions in one statement ❌ Don't use placeholders in examples
注意事项： ✅ 将复合需求拆分（每个需求对应一条EARS陈述） ✅ 指定可衡量的标准（数字、时间范围、百分比） ✅ 包含错误/边缘案例 ✅ 基于已确立的理论 ✅ 使用带有真实数据的具体示例
禁忌： ❌ 避免模糊语言（如“快速”“用户友好”） ❌ 不要假设用户具备隐含知识 ❌ 不要在一条陈述中混合多个动作 ❌ 不要在示例中使用占位符

Resources

资源

Load these reference files as needed:
  • references/ears_syntax.md
     - Complete EARS syntax rules, all 5 patterns, transformation guidelines, benefits
  • references/domain_theories.md
     - 40+ theories mapped to 10 domains (productivity, UX, gamification, learning, e-commerce, security, etc.)
  • references/examples.md
     - Four complete transformation examples (procrastination app, e-commerce product page, learning dashboard, password reset security) with before/after comparisons and reusable template
  • references/advanced_techniques.md
     - Multi-stakeholder requirements, non-functional specs, complex conditional logic patterns
When to load references:
  • EARS syntax clarification needed → 
    ears_syntax.md
  • Domain theory selection requires extensive options → 
    domain_theories.md
  • User requests multiple optimization examples → 
    examples.md
  • Complex requirements with multiple stakeholders or non-functional specs → 
    advanced_techniques.md
根据需要加载以下参考文件：
  • references/ears_syntax.md
     - 完整的EARS语法规则、所有5种模式、转换指南、优势
  • references/domain_theories.md
     - 40+种理论映射到10个领域（生产力、UX、游戏化、学习、电商、安全等）
  • references/examples.md
     - 四个完整的转换示例（拖延症应用、电商产品页面、学习仪表盘、密码重置安全），包含前后对比和可复用模板
  • references/advanced_techniques.md
     - 多干系人需求、非功能性规格、复杂条件逻辑模式
何时加载参考文件：
  • 需要明确EARS语法 → 
    ears_syntax.md
  • 领域理论选择需要更多选项 → 
    domain_theories.md
  • 用户请求多个优化示例 → 
    examples.md
  • 涉及多干系人或非功能性规格的复杂需求 → 
    advanced_techniques.md