提示词工程 on 拾光集

AI 反推提示词教程：3 步从参考图片生成可复用的生图提示词

Tue, 28 Jul 2026 17:21:00 +0800

看到一张喜欢的图片，却不知道应该怎样写提示词？

可以使用“AI 反推提示词”工作流，让支持图片识别的 AI 先分析画面，再将分析结果整理成适合 Midjourney、Stable Diffusion、即梦、豆包或其他生图工具使用的提示词。

整个流程分为三个步骤：

拆解图片元素
生成基础提示词
优化成指定工具可直接使用的版本

需要注意的是，AI 反推得到的通常不是原作者输入的真实提示词，而是根据图片内容推测出的近似描述。它更适合用来学习画面的构图、风格、光影和视觉语言，而不是逐字恢复原始 Prompt。

第一步：拆解图片元素

先把参考图片上传给支持图片识别的 AI，例如 ChatGPT、Gemini、Claude 或其他多模态模型。

不要一开始就让 AI 直接生成提示词，而是先要求它对图片进行结构化拆解。

可直接复制的指令

请详细拆解这张图片，并按照以下维度进行分析：

1. 主体：画面中的主要人物、物体或视觉对象。
2. 场景：主体所处的环境、时间、地点和空间关系。
3. 动作：人物姿态、表情、动作方向，以及物体的运动状态。
4. 风格：写实摄影、商业广告、插画、动漫、3D渲染、赛博朋克或其他视觉风格。
5. 色调：主色、辅助色、色彩饱和度、冷暖关系和整体情绪。
6. 光线：光源方向、光线强弱、自然光或人工光，以及阴影和高光表现。
7. 构图：景别、拍摄角度、主体位置、视觉中心、前景、中景和背景关系。
8. 材质：皮肤、布料、金属、玻璃、木材或其他表面的纹理表现。
9. 镜头：可能使用的焦段、景深、透视关系和摄影机位。
10. 细节：画面中的道具、装饰、环境元素和容易被忽略的信息。

请尽量描述具体，不要只使用“高级感”“电影感”“氛围感”等空泛词语。
最后将分析结果整理成结构化列表。

为什么需要先拆解

直接让 AI 反推提示词，常见结果是：

`1`	`一个女孩站在街道上，电影感，高清，细节丰富。`

这种描述虽然没有错，但缺少人物姿态、服装材质、环境光线、镜头角度和构图关系，很难稳定复现参考图片的视觉效果。

先拆解图片，可以减少遗漏，也方便后续修改其中某一个元素。

第二步：反向生成基础提示词

完成图片拆解后，再让 AI 把分析结果组合成完整的生图提示词。

可直接复制的指令

请根据刚才的图片分析结果，反向生成一套完整的AI生图提示词。

要求：

1. 保留主体、场景、动作、构图、色调、光线、材质和镜头信息。
2. 使用具体、可视化的描述，不要只写“高级感”“震撼”“精美”等抽象词。
3. 按照以下顺序组织：
   主体 → 动作 → 场景 → 构图 → 光线 → 色彩 → 材质 → 风格 → 镜头 → 画质。
4. 不要添加原图中不存在的人物、物体、文字或装饰。
5. 分别输出中文提示词和英文提示词。
6. 额外提供一组负面提示词，用于避免文字、水印、变形、模糊和多余元素。

目标是尽可能还原参考图片的视觉氛围、构图方式和画面质感，而不是猜测原作者输入过的真实提示词。

第三步：优化成指定 AI 工具版本

不同 AI 生图工具对提示词的理解方式并不完全相同。

因此，基础提示词生成后，还需要告诉 AI 你准备使用哪一个生图工具。

通用优化指令

请将刚才的提示词优化成适合【工具名称】直接使用的版本。

要求：

1. 保留原图最重要的主体、构图、色调、光线和材质特征。
2. 调整语序和表达方式，使其符合该工具的提示词习惯。
3. 删除重复、矛盾和无法被模型理解的描述。
4. 不要随意改变原图内容。
5. 如果该工具支持参数，请补充合理参数。
6. 如果该工具不支持某项参数，请不要虚构。
7. 最终只输出：
   - 成品提示词
   - 负面提示词
   - 参数说明

提示词需要能够直接复制使用。

将其中的“工具名称”替换为：

Midjourney
Stable Diffusion
Flux
即梦AI
豆包
通义万相
Gemini
ChatGPT图像生成

Midjourney 提示词优化指令

请将这套图片描述优化成适合 Midjourney 使用的英文提示词。

要求：

1. 使用自然、连贯的英文视觉描述。
2. 优先描述主体、场景、构图、光线、色彩和镜头。
3. 删除重复词和没有实际视觉意义的形容词。
4. 不要添加原图中不存在的元素。
5. 根据参考图比例添加合适的 --ar 参数。
6. 根据画面需要添加合理的 --stylize 参数。
7. 最终只输出一条可以直接复制到 Midjourney 使用的完整提示词。

示例：

A realistic photograph of a white lighthouse standing on a rocky coastline at sunset, a small red-roofed house beside it, ocean waves crashing against dark rocks, warm golden sunlight passing through orange and pink clouds, rule-of-thirds composition, foreground rocks creating leading lines, wide-angle lens, natural cinematic lighting, realistic textures, high dynamic range, detailed coastal atmosphere --ar 4:3 --stylize 150

Stable Diffusion 提示词优化指令

请将这套图片描述优化成适合 Stable Diffusion 或 Flux 使用的提示词。

请分别输出：

1. Positive Prompt
2. Negative Prompt
3. 推荐画面比例
4. 推荐采样步数
5. 推荐 CFG 范围

要求：

- 主体描述放在前面。
- 使用清晰、具体的视觉关键词。
- 避免重复堆砌 masterpiece、best quality 等质量词。
- 负面提示词重点排除文字、水印、模糊、畸形和多余主体。
- 参数只提供通用建议，不要声称所有模型都使用相同设置。

通用负面提示词示例：

`1`	`low quality, blurry, distorted perspective, malformed objects, duplicated subjects, extra limbs, bad anatomy, oversaturated colors, text, watermark, logo, frame, compression artifacts`

让反推结果更准确的补充指令

第一次生成的提示词不够准确时，可以继续让 AI 对比和修正。

请重新检查参考图片和刚才生成的提示词，找出提示词中遗漏、描述错误或权重不足的部分。

重点检查：

1. 主体位置是否准确。
2. 人物或物体数量是否正确。
3. 拍摄角度和景别是否一致。
4. 光源方向是否正确。
5. 主色调和冷暖关系是否准确。
6. 前景、中景和背景是否完整。
7. 是否加入了原图中不存在的元素。

请根据检查结果重新输出一版更准确、更简洁的提示词。

一个更高效的一次性提示词

不想分三次操作，也可以使用下面这套完整指令：

请根据我上传的参考图片，完成一次AI生图提示词反向分析。

第一步，详细分析图片中的主体、场景、人物动作、视觉风格、色调、光线、构图、材质、镜头和关键细节。

第二步，根据分析结果生成一套能够尽量还原原图视觉效果的中文和英文提示词。

第三步，将提示词优化成适合【工具名称】直接使用的版本，并补充负面提示词与必要参数。

要求：

- 使用具体、可视化的描述。
- 不要只使用“高级感”“电影感”“精美”等空泛词语。
- 不要添加原图中不存在的内容。
- 清楚区分图片中能够确认的信息和根据画面推测的信息。
- 不要声称能够恢复原作者的真实提示词。
- 最终结果必须可以直接复制使用。

