# 工作流数据流转与自定义 Prompt 使用指南

## 📋 目录

- [核心概念](#核心概念)
- [什么是输入/输出键名](#什么是输入输出键名-数据流转)
- [什么是自定义 Prompt](#什么是自定义-prompt-让-ai-按你的想法做事)
- [完整实战示例](#完整实战示例)
- [使用技巧总结](#使用技巧总结)
- [常见问题](#常见问题)

---

## 🎯 核心概念

| 概念 | 一句话解释 |
|------|-----------|
| **输入输出键名** | 节点之间传递数据的"快递单号"，让数据能在节点间正确流转 |
| **自定义 Prompt** | 给 AI 的"任务说明书"，让它知道拿到数据后该做什么、怎么输出 |

---

## 什么是输入/输出键名？（数据流转）

### 📦 类比理解：快递中转站

| 概念 | 类比 | 说明 |
|------|------|------|
| **节点 A** | 发件人 | 执行后产生数据（输出） |
| **节点 B** | 收件人 | 需要节点 A 的数据才能工作（输入） |
| **输出键名** | 快递单号（如 `result`） | 节点 A 把数据打包成一个包裹，贴上个标签 |
| **输入键名** | 取件码（如 `result`） | 节点 B 凭这个标签去取包裹 |

---

### 💻 工作原理示意图

```
┌──────────────┐          ┌──────────────┐          ┌──────────────┐
│   告警分析   │ ───────→ │   根因诊断   │ ───────→ │   执行修复   │
│    节点 A    │          │    节点 B    │          │    节点 C    │
└──────────────┘          └──────────────┘          └──────────────┘
  输出键名:                 输入键名:                 输入键名:
  `alert_analysis`          `alert_analysis`         `root_cause`
                           输出键名:                 输出键名:
                           `root_cause`             `fix_result`
```

---

### 🔄 数据流转过程详解

#### 1. 节点 A（告警分析）执行完毕，输出：
```json
{
  "alert_analysis": "检测到服务器 CPU 占用率过高（95%），进程 ID: 12345"
}
```

#### 2. 节点 B（根因诊断）拿到数据后分析，再输出：
```json
{
  "root_cause": "进程 12345 是恶意挖矿程序，建议立即终止"
}
```

#### 3. 节点 C（执行修复）拿到诊断结果，执行命令后输出：
```json
{
  "fix_result": "已成功终止进程 12345，CPU 使用率已降至 15%"
}
```

---

### ⚠️ 常见错误：键名不匹配

❌ **错误做法**：
- 节点 A 输出键名：`result`
- 节点 B 输入键名：`output`

→ 节点 B 取不到数据，直接报错

✅ **正确做法**：
- 输出键名 **完全等于** 输入键名

---

## 什么是自定义 Prompt？（让 AI 按你的想法做事）

### 📋 类比理解：给员工的"任务说明书"

| 场景 | 效果对比 |
|------|---------|
| **默认 Prompt** | "分析一下输入数据" → AI 自由发挥，结果不可控 |
| **自定义 Prompt** | "你是一名 10 年经验的 DBA，请按照以下格式分析 SQL 慢查询：<br>1. 定位问题 SQL<br>2. 给出优化建议<br>3. 评估影响范围<br><br>输入数据：{{input}}" |

---

### 💡 为什么需要自定义 Prompt？

#### ❌ 默认情况下，AI 的回答：
```
好的，我来分析一下这个告警...
（内容笼统，格式不固定，无法直接用于后续节点）
```

#### ✅ 加了自定义 Prompt 后，AI 的回答：
```
我是一名 10 年经验的运维专家，按照标准故障处理流程分析：

【告警级别】P0 严重
【影响范围】生产数据库 192.168.1.100
【根因分析】慢查询导致锁等待，SQL 语句：SELECT ...
【处理建议】1. 添加索引 idx_user_status；2. 优化 LIMIT 分页
【预计耗时】5 分钟
```

---

### 🎨 高级用法：模板变量替换

你可以在 Prompt 中使用 `{{变量名}}` 来引用前面节点的输出：

```
你是 Linux 运维专家，请执行以下修复命令：

# 根据前面诊断出的进程 ID，终止恶意进程
kill -9 {{root_cause.pid}}

# 验证修复效果
ps aux | grep {{root_cause.process_name}}
```

→ `{{root_cause.pid}}` 会被自动替换成前面节点输出的实际值

---

## 完整实战示例：一个真正能用的工作流

### 🎯 目标：收到告警 → 自动分析 → 自动修复

---

#### **节点 1：告警分析**

| 配置项 | 值 |
|--------|---|
| **输出键名** | `alert_result` |
| **自定义 Prompt** | `你是告警分析专家，请从以下告警中提取：告警级别、服务器IP、告警类型、告警详情。输出严格的 JSON 格式，包含 level、server_ip、type、detail 四个字段。` |

**节点 1 实际输出**：
```json
{
  "alert_result": {
    "level": "P0",
    "server_ip": "192.168.1.100",
    "type": "high_cpu",
    "detail": "CPU 使用率 98% 持续 5 分钟"
  }
}
```

---

#### **节点 2：根因诊断**

| 配置项 | 值 |
|--------|---|
| **输入键名** | `alert_result` ← 必须和节点 1 的输出键名完全一致 |
| **输出键名** | `diagnosis_result` |
| **自定义 Prompt** | `根据以下告警分析结果，诊断根因：<br><br>告警级别：{{alert_result.level}}<br>服务器IP：{{alert_result.server_ip}}<br>告警详情：{{alert_result.detail}}<br><br>请输出 JSON 格式，包含以下字段：<br>1. cause：根因分析<br>2. fix_command：建议修复命令<br>3. risk：风险评估（高/中/低）` |

**节点 2 实际输出**：
```json
{
  "diagnosis_result": {
    "cause": "挖矿病毒进程占用 CPU，进程 ID: 12345",
    "fix_command": "kill -9 12345",
    "risk": "中风险，终止进程不会影响业务"
  }
}
```

---

#### **节点 3：执行修复**

| 配置项 | 值 |
|--------|---|
| **输入键名** | `diagnosis_result` ← 必须和节点 2 的输出键名完全一致 |
| **输出键名** | `fix_result` |
| **自定义 Prompt** | `在服务器 {{alert_result.server_ip}} 上执行以下命令并验证效果：<br><br>{{diagnosis_result.fix_command}}<br><br>执行后验证该进程是否已终止，并输出当前 CPU 使用率。` |

**节点 3 实际输出**：
```json
{
  "fix_result": "已成功终止进程 12345，验证结果：进程不存在，CPU 使用率已降至 12%"
}
```

---

## 使用技巧总结

| 技巧 | 说明 | 示例 |
|------|------|------|
| ✅ **键名要有意义** | 用语义化命名，方便理解和维护 | `alert_result`、`root_cause` |
| ✅ **加版本号** | 后续迭代时方便区分 | `mysql_slow_query_v2` |
| ✅ **Prompt 加身份设定** | 让 AI 更专业，输出更可靠 | `"你是 10 年经验的 DBA..."` |
| ✅ **Prompt 加输出格式** | 确保输出能被后续节点正确解析 | `"输出 JSON 格式，包含 cause、command、risk 三个字段"` |
| ❌ **不要太长** | Prompt 太长会增加 Token 消耗，也可能超过模型上下文限制 | 控制在 500 字以内 |
| ❌ **不要太笼统** | 太笼统会导致 AI 输出不可控 | ❌ `"修复一下"` → ✅ `"执行以下命令并验证效果：..."` |

---

## 常见问题

### Q1：为什么我的工作流执行时，后面的节点拿不到前面的数据？

**最可能原因**：输入键名和输出键名不匹配。

**排查方法**：
1. 检查每个节点的"输入键名"是否等于上一个节点的"输出键名"
2. 键名区分大小写，`Result` 和 `result` 是不同的
3. 不要有多余的空格或特殊字符

---

### Q2：自定义 Prompt 中的 `{{input}}` 是什么意思？

`{{input}}` 是内置变量，会被自动替换为：
- 如果有上一个节点，就是上一个节点的输出
- 如果是第一个节点，就是工作流的初始输入

---

### Q3：可以引用多个前面节点的输出吗？

可以！工作流执行时，所有前面节点的输出都会被合并到上下文中，你可以引用任意一个：

```
告警分析结果：{{alert_result}}
诊断结果：{{diagnosis_result}}
修复结果：{{fix_result}}
```

---

### Q4：Prompt 可以写多长？

建议控制在 500-1000 字以内。原因：
1. 太长会消耗更多 Token，增加成本
2. 模型上下文窗口有限，太长可能被截断
3. 越简洁，AI 理解越好，输出越稳定

---

## 🎯 最佳实践建议

1. **先画流程图**：想清楚每个节点输入什么、输出什么，再开始配置
2. **键名统一规范**：整个项目的键名命名要统一，比如都用 `xxx_result` 格式
3. **Prompt 逐步优化**：先写简单的，测试通过后再细化格式和要求
4. **单节点测试**：每个节点单独测试通过后，再串起来跑整个工作流
5. **善用模板变量**：用 `{{变量名}}` 让数据在节点间灵活传递

---

## 📚 进阶学习

- 学习 Prompt Engineering，掌握更精准的 AI 指令技巧
- 参考预设工作流，学习标准的配置方式
- 多尝试、多测试，找到最适合你场景的配置方式

---

> 💡 **记住**：工作流的威力在于"编排"——把复杂的任务拆解成简单的步骤，让 AI 一步步帮你完成。配置好数据流转和 Prompt，你就能真正实现运维自动化！

---

**文档版本**：v1.0
**最后更新**：2026 年 5 月