Llm Workflow Diagnoser

Use this skill whenever a user wants to evaluate whether an existing offline / reusable workflow is worth converting into an LLM-driven workflow. Triggers on...

Overlord

@graysilver

What This Skill Does

Evaluates an existing offline or reusable workflow to determine whether it should be converted into an LLM-driven workflow. Outputs a go/partial/no-go decision with an ROI score, difficulty ratings across five dimensions, and an MVP roadmap.

Replaces subjective gut-feel decisions about LLM adoption with a structured, multi-dimensional diagnostic framework that includes ROI scoring, difficulty ratings, and a concrete migration plan.

When to Use It

  • Assess whether a weekly report generation script is worth converting to an LLM workflow
  • Evaluate a customer support FAQ response process for partial LLM automation
  • Diagnose if a daily log-to-summary template workflow should be fully or partially automated with LLM
  • Compare the cost and benefit of introducing LLM into a manual data extraction pipeline
  • Determine the feasibility of replacing a rule-based approval workflow with an LLM-based decision system

Install

$ openclaw skills install @graysilver/llm-workflow-diagnoser

LLM Workflow Diagnoser

把一个已有的「离线 / 可复用流程」拆开,看它是否值得交给 LLM,输出全量改造 / 部分改造 / 不适合的结论 + ROI 分数 + 改造难度评级 + 落地 MVP 路线图。

整套流程由 LLM 主判,叠加一份 8 题追问清单做骨架;不允许用纯规则打分硬给结论。

何时使用 / 何时不使用

触发

  • 用户说一个明确可复用流程("我每周跑一次的报告生成脚本"、"我们客服有一套固定 FAQ 回复流程"、"我每天把日志按模板整理成周报")。
  • 用户想判断它"能不能 / 该不该 / 值不值得"被 LLM 改造成工作流。
  • 用户描述里同时存在触发频率 + 输入来源 + 输出形式 + 错误成本。

不触发

  • 一次性 prompt("帮我写一封邮件"),不是可复用流程。
  • 单纯的代码重构 / bug 修复 / 写文章(请走 clean-code-skill / mubai-writer-v2 / technical-report-writer)。
  • 用户只是想做技术选型,没问"LLM 改造"。

主路径(4 步)

Step 0:入口澄清

如果用户描述里没有提到「流程名 / 触发频率 / 输出形式」中的任意两项,先问一句:

你这次想诊断的「离线流程」大致叫什么名字?多久跑一次?输出长什么样?

不准默认脑补流程主题。不准直接进入追问。

Step 1:追问(最多 6 轮,每轮 3-4 题一批)

references/question_bank.md 的 8 维度出第一组问题,每轮给 3-4 个题,用户可一次答完。

LLM 在收到回答后可补问 0-3 题,针对信息缺口。

退出准则(明确写进追问流程):

  • 已收集到 ≥ 6 个有效回答。
  • 每个维度至少有一个具体答案(不能全是"不知道 / 看情况")。
  • 没有明显冲突的假设(例如用户同时说"完全不能错"和"全自动跑")。

任意一项不满足 → 继续追问;满足 → 进入诊断。

Step 2:LLM 主判

LLM 综合判断改造建议 + 5 维度难度评级:

  • 输入多样性(难度 0-10):输入多样性越高,难度越大。
  • 输出一致性要求(难度 0-10):一致性要求越严格,难度越大。
  • 容错率(难度 0-10):容错率越低(错误代价越高),难度越大。
  • 决策密度(难度 0-10):决策越复杂 / 主观,难度越大。
  • 可验证性(难度 0-10):越难量化验证,难度越大。

按下列标准给最终建议:

建议触发条件
全量改造5 维度难度均值 ≤ 4 + 没有命中任何「不适合」硬护栏 + ROI 分数 ≥ 7
部分改造命中 1-2 个硬护栏,或难度均值 5-7,或 ROI 分数 4-6
不适合命中 ≥ 3 个硬护栏,或 ROI 分数 ≤ 3,或难度均值 ≥ 8