使用时需要注意的三个问题

1. AI 无法保证恢复原始提示词

同一张图片可以由多套不同提示词生成。反推提示词的本质，是根据最终画面重新描述视觉信息，而不是读取图片背后的原始 Prompt。

2. 图片中的文字需要单独处理

AI 对招牌、海报、包装和界面文字的识别可能出现错误。涉及准确文字时，应手动提供文字内容，不要完全依赖图片反推。

3. 参数不能机械照搬

采样器、步数、CFG、模型版本和 LoRA 权重主要适用于 Stable Diffusion 类工具。Midjourney、Gemini、ChatGPT 图像生成和即梦等平台使用不同的控制方式，不应强行套用相同参数。

适用场景

这套 AI 反推提示词工作流适合用于：

分析优秀摄影作品的构图和光线
学习商业海报的视觉结构
复刻相近的插画或 3D 风格
提取网站 Banner 的画面语言
优化产品图和电商主图提示词
将参考图片转换成 Midjourney 或 Stable Diffusion Prompt
建立个人 AI 图片提示词素材库

建议把反推得到的内容当作初始版本，再根据实际生成结果不断调整主体、构图和光线，而不是一次生成后直接结束。

AI Skills 入门教程：用一个 SKILLs.md，让 AI 记住你的工作方法

Tue, 28 Jul 2026 15:54:00 +0800

每次让 AI 写周报、整理会议纪要或分析数据，都要重新解释格式、语气和步骤？

这类问题可以通过 AI Skills 解决。

Skills 可以理解为写给 AI 的一份“标准操作手册”：它把任务说明、执行规则、参考案例和所需资源整理在一个文件夹中。当用户提出相关需求时，支持 Agent Skills 的 AI 工具可以读取并执行这些规则。

简单来说：普通提示词只服务于当前对话，Skills 更适合保存可重复使用的工作流程。

Skills 是什么？

一个 Skills 通常对应一项明确任务，例如：

根据工作记录生成周报
按固定标准审核文章
整理会议纪要并提取待办事项
检查代码中的安全问题
按品牌规范生成营销文案

官方 Agent Skills 规范将 Skills 定义为一种轻量级开放格式。最基础的 Skills 是一个文件夹，其中必须包含 Skills.md；复杂 Skills 还可以附带脚本、模板、示例和参考资料。

Skills 能解决什么问题？

1. 减少重复沟通

不需要每次都重新说明：

输出包含哪些栏目
使用什么语气
哪些内容不能出现
数据应该如何展示
最终结果采用什么格式

2. 统一输出标准

多人或多次使用同一个 Skills 时，可以尽量保持相同的结构、流程和判断标准。

3. 沉淀个人工作方法

当你发现一套提示词效果很好，可以把它整理成 Skills，而不是让它一直留在聊天记录中。

需要注意的是，Skills 并不是让 AI 获得真正的“永久记忆”。它更像一份保存在本地或项目目录中的规则文件：只有工具能够发现并加载它时，规则才会生效。

Skills 的基本目录结构

一个标准 Skills 不只是单独散落的文本文件，而是一个独立文件夹：

weekly-report/
├── Skills.md
├── references/
│   └── report-example.md
└── templates/
    └── weekly-report-template.md

其中：

Skills.md：必需，写明名称、用途和执行规则
references/：可选，存放参考资料或优秀案例
templates/：可选，存放固定模板
scripts/：可选，存放需要执行的辅助脚本

Anthropic 和 OpenAI 的官方文档都将 Skills 描述为包含指令、资源以及可选脚本的任务能力包，而不只是一个简单提示词。

三步写出第一个 Skills

下面以“周报助手”为例。

第一步：写清楚名称和触发条件

在 Skills.md 顶部加入 YAML 元数据：

---
name: weekly-report
description: 根据用户提供的本周工作记录生成中文周报。当用户要求写周报、整理本周工作，或提交一组工作记录时使用。
---

至少应写清楚：

name：Skills 的名称
description：它能做什么，以及什么时候应该使用

description 不要只写“处理文档”或“提高效率”，否则 AI 很难判断什么时候需要调用它。

第二步：把要求改成可执行规则

不要只写：

1
2

写得专业一点。
内容简洁一些。

这种描述过于主观，不同模型可能有不同理解。

可以改成：

# 周报生成规则

收到用户的工作记录后，按以下顺序处理：

1. 将内容分为：
   - 本周完成
   - 进行中
   - 下周计划

2. 每条内容优先保留：
   - 项目名称
   - 完成数量
   - 当前进度
   - 产生的结果
   - 后续动作

3. 不得虚构用户未提供的数据。

4. 没有具体数字时，保留原始事实，并注明“未提供量化数据”。

5. 删除“积极推进”“持续赋能”“圆满完成”等空泛表达。

6. 每条控制在两句话以内。

7. 最后增加一段不超过80字的本周总结。

这些规则能够直接执行，也更容易检查结果是否合格。

第三步：提供输入与输出示例

示例能帮助 AI 理解你真正想要的效果。

# 示例

## 输入

- 完成用户调研
- 修复了几个登录页面的问题
- 数据看板还在调整
- 下周准备上线新活动

## 输出

### 本周完成

1. 完成用户调研，共收集326份有效问卷，并整理出15条核心反馈。
2. 修复登录页面3个影响用户使用的问题，登录功能已通过测试。

### 进行中

1. 数据看板重构已完成约60%，预计下周完成剩余图表和筛选功能。

### 下周计划

1. 完成数据看板重构并提交测试。
2. 上线新用户活动，持续跟踪访问量和注册转化率。

### 本周总结

本周重点完成用户调研和登录功能修复，数据看板重构按计划推进，下周将进入功能上线和数据验证阶段。

示例越接近真实工作场景，输出通常越稳定。

可直接复制的完整 Skills.md

---
name: weekly-report
description: 根据用户提供的工作记录生成结构清晰的中文周报。当用户要求写周报、总结本周工作或发送零散工作记录时使用。
---

# 周报助手

## 目标

将用户提供的零散工作记录整理为可以直接发送的中文周报。

## 执行步骤

1. 阅读全部工作记录。
2. 合并重复事项。
3. 按“本周完成、进行中、下周计划”分类。
4. 保留项目名称、数量、进度、结果和下一步动作。
5. 生成结构清晰的 Markdown 周报。

## 输出结构

### 本周完成

列出已经完成并产生结果的事项。

### 进行中

列出尚未完成的任务，并说明当前进度和下一步动作。

### 下周计划

列出下周需要执行的具体任务。

### 本周总结

使用不超过80字总结本周重点、进展和风险。

## 写作规则

- 使用平实、清晰的中文。
- 每条内容不超过两句话。
- 优先使用具体数字、进度和结果。
- 不使用“积极推进”“持续赋能”“圆满完成”等空泛表达。
- 不得编造用户没有提供的信息。
- 信息不足时，保留原意并注明缺少的数据。
- 默认使用 Markdown 格式。

## 示例

输入：

- 完成客户调研
- 修复登录页面问题
- 看板还在调整
- 下周上线活动

输出：

### 本周完成

1. 完成客户调研，并整理主要需求和反馈。
2. 完成登录页面问题修复，相关功能已恢复正常。

### 进行中

1. 数据看板仍在调整，下一步将完善图表和筛选功能。

### 下周计划

1. 完成数据看板调整并提交测试。
2. 上线新活动并跟踪用户参与数据。

