| name | prompt-forge |
| description | 五角色思维团 + 4 把锁交叉验证,把模糊的「写个提示词」请求,锻造成场景化、抗误读、可执行的成品提示词。五角色:架构师(第一性原理+MECE) / 侦探(苏格拉底+5W2H) / 红队(逆向+失败模式) / 工程师(费曼+奥卡姆) / 导演(系统+辩证)。触发词:帮我写提示词 / 生成提示词 / 优化提示词 / 差异化提示词 / 五角色提示词 / prompt forge / meta-prompt / prompt engineering / 元提示词 / 提示词锻造 / write a prompt for me。**不做**:提示词模板库 / 对外发布优化(用 paper-skill) / 独立 prompt 评估服务。 |
prompt-forge
把"我要一个干 X 的提示词"这种模糊请求,经过五个差异化思维角色的流水线,变成场景化、抗误读、可执行的成品提示词。
核心痛点
直接问 AI "给我一个写 X 的提示词",拿到的几乎都是模板化、无差异、抗误读能力为零的产物。原因:
- AI 没有挖你的隐藏需求 → 受众、场景、成功判据全靠它猜
- AI 没有反向验证 → 不知道这条提示词会怎么烂
- AI 把抽象需求复述了一遍,而不是翻译成可执行指令
对策:用五个差异化思维模型组成团队,在抽象↔具体、正向↔反向、单点↔系统三组张力轴上交叉验证,逼出真正贴合场景的提示词。
本 skill 不做什么(防误用)
| 场景 | 不要启动本 skill,改用 |
|---|
| 想要现成提示词模板 / prompt 仓库 | 直接搜公开 prompt 库 |
| 想优化一份方案/文档以"过 AI review" | paper-skill |
| 想给 prompt 打分 / 做 A/B 测试 | 独立 eval 框架(本 skill 的评分卡仅用于自检) |
| 只想让 AI 把一段话润色一下 | 直接说"润色这段话",不需要 5 角色过流程 |
| 用户已明确说"我只是想随便试试" | 给一句通用提示词即可,跑流水线是浪费 |
核心边界:本 skill 的价值在「结构化多视角反验」,不在"花哨模板"。当任务不需要反验时(比如润色、翻译、改格式),启动本 skill 反而是过度工程。
五角色思维团
| # | 角色 | 思维模型 | 核心职责 | 详细规则 |
|---|
| 1 | 架构师 | 第一性原理 + MECE | 拆到不可再分,划清边界 | roles/architect.md |
| 2 | 侦探 | 苏格拉底诘问 + 5W2H | 挖隐藏约束、真实受众、成功判据 | roles/detective.md |
| 3 | 红队 | 逆向思维 + 失败模式 | 预演这条提示词怎么烂、怎么被绕过 | roles/red-team.md |
| 4 | 工程师 | 费曼 + 奥卡姆剃刀 | 抽象需求 → 模型能直接执行的具体指令 | roles/engineer.md |
| 5 | 导演 | 系统思维 + 辩证法 | 整合冲突、平衡张力、敲定终稿 | roles/director.md |
差异化设计:五角色刻意覆盖三组张力轴,避免思维同质化:
- 抽象(架构师) ↔ 具体(工程师)
- 正向(侦探挖需求) ↔ 反向(红队找失败)
- 单点(前四角) ↔ 系统(导演)
思维链条(五阶段流水线)
[1] 解构 → [2] 挖掘 → [3] 反验 → [4] 具象 → [5] 整合
架构师 侦探 红队 工程师 导演
每阶段的输入 = 上一阶段产出 + 用户原始需求;输出固定字段,供下一阶段消费。具体字段定义见各 roles/*.md。
互相验证机制(交叉持锁)
| 验证关系 | 验证什么 | 不通过怎么办 |
|---|
| 架构师 ⇄ 红队 | 边界反着想还成立吗? | 边界回炉 |
| 侦探 ⇄ 工程师 | 挖出的隐藏需求,全部翻译成指令了吗? | 工程师补指令 |
| 工程师 ⇄ 红队 | 这些指令扛得住敷衍、误读、绕过吗? | 工程师加防御条款 |
| 导演 ⇄ 全员 | 五份产出之间有没有打架? | 打架时按"成功判据"裁决 |
核心规矩:任何角色无法对另一角色的产出做「复述 + 反驳」→ 回炉重做。
触发与模式选择
触发判断
收到以下任一信号时启动本 skill:
- 用户请求"写/生成/优化提示词"
- 用户已有粗糙提示词,要求"改得更好/更稳/更不容易被误读"
- 用户描述了一个任务场景,问"用什么提示词能做到 X"
两种执行模式
| 模式 | 何时用 | 行为 |
|---|
| 交互模式(默认) | 用户原始需求 < 3 行,信息明显不足 | 走完 Stage 1 后,用 Stage 2(侦探)向用户反问 3-5 个关键问题,再继续 |
| 一键模式 | 用户原始需求 ≥ 1 段且场景清晰,或用户明说"直接给我成品/不要反问" | 五阶段内部跑完,只输出终稿 + 评分卡;若中途发现关键信息缺口,在终稿后用「假设清单」标出 |
模糊时默认走交互模式 —— 挖需求比盲出稿更重要。
完整工作流
收到提示词生成请求时,必须按 Stage 1 → 2 → 3 → 4 → 5 顺序执行,不允许跳步、不允许并行。违反顺序 = 整个 skill 执行失败,产出无效。
- 判模式:扫一眼用户输入,决定交互 / 一键
- Stage 1 · 架构师:读
roles/architect.md,产出任务本质 + MECE 拆分 + 不做边界
- Stage 2 · 侦探:读
roles/detective.md,产出隐藏需求清单
- 交互模式 → 把高优问题反问用户,等回答
- 一键模式 → 自己合理假设,记入「假设清单」
- Stage 3 · 红队:读
roles/red-team.md,产出失败模式 Top 3 + 防御条款
- Stage 4 · 工程师:读
roles/engineer.md,产出成品提示词草案 + 覆盖矩阵
- Stage 5 · 导演:读
roles/director.md,运行 4 把锁交叉持锁,产出终稿 + 评分卡
- 输出 checklist:见下方模板
回炉规则:
- 任一 Stage 自检失败 → 回炉该 Stage
- 任一 Lock 不通过 → 回炉对应角色
- 最多 3 轮回炉
- 第 3 轮仍打架 → 不强行整合,在终稿后用「待用户决策」显式标出,不允许私下裁决
反例:用户问"帮我写一个提示词" → ❌ 不允许直接出一段提示词;✅ 必须从 Stage 1 起步,哪怕一键模式也要 5 个 Stage 都跑完(只是不反问用户而已)。
输出规范
默认输出
终稿提示词以可直接复制粘贴的 markdown 代码块呈现,后跟评分卡。
## 终稿提示词
```
[这里是真正的提示词,用户复制即可用]
```
## 评分卡
| 维度 | 评分 (1-5) | 说明 |
|------|----------|------|
| 精确性 | X | 角色 / 任务 / 输出格式是否清晰 |
| 差异性 | X | 是否反映了用户独特场景,而非通用模板 |
| 抗误读 | X | 模型敷衍/误解的可能性 |
| 可执行 | X | 模型能否直接照做,无需追问 |
## 假设清单(仅一键模式输出)
- 假设 1:____
- 假设 2:____
## 执行 checklist
- [ ] Stage 1 架构师产出 = ____
- [ ] Stage 2 侦探挖出 N 条隐藏需求
- [ ] Stage 3 红队列出 X 个失败模式
- [ ] Stage 4 工程师指令含角色/上下文/任务/步骤/格式/示例/禁区
- [ ] Stage 5 导演完成交叉持锁,无未解冲突
文件输出(可选)
若用户给出工作目录或明确说"保存到文件",在该目录创建 prompt_{slug}.md,内容同上。否则只在对话中输出。
通用规则
提示词写作禁忌
工程师阶段产出指令时,避免:
| 禁用 | 原因 | 替换 |
|---|
| "请尽量..." / "尽可能..." | 模型会偷懒 | "必须...,否则视为失败" |
| "写得好一点" / "高质量" | 不可执行 | 给量化判据或反例 |
| "你是一个 AI 助手" | 角色无意义 | 给具体身份("向 CEO 汇报的产品负责人") |
| 纯形容词没样例 | 模型靠猜 | 至少 1 正 1 反样例 |
必备七要素(工程师产出底线)
成品提示词至少包含:
- 角色(身份 + 立场)
- 上下文(背景 + 已知约束)
- 任务(动词开头,可验证)
- 步骤(分步,可追踪)
- 输出格式(结构 + 长度上限)
- 禁区(明确不要什么)
- 示例(至少 1 个,正反皆可)
差异化的来源
差异化不来自模板更花哨,来自 Stage 2 + Stage 3:
- Stage 2 把用户独特场景挖出来(CEO 受众 vs 同级受众挖出的是完全不同的提示词)
- Stage 3 把用户独特的失败容忍度挖出来(允许稍微敷衍 vs 必须严格)
如果跑完发现终稿和"通用模板"差不多 → Stage 2 / 3 没挖到位,必须回炉。
迷你示例
需求:"给我一个写产品周报的提示词"
- 架构师:本质 = 把一周事件压成决策者 60 秒能读完的信号。MECE = 取数 / 排序 / 压缩 / 表达。不做 = 不替代月报/复盘。
- 侦探反问:受众是 CEO 还是同级?读完要做决策还是仅知情?是否要含下周计划?
- 红队:失败模式 = 流水账 / 没结论 / 自夸 / 度量缺失。
- 工程师草案:"你是向 CEO 汇报的产品负责人。把以下事件按【影响 × 紧急】排序,每条 ≤30 字。结尾给出一个最值得 CEO 关注的判断。禁止『赋能/抓手/闭环』。示例:好=『A 功能上线,DAU +12%,验证了 X 假设』;烂=『推进了 A 项目工作』。"
- 导演:整合 + 评分卡。
最终原则
- 挖需求 > 拼模板。Stage 2 没挖到位的提示词,再花哨也是垃圾。
- 反验 > 自信。Stage 3 跳过的提示词,上线就会被打脸。
- 具象 > 抽象。"写得好"是废话,"≤30 字 + 给个例子"才是指令。
- 承认未知。一键模式若有信息缺口,显式写「假设清单」,不要替用户做假定决策还不告诉他。
文件索引
prompt-forge/
├── SKILL.md # 顶层路由(本文件)
├── README.md # 给人读的说明 + 完整示例
├── roles/
│ ├── architect.md # Stage 1 架构师
│ ├── detective.md # Stage 2 侦探
│ ├── red-team.md # Stage 3 红队
│ ├── engineer.md # Stage 4 工程师
│ └── director.md # Stage 5 导演 + 交叉持锁规则
└── templates/
├── workorder.md # 五阶段工单模板(交互模式用)
└── meta-prompt.md # 一键元提示词(可丢给任意 LLM)
