enhance-prompt

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prompt Enhancement

提示词优化

Analyze, write, and improve LLM prompts and agent instructions. Apply these principles to system prompts, agent instructions, skills, CLAUDE.md files, rules, slash commands, and any LLM prompt.

分析、编写并优化LLM提示词与Agent指令。将以下原则应用于系统提示词、Agent指令、Skill、CLAUDE.md文件、规则、斜杠命令及所有LLM提示词。

Workflow

工作流程

When invoked with input:

Classify the request: Determine if the input is a prompt to review, a description of a prompt to write, or a general prompt engineering question
Analyze: For existing prompts, identify violations of the principles below. For new prompts, gather requirements
Apply principles: Apply Token Economics, Determinism, Imperative Language, Formatting, and Anti-Pattern checks
Produce output: Return the enhanced prompt only

当接收到输入时：

分类请求：判断输入为待审查的提示词、待编写提示词的需求描述，还是通用提示词工程问题
分析环节：针对现有提示词，识别是否违反以下原则；针对新提示词，收集需求信息
应用原则：应用Token经济性、确定性、命令式语言、格式规范及反模式检查原则
生成输出：仅返回优化后的提示词

Output Format

输出格式

Return the enhanced prompt only. No preamble, no violation notes, no commentary, no explanations. The entire response is the improved prompt, ready to copy and paste.

When invoked without input, serve as a reference guide for the principles below.

仅返回优化后的提示词。无需前置说明、违规注释、评论或解释。整个响应即为可直接复制粘贴的优化后提示词。

当未接收到输入时，作为以下原则的参考指南提供服务。

Token Economics

Token经济性

The context window is a shared resource. Challenge each piece of information: "Does the model already know this?" Only add context the model lacks. Assume high baseline capability.

Remove decorative language. No "please", "remember", "make sure", "it's important".

Use examples over explanations. One concrete before/after pair teaches more than three paragraphs of description.

Prefer tables for structured data. Compress related information into scannable format.

上下文窗口是共享资源。对每一条信息提出质疑：“模型是否已知晓该内容？”仅添加模型不具备的上下文信息。假设模型具备较高的基础能力。

删除修饰性语言。避免使用“请”“记住”“确保”“这很重要”等表述。

优先使用示例而非解释。一组具体的前后对比示例，比三段描述性文字的教学效果更好。

结构化数据优先使用表格。将相关信息压缩为便于快速扫描的格式。

Determinism and Specificity

确定性与特异性

Degrees of Freedom

自由度层级

Match specificity to task requirements.

High freedom (text instructions): Use when multiple approaches are valid. Medium freedom (pseudocode, parameterized scripts): Use when a preferred pattern exists. Low freedom (exact scripts, no parameters): Use when operations are fragile or consistency is critical.

根据任务需求匹配对应特异性。

高自由度（文本指令）：适用于多种方法均有效的场景。中自由度（伪代码、参数化脚本）：适用于存在首选模式的场景。低自由度（精确脚本、无参数）：适用于操作要求严格或一致性至关重要的场景。

Zero Ambiguity

零歧义

Every instruction must have exactly one interpretation.

Use explicit constraints, not suggestions. "Run

pytest tests/ --strict-markers

" not "Run tests with strict markers when appropriate."

Specify conditions completely. "Validate input at API boundaries" not "Validate input."

Eliminate hedge words: "consider", "try to", "when possible", "generally", "often".

每条指令必须只有一种解释。

使用明确约束而非建议。例如：使用

pytest tests/ --strict-markers

而非“在合适时启用严格标记运行测试”。

完整指定条件。例如：“在API边界处验证输入”而非“验证输入”。

消除模糊性词汇：“考虑”“尝试”“在可能的情况下”“通常”“经常”。

Deterministic Commands

确定性命令

Include all flags and arguments.

dotnet test --logger "console;verbosity=detailed"

not

dotnet test

Use absolute paths or precisely scoped paths.

/src/api/

src/**/*.ts

, not "the API code."

Specify tool versions when behavior differs. "Node.js 20+: use native fetch" not "Use fetch."