### 本周总结

本周完成客户调研和登录问题修复，数据看板正在推进，下周重点为活动上线和数据验证。

新手常见的三个错误

触发条件太模糊

错误写法：

用于处理工作。

推荐写法：

`1`	`当用户要求生成周报，或提交本周工作记录时使用。`

规则只有形容词

错误写法：

`1`	`写得专业、简洁、有深度。`

推荐写法：

`1`	`正文不超过500字，每条不超过两句话，每项至少保留一个结果或进度信息。`

一个 Skills 承担太多任务

不建议把“写周报、做PPT、分析数据、发送邮件”全部放进同一个 Skills。

更合理的方式是拆成多个独立 Skills：

weekly-report/
meeting-notes/
data-analysis/
email-reply/

一个 Skills 只解决一类明确问题，通常更容易触发，也更方便维护。

使用第三方 Skills 前要注意什么？

不要看到 GitHub 上的 Skills 就直接安装。

第三方 Skills 可能附带脚本、命令或外部资源。使用前至少检查：

Skills.md 要求 AI 执行哪些操作
是否包含 scripts/ 等可执行文件
是否会读取环境变量、密钥或私人文件
是否要求上传数据到外部服务
GitHub 仓库是否持续维护

研究已经指出，Agent Skills 生态存在指令注入、恶意脚本和供应链风险，因此第三方 Skills 应当像第三方代码一样审查，而不是只把它当作文档。

去哪里找现成的 Skills？

可以从以下官方项目开始：

建议先阅读官方示例，再根据自己的工作流程修改。不要直接复制一个功能复杂的 Skills，然后期待它完全符合自己的需求。

总结

写 Skills 的关键，不是堆积大量提示词，而是把一项任务说明清楚：

什么时候使用
按什么步骤执行
必须遵守哪些规则
最终输出什么格式
什么样的结果才算合格

第一次可以从最常用、最重复的一项任务开始，例如周报、会议纪要或文章审核。先完成一个简单可用的版本，再根据实际输出逐步补充规则和示例。

用 AI 做深度研究：STORM 方法图解与 4 组实用提示词

Tue, 28 Jul 2026 11:22:00 +0800

很多人使用 AI 做研究时，采用的方式仍然是：

提出一个问题，等待 AI 给出一段完整答案。

这种方法适合快速了解概念，却很难完成真正的深度研究。

原因很简单：当问题比较复杂时，不同领域、不同利益关系和不同立场的人，往往会得出完全不同的结论。只让 AI 给出一个答案，通常只能得到经过压缩的主流观点，而看不到观点之间的矛盾、证据强弱和尚未解决的问题。

更有效的方法，是让 AI 先从多个视角提出问题，再检索资料、比较证据、整理冲突，最后形成结构化结论。

这正是斯坦福大学 OVAL 实验室提出的 STORM 方法所关注的问题。

一、什么是 STORM？

STORM 的全称是：

Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking

可以理解为：

通过信息检索和多视角提问，综合生成主题大纲。

STORM 是斯坦福 OVAL 实验室开发的一套 AI 知识研究与长文生成系统。它的目标并不是让 AI 直接写出答案，而是在写作之前先完成更充分的资料调查。

其核心流程包括：

发现与研究主题相关的不同视角；
模拟不同视角的提问者；
根据可靠的网络资料回答问题；
整理收集到的信息；
生成结构化文章大纲；
按照大纲撰写带有引用来源的长文。

因此，STORM 更适合处理需要多来源、多视角和结构化分析的复杂问题。

例如：

某项新技术是否值得采用；
一个商业模式是否可持续；
某个行业未来可能如何变化；
一项政策会影响哪些群体；
一个产品是否值得长期投入；
某个社会观点是否有充分证据支持。

需要注意的是，下面介绍的“四步提示词工作流”并不是 STORM 官方固定模板，而是根据其多视角提问、检索、整理与验证思想改造出来的实用方法。

二、第一步：多视角扫描

面对复杂问题时，不要立即要求 AI 给出最终结论。

第一步应该让 AI 从多个角色出发，分别提出观点、证据和疑问。

多视角扫描提示词

将下面的提示词复制给支持联网搜索的 AI，并替换其中的研究主题。

你是一名深度研究助手。

请围绕以下主题展开多视角研究：

【研究主题】
在这里填写需要研究的问题。

请分别模拟以下五种角色：

1. 实践者：关注真实执行经验、现实限制和理论与实际之间的差距。
2. 学者：关注同行评审研究、理论模型、数据质量和学术共识。
3. 怀疑者：挑战主流观点，提出最有力的反方论证。
4. 经济学家：分析利益关系、成本结构、激励机制和资源分配。
5. 历史学家：寻找历史案例、长期规律和类似事件。

每个角色分别输出：

- 核心立场；
- 支持该立场的三个主要论据；
- 可以查证的证据或来源；
- 该视角最担心的问题；
- 一个其他角色可能忽略的重要信息；
- 当前结论的置信度，使用高、中、低表示。

要求：

- 不得虚构研究、统计数据、专家观点或来源；
- 将事实、推测和观点分开表达；
- 优先引用原始资料、官方文件和学术论文；
- 无法确认的信息必须明确标注；
- 不要急于给出统一结论。

这一步的重点不是马上判断谁对谁错，而是尽可能展开问题的不同侧面。

三、第二步：绘制矛盾图

多视角研究真正有价值的地方，不是得到五段相似的介绍，而是发现它们之间的分歧。

例如：

学术研究认为某种方法有效，但实践者认为执行成本太高；
经济学家认为市场会迅速接受，但历史学家发现类似技术曾多次失败；
多数观点支持某项政策，但怀疑者指出研究样本存在偏差。

这些冲突往往比单独的观点更值得研究。

矛盾图需要分析什么？

1. 直接矛盾

找出无法同时成立的结论。

例如：

1
2
3

观点 A：AI 可以显著降低企业运营成本。

观点 B：企业部署 AI 后，短期运营成本反而会上升。

这两个观点看似冲突，但可能分别讨论了长期成本和短期成本。

因此，还需要继续检查：

双方讨论的是不是同一时间范围；
使用的是不是同一种衡量标准；
研究对象是否相同；
是否存在隐藏的前提条件。

2. 证据强弱

不是所有观点都具有相同可信度。

可以按照以下顺序评估来源：

原始数据和官方文件；
同行评审论文；
系统性综述或专业机构报告；
企业公开报告；
专家访谈；
新闻报道；
个人经验；
无法验证的网络观点。

来源级别高，并不代表结论一定正确，但通常更容易核验。

3. 跨视角共识

如果立场不同的角色仍然同意某个判断，这部分信息通常更值得重视。

例如，实践者、学者和怀疑者可能都认为：

当前证据不足以支持大规模部署。

这类跨立场共识，可以作为阶段性判断的重要依据。

4. 研究空白

还要检查哪些关键问题没有被任何角色提到。

常见空白包括：

缺乏长期数据；
没有分析失败案例；
忽略特定地区或人群；
缺少实际成本数据；
没有讨论实施条件；
没有考虑政策变化；
只引用单一语言或单一国家的资料。

矛盾分析提示词

请基于上一轮五个角色的研究结果，绘制一份“观点矛盾图”。

按照以下结构输出：

## 一、主要观点列表

列出每个角色最核心的结论。

## 二、直接冲突

找出彼此对立或无法同时成立的观点。

对每组冲突分别说明：

