prompt-engineering-patterns

prompt-engineering-patterns 技能概览

prompt-engineering-patterns 是一套面向实战的提示词设计指南，重点是帮助你搭建更可靠的 LLM 工作流，而不是只给一堆泛泛的 prompting 小技巧。它尤其适合这类场景：要编写可上线的生产级 prompt、做结构化抽取流程、沉淀可复用的提示词模板，或建立以输出稳定性为核心的评估闭环，而不是追求一次性的创意发挥。

这个技能适合谁

如果你符合下面这些情况，就很适合用 prompt-engineering-patterns：

• 在为应用、agent 或内部自动化设计 prompts
• 想减少输出漂移、格式失败或推理不稳定的问题
• 正在权衡 few-shot examples、chain-of-thought、system prompts 和 structured outputs 该怎么选
• 想把临时拼凑的 prompt，整理成团队能长期维护的可复用模板

如果你只是想临时写一个一次性 prompt，这个技能可能有点重。

它帮你完成的核心工作

它真正解决的问题，不是“模型偶尔能用”，而是“模型大多数时候都能稳定到可以上线”。这个仓库围绕具体使用场景来组织 prompt 模式，包括：few-shot learning、chain-of-thought prompting、JSON 风格的 structured outputs、可复用模板、system prompt 设计，以及 prompt 优化工作流。

它和普通 prompt 建议有什么不同

prompt-engineering-patterns 最大的区别在于，它不是概念罗列，而是更像一份可落地的实施手册。仓库里包含：

• 主流 prompting 模式的参考文档
• 可以直接改造使用的示例资产
• 按任务类型整理的 prompt template library
• 用于迭代优化的 Python 脚本

对于安装前评估来说，这比那种只讲概念、不提供可复用材料的技能更有参考价值。

采用前建议先确认什么

这个技能最适合这样的前提：你已经比较清楚任务是什么、输出长什么样、成功标准如何定义。它不太适合作为“帮我想想要做什么”的发散式 brainstorming 工具。安装前先问自己：

• 你是否需要可预测的输出格式，或可量化的效果提升？
• 你手头是否有样例输入和期望输出？
• 你是否愿意拿一小组评估样本来测试 prompts？

如果答案是肯定的，那么 prompt-engineering-patterns for Context Engineering 会很匹配，因为它能帮助你把 context、examples、constraints 和 output contracts 明确下来。

如何使用 prompt-engineering-patterns 技能

prompt-engineering-patterns 的安装信息

这个技能位于 wshobson/agents 仓库中的 plugins/llm-application-dev/skills/prompt-engineering-patterns。

安装命令：

npx skills add https://github.com/wshobson/agents --skill prompt-engineering-patterns

由于上游 SKILL.md 没有提供安装命令，目录页用户可以把上面的命令视为实际可用的 prompt-engineering-patterns install 方式。

优先先读这些文件

建议按下面这个顺序先看信号最强的文件：

1. SKILL.md
2. assets/prompt-template-library.md
3. assets/few-shot-examples.json
4. references/prompt-optimization.md
5. references/system-prompts.md

然后再根据你真正需要的模式，继续深入阅读对应参考文档：

• references/few-shot-learning.md
• references/chain-of-thought.md
• references/prompt-templates.md

这样读更省时间，因为 assets 会先让你看到哪些内容能立刻复用，而 references 再解释这些模式为什么有效。

这个技能需要你提供什么输入

当你提供的任务输入越具体，prompt-engineering-patterns usage 的效果就越好。至少应提供：

• 具体任务是什么
• 目标受众或执行角色
• 希望的输出格式
• 硬性约束
• 3 到 10 个有代表性的 examples 或测试样本
• 已知失败案例

弱输入示例：

• “Improve this prompt.”

强输入示例：

• “I need a support-ticket classifier. Labels are billing, technical_issue, account_access, and other. Output must be valid JSON with label and confidence. Common failures: mixing labels, adding prose, and mishandling multi-intent tickets.”

第二种写法能给技能足够的上下文，让它推荐合适的模式，而不是只给出泛泛的改写建议。

根据任务选择合适的模式

请有选择地使用仓库中的模式：

