prompt-forge

# prompt-forge 把"我要一个干 X 的提示词"这种**模糊请求**,经过五个差异化思维角色的流水线,变成**场景化、抗误读、可执行**的成品提示词。 ## 核心痛点 直接问 AI "给我一个写 X 的提示词",拿到的几乎都是**模板化、无差异、抗误读能力为零**的产物。原因: 1. AI 没有挖你的隐藏需求 → 受众、场景、成功判据全靠它猜 2. AI 没有反向验证 → 不知道这条提示词会怎么烂 3. 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 执行失败,产出无效。 1. **判模式**:扫一眼用户输入,决定交互 / 一键 2. **Stage 1 · 架构师**:读 `roles/architect.md`,产出任务本质 + MECE 拆分 + 不做边界 3. **Stage 2 · 侦探**:读 `roles/detective.md`,产出隐藏需求清单 - 交互模式 → 把高优问题反问用户,等回答 - 一键模式 → 自己合理假设,记入「假设清单」 4. **Stage 3 · 红队**:读 `roles/red-team.md`,产出失败模式 Top 3 + 防御条款 5. **Stage 4 · 工程师**:读 `roles/engineer.md`,产出成品提示词草案 + 覆盖矩阵 6. **Stage 5 · 导演**:读 `roles/director.md`,运行 4 把锁交叉持锁,产出终稿 + 评分卡 7. **输出 checklist**:见下方模板 **回炉规则**: - 任一 Stage 自检失败 → 回炉该 Stage - 任一 Lock 不通过 → 回炉对应角色 - 最多 3 轮回炉 - 第 3 轮仍打架 → 不强行整合,在终稿后用「待用户决策」显式标出,**不允许私下裁决** **反例**:用户问"帮我写一个提示词" → ❌ 不允许直接出一段提示词;✅ 必须从 Stage 1 起步,哪怕一键模式也要 5 个 Stage 都跑完(只是不反问用户而已)。 ## 输出规范 ### 默认输出 终稿提示词以**可直接复制粘贴**的 markdown 代码块呈现,后跟评分卡。 ````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. **角色**(身份 + 立场) 2. **上下文**(背景 + 已知约束) 3. **任务**(动词开头,可验证) 4. **步骤**(分步,可追踪) 5. **输出格式**(结构 + 长度上限) 6. **禁区**(明确不要什么) 7. **示例**(至少 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) ```