- 冲突双方；
- 具体分歧；
- 双方使用的证据；
- 双方是否讨论了不同对象、时间范围或前提条件；
- 当前哪一方的证据更强；
- 还需要什么信息才能解决争议。

## 三、证据强度排序

将主要观点按照证据可靠性排序，并说明理由。

优先考虑：

1. 原始数据；
2. 官方资料；
3. 同行评审论文；
4. 专业机构报告；
5. 企业资料；
6. 新闻报道；
7. 专家或个人观点。

## 四、跨视角共识

找出多个角色共同认可的部分，并说明：

- 有多少角色支持；
- 是否存在可靠来源；
- 是否可以视为阶段性事实；
- 仍有哪些限制条件。

## 五、研究盲区

指出当前分析中无人讨论或证据不足的领域。

要求：

- 不要为了形成结论而强行消除矛盾；
- 将事实冲突和价值判断冲突分开；
- 对证据不足的部分明确标注“不确定”；
- 不得用来源数量代替来源质量。

四、第三步：合成研究简报

完成多视角扫描和矛盾分析后，再让 AI 整合信息。

这时生成的结论会比直接提问更有层次，因为 AI 已经知道：

有哪些主要观点；
哪些观点存在冲突；
哪些证据比较可靠；
哪些问题仍然没有答案。

一份合格的研究简报应该包含什么？

1. 一句话总结

用一句话概括当前最重要的研究结论。

它不应该只是重复标题，而应该直接回答：

综合现有证据，目前最合理的判断是什么？

2. 五个关键发现

按照可靠程度排序，而不是按照表达是否精彩排序。

每个发现应该包含：

结论；
主要证据；
反方意见；
适用条件；
置信度。

3. 隐藏的关联

寻找只有结合多个视角才能发现的关系。

例如：

技术效果很好，但组织激励阻碍了落地；
市场需求真实存在，但现有商业模式无法盈利；
学术证据支持短期效果，却缺少长期风险数据；
历史案例失败，并非技术问题，而是成本和监管问题。

这类跨视角联系，往往是深度研究最有价值的部分。

4. 可操作建议

研究结果最终要能够帮助用户做出判断或采取行动。

建议应该具体到：

先做什么；
暂时不要做什么；
需要验证什么；
应该设置什么条件；
在什么情况下停止；
在什么情况下扩大投入。

5. 下一步研究问题

一份可信的研究不会假装所有问题都已经解决。

它应该明确指出：

哪些结论仍然不确定；
需要补充哪些数据；
哪些变量最可能改变结论；
未来应该持续关注什么。

研究简报提示词

请基于前面的多视角研究和矛盾分析，生成一份结构化研究简报。

按照以下格式输出：

# 研究主题

## 一句话结论

用一句准确、克制的语言概括当前最重要的发现。

## 五个关键发现

按照可靠性从高到低排序。

每个发现包含：

- 结论；
- 主要证据；
- 支持来源；
- 反方观点；
- 适用条件；
- 置信度。

## 主要争议

总结目前仍未解决的核心矛盾，并说明争议产生的原因。

## 隐藏的关联

列出至少三个只有综合多个视角才能发现的深层联系。

## 可操作建议

分别给出：

- 现在可以执行的行动；
- 执行前需要验证的条件；
- 暂时不建议采取的行动；
- 需要持续观察的指标。

## 研究限制

说明资料、数据、时间范围、地域和研究方法存在的限制。

## 下一步问题

列出五个值得进一步研究的问题。

要求：

- 不要把推测写成事实；
- 不要隐藏相互矛盾的证据；
- 每项重要结论尽量附带可核验来源；
- 建议必须能够追溯到前面的研究发现；
- 没有充分证据时，使用审慎措辞。

五、第四步：让 AI 自我评估

AI 给出结构化报告之后，还不能立即把它当作最终答案。

最后一步是让 AI 重新审视自己的研究过程。

这一步主要用于发现：

证据不足；
来源质量不高；
观点偏向单一；
推理跳跃；
结论过度确定；
忽略反例；
将相关性误写成因果关系。

自我评估的四个重点

1. 结论置信度

让 AI 对每个关键结论分别评分，而不是只给整篇报告一个总分。

可以采用以下标准：

高置信度：多个高质量独立来源相互支持；
中等置信度：有一定证据，但存在范围或方法限制；
低置信度：证据较少、来源单一或主要依赖推测。

2. 最薄弱的部分

要求 AI 主动指出：

哪个发现证据最少；
哪条因果关系最可疑；
哪个数据最可能过时；
哪个来源可能存在利益冲突；
哪项建议最依赖特定假设。

3. 视角偏差

检查研究是否遗漏了重要群体。

例如：

只分析企业，没有分析消费者；
只分析支持者，没有分析反对者；
只分析欧美市场，没有分析其他地区；
只关注技术，没有关注法律和伦理；
只看成功案例，没有看失败案例。

4. 外部专家审查

可以让 AI 模拟教授、行业专家或审稿人进行批评。

但要注意：模拟评分只是帮助发现问题，不能代替真实专家评审。

自我评估提示词

请对上一份研究简报进行严格的自我评估。

不要继续扩写报告，而是站在审稿人的角度寻找问题。

按照以下结构输出：

## 一、结论置信度

对每个关键发现分别给出：

- 置信度：高、中或低；
- 支持该结论的证据；
- 降低可信度的因素；
- 哪些新证据可能改变结论。

## 二、最薄弱的三个环节

分别说明：

- 薄弱点是什么；
- 为什么薄弱；
- 是否存在推理跳跃；
- 应该补充什么资料。

## 三、来源质量检查

检查：

- 是否过度依赖单一来源；
- 是否引用了二手资料而没有找到原始来源；
- 是否存在利益冲突；
- 是否混用了不同时间、地区或统计口径的数据；
- 是否存在无法核验的来源。

## 四、视角偏差检查

分析：

- 哪个角色的影响过大；
- 哪些关键利益相关者没有被纳入；
- 是否遗漏法律、伦理、环境、地域或文化视角；
- 是否忽略失败案例和反例。

## 五、推理错误检查

重点检查：

- 是否把相关性当成因果关系；
- 是否存在过度概括；
- 是否以偏概全；
- 是否使用未经证明的前提；
- 是否因为多数观点一致就直接判断为事实。

## 六、模拟专家评分

假设由一位严格的大学教授或行业研究负责人评分：

- 研究广度：满分20分；
- 证据质量：满分20分；
- 逻辑严谨性：满分20分；
- 反方观点处理：满分20分；
- 可操作性：满分20分。

给出总分，并说明最需要修改的三处内容。

## 七、修订建议

按优先级列出下一轮研究需要完成的工作。

要求：

- 不要为原报告辩护；
- 优先寻找可能推翻结论的证据；
- 明确区分已知事实、合理推断和未知信息；
- 不得虚构新的来源。

六、如何连续使用这四组提示词？

实际操作时，可以按照以下顺序执行：

确定研究问题
↓
多视角扫描
↓
绘制矛盾图
↓
合成研究简报
↓
执行自我评估
↓
补充检索与人工核验
↓
形成最终结论

不要一次把四组提示词全部发给 AI。

更合适的方法是逐步执行，因为每一步都需要检查上一轮结果。

例如：

先执行多视角扫描；
删除明显无关或重复的观点；
要求 AI 补充缺失来源；
再执行矛盾分析；
检查冲突是否真实存在；
再生成研究简报；
最后执行自我评估；
人工打开关键来源进行核验。

这样能够减少错误在不同阶段不断累积。