包含所有标志与参数。例如：

dotnet test --logger "console;verbosity=detailed"

而非

dotnet test

。

使用绝对路径或精确范围的路径。例如：

/src/api/

、

src/**/*.ts

而非“API代码”。

当工具版本影响行为时，指定版本。例如：“Node.js 20+：使用原生fetch”而非“使用fetch”。

Imperative Language Patterns

命令式语言模式

Use imperative form only. "Validate at boundaries" not "You should validate at boundaries."

Write direct commands in imperative mood.

Good: "Validate input at API boundaries" Avoid: "You should consider validating input"

Prefer positive instructions over negations. "Let exceptions propagate" rather than "Do not catch exceptions unnecessarily."

仅使用命令式语气。例如：“在边界处验证”而非“你应该在边界处验证”。

直接使用命令式语气编写指令。

正确示例：“在API边界处验证输入” 避免示例：“你应该考虑验证输入”

优先使用肯定式指令而非否定式。例如：“让异常向上传播”而非“不要不必要地捕获异常”。

Specificity in Constraints

约束的特异性

Be specific in prohibitions and requirements.

Good: "Do not implement retry logic in background jobs" Avoid: "Avoid defensive patterns"

对禁止项与要求项表述明确。

正确示例：“不要在后台任务中实现重试逻辑” 避免示例：“避免防御性模式”

Formatting for LLM Parsing

便于LLM解析的格式规范

Use markdown structure that aids LLM understanding.

Format	Purpose
Headings	Establish context and scope boundaries
Lists	Discrete, parallel, independent items only
Code blocks	Exact values, commands, identifiers, patterns
Tables	Structured comparisons, reference data, decision matrices
Bold	Hard constraints where violation causes failure (max 10% of content)
Prose	Relationships between ideas, conditional logic, rationale
White space	Blank lines between paragraphs and sections for parsing clarity

使用有助于LLM理解的Markdown结构。

格式	用途
标题	建立上下文与范围边界
列表	仅用于离散、平行、独立的项目
代码块	精确值、命令、标识符、模式
表格	结构化对比、参考数据、决策矩阵
加粗	违反会导致失败的硬性约束（占比不超过内容的10%）
散文段落	阐述观点间的关系、条件逻辑、原理
空白间隔	段落与章节间的空行，提升解析清晰度

Emphasis and Terminology

强调与术语一致性

Emphasis Modifiers

强调修饰词

Use MUST, MUST NOT, REQUIRED only for hard constraints where violation causes failure.

Do not use modifiers for preferences or defaults. If every instruction uses MUST, none stand out.

仅在违反会导致失败的硬性约束中使用MUST、MUST NOT、REQUIRED。

偏好或默认规则不使用修饰词。如果每条指令都用MUST，那么没有一条会突出显示。

Terminology Consistency

术语一致性

Choose one term per concept and use it throughout.

Good: Always "API endpoint" Avoid: Alternating "API endpoint", "URL", "route", "path"

每个概念选择一个术语并全程使用。

正确示例：始终使用“API endpoint” 避免示例：交替使用“API endpoint”“URL”“route”“path”

Structural Optimization

结构优化

Place critical constraints first. Most important information at top of file.

Use progressive specificity. Global rules first, then domain-specific, then file-specific.

Separate concerns cleanly. One section per topic. Do not mix testing rules with deployment procedures.

End sections decisively. No trailing "etc." or "and more."

将关键约束放在最前面。最重要的信息放在文件顶部。

使用渐进式特异性。先全局规则，再领域特定规则，最后文件特定规则。

清晰分离关注点。每个章节对应一个主题。不要将测试规则与部署流程混合。

章节结尾明确。避免使用“等”“及其他”等表述。

Common Anti-Patterns

常见反模式

Language Anti-Patterns

语言反模式

Suggestion language:

Avoid: "Consider using async/await"
Good: "Use async/await for I/O operations"

Vague quantifiers:

Avoid: "Usually validate input"
Good: "Validate input at API boundaries"