Step 3:报告输出(必须按固定结构原文输出,不写 .md

references/report_template.md 的固定结构,把六个章节原文贴在对话回复里

  1. 诊断说明(含 ROI 分数 xx/10)
  2. LLM 介入边界
  3. 改造难度评级(5 维度 xx/10 表格)
  4. 落地 MVP 路线图
  5. 风险清单
  6. 信息缺口 / 需补充追问(如有)

章节标题必须完全一致。不要写 .md 文件、不要重命名、不要拼接、不要保存到磁盘。


LLM 介入边界地图(写入报告)

报告"LLM 介入边界"章节必须按四个分类组织:

分类含义
硬护栏护住监管 / 合规 / 实时 / 高精度场景,LLM 不能介入;保留原人工或规则路径
仅部分场景适用LLM 可生成候选 / 提供多版本,但必须人工裁决
全量适用决策 / 执行 / 润色都可交给 LLM,必要时保留少量校验
AI 可护住LLM 能补充的具体能力(生成 / 翻译 / 命名 / 检索 / 推理 / 提炼 / 数据能力边界等)

ROI 分数(强制 xx/10)

ROI 分数填在"诊断说明"章节,必须是 0-10 整数或一位小数:

  • 9-10:极高(投入低、收益高、立即回收)
  • 7-8:高(投入低-中、收益中-高、月级回收)
  • 5-6:中(投入中、收益中、季级回收)
  • 3-4:低(投入高、收益低、年级回收)
  • 1-2:极低(投入高、收益微、不可回收)
  • 0:信息不足,无法判断

ROI 分数只允许写在"诊断说明 - ROI 分数"那一行,其他章节不要再写一遍 ROI。


难度评级(强制 xx/10)

报告"改造难度评级"章节必须使用 Markdown 表格,列固定为:

维度 | 难度值(xx/10,10为满分) | 解释

5 个维度固定:

维度难度 0难度 10
输入多样性高度结构化自由文本 / 多模态
输出一致性要求允许多版本严格统一
容错率高容错零容错
决策密度机械转换多步推理 / 创造性
可验证性指标完整难以量化

追问清单(references/question_bank.md 摘要)

8 个必问维度:

  1. 执行方与频率:谁在跑?多久一次?
  2. 输入来源:来自哪里?是否结构化?多样性?
  3. 输出形式:长什么样?可不可以表达成文字 / 结构化语言?是否依赖身体感知 / 物理动作 / 高精度控制?
  4. 关键瓶颈:最耗时 / 最容易出错 / 最依赖经验的环节?
  5. 错误成本:能否被人工兜底?出错会不会直接进生产路径?
  6. 约束:是否需要私有数据 / 离线部署 / 合规约束?
  7. 改造目标:期望提升的是质量 / 效率 / 人力 / 新场景能力?
  8. 可观察数据:有没有日志 / 反馈 / 评分数据可以衡量改造前后?

多轮诊断历史

每次诊断都在对话里原文输出;同主题多次诊断时,新诊断开头用一行"相比上轮变化"做对比,再进入六章节。


核心反模式

  • 跳过追问直接给结论 → ✅ 至少 6 个有效回答 + 每个维度有具体答案才下判断
  • 用纯规则打分直接给"全量 / 部分 / 不适合" → ✅ LLM 主判,维度评分仅做解释
  • 把 ROI 算成精确数字或具体金额 → ✅ 仅给 xx/10 分数
  • 报告塞假案例 / 假数据 → ✅ 关键假设和未答问题显式列出
  • 推荐"未来需要时再加 LLM"这种偷懒话术 → ✅ 给出具体最小可验证动作
  • 不区分"全量 / 部分 / 不适合"硬护栏 → ✅ 命中 ≥ 3 个硬护栏必须落到"不适合"
  • 追问里一次只问一题 → ✅ 每轮 3-4 题一批,最多 6 轮
  • 报告输出到 .md 文件 → ✅ 原文贴在 Chat 里
  • 章节标题改名 / 拼接 / 增删 → ✅ 完全照抄 report_template 的固定结构
  • ROI 写具体金额 → ✅ 仅 xx/10 分数
  • 难度评级只写"中 / 高" → ✅ 必须 xx/10 数字

文件索引

按需加载,不要预先全部读:

文件用途何时读
references/question_bank.md8 维度必问清单 + 退出准则追问阶段必读
references/scoring_rubric.md5 维度难度评级描述 + 改造建议触发表诊断阶段读
references/report_template.md报告六章节固定结构(原文 Chat 输出)出报告时必读
references/examples/full_replace.md"全量改造"样例写报告前对照风格
references/examples/partial_replace.md"部分改造"样例同上
references/examples/not_suitable.md"不适合"样例同上
scripts/diagnose.py打印追问清单 + 报告骨架(辅助)调试或人工查看时用

一句话总结

入口澄清 → 8 维度追问最多 6 轮 → LLM 主判给建议 + 5 维度难度评级 + ROI 分数 → 按固定结构原文贴在 Chat 输出,不写 .md。

Top skills in this category