七、如何提出一个适合深度研究的问题？

问题越模糊，研究结果越容易变成泛泛介绍。

不推荐这样问：

`1`	`AI 未来怎么样？`

可以改成：

`1`	`未来三年，生成式 AI 会如何影响中国中小型外贸企业的内容营销、人力成本和客户服务？请重点分析实际部署成本、数据安全和投资回报。`

不推荐这样问：

`1`	`独立站还有必要做吗？`

可以改成：

`1`	`对于预算有限的中国中小企业，在 Google 搜索流量受到 AI Overview 影响的情况下，2026 年继续建设品牌独立站是否仍然具有长期价值？`

一个好的研究问题通常包含：

研究对象；
时间范围；
地域范围；
需要比较的方案；
关注的指标；
最终需要支持的决策。

八、STORM 方法适合哪些场景？

STORM 式多视角研究更适合以下任务：

商业决策

例如：

是否进入一个新市场；
是否采用某项新技术；
是否更换供应商；
是否开发某类产品；
是否调整营销渠道。

行业研究

例如：

AI 搜索会如何影响传统 SEO；
自动化会如何改变某个职业；
某类材料是否具备增长潜力；
某项政策会怎样影响行业。

产品与技术选型

例如：

WordPress 与 Next.js 如何选择；
是否需要自建大模型；
某个开源项目是否适合生产环境；
云服务与本地部署哪个成本更低。

内容创作

例如：

深度博客文章；
行业趋势报告；
产品研究报告；
商业分析文章；
带引用的知识型内容。

学习复杂概念

例如：

比较不同经济理论；
分析历史事件；
理解存在争议的科学问题；
梳理一个跨学科主题。

九、哪些情况不需要使用 STORM？

并不是所有问题都需要深度研究。

以下任务通常直接提问即可：

查询一个明确日期；
翻译一段文字；
修正错别字；
进行简单计算；
编写一个基础函数；
查询一个稳定定义；
调整一段文案语气。

如果一个问题只有明确答案，就没有必要模拟多个专家制造无意义的分歧。

STORM 更适合以下特征的问题：

问题本身比较复杂；
存在明显争议；
不同群体立场不同；
需要综合多个来源；
结论会影响重要决策；
需要形成长篇研究报告。

十、使用 AI 深度研究时需要注意什么？

1. 多视角不等于真实专家

AI 模拟的实践者、学者或经济学家，并不是真实专家。

这些角色的作用是帮助展开问题，而不是提供专家资质。

2. 有引用不代表引用正确

AI 可能出现：

链接与结论不匹配；
引用二手报道；
错误理解论文内容；
引用已经过时的数据；
找到同名但无关的资料。

关键来源仍然需要人工打开核验。

3. 共识不一定就是事实

多个 AI 角色可能共享同一训练偏差，因此它们同时认同某个观点，并不能自动证明观点正确。

4. 复杂输出可能掩盖错误

表格、评分、引用和专业术语会让报告看起来更可信，但排版精美不等于证据可靠。

5. 研究结果具有时间限制

涉及技术、市场、法律、价格、公司和政策的信息可能快速变化。

最终报告中应该标明：

检索日期；
数据时间范围；
资料来源；
尚未核实的内容；
研究适用边界。

总结：不要让 AI 只给答案，要让它展示研究过程

传统的 AI 问答通常是：

1
2
3

提出问题
↓
生成答案

STORM 式研究则更接近：

拆解问题
↓
发现不同视角
↓
提出多维度问题
↓
检索外部资料
↓
比较证据与矛盾
↓
形成结构化大纲
↓
生成研究简报
↓
评估结论可信度

两者最大的区别，不是最终文章更长，而是研究过程更加透明。

当一个问题涉及争议、利益、风险或长期决策时，不要急着让 AI 给出确定答案。先让它寻找不同视角、展示矛盾、比较证据，再决定哪些结论值得相信。

AI 深度研究真正有价值的地方，不是替你思考，而是帮助你发现原本没有想到的问题。

项目地址

STORM 在线版属于研究预览，生成的报告仍可能包含错误。涉及医疗、法律、金融、商业投资或其他重要决策时，应进一步核对原始资料，并咨询对应领域的专业人士。

Skills 创建全流程：从需求规划到测试落地，零基础也能完成

Tue, 28 Jul 2026 11:08:00 +0800

很多人第一次接触 Skills 时，会认为它只是一个写了提示词的 Markdown 文件。

实际上，一个真正稳定、可复用的 Skill，更像是一份专门交给 AI 执行的标准作业流程。它不仅要告诉 AI“做什么”，还要说明什么时候启用、按照什么步骤执行、需要读取哪些资料，以及最终应该输出什么结果。

本文将完整梳理 Skills 创建流程，从前期规划、目录初始化、SKILL.md 编写，到验证与实际测试。即使没有开发经验，也可以按照步骤逐步完成。

一、什么是 Skill？

Skill 是一个独立的文件夹，其中包含 AI 完成特定任务所需要的说明、脚本、参考资料和模板资源。

它可以把通用 AI 转变成更适合某项工作的专业助手，例如：

按固定格式撰写产品介绍
根据公司规范回复客户邮件
自动分析 Excel 或 CSV 数据
按统一标准生成网站文章
批量处理图片或 PDF 文件
调用特定 API 完成固定工作流
根据团队规范检查代码

一个 Skill 通常围绕一个明确任务设计，而不是试图解决所有问题。

第一阶段：前期规划

在创建文件之前，先把 Skill 的目标和使用方式规划清楚。

这一步看似没有写代码，却会直接决定 Skill 是否容易触发、执行是否稳定，以及后续是否方便维护。

1. 明确 Skill 的目标

建议从以下四个方面定义目标。

1.1 功能描述

首先说明这个 Skill 具体解决什么问题。

不要只写：

帮助用户处理内容。

这种描述过于宽泛，AI 很难判断应该在什么情况下调用它。

更清晰的写法是：

根据用户提供的原始资料，生成适合个人博客发布的中文 Markdown 文章，并补充标题、文章结构、SEO 关键词、标签和项目地址。

功能描述越具体，后续越容易设计执行流程。

1.2 适用场景

明确用户在什么情况下需要使用这个 Skill。

例如：

用户要求润色个人博客文章
用户提供视频文案，希望整理成教程
用户希望生成可直接复制的 Markdown 内容
用户希望补充 GitHub 项目地址
用户要求文章适合 Google SEO 和 AI 搜索引用

适用场景也是 Skill 判断是否应该触发的重要依据。

1.3 预期输出

提前规定 Skill 完成任务后应该交付什么。

例如：

1. 原文问题分析
2. 建议补充的信息
3. 优化后的文章标题
4. 可直接复制的 Markdown 正文
5. SEO 描述
6. Tags 标签
7. 项目地址

输出格式越明确，多次执行时的结果越稳定。

1.4 限制条件

同时还要说明 Skill 不应该做什么。

例如：

不虚构测试数据
不编造 GitHub Stars 数量
无法确认的信息需要明确标注
不堆砌 SEO 关键词
不在文章中保留明显错别字
不泄露 API Key、密码或个人隐私
未经确认不得执行删除、付款或生产环境修改

限制条件可以减少 AI 自由发挥过度造成的问题。

2. 分析实际需求

目标明确后，需要从用户、技术、性能和兼容性四个维度继续分析。

2.1 用户需求

先判断谁会使用这个 Skill，以及他们会如何提出请求。

建议至少准备 3～5 个真实示例。