• 当任务效果依赖格式、风格或边界判定时，用 few-shot examples
• 当任务涉及多步推理、逻辑判断或数学处理时，用 chain-of-thought
• 当结果要被下游系统解析时，用 structured outputs
• 当你需要稳定的角色、语气、安全边界或行为边界时，用 system prompts
• 当同一个 prompt 会反复套入不同变量时，用 template systems

一个常见错误是把所有模式一次性全叠上去。更好的做法是：先从最小、最能解决当前失败点的模式开始。

把模糊目标整理成可用的 prompt brief

在调用这个技能前，先把你的目标改写成五个部分：

1. Task：模型必须完成什么
2. Context：背景信息或领域假设
3. Constraints：必须避免什么，或必须始终包含什么
4. Output contract：精确的输出格式
5. Examples：有代表性的输入与理想输出

示例 brief：

Task: Extract entities from customer complaint emails.
Context: Emails may mention products, stores, dates, refund amounts, and staff names.
Constraints: Do not infer missing fields. Return empty arrays instead of null.
Output contract: Valid JSON with keys persons, products, locations, dates, monetary_values.
Examples: Include at least one email with no monetary value and one with multiple products.

这种具体程度，正是 prompt-engineering-patterns skill 明显优于“帮我写个 prompt”这类泛化请求的关键。

把模板库当作起点，而不是终点

assets/prompt-template-library.md 最有价值的用法，是把它当作脚手架。先复制一个接近的模板，再补上：

• 你的真实 schema
• 任务特有的约束
• 边界情况处理方式
• 信息缺失时的 refusal behavior

例如，对于抽取类模板，如果你明确说明模型遇到未知字段时应该省略、返回空值，还是引用原文片段，效果通常会更稳。

有目的地使用 few-shot examples

仓库里的 assets/few-shot-examples.json 真正有价值的地方，不完全在于里面那些具体示例，而在于示例是如何被设计出来的。好的 few-shot 集合应该：

• 贴近你的真实输入分布
• 覆盖边界情况，而不只是明显的正例
• 保持标签定义一致
• 避免噪声大或相互矛盾的 examples

如果你的任务总是在边界案例上出错，优先补这些边界示例，通常比单纯增加更多普通示例更有效。

在生产环境中谨慎使用 chain-of-thought

仓库中的 references/chain-of-thought.md 对推理类任务很有帮助，但并不是所有生产系统都适合暴露完整推理过程。实务上更建议这样做：

• 在内部分析和调试阶段使用显式 reasoning prompts
• 面向用户输出时保持答案格式简洁
• 测试 chain-of-thought 带来的准确率提升，是否足以抵消额外的 tokens 和 latency 成本

对很多团队来说，最佳生产模式通常是：内部隐藏推理 + 严格的最终答案格式。

把优化脚本当作工作流信号

scripts/optimize-prompt.py 和 references/prompt-optimization.md 其实已经暗示了推荐工作流：先建立 baseline，再对照测试集评估，分析失败点，迭代优化，然后重复。

即使你不用仓库里的原始脚本，也应该照着这个流程来：

1. 定义一个 baseline prompt
2. 建一个小型测试集
3. 衡量格式有效性和任务准确率
4. 检查失败聚类
5. 每次只调整一个变量

这是这个仓库最实用的价值之一：它会把你从无休止的主观微调，推向可衡量的 prompt 改进流程。

Context Engineering 的最佳工作流

prompt-engineering-patterns for Context Engineering 在 context 是经过筛选和组织的情况下效果最好，而不是把所有信息一股脑塞进去。更稳妥的工作流是：

1. 先定义任务和 output contract
2. 只加入完成该任务所必需的 context
3. 提供能够教会模型目标行为的 examples
4. 把稳定指令和动态用户输入分开
5. 用真实案例做评估
6. 删除那些不会影响结果的 context

这点很关键，因为长 prompt 失败，很多时候并不是因为 context 太少，而是因为 context 组织得不好。

prompt-engineering-patterns 技能 FAQ

prompt-engineering-patterns 适合新手吗？

适合，前提是你已经有一个具体任务。它的 examples 和 references 都比较容易上手，而且按模式拆解的方式能帮助新手停止“凭感觉试 prompt”。但如果你还完全没有定义 schema、labels 或评估标准，那它就没那么适合。

