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

📋 目录

核心概念
什么是输入/输出键名
什么是自定义 Prompt
完整实战示例
使用技巧总结
常见问题

🎯 核心概念

概念	一句话解释
输入输出键名	节点之间传递数据的"快递单号"，让数据能在节点间正确流转
自定义 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 慢查询： 1. 定位问题 SQL 2. 给出优化建议 3. 评估影响范围输入数据：{{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：为什么我的工作流执行时，后面的节点拿不到前面的数据？

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

排查方法：

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

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

{{input}} 是内置变量，会被自动替换为：

如果有上一个节点，就是上一个节点的输出
如果是第一个节点，就是工作流的初始输入

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

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

告警分析结果：{<!-- -->{alert_result}<!-- -->}
诊断结果：{<!-- -->{diagnosis_result}<!-- -->}
修复结果：{<!-- -->{fix_result}<!-- -->}

Q4：Prompt 可以写多长？

建议控制在 500-1000 字以内。原因：

太长会消耗更多 Token，增加成本
模型上下文窗口有限，太长可能被截断
越简洁，AI 理解越好，输出越稳定

🎯 最佳实践建议

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

📚 进阶学习

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

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

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

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

📋 目录 ​

🎯 核心概念 ​

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

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

💻 工作原理示意图 ​

🔄 数据流转过程详解 ​

1. 节点 A（告警分析）执行完毕，输出： ​

2. 节点 B（根因诊断）拿到数据后分析，再输出： ​

3. 节点 C（执行修复）拿到诊断结果，执行命令后输出： ​

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

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

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

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

❌ 默认情况下，AI 的回答： ​

✅ 加了自定义 Prompt 后，AI 的回答： ​

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

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

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

节点 1：告警分析 ​

节点 2：根因诊断 ​

节点 3：执行修复 ​

使用技巧总结 ​

常见问题 ​

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

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

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

Q4：Prompt 可以写多长？ ​

🎯 最佳实践建议 ​

📚 进阶学习 ​

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

📋 目录

🎯 核心概念

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

📦 类比理解：快递中转站

💻 工作原理示意图

🔄 数据流转过程详解

1. 节点 A（告警分析）执行完毕，输出：

2. 节点 B（根因诊断）拿到数据后分析，再输出：

3. 节点 C（执行修复）拿到诊断结果，执行命令后输出：

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

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

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

💡 为什么需要自定义 Prompt？

❌ 默认情况下，AI 的回答：

✅ 加了自定义 Prompt 后，AI 的回答：

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

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

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

节点 1：告警分析

节点 2：根因诊断

节点 3：执行修复

使用技巧总结

常见问题

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

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

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

Q4：Prompt 可以写多长？

🎯 最佳实践建议

📚 进阶学习