例如，创建一个博客文章优化 Skill 时，用户可能会这样说：

`1`	`帮我把这段视频文案整理成博客文章。`

`1`	`重新润色这篇文章，并补充 GitHub 项目地址。`

`1`	`生成可以直接复制到 Hugo 网站中的 Markdown 内容。`

`1`	`让文章更适合 Google SEO 和 AI 搜索引用。`

这些真实表达可以帮助你完善 Skill 的触发描述。

2.2 技术需求

检查 Skill 是否需要额外工具或文件。

常见资源包括：

Python 或 Bash 脚本
API 接口
MCP 服务
浏览器搜索能力
GitHub 项目资料
公司内部文档
Markdown 模板
图片、Logo 或字体
Excel、PDF、Word 处理工具

并不是每个 Skill 都需要脚本。

能够通过清晰文字说明完成的任务，优先写在 SKILL.md 中；只有重复、容易出错或需要固定结果的操作，才更适合使用脚本。

2.3 性能需求

提前考虑执行成本和效率，例如：

是否需要联网搜索
是否会读取大型文件
是否需要处理大量图片
是否会调用付费 API
是否需要批量执行
是否存在较长的运行时间
是否需要限制 Token 消耗

Skill 内容也不宜无限扩张。应只保留 AI 真正需要的规则，把较长的资料放入 references/，需要时再读取。

2.4 兼容性需求

确认 Skill 将在哪些平台或环境中运行，例如：

Codex
Claude Code
GitHub Copilot
Cursor
Gemini CLI
Windows
macOS
Linux
Docker
团队内部 Agent 平台

不同平台对 Skill 的安装路径、元数据和调用方式可能不同，因此不要默认一个 Skill 在所有环境中都能完全通用。

第二阶段：正式创建 Skill

规划完成后，就可以开始建立目录和编写内容。

3. Skill 命名规范

建议使用：

小写英文字母
数字
连字符 -

不要使用：

空格
中文文件夹名
下划线
大写字母
含义不清的缩写

正确示例：

`1`	`blog-content-optimizer`

`1`	`fabric-email-writer`

`1`	`github-project-researcher`

不推荐：

`1`	`My Skill`

`1`	`blog_skill`

新建技能

文件夹名称应该与 SKILL.md 中的 name 保持一致。

4. 使用 Skill Creator 初始化

如果当前环境中已经安装官方 skill-creator，建议优先使用初始化脚本，而不是手动建立所有文件。

标准命令格式：

`1`	`scripts/init_skill.py <skill-name> --path <output-directory>`

例如，将 Skill 创建到 Codex 默认 Skills 目录：

1
2

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills"

同时创建 scripts/ 和 references/：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references

同时创建脚本、参考资料和静态资源目录：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references,assets

初始化脚本可以自动生成基础模板，减少目录名称、YAML 格式和必要文件写错的概率。

不同版本的 Skill Creator 所在路径可能不同。实际使用时，应以本机安装目录中的 skill-creator 文件为准。

5. 手动创建 Skill 目录

没有初始化脚本时，也可以手动创建。

Windows PowerShell

mkdir my-skill
cd my-skill

New-Item SKILL.md -ItemType File
mkdir scripts
mkdir references
mkdir assets

tree /F

macOS 或 Linux

mkdir my-skill
cd my-skill

touch SKILL.md
mkdir scripts references assets

tree -a

如果系统没有安装 tree，可以使用：

`1`	`find . -maxdepth 3 -print`

或者：

ls -la

需要注意，scripts/、references/ 和 assets/ 都是可选目录。没有实际用途时，不需要为了结构完整而创建空文件夹。

6. 标准目录结构

一个较完整的 Codex Skill 可以采用以下结构：

my-skill/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

各目录作用如下。

`SKILL.md`

这是整个 Skill 的核心文件，必须存在。

它负责说明：

Skill 名称
Skill 的用途
什么时候应该触发
应该按照什么流程执行
应该读取哪些资源
最终输出什么结果
有哪些限制条件

文件名必须写成：

`1`	`SKILL.md`

不建议写成：

`1`	`skill.md`

部分系统区分大小写，错误命名可能导致 Skill 无法被识别。

`agents/openai.yaml`

这是 Codex Skill 推荐使用的界面元数据文件，可用于展示：

Skill 显示名称
简短说明
默认提示语
图标或界面相关信息

它主要服务于 Skill 列表和交互界面，不应代替 SKILL.md 中的核心执行规则。

`scripts/`

用于保存可以重复执行的代码，例如：

scripts/
├── clean_markdown.py
├── validate_output.py
└── export_result.py

适合放入脚本的任务通常具备以下特点：

操作步骤固定
需要重复执行
手动生成容易出错
结果必须保持一致
需要调用本地程序或处理文件

新增脚本后，应实际运行测试，不能只确认代码看起来正确。

`references/`

用于保存参考资料，例如：

references/
├── writing-rules.md
├── seo-checklist.md
├── api-documentation.md
└── company-style-guide.md

较长的背景资料不建议全部塞进 SKILL.md。

可以在 SKILL.md 中说明什么时候读取某份参考资料，让 AI 按需加载，从而减少上下文占用。

`assets/`

用于保存最终任务可能使用的静态资源，例如：

assets/
├── logo.png
├── article-template.md
├── report-template.docx
└── website-template/

它适合存放：

图片
图标
Logo
文档模板
网页模板
示例文件
需要复制到输出结果中的资源

`LICENSE` 或 `LICENSE.txt`

如果 Skill 准备公开发布或共享给团队，应明确授权方式。

常见许可证包括：

MIT License
Apache License 2.0
GNU GPL
项目自定义许可证

对于仅在个人电脑内部使用的 Skill，许可证通常不是运行所必需的；但公开到 GitHub 前，建议补充清晰的授权文件。

第三阶段：编写 SKILL.md

7. YAML Frontmatter

SKILL.md 顶部需要包含 YAML 元数据。

基础格式：

---
name: my-skill
description: Explain what this skill does and exactly when it should be used.
---

其中最重要的是 description。

它不仅是介绍文字，也是 AI 判断是否调用这个 Skill 的主要依据。

不推荐：

`1`	`description: 一个非常好用的内容处理工具。`

8. 编写执行流程

SKILL.md 正文应该以明确、可执行的规则为主。

下面是一个简单示例：

---
name: blog-content-optimizer
description: Optimize Chinese blog content into clear, credible and copy-ready Markdown. Use when the user provides rough notes, transcripts or existing articles and asks for rewriting, SEO improvement, GitHub project verification, tags or website publishing content.
---

# Blog Content Optimizer

## Workflow

1. Read the complete source material.
2. Correct spelling, command and terminology errors silently.
3. Identify vague, repetitive or overly promotional statements.
4. Determine what factual information is missing.
5. Verify time-sensitive claims and GitHub project information.
6. Rewrite the article in clear Chinese Markdown.
7. Preserve relevant SEO keywords naturally.
8. Add the verified project address at the end.
9. Generate comma-separated tags.

## Output

Return the following sections:

1. 原文存在的问题
2. 建议补充的信息
3. 中文优化版
4. Tags
5. 项目地址

## Rules

- Do not fabricate facts, statistics, Stars or test results.
- Do not stuff keywords.
- Do not mention spelling corrections in the final article.
- Mark information that cannot be verified.
- Keep headings descriptive and easy to quote.
- Prefer concrete steps and examples over marketing language.

这类写法比长篇介绍更有效，因为每一条都可以直接指导 AI 执行。

