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 phrases like "这个流程要不要交给大模型做", "我有个跑得很熟的脚本流程, 能不能用 LLM 改造", "我想把这套离线流程升级成 LLM 工作流", "判断一下现在流程合不合适交给大模型", "LLM 改造 ROI 诊断", "评估一下大模型介入的成本收益". Always trigger when the user describes a reusable workflow and wants a go / partial / no-go decision plus ROI reasoning, even if they don't ask for the words "diagnose" or "ROI" explicitly. Do not trigger for one-off prompts that are not a reusable workflow, and do not trigger for general writing / coding tasks.

把一个已有的「离线 / 可复用流程」拆开，看它是否值得交给 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.md	8 维度必问清单 + 退出准则	追问阶段必读
references/scoring_rubric.md	5 维度难度评级描述 + 改造建议触发表	诊断阶段读
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。