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 的固定结构，把六个章节原文贴在对话回复里：
- 诊断说明（含 ROI 分数 xx/10）
- LLM 介入边界
- 改造难度评级（5 维度 xx/10 表格）
- 落地 MVP 路线图
- 风险清单
- 信息缺口 / 需补充追问（如有）
章节标题必须完全一致。不要写 .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 个必问维度：
- 执行方与频率：谁在跑？多久一次？
- 输入来源：来自哪里？是否结构化？多样性？
- 输出形式：长什么样？可不可以表达成文字 / 结构化语言？是否依赖身体感知 / 物理动作 / 高精度控制？
- 关键瓶颈：最耗时 / 最容易出错 / 最依赖经验的环节？
- 错误成本：能否被人工兜底？出错会不会直接进生产路径？
- 约束：是否需要私有数据 / 离线部署 / 合规约束？
- 改造目标：期望提升的是质量 / 效率 / 人力 / 新场景能力？
- 可观察数据：有没有日志 / 反馈 / 评分数据可以衡量改造前后？
多轮诊断历史
每次诊断都在对话里原文输出；同主题多次诊断时，新诊断开头用一行"相比上轮变化"做对比，再进入六章节。
核心反模式
- ❌ 跳过追问直接给结论 → ✅ 至少 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。
评论
加载中…