第四阶段：验证与测试

9. 运行基础校验

完成 Skill 后，可以使用 Skill Creator 提供的验证脚本检查格式。

`1`	`scripts/quick_validate.py <path/to/skill-folder>`

例如：

`1`	`scripts/quick_validate.py ~/.codex/skills/my-skill`

验证工具通常可以发现：

SKILL.md 缺失
YAML 格式错误
缺少 name
缺少 description
文件夹命名不符合规范
Skill 名称与目录不一致

出现错误后，根据提示修改，再重新运行验证命令。

10. 使用真实任务测试

通过格式验证，并不代表 Skill 已经真正可用。

至少准备 3～5 个测试请求，例如：

`1`	`把下面的视频文案整理成可以发布的 Markdown 教程。`

`1`	`检查这篇文章中的 GitHub 项目是否真实，并补充项目地址。`

`1`	`让文章更适合 Google SEO，但不要堆砌关键词。`

`1`	`只修改错别字，不改变原文语气。`

测试时重点观察：

Skill 是否在正确场景触发
不相关请求是否错误触发
输出结构是否稳定
是否遗漏关键步骤
是否读取了正确的参考资料
是否出现虚构内容
脚本是否能够正常运行
多次执行的结果是否基本一致

11. 根据测试结果持续优化

Skill 通常不会一次完成。

更合理的优化循环是：

实际使用
↓
发现遗漏或错误
↓
定位问题来源
↓
修改 SKILL.md、脚本或参考资料
↓
重新验证
↓
再次使用真实任务测试

例如：

经常没有补充项目地址 → 在工作流程和输出格式中同时增加 GitHub 检查要求。
经常错误触发 → 缩小 description 中的使用范围。
经常无法识别用户表达 → 在 description 中增加常见触发场景。
输出格式不稳定 → 提供固定模板或示例。
重复任务消耗较多 Token → 把固定操作改成脚本。

Skill 的价值并不在于文件数量，而在于它能否让同类任务以更稳定、更可预测的方式重复完成。

哪些情况适合使用 Skill Creator？

1. 创建新的 Skill

当你只有一个需求想法，还没有确定目录、执行步骤和输出结构时，可以让 Skill Creator 帮助完成：

需求梳理
使用场景分析
目录初始化
SKILL.md 草稿
资源规划
验证与测试

2. 优化已有 Skill

如果已有 Skill 经常漏步骤、错误触发或输出不稳定，可以使用 Skill Creator：

优化 description
精简冗余内容
补充测试案例
重新规划脚本和参考资料
比较修改前后的执行结果

3. 团队协作

多人共同维护 Skills 时，Skill Creator 可以帮助团队统一：

目录结构
文件命名
输出格式
开发流程
测试标准
版本维护方式

4. 固定且重复的工作流

例如只需要几个固定命令或固定步骤的任务，也适合封装成 Skill：

项目初始化
文件格式转换
批量重命名
发布前检查
固定格式报告生成

不过，任务越简单，Skill 内容越应该保持精简，不需要为了显得完整而增加大量无用说明。

5. 高度定制的业务任务

当任务依赖公司内部规范、专业资料、固定模板或特殊流程时，Skill 可以将这些知识组织成可复用资源。

例如：

面料报价邮件规范
公司品牌文案规则
内部数据库查询方式
特定 API 调用流程
固定交付文件格式

创建 Skill 时的常见错误

错误一：目标范围过大

例如：

`1`	`帮助用户完成所有办公任务。`

这种 Skill 几乎无法稳定触发，也很难测试。

应该拆分成：

1
2
3

customer-email-writer
invoice-data-checker
weekly-report-generator

错误二：只写功能，不写触发场景

如果 description 没有说明什么时候使用，AI 可能无法正确调用。

错误三：把所有资料都写进 SKILL.md

过长的文件会占用更多上下文。

应该将详细资料拆分到 references/，需要时再读取。

错误四：创建大量无用目录

没有脚本就不需要建立空的 scripts/；没有静态资源也不需要建立 assets/。

错误五：脚本没有实际运行

AI 生成的脚本即使语法看起来正确，也可能存在依赖、路径或参数问题，必须实际执行测试。

错误六：只验证格式，不测试效果

格式正确只能证明 Skill 可以被读取，不能证明它能完成真实任务。

错误七：在文件中写入敏感信息

不要把以下内容直接写入 Skill：

API Key
登录密码
Cookie
私钥
客户隐私数据
生产环境凭据

敏感信息应通过安全的环境变量或密钥管理工具提供。

总结

一个标准的 Skills 创建流程，可以归纳为六个步骤：

明确目标
↓
收集真实使用案例
↓
规划 scripts、references 和 assets
↓
初始化并编写 SKILL.md
↓
运行格式验证和真实任务测试
↓
根据实际结果持续迭代

对于零基础用户来说，最重要的不是一次写出复杂的 Skill，而是先选择一个明确、重复出现的小任务。

只要目标清晰、触发场景明确、输出格式固定，并通过真实任务不断测试优化，就可以逐步建立一套属于自己的 AI 工作流程。

Prompt Optimizer：把模糊想法变成可测试、可复用的 AI 提示词

Mon, 27 Jul 2026 22:24:00 +0800

写 AI 提示词时没有思路，很多人的第一反应是继续堆背景、加角色、补格式。

结果往往是提示词越来越长，AI 的回答却不一定更准确。

最近我发现了一个比较实用的开源项目：Prompt Optimizer。它不是单纯把一句话扩写成一大段，而是提供了一套完整的提示词优化流程，包括：

优化原始提示词
测试实际输出
对比优化前后的结果
根据反馈继续迭代
收藏并复用稳定版本

项目在 GitHub 上已经获得超过 3 万个 Star，适合经常使用 ChatGPT、Claude、Gemini、DeepSeek、Grok 等 AI 模型的人。

Prompt Optimizer 是什么？

Prompt Optimizer 是一款开源的 AI 提示词优化工具。

你只需要输入一个比较粗糙的需求，例如：

帮我写一篇介绍网站速度优化的文章。

它会尝试补充任务目标、读者对象、内容结构、输出格式和限制条件，将原本模糊的想法整理成更容易被 AI 理解和执行的提示词。

它真正有价值的地方，不是把提示词写得更长，而是让提示词变得：

目标更明确
条件更完整
输出更可控
测试结果更容易比较
后续更方便重复使用

它和普通提示词扩写工具有什么区别？

普通的提示词生成器通常只完成一次改写。

Prompt Optimizer 更接近一个提示词工作台：你可以优化、测试、比较，再根据结果继续调整。

1. 支持两种提示词优化模式

它可以分别处理：

系统提示词：定义 AI 的身份、长期规则、行为边界和输出标准。
用户提示词：处理某一次具体任务，例如写文章、分析数据、生成代码或制作图片。

这两种提示词的作用不同，分开优化比简单混在一起更容易控制最终结果。

2. 可以对比优化前后的回答

提示词看起来更专业，不代表实际效果一定更好。

Prompt Optimizer 支持分析、单结果评估和多结果对比。你可以使用同一个问题分别测试原始提示词和优化后的提示词，再观察以下变化：

回答是否更准确
结构是否更清晰
是否减少无关内容
是否遵守输出格式
是否真正解决了任务

这种方式比凭感觉判断提示词质量更可靠。

3. 支持多轮迭代

第一次优化不满意，可以继续提出修改方向，例如：

