你的Prompt为什么总调不好？这个Skill给了一套工程化方法
写 Prompt 这件事，很多人以为就是「把话说清楚」——但为什么同样一句话，不同人调出来的效果天差地别？
答案藏在这个叫 Prompt Engineering Guide 的 Skill 里，作者是 Davecelot/skilly-hand，来自 SkillsMP。
它到底干了什么
这个 Skill 不是给你一堆模板让你背，而是给你一套工程化的 Prompt 设计方法论——像开发软件一样设计 Prompt，可测试、可迭代、可版本管理。
核心分四块：
① 先签合同，再动笔
它要求你写 Prompt 之前先搭「Prompt Contract」，明确六个组件：
| 组件 | 作用 |
|---|---|
| Role | 定角色，别写”你是专家”这种废话 |
| Task | 说清楚要什么结果，不是说步骤 |
| Context | 只给必要信息，不要喂一堆无关背景 |
| Constraints | 边界条件：长度、格式、禁区 |
| Examples | 示例输入输出，格式风格很重要 |
| Output | 规定死输出结构，JSON/表格/段落都行 |
最关键一条：信息不足时直接说”insufficient data”，不瞎猜不编造。 这一个约束能减少 80% 的幻觉。
② 选对策略，别一把梭
Skill 给了一张决策树，根据场景推荐策略：
- 简单任务 → Zero-shot，直接说清楚格式和长度
- 需要格式一致 → Few-shot，给例子
- 要基于上下文回答 → 加 “use only context” 约束
- 复杂推理 → Step-back prompting 先想原则再应用
- 数学/逻辑 → Bounded reasoning，规定好答案边界
- 需要工具调用 → ReAct 风格，Thought/Action/Observation 写清楚
③ 参数调优，有章法
| 目标 | 起点参数 |
|---|---|
| 事实问答/分类/代码 | temperature=0.0~0.3，低 top_p |
| 通用解释/摘要/文案 | temperature=0.4~0.6，top_p=0.8~0.95 |
| 创意脑暴/小说/口号 | temperature=0.8~1.0，top_p=0.9~1.0 |
| JSON/代码/结构化输出 | 惩罚设 0.0，用 JSON Schema 校验 |
一个诀窍：一次只调一个主要参数，通常是 temperature 或 top_p，不要同时动三四个。
④ 验证循环，持续迭代
Draft → Run examples → Inspect failures → Refine → Validate → Version
生产级 Prompt 要加：金丝雀测试（golden tests）、红队测试、结构化输出校验。每次改动记录版本、模型、参数、已知失败case。
适用场景
- 工作中经常用 LLM 做分析/写内容，对输出质量有要求
- 想系统化沉淀 Prompt，不想每次都「凭感觉」
- 团队需要统一 Prompt 规范，减少无效沟通
怎么装
npx skills add https://github.com/Davecelot/skilly-hand --skill prompt-engineering
Prompt 是 LLM 的界面，界面烂体验一定烂。与其花时间换模型，不如先把自己的 Prompt 工程能力提上来。这个 Skill 值得存一份。
GitHub: Davecelot/skilly-hand
评论区
0 条评论
登录后可评论。