它和“把 prompt 写得更好”有什么区别？

普通 prompt 建议通常停留在措辞优化层面。prompt-engineering-patterns guide 更进一步，覆盖了模式选择、可复用模板、示例设计和迭代优化。因此它更适合搭建可重复的系统，而不只是优化一次性的聊天输入。

什么情况下不该用 prompt-engineering-patterns？

以下情况可以跳过它：

• 你更需要开放式 ideation，而不是可控性
• 你的任务每次都变，没有可复用结构
• 你还不知道目标输出格式应该是什么
• 你不愿意用 examples 去测试 prompts

在这些场景里，更简单的探索式 prompting 流程往往更快。

它对 structured outputs 的支持好吗？

支持得不错。整个仓库反复强调 JSON 风格抽取和受约束格式输出。如果你的下游代码需要可解析的响应，而当前 prompt 又经常夹带多余 prose，这个技能会特别有用。

prompt-engineering-patterns 是否绑定某一家模型厂商？

没有明显证据表明它存在厂商锁定。这里的模式在大多数现代 LLM 上都可以迁移使用，不过不同模型的具体表现还是会有差异。即便如此，你仍然应该在自己选定的 provider 上验证 token 成本、格式稳定性和推理质量。

如何改进 prompt-engineering-patterns 技能的使用效果

给这个技能一个更清晰的问题定义

想让 prompt-engineering-patterns 出效果，最快的方法就是不要再抽象地要求“给我更好的 prompts”。你应该明确提供：

• 成功标准
• 不可接受的输出
• 目标 schema
• 具有代表性的失败案例

这样技能才能推荐对的模式，并产出在真实使用中更扛打的 prompts。

在重写 prompt 之前先补齐评估样本

很多用户改 prompt 改得太早。更好的做法是，先收集 10 到 20 个 examples，其中包括：

• 简单案例
• 容易混淆的近似案例
• 格式异常的输入
• 当前已经会失败的案例

然后再用这些 examples 比较不同 prompt 版本。仓库里的优化材料非常明确地支持这种 test-driven 方法。

把稳定指令和可变 context 分开

一个常见失败模式，是把 role、任务规则、examples 和用户数据混在一个大段里。要提高质量，建议拆分为：

• system behavior
• 可复用的任务说明
• few-shot demonstrations
• 当前输入

这种结构更容易调试，也能减少指令意外漂移。

与其增加更多 examples，不如强化 examples 质量

few-shot 数据不是越多越好。与其堆更多示例，不如替换掉那些重复、无效或不真实的 examples，重点补齐：

• 边界案例
• 模糊输入
• 精确的输出格式
• 模型常犯错误

高质量 demonstrations 带来的提升，通常比单纯扩大示例数量更明显。

收紧 output contract

如果输出总是不一致，问题往往不是模型不听话，而是格式要求定义得太松。你可以通过明确下面这些内容来改进 prompt：

• 必须包含哪些 keys
• 允许使用哪些 labels
• 输出顺序规则
• 信息缺失时该如何处理

对于抽取任务来说，“return empty arrays for missing categories” 会比“extract entities in JSON”强得多。

每轮只修一个失败模式

不要一次同时改 role、schema、examples、reasoning style 和 temperature 假设。每次只改一个主要变量，重新测试，并记录影响。这样更符合仓库倡导的迭代优化逻辑，也更容易判断哪些改动真的有效。

注意不要过度工程化

prompt-engineering-patterns skill 很强，但也容易被用过头。常见预警信号包括：

• prompt 很长，而且重复指令很多
• 对简单任务塞了过多 examples
• 明明只需要抽取，却加了 chain-of-thought
• 任务还没稳定，就过早做了大量模板化

如果更简单的 prompt 已经能达到同样的可靠性，就应该优先用更简单的方案。

把仓库当作模式目录，而不是照抄脚本

想真正用好 prompt-engineering-patterns，最有效的方式不是逐字照搬，而是针对你自己的失败模式去改造它的 assets 和 references。先读 repo 选模式，再借一个模板，然后拿你的数据去测试。这比直接复制示例、指望它自动泛化要有效得多。