工作流解码器

问题：工具在手，不知所用

很多团队把 AI 接入业务流程后，卡在一个尴尬的位置：Agent 能跑、模型能调，但没有人说得清它到底应该先替谁解决什么问题。

更常见的情况是，使用者自己也没想清楚自己的流程。能感觉到"忙"，却拆不出忙在哪些环节；知道某个环节重复、耗时、容易出错，但无法定义输入和输出，也就没办法判断这件事能不能交给 AI。结果是 AI 能力被闲置，或者勉强用起来之后发现自动化了一个本不该自动化的环节。

这个技能要处理的就是这一步：把模糊的工作状态拆成可描述的动作链，再判断哪些部分值得自动化。

工作方式：21 步渐进式提问

它的核心不是给出一套模板化方案，而是通过 21 步结构化提问，让使用者自己在对话中把流程说清楚。

第一阶段：目标倒推（5 步）

从"想要什么结果"切入，而不是从"现在在做什么"。先识别业务场景、定义最终目标，再量化达成后的可见变化、分析当前差距，最后定位最疼的那个缺口。

第二阶段：流程拆解（8 步）

把"忙"拆成具体动作链条。逐个步骤追问：具体在做什么、哪个最耗时、哪个最重复、哪个最容易出错、哪个需要本人判断。尤其关键的是两步隐性知识挖掘——判断依据是什么？如果交给别人，需要告诉他什么？这一步往往能暴露出团队从没写下来过的规则。

第三阶段：AI 可行性评估（5 步）

按任务类型判断自动化倾向：纯信息收集与初稿生成可以全自动；多工具协同与定时触发适合人机协同；涉及商业决策和风险评估的环节暂不自动化。同时追问两个风险问题：自动化后最担心什么？最坏结果是什么？

第四阶段：方案设计（3 步）

只选一个环节先动手，明确它的输入数据源和期望输出，形成最小可行的自动化起点。

输出与执行原则

21 步走完之后，输出一份包含具体工具、数据源、输出格式的可执行方案，而不是停留在抽象建议。

执行时有几条硬规则：单问单答，每次只问一个问题；回答模糊时追问 能举个例子吗？；每个阶段结束做一次总结确认；用户说"这个不行"时立即停止该方向，不强行说服。

适用边界

这个技能的价值边界很清楚：它是诊断和规划工具，不是执行器。它不会替你跑通一个自动化流程，也不会替你写 Agent 的 prompt。

它最适合的场景是：流程存在但未被文档化、隐性知识大量存在于个人经验中、团队想找到 AI 的合理切入点而非全面铺开。

反过来说，如果流程本身已经高度结构化且完全文档化，直接做技术选型会更高效。如果团队的目标只是"试试 AI"而没有明确的业务场景，21 步提问会显得冗长——这种情况下，先明确业务问题再来做拆解会更顺。