内容太长，需要精简
语言太像 AI
缺少具体示例
输出格式不稳定
需要增加限制条件
需要适配某个特定模型

通过多轮修改，可以逐步得到更符合实际工作需求的提示词。

不只是文字提示词

Prompt Optimizer 也支持图片生成相关工作流，包括：

文生图
图生图
多图生成
参考图风格迁移
图片提示词优化
图片生成结果预览

例如你只输入：

一座漂浮在夜空中的图书馆。

优化后可以进一步明确：

主体位置
镜头视角
空间层次
光线方向
色彩氛围
画面风格
主体与背景关系
不希望出现的元素

这样做不能保证每一次都生成完美图片，但可以减少模型自由发挥带来的随机性，让画面更接近预期。

支持哪些 AI 模型？

根据项目文档，Prompt Optimizer 已支持或兼容多种主流模型和服务，包括：

OpenAI
Gemini
DeepSeek
Grok
智谱 AI
MiniMax
SiliconFlow
Ollama 等本地模型

不同模型对提示词的理解方式并不完全相同，因此实际使用时，最好固定模型进行测试，不要只优化一次就直接在所有模型中通用。

四种使用方式

Prompt Optimizer 提供了多种使用方式。

在线版

适合第一次体验，不需要安装程序。

项目采用纯前端架构，数据主要保存在浏览器本地，并直接与配置的 AI 服务商交互。

使用在线版时仍需注意：不要把公司机密、客户资料、账号密码或未公开代码直接发送给第三方 AI 模型。

桌面版

桌面版适合长期使用，也更方便连接本地模型或存在跨域限制的 API。

项目提供 Windows、macOS 和 Linux 对应的安装包或压缩包，具体版本以 GitHub Releases 页面为准。

Chrome 插件

Chrome 插件适合在浏览器中直接调用提示词优化功能，减少在多个页面之间复制和切换。

Docker 部署

熟悉 Docker 的用户可以将 Prompt Optimizer 部署到自己的服务器或 NAS 中，方便自己使用或在团队内部共享。

私有部署并不等于绝对安全。API Key、访问密码、服务器权限和日志记录仍需要正确配置。

提示词也可以成为可复用资产

很多人写完提示词后就随手丢在聊天记录里，下次遇到相同任务又要重新写一遍。

Prompt Optimizer 支持收藏、版本历史、示例保存和来源绑定，可以将经过验证的提示词整理成自己的提示词库。

例如可以分别保存：

SEO 文章写作提示词
商务邮件翻译提示词
GitHub 项目分析提示词
商品测评提示词
代码审查提示词
网站封面图提示词
客服回复提示词

当提示词经过多次测试并证明稳定后，它就不再是一段临时文字，而是一套可以重复执行的工作流程。

一个简单的使用方法

第一次使用时，可以按照下面的步骤操作：

输入原始需求，不需要一开始就写得很完整。
选择系统提示词或用户提示词优化模式。
检查优化结果是否准确表达了你的真实目的。
使用同一个模型测试原始版和优化版。
对比准确性、完整性、格式和冗余程度。
根据测试结果继续优化。
将稳定版本收藏并命名。
保存一个实际输入与输出示例，方便以后复现。

哪些人适合使用？

Prompt Optimizer 比较适合以下用户：

不熟悉提示词工程的新手
经常使用多个 AI 模型的人
需要稳定生成文章、邮件或代码的人
需要制作 AI 图片提示词的人
希望沉淀团队提示词模板的人
想对比不同提示词实际效果的人
希望把提示词作为工作资产管理的人

使用时需要注意什么？

Prompt Optimizer 可以提高提示词的清晰度，但它不能替代事实核查和人工判断。

使用时建议注意以下几点：

提示词更长不代表更好。 多余背景和重复规则可能增加 Token 消耗，也可能让模型忽略真正重要的要求。
优化后必须测试。 不要只看文字是否专业，应检查实际输出是否改善。
不同模型需要分别验证。 在一个模型上表现良好的提示词，不一定适合所有模型。
不要提交敏感信息。 客户资料、商业机密、密码、私有代码和个人隐私应先脱敏。
保留版本和示例。 只有保存模型、参数、输入和输出示例，后续结果才更容易复现。

总结

Prompt Optimizer 的核心价值，不是自动帮你写出一段看起来复杂的提示词，而是将提示词从一次性的聊天输入，变成一套可以优化、测试、比较和复用的工作资产。

对于偶尔使用 AI 的用户，它可以降低提示词写作门槛。

对于高频使用 AI 的个人或团队，它更适合用来建立稳定的提示词库和测试流程。

真正值得保留的提示词，不是文字最长的那一个，而是经过实际任务验证后，能够稳定得到理想结果的那一个。

项目地址

GitHub：https://github.com/linshenkx/prompt-optimizer
在线版：https://prompt.always200.com
项目文档：https://docs.always200.com

提示：GitHub Star、支持的模型和功能版本会持续变化，请以项目仓库和最新 Release 说明为准。

提示词工程 on 拾光集

AI 反推提示词教程：3 步从参考图片生成可复用的生图提示词

第一步：拆解图片元素

可直接复制的指令

为什么需要先拆解

第二步：反向生成基础提示词

可直接复制的指令

推荐的提示词结构

第三步：优化成指定 AI 工具版本

通用优化指令

Midjourney 提示词优化指令

Stable Diffusion 提示词优化指令

让反推结果更准确的补充指令

一个更高效的一次性提示词

使用时需要注意的三个问题

1. AI 无法保证恢复原始提示词

2. 图片中的文字需要单独处理

3. 参数不能机械照搬

适用场景

相关 GitHub 项目

AI Skills 入门教程：用一个 SKILLs.md，让 AI 记住你的工作方法

Skills 是什么？

Skills 能解决什么问题？

1. 减少重复沟通

2. 统一输出标准

3. 沉淀个人工作方法

Skills 的基本目录结构

三步写出第一个 Skills

第一步：写清楚名称和触发条件

第二步：把要求改成可执行规则

第三步：提供输入与输出示例

可直接复制的完整 Skills.md

新手常见的三个错误

触发条件太模糊

规则只有形容词

一个 Skills 承担太多任务

使用第三方 Skills 前要注意什么？

去哪里找现成的 Skills？

总结

用 AI 做深度研究：STORM 方法图解与 4 组实用提示词

一、什么是 STORM？

二、第一步：多视角扫描

推荐的五个专家视角

1. 实践者

2. 学者

3. 怀疑者

4. 经济学家

5. 历史学家

多视角扫描提示词

三、第二步：绘制矛盾图

矛盾图需要分析什么？

1. 直接矛盾

2. 证据强弱

3. 跨视角共识

4. 研究空白

矛盾分析提示词

四、第三步：合成研究简报

一份合格的研究简报应该包含什么？

1. 一句话总结

2. 五个关键发现

3. 隐藏的关联

4. 可操作建议

5. 下一步研究问题

研究简报提示词

五、第四步：让 AI 自我评估

自我评估的四个重点

1. 结论置信度

2. 最薄弱的部分

3. 视角偏差

4. 外部专家审查

自我评估提示词

六、如何连续使用这四组提示词？

七、如何提出一个适合深度研究的问题？

八、STORM 方法适合哪些场景？

商业决策

行业研究

产品与技术选型

内容创作

学习复杂概念

九、哪些情况不需要使用 STORM？

`SKILL.md`

`agents/openai.yaml`

`scripts/`

`references/`

`assets/`

`LICENSE` 或 `LICENSE.txt`