1. 从一张售后工单说起AI PM 工作流到底在解决什么问题售后工单这个场景做过产品经理的人都懂它属于那种看起来不起眼、做起来要命的典型需求。一张工单从用户提交到最终闭环中间要经过客服初审、分类打标、责任判定、跨部门流转、方案确认、用户回访、数据归档等一连串环节。传统做法是产品经理先花两三天写一份 PRD画几张流程图然后拉上研发、客服、运营开评审会来回扯皮一两周最后上线一个能用但不好用的系统。我最近拿一个真实的售后工单案例完整跑了一遍以 AI 为核心的新工作流从需求梳理到 PRD 产出、从流程图绘制到原型验证整个链路压缩到了原来的三分之一时间。这篇文章就把这套流程拆开讲清楚包括我用了哪些工具、每个环节为什么这么设计、踩了哪些坑、哪些地方 AI 还靠不住需要人工兜底。先说清楚这套工作流适合谁一是正在做 B 端系统、中后台产品的产品经理尤其是售后、客服、工单、审批这类流程型系统二是想用 AI 提效但不知道怎么落地的技术同学三是对 AI Agent、Codex 这类工具感兴趣、想找个真实场景练手的开发者。不需要你有多深的 AI 背景但得对产品流程有基本认知。核心思路其实一句话把 AI 当成一个能干活但需要明确指令的初级同事而不是一个许愿池。你给它模糊的需求它给你模糊的结果你把流程拆细、把约束讲清楚、把验收标准定死它才能真正帮你省时间。下面我按实际操作的顺序一层层拆。2. 整体工作流设计与工具选型思路2.1 为什么是AI 主导 人工卡点而不是全自动很多人一上来就想搞全自动需求丢给 AIPRD 自动生成流程图自动画原型自动出。我试过结论是现阶段全自动在流程型系统上必翻车。原因很简单售后工单这类需求的核心难点不在写文档而在业务规则的边界判定。比如什么情况下工单可以自动关闭跨部门流转时责任怎么划分超时升级的阈值定多少这些是需要跟业务方反复确认的AI 没有业务上下文它只能猜。所以我设计的工作流是AI 主导产出 人工在关键节点卡点环节AI 负责人工负责卡点原因需求梳理结构化拆解、补全遗漏项确认业务规则边界AI 不懂你的业务潜规则PRD 撰写生成初稿、字段定义、状态机审核逻辑一致性AI 容易自相矛盾流程图生成 drawio 可编辑文件校验流程闭环AI 画的图常有断头路原型验证生成交互逻辑、边界用例判断体验合理性AI 不懂用户真实习惯测试用例批量生成覆盖用例补充异常场景AI 想不到脏数据这个表格是我实际跑下来总结的不是拍脑袋。你会发现人工卡点全部集中在业务判断和体验判断上而 AI 承担的是结构化输出和批量生成这类重复劳动。分工清楚了效率才上得去。2.2 工具链选型Codex、drawio、PRD 模板怎么配合工具选型这块我踩过不少坑说几个关键决策。代码与逻辑验证用 Codex。售后工单系统里有很多状态流转逻辑比如工单从待处理到处理中到待确认到已关闭中间还有挂起转派升级这些分支。这些逻辑用自然语言描述容易有歧义但用代码表达就非常精确。我会让 Codex 帮我把状态机写成伪代码或者直接写成可运行的状态流转函数这样研发一看就懂评审时也少扯皮。Codex 在这类把业务规则翻译成代码的任务上表现相当稳尤其是它能理解上下文你给它一个状态定义它能帮你补全所有可能的转移路径。流程图用 drawio。为什么不用那些在线的流程图工具因为 drawio 的文件格式是开放的 XMLAI 可以直接生成这个 XML你打开就能编辑不用手动重画。这一点太关键了。我让 AI 生成 drawio 格式的流程图它输出的是一段 XML我保存成.drawio文件双击就能用 drawio 打开节点、连线、文字全都在还能继续拖拽调整。如果你还不清楚 drawio 格式文件怎么打开最简单的办法就是去 drawio 官网下载桌面版或者用它的网页版直接导入文件不需要装什么特殊插件。PRD 用结构化模板 AI 填充。PRD 最怕的是想到哪写到哪所以我固定了一套模板背景与目标、用户角色、核心流程、字段定义、状态机、异常处理、验收标准。每次让 AI 按这个骨架填填完我再逐项审。模板固定了AI 的输出质量会稳定很多因为它知道每一节该写什么。2.3 工作流的三个阶段划分整套流程我分成三个阶段每个阶段有明确的输入和输出需求解构阶段输入是业务方的口头需求或者零散文档输出是结构化的需求清单和业务规则表。这个阶段 AI 帮你把一团乱麻理成一条条线。方案产出阶段输入是需求清单输出是 PRD 初稿、drawio 流程图、状态机代码。这个阶段是 AI 的主力战场。验证迭代阶段输入是方案输出是测试用例、边界问题清单、修订版方案。这个阶段 AI 帮你查漏人工做最终判断。三个阶段串起来就是一个完整的闭环。下面我逐个拆开讲实操细节。3. 需求解构把一团乱麻理成可执行清单3.1 售后工单的核心业务规则拆解先说说这个售后工单案例的背景。业务方的原始需求大概是这样的用户买了东西有问题要能提交售后客服要能处理处理不了要转给相关部门最后要能统计。就这么几句话信息量极少但要做成一个系统背后要补的规则一大堆。我做的第一件事是让 AI 帮我把这些模糊描述拆成具体问题。我给它的提示词大意是这是一个售后工单系统的原始需求请你以资深产品经理的视角列出所有需要跟业务方确认的关键问题按优先级排序。它给我列了几十条我挑出真正关键的工单的来源渠道有哪些只有 App 还是包括电话、邮件、第三方平台工单的分类维度是什么按商品、按问题类型、按紧急程度什么情况下工单可以自动关闭用户多久不回复算超时跨部门流转时责任怎么判定谁有权限转派升级机制怎么设计超时多久升级、升级给谁工单的优先级怎么定是用户选还是系统算这些问题如果靠我自己想可能会漏掉几个但 AI 一次性列全了我拿着这个清单去跟业务方对效率高很多。这就是 AI 在需求阶段最大的价值它不会累不会烦能把一个需求的边边角角都翻一遍。3.2 用 AI 补全遗漏项和边界场景业务方回答完上面那些问题后我手里就有了一份相对完整的规则。但这时候还不能直接写 PRD因为还有大量边界场景没覆盖。我继续让 AI 做边界场景穷举。举个例子工单状态流转里有个转派操作。正常情况是客服 A 把工单转给客服 B。但边界情况呢转派时 B 正在休假怎么办转派后 A 还能不能看到这个工单转派次数有没有上限无限转派怎么办转派后原来的处理记录要不要保留用户能不能看到工单被转派了这些场景 AI 能帮你想出一大半。我的做法是给它一个具体的功能点让它列出所有可能的异常情况和边界条件。它列出来的我逐条判断合理的纳入 PRD不合理的丢弃。实测下来AI 在边界场景穷举上的覆盖率能到七八成剩下两三成需要靠经验补但已经省了大量时间。提示让 AI 穷举边界场景时一定要给它具体的功能点不要给它整个系统。范围越小它想得越细。给整个系统它只会给你泛泛而谈。3.3 业务规则表的整理与确认拆解完之后我把所有规则整理成一张业务规则表这是后续 PRD 和状态机的输入。表格大概长这样规则编号规则描述触发条件处理动作优先级R001工单自动关闭用户 7 天未回复状态置为已关闭高R002工单超时升级处理中超过 24 小时升级至主管高R003转派上限同一工单转派超过 3 次禁止继续转派中R004优先级自动计算用户为 VIP 且问题为质量类优先级置为紧急中这张表的价值在于它把散落在各处的规则集中管理后面写状态机、写测试用例、做验收全都以这张表为准。AI 帮我生成了初版我逐条核对修改。规则表是整套工作流的单一事实来源所有下游产出都必须跟它对齐这一点非常重要否则后面 PRD、流程图、代码各说各话评审时就是灾难。4. PRD 与流程图的 AI 产出实操4.1 PRD 结构化模板与 AI 填充技巧PRD 这块我用的模板分七节每节都有明确的写作要求。我把模板和业务规则表一起喂给 AI让它逐节填充。这里有个关键技巧不要一次性让 AI 写完整份 PRD要一节一节来。一次性写它写到后面会忘记前面的约束出现自相矛盾。一节一节写每节写完我快速扫一眼有问题当场纠正再写下一节。以状态机这一节为例我让 AI 根据业务规则表生成工单的完整状态定义。它输出的内容大概是待处理工单创建后的初始状态处理中客服接单后的状态待确认客服给出方案、等待用户确认已关闭用户确认或超时自动关闭已挂起因缺少信息暂时搁置已升级超时或用户投诉触发每个状态还要定义进入条件退出条件可执行操作。这些 AI 都能生成我主要检查逻辑是否闭环比如已挂起能不能回到处理中已关闭能不能重新打开。这些边界 AI 有时候会漏需要人工补。4.2 用 drawio 格式生成可编辑流程图流程图这块是我觉得最惊艳的部分。传统做法是我在工具里一个个拖节点、连线、调格式一张复杂的工单流转图要画一两个小时。现在我的做法是把状态机的定义给 AI让它直接输出 drawio 的 XML 格式。drawio 的文件本质是一段 XML结构大概是mxGraphModel里面套mxCell节点和边。AI 完全能理解这个结构你给它状态和转移关系它能生成对应的 XML。我拿到 XML 后保存成.drawio文件用 drawio 打开节点位置可能有点乱但所有逻辑关系都在我只需要拖一拖调整布局就行省了百分之八十的时间。这里有个实操细节让 AI 生成 drawio XML 时要明确告诉它每个节点的坐标和宽高否则它生成的节点会全部叠在一起。我一般让它按网格布局每个节点间隔 200 像素这样打开后基本能看微调一下就行。注意AI 生成的 drawio XML 偶尔会有语法错误导致打不开。遇到这种情况把报错信息贴回给 AI让它修正一般一两轮就能解决。我踩过这个坑一开始以为是文件坏了其实是 XML 里有个标签没闭合。4.3 状态机代码化让逻辑无歧义前面说过状态流转逻辑用自然语言描述容易有歧义所以我让 Codex 帮我把状态机写成代码。不是写完整的业务代码而是写一个清晰的状态流转函数把所有合法的状态转移列出来。比如用 Python 写一个状态转移校验函数VALID_TRANSITIONS { pending: [processing, suspended], processing: [pending_confirm, suspended, escalated], pending_confirm: [closed, processing], suspended: [processing, closed], escalated: [processing, closed], closed: [] } def can_transition(current, target): return target in VALID_TRANSITIONS.get(current, [])这段代码的价值在于它把哪些状态能转到哪些状态这件事变得绝对精确。研发看这段代码比看十页文字描述都清楚。而且这段代码可以直接拿去做单元测试验证状态机有没有漏洞。Codex 生成这类代码非常快我给它状态定义它几秒钟就输出我再检查一遍逻辑就行。为什么这一步值得做售后工单系统上线后最常见的 bug 就是状态流转错误比如工单卡在某个状态出不来或者出现了不该出现的状态组合。提前把状态机代码化并测试能挡掉一大半这类问题。5. 验证迭代AI 查漏与人工兜底5.1 用 AI 批量生成测试用例方案产出后我让 AI 根据业务规则表和状态机批量生成测试用例。这一步的产出直接决定上线质量。我给的指令是根据以下业务规则和状态定义生成覆盖正常流程、异常流程、边界条件的测试用例每条用例包含前置条件、操作步骤、预期结果。AI 生成的用例覆盖度相当高尤其是正常流程和常见异常。但有两类它容易漏一是脏数据场景比如用户输入超长文本、特殊字符、空值二是并发场景比如两个客服同时操作同一张工单。这两类需要人工补。我的做法是 AI 生成一批我人工补一批最后合并成完整的测试用例集。5.2 常见问题排查速查表实际跑这套流程的过程中我遇到不少问题整理成速查表方便你对照问题现象可能原因解决办法AI 生成的 PRD 前后矛盾一次性生成内容太长分节生成每节确认后再继续drawio 文件打不开XML 语法错误把报错贴回 AI 修正状态机有死循环转移规则定义不全用代码列出所有转移逐一检查测试用例覆盖不全缺少脏数据和并发场景人工补充这两类用例AI 理解错业务规则提示词太模糊给具体例子明确输入输出这张表里的每一条都是我实际踩过的。尤其是第一条我一开始图省事让 AI 一次性写完整份 PRD结果写到后面它把前面定义的状态名都改了评审时被研发当场指出非常尴尬。后来改成逐节生成再没出现过这个问题。5.3 人工卡点的判断标准最后说说人工卡点怎么判断。我的标准是三条涉及钱、涉及权限、涉及用户体验的地方必须人工确认。涉及钱的比如退款金额计算、赔付规则涉及权限的比如谁能转派、谁能关闭涉及用户体验的比如提示文案、操作路径。这三类 AI 可以给建议但最终决定必须人来拍板。其他纯结构化的内容比如字段定义、状态枚举、接口参数AI 生成后我快速扫一遍就行不用逐字审。把精力集中在真正需要判断的地方这才是人机协作的正确姿势。6. 我在这套工作流里踩过的坑和总结的技巧6.1 提示词写不好后面全是坑我最大的体会是这套工作流的上限取决于你写提示词的水平。同样一个需求提示词写得模糊AI 给你的就是一堆正确的废话提示词写得具体AI 给你的就是能直接用的东西。我的提示词一般包含四要素角色设定、任务描述、输入材料、输出格式。比如你是一个有十年经验的 B 端产品经理请根据以下业务规则表生成工单状态机的定义输出格式为表格包含状态名、进入条件、退出条件、可执行操作四列。这样写AI 的输出基本不用大改。6.2 不要指望 AI 一次做对另一个坑是期望值管理。AI 不是一次就能给你完美结果它更像是一个需要反复沟通的同事。我的习惯是第一轮让它出初稿第二轮针对问题让它改第三轮做细节打磨。三轮下来质量基本能到可用水平。指望一轮到位只会失望。6.3 工具是死的流程是活的最后一点工具选型不是重点流程设计才是。Codex、drawio 这些工具只是载体真正决定效率的是你有没有把流程拆清楚、把卡点设对。我见过有人工具用得很溜但流程一团乱产出还是不行。也见过工具很朴素但流程清晰效率照样高。先把流程想明白再选工具顺序不能反。这套工作流我还在持续迭代后面打算把测试用例生成和自动化测试再串起来让验证环节也尽量自动化。不过那是下一步的事了眼下这套已经能实打实省下不少时间。如果你也在做类似的中后台系统不妨拿一个真实需求试试跑一遍就知道哪里适合 AI、哪里还得靠自己。