Ambiguous conditionals:

Avoid: "Add logging when appropriate"
Good: "Log errors with stack traces. Omit logging for expected control flow."

Multiple options without default:

Avoid: "Use Jest, Vitest, or Mocha for testing"
Good: "Use Vitest for tests. Jest acceptable for legacy files."

建议性语言：

避免：“Consider using async/await”
正确：“Use async/await for I/O operations”

模糊量词：

避免：“Usually validate input”
正确：“Validate input at API boundaries”

模糊条件：

避免：“Add logging when appropriate”
正确：“Log errors with stack traces. Omit logging for expected control flow.”

无默认选项的多选择：

避免：“Use Jest, Vitest, or Mocha for testing”
正确：“Use Vitest for tests. Jest acceptable for legacy files.”

Structural Anti-Patterns

结构反模式

Burying critical constraints:

Avoid: Long preamble, then critical requirement in middle
Good: Critical requirement first, context after if needed

Over-emphasis:

Avoid: Every other word bold
Good: Bold only for hard constraints where violation causes failure

Lists as default:

Avoid: Everything formatted as bulleted list
Good: Lists for discrete items, prose for relationships

关键约束被隐藏：

避免：冗长的前言，关键要求放在中间
正确：关键要求放在最前面，必要时再添加上下文

过度强调：

避免：Every other word bold
正确：仅在违反会导致失败的硬性约束中使用加粗

默认使用列表：

避免：所有内容都用项目符号列表
正确：列表用于离散项目，散文段落用于阐述关系

Content Anti-Patterns

内容反模式

Repeating framework documentation:

Avoid: "React hooks let you use state and lifecycle in function components..."
Good: "Store form state in URL params, not local state"

Generic best practices:

Avoid: "Functions should be small and focused"
Good: "Limit API handlers to routing only. Move logic to services/"

Time-sensitive information:

Avoid: "Before August 2025, use legacy API"
Good: "Use v2 API at api.example.com/v2/"

Decorative content: Welcome messages, motivational statements, background history.

Hypothetical scenarios: "If we ever migrate to Postgres..." Address when actual, not hypothetical.

重复框架文档内容：

避免：“React hooks let you use state and lifecycle in function components...”
正确：“Store form state in URL params, not local state”

通用最佳实践：

避免：“Functions should be small and focused”
正确：“Limit API handlers to routing only. Move logic to services/”

时效性信息：

避免：“Before August 2025, use legacy API”
正确：“Use v2 API at api.example.com/v2/”

装饰性内容：欢迎语、励志语句、背景历史。

假设性场景：“If we ever migrate to Postgres...” 仅在实际发生时处理。

Optimization Techniques

优化技巧

Sentence Compression

句子压缩

Remove filler:

Before: "You should make sure to always run the test suite before committing your changes"
After: "Run
```
pytest
```
before committing"

Combine related instructions:

Before: "Use TypeScript. Add type annotations. Enable strict mode."
After: "Use TypeScript strict mode with explicit type annotations"

删除冗余内容：

优化前：“You should make sure to always run the test suite before committing your changes”
优化后：“Run
```
pytest
```
before committing”

合并相关指令：

优化前：“Use TypeScript. Add type annotations. Enable strict mode.”
优化后：“Use TypeScript strict mode with explicit type annotations”

Command Specification

命令规范

Full specification:

markdown

undefined

完整规范：

markdown

undefined

Commands

pytest tests/ --strict-markers --cov=src --cov-report=html

: Run tests with coverage

dotnet build --configuration Release --no-restore

: Production build

```
npm run lint -- --fix
```
: Auto-fix linting issues


Not:
```markdown

pytest tests/ --strict-markers --cov=src --cov-report=html

: Run tests with coverage

dotnet build --configuration Release --no-restore

: Production build

```
npm run lint -- --fix
```
: Auto-fix linting issues


避免：
```markdown

Commands

Run pytest to test. Use dotnet build for building. Lint with npm.

undefined

Run pytest to test. Use dotnet build for building. Lint with npm.

undefined