Back to Details

prompt

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Prompt

Prompt

Objective

目标

Treat a prompt as a specification of intended behavior, not a record of past corrections.
Maximize behavioral accuracy with the fewest necessary independent concepts. Semantic complexity should grow only when the intended behavior grows. The goal is not minimum word count; it is minimum unnecessary complexity.
将 Prompt 视为对预期行为的规范，而不是过往修正的记录。
以尽可能少的必要独立概念实现最高的行为准确性。只有当预期行为本身变得复杂时，语义复杂度才应随之增加。目标不是字数最少，而是没有不必要的复杂性。

Core principle

核心原则

Examples and failures are evidence, not automatic requirements.
text
observed behavior → intended behavior → general principle
not:
text
observed behavior → permanent exception
A failure shows what happened, not necessarily what should have happened. Establish the intended behavior first, then generalize the correction.
When several prompts would produce the same behavior, prefer, in order:
  1. Rewriting an existing rule.
  2. Merging related rules.
  3. Replacing specific cases with a broader principle.
  4. Adding a rule only for a genuinely new requirement.
示例和失败案例是证据，而不是自动生效的要求。
text
观察到的行为 → 预期行为 → 通用原则
而不是：
text
观察到的行为 → 永久性特例
失败案例说明发生了什么，但不一定说明应该发生什么。首先明确预期行为，然后将修正泛化。
当多个 Prompt 都能产生相同行为时，应按以下顺序优先选择：
  1. 重写现有规则。
  2. 合并相关规则。
  3. 用更宽泛的原则替代具体案例。
  4. 仅当某项要求确实是全新需求时，才添加新规则。

Example

示例

Intent: characters should have realistic, naturally occurring hair colors. Observed failure: the model gave a character neon blue hair.
"Do not generate neon blue hair" encodes one instance and invites the next one (green, purple, pink). "Use realistic, naturally occurring hair colors" states the requirement and covers the whole category.
意图：角色应拥有真实、自然出现的发色。观察到的失败：模型给角色生成了霓虹蓝头发。
“不要生成霓虹蓝头发”只编码了一个具体实例，并会引出下一个实例（绿色、紫色、粉色）。“使用真实、自然出现的发色”则陈述了需求，并涵盖整个类别。

Workflow

工作流

  1. Establish intent. Identify the behavior, scope, constraints, and outcomes the prompt must produce or preserve. Do not infer the rule from a failure alone.
  2. Diagnose complexity. Find redundant or conflicting instructions, overly narrow constraints, enumerated examples that should be categories, and historical patches.
  3. Generalize. Replace narrow cases with the principle that accurately represents the intent. Keep explicit distinctions where behavior genuinely differs.
  4. Simplify. Rewrite the governing instruction instead of appending a correction, merge related rules, and remove instructions already implied elsewhere.
  5. Validate. Confirm the result preserves intended behavior, generalizes beyond the examples, adds no unintended restrictions, stays internally consistent, and is clearer or more expressive than before. Test against real inputs when possible.
  1. 明确意图。 确定 Prompt 必须产生或保留的行为、范围、约束和结果。不要仅凭失败案例推断规则。
  2. 诊断复杂性。 找出冗余或冲突的指令、过于狭窄的约束、本应作为类别处理却逐项列举的示例，以及历史补丁。
  3. 泛化。 用能够准确表达意图的原则替代狭窄案例。在行为确实存在差异时，保留明确的区分。
  4. 简化。 重写主导性指令，而不是追加修正内容；合并相关规则，并删除已由其他内容隐含表达的指令。
  5. 验证。 确认结果保留了预期行为，能够泛化到示例之外，没有引入意外限制，保持内部一致，并且比之前更清晰或更具表达力。尽可能使用真实输入进行测试。

Editing rules

编辑规则

  • Principles over examples: Examples should teach a reasoning pattern, not become permanent constraints. "Communicate respectfully" beats "Never say 'that's stupid.'"
  • Abstraction over enumeration: Name the category when it accurately covers the intended cases. "Use natural colors" beats a list of forbidden ones.
  • Rewriting over appending: Strengthen the existing instruction ("Be concise" → "Be concise and direct") rather than adding a second one that restates it.
  • Semantic over textual compression: Remove redundant concepts, not wording the model needs to interpret and apply the instruction correctly.
  • Consistency over isolated fixes: Resolve conflicting instructions at the level of the specification, not by adding a tie-breaker for each collision.
  • 原则优于示例： 示例应教会一种推理模式，而不是变成永久性约束。“以尊重的方式沟通”优于“永远不要说‘那太蠢了’”。
  • 抽象优于枚举： 当某个类别能够准确覆盖预期情况时，直接指出该类别。“使用自然色”优于列出一系列禁用颜色。
  • 重写优于追加： 强化现有指令（“保持简洁”→“保持简洁且直接”），而不是添加第二条重复其含义的指令。
  • 语义优化优于文本压缩： 删除冗余概念，而不是删除模型正确理解和执行指令所需的措辞。
  • 整体一致性优于孤立修复： 在规范层面解决冲突指令，而不是为每次冲突添加单独的裁决规则。

Complexity gate

复杂性检查

Before adding or changing an instruction, ask:
  1. Does it express a genuinely new requirement?
  2. Is the behavior already implied elsewhere?
  3. Could it be expressed more generally?
  4. Is it a principle or merely an observed example?
  5. Would removing it change expected behavior?
Reject changes that add complexity without improving behavioral accuracy or expressive power.
在添加或修改指令前，请问：
  1. 它是否表达了一个真正全新的要求？
  2. 该行为是否已由其他内容隐含表达？
  3. 是否可以用更通用的方式表达？
  4. 它是一条原则，还是仅仅是一个观察到的示例？
  5. 移除它是否会改变预期行为？
拒绝那些只增加复杂性，却不能提升行为准确性或表达力的修改。

Stability test

稳定性测试

A well-maintained prompt converges. Applying this process again should produce little or no meaningful change. If each review adds more exceptions, the prompt is accumulating history instead of expressing principles, and the underlying specification needs rethinking.
Guiding maxim: A prompt should describe what the system must do, not the history of mistakes that shaped it.
维护良好的 Prompt 应当逐渐收敛。再次应用这一流程时，Prompt 应当几乎没有或不再发生有意义的变化。如果每次审查都会增加更多特例，说明 Prompt 正在累积历史，而不是表达原则，此时需要重新思考底层规范。
指导原则： Prompt 应描述系统必须做什么，而不是描述塑造它的错误历史。