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 attribution: EARS + domain-theory grounding の組み合わせは外部記事に着想を得たもの (出典は frontmatter 
metadata.origin
)。
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 + 领域理论落地的组合灵感来自外部文章（来源见前置元数据
metadata.origin
）。
四层优化流程：
  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>
快速示例：
优化前：“开发一款带任务管理功能的提醒应用”

优化后（EARS格式）：
1. 当用户创建任务时，系统应引导其将任务分解为可执行的子任务
2. 当任务截止时间剩余30分钟且用户尚未开始执行时，系统应发送带声音提醒的通知
3. 当用户完成子任务时，系统应更新进度并给出正向反馈
转换检查清单：
  • 识别隐含条件并明确化
  • 指定触发事件或状态
  • 使用精准的动作动词（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.
结合真实数据生成具体示例：
  • 用户场景：“当用户在移动设备上登录时……”
  • 数据示例：“产品：'笔记本电脑'，价格：999美元，库存：15台”
  • 工作流示例：“任务：撰写报告 → 子任务：调研（2小时）、起草（3小时）、编辑（1小时）”
示例需满足真实可信、具体明确、覆盖多样场景（成功/错误/边缘案例）及可测试的要求。

Step 5: Generate Enhanced Prompt

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

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

Role

角色

[Specific expert role with domain expertise]
[具备领域专业知识的具体专家角色]

Skills

技能

  • [Core capability 1]
  • [Core capability 2] [List 5-8 skills aligned with domain theories]
  • [核心能力1]
  • [核心能力2] [列出5-8项与领域理论匹配的技能]

Workflows

工作流

  1. [Phase 1] - [Key activities]
  2. [Phase 2] - [Key activities] [Complete step-by-step process]
  1. [阶段1] - [关键活动]
  2. [阶段2] - [关键活动] [完整的分步流程]

Examples

示例

[Concrete examples with real data, not placeholders]
[结合真实数据的具体示例，而非占位符]

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"
[精准的输出规格：
  • 文件类型、结构要求
  • 设计/样式预期
  • 技术约束
  • 交付物检查清单]

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

Step 6: Present Optimization Results

步骤6：呈现优化结果

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

Original Requirement

原始需求

[User's vague requirement]
Identified Issues:
  • [Issue 1: e.g., "Lacks specific trigger conditions"]
  • [Issue 2: e.g., "No measurable success criteria"]
[用户的模糊需求]
识别出的问题：
  • [问题1：例如“缺少特定触发条件”]
  • [问题2：例如“无可衡量的成功标准”]

EARS Transformation

EARS转换结果

[Numbered list of EARS-formatted requirements]
[编号形式的EARS格式需求列表]

Domain & Theories

领域与理论

Primary Domain: [e.g., Authentication Security]
Applicable Theories:
  • [Theory 1] - [Brief relevance]
  • [Theory 2] - [Brief relevance]
核心领域： [例如“认证安全”]
适用理论：
  • [理论1] - [简要说明相关性]
  • [理论2] - [简要说明相关性]

Enhanced Prompt

优化后的提示词

[Complete Role/Skills/Workflows/Examples/Formats prompt]
How to use: [Brief guidance on applying the prompt]
undefined
[完整的「角色/技能/工作流/示例/格式」提示词]
使用指南： [关于该提示词的简要应用说明]
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
     - 覆盖10个领域（生产力、UX、游戏化、学习、电商、安全等）的40+种理论映射
  • references/examples.md
     - 四个完整的转换示例（拖延症应用、电商产品页、学习仪表盘、密码重置安全），包含优化前后对比及可复用模板
  • references/advanced_techniques.md
     - 多干系人需求、非功能性规格、复杂条件逻辑模式
加载参考文件的时机：
  • 需要明确EARS语法 → 
    ears_syntax.md
  • 需要大量选项来选择领域理论 → 
    domain_theories.md
  • 用户要求多个优化示例 → 
    examples.md
  • 涉及多干系人或非功能性规格的复杂需求 → 
    advanced_techniques.md