售后工单这件事做过产品的人都知道它有多脏——信息散落在聊天记录、邮件、电话录音里用户描述模糊客服转述又丢一层等落到产品经理手上时往往只剩一句用户说不好用。我最近拿一个真实的售后工单案例把 AI 揉进了从原始诉求到 PRD 的整条链路里跑通了一套新的工作流。这套流程的核心不是让 AI 帮我写文档而是让 AI 承担信息结构化、逻辑校验和可视化这三件最耗人力的脏活人只负责判断和拍板。下面我把整个链路拆开讲包括我为什么这么设计、每一步具体怎么操作、以及实测中踩到的坑。1. 为什么售后工单是检验 AI 工作流的最佳试炼场1.1 售后工单的三个天然难点选售后工单作为验证场景不是随便挑的。它几乎集齐了产品需求处理里最麻烦的几个特征。第一是信息源极度分散且非结构化。一个售后问题可能来自客服系统的一条工单、用户发来的一段语音、一张报错截图甚至是一段情绪化的吐槽。这些内容没有统一格式字段缺失严重时间、版本、操作路径经常对不上。第二是诉求与根因之间存在断层。用户说你们的导出功能坏了这只是一个表象。真实原因可能是权限配置问题、可能是数据量超限、也可能是前端某个字段渲染失败。从表象到根因中间隔着好几层推理。第三是跨角色协作成本高。售后工单要在客服、产品、研发、测试之间流转每个角色关注的点不同客服关心安抚话术研发关心复现路径产品关心需求优先级。同一份信息要翻译成好几种语言。传统做法是产品经理当人肉翻译机把这些碎片信息在脑子里过一遍然后手写 PRD。这个过程慢、容易漏、还高度依赖个人经验。AI 的价值恰恰在于它能同时处理非结构化输入、做逻辑推理、并按不同角色输出不同格式。1.2 我为什么把 Codex 放在链路的核心位置热词里 Codex 出现频率很高很多人第一反应是代码生成工具。但在这套工作流里我把它当成一个结构化推理引擎来用而不是单纯的写代码。原因很实际售后工单处理需要的是理解模糊输入 生成结构化输出 保持逻辑一致这三件事的组合能力。Codex 这类工具在长上下文理解、多轮指令跟随、以及按模板稳定输出方面表现比较可靠。尤其是当我把工单原文、历史相似案例、产品现有功能文档一起喂进去时它能做交叉比对指出这个诉求和三个月前那个工单高度相似可能是同一个根因。提示把 Codex 当推理引擎用关键在于提示词里要明确角色 输入 输出格式 约束条件四要素缺一个输出就会飘。1.3 这套工作流适合谁坦白说这套流程不是给所有人准备的。它最适合三类人一是每天被大量零散需求淹没的产品经理二是想提升需求处理效率但不想学复杂工具的业务人员三是需要快速把模糊问题转成可执行文档的技术负责人。如果你只是偶尔处理一两个简单需求手工写反而更快。但当你面对的是每天十几条工单、每条都要跨角色沟通时这套流程的边际收益会非常明显。2. 从原始工单到结构化需求信息清洗的完整链路2.1 第一步不是喂给 AI而是先做人工粗筛很多人一上来就把原始工单直接丢给 AI这是第一个坑。原始工单里往往混着大量噪音用户的情绪表达、客服的安抚话术、无关的寒暄。如果不做粗筛AI 会被这些噪音带偏输出的需求描述里会莫名其妙出现用户很生气这种对 PRD 毫无价值的信息。我的做法是先人工过一遍只保留三类信息客观现象描述、复现条件、用户期望结果。情绪、评价、猜测全部删掉。这一步花不了几分钟但能让后续 AI 处理的准确率提升一大截。举个实际例子。原始工单是这样的客户很着急说昨天还好好的今天打开报表页面就白屏了重启了电脑也没用我们这边试了试好像也复现不了客户说再不行就要退款了。粗筛之后变成现象报表页面白屏。时间昨天正常今天异常。复现条件客服侧未能复现。用户期望恢复正常显示。你看信息量没减少但噪音全没了。这一步是后面所有环节的地基。2.2 用 Codex 做信息补全与逻辑校验粗筛后的信息还是太薄缺关键字段。这时候把内容喂给 Codex让它做两件事补全缺失字段、校验逻辑矛盾。我的提示词大致是这样组织的你是一名资深产品经理。下面是一条售后工单的粗筛信息。 请完成两件事 1. 补全以下字段影响范围、严重程度、可能的根因方向、需要向用户追问的信息。 2. 指出信息中存在的逻辑矛盾或缺失项。 工单信息 现象报表页面白屏 时间昨天正常今天异常 复现条件客服侧未能复现 用户期望恢复正常显示Codex 返回的结果里会明确指出客服侧未能复现和用户侧稳定复现之间存在环境差异需要追问用户的操作系统、浏览器版本、账号权限。同时它会给出几个根因方向前端资源加载失败、接口返回异常、权限变更、缓存问题。这一步的价值在于它把我该问用户什么这件事从凭经验变成了有清单。以前我可能会漏问浏览器版本现在 AI 会提醒我。2.3 追问清单的生成逻辑追问清单不是随便列的它遵循一个原则每个问题都要能缩小根因范围。比如你用的什么浏览器这个问题如果用户回答是某个特定版本而其他版本正常那根因大概率在前端兼容性。如果所有浏览器都白屏那问题更可能在接口或权限层。每个问题都是一个二分叉问得越多根因范围越小。我让 Codex 生成追问清单时会额外加一条约束每个问题必须说明它能排除哪种可能。这样生成的清单才有针对性而不是泛泛地问一堆无关信息。实测下来一个模糊工单经过这一步通常能生成 5 到 8 个高质量追问项覆盖环境、操作路径、时间线、账号状态四个维度。3. PRD 生成让 AI 写出研发愿意看的文档3.1 为什么大多数 AI 生成的 PRD 研发不看我见过太多 AI 生成的 PRD通病是看起来完整实际没法用。它们通常有漂亮的章节结构但内容空洞缺少边界条件、异常处理、验收标准这些研发真正关心的东西。根本原因是提示词里只说了写一份 PRD没说写给谁看、要解决什么问题、必须包含哪些硬性内容。AI 只能按通用模板输出结果就是一份正确的废话。我的做法是在提示词里明确研发视角的硬性要求。具体来说一份能被研发接受的 PRD必须包含功能描述、输入输出定义、边界条件、异常场景、验收标准、依赖项。缺任何一个研发都会回来找你补。3.2 我的 PRD 提示词模板拆解这是我实际在用的模板结构拆开讲每一块的作用角色你是一名有 5 年 B 端产品经验的产品经理正在为研发团队撰写 PRD。 背景{这里放清洗后的工单信息和追问结果} 要求 1. 功能描述用用户故事 验收标准的格式每条验收标准必须可测试。 2. 明确列出输入字段、输出字段、字段类型和必填性。 3. 列出至少 5 个边界条件如空数据、超大数据量、并发操作。 4. 列出至少 3 个异常场景及处理方式。 5. 标注依赖项依赖哪些现有功能、哪些接口。 6. 不要写提升用户体验这类无法验证的描述。 输出格式Markdown用二级标题分章节。这里最关键的是第 6 条约束。AI 天然喜欢写优化体验提升效率这种话但这些对研发毫无意义。明确禁止之后输出质量会明显提升。3.3 验收标准怎么写才算可测试这是 PRD 里最容易翻车的部分。我举个对比你就明白了。不可测试的写法报表页面能正常显示数据。可测试的写法当用户拥有报表查看权限且数据量小于 10000 条时报表页面在 3 秒内完成加载并显示全部字段当数据量为 0 时显示空状态提示文案暂无数据。区别在哪后者有明确的前置条件、量化指标、预期结果。研发看完就知道怎么测测试看完就知道怎么验。我让 Codex 生成验收标准时会强制要求每条都包含当……时应……的结构这样能倒逼它写具体。实测中我发现如果不在提示词里强调这一点AI 生成的验收标准有七成是模糊的。加上约束后可测试比例能提到九成以上。4. 用 drawio 把需求变成可视化流程图4.1 为什么 PRD 里必须有一张流程图文字描述再清楚也比不上一张流程图直观。尤其是涉及多角色、多分支的售后处理流程纯文字描述会让研发在脑子里自己画图画错了就是返工。drawio 是我常用的工具免费、跨平台、支持导出多种格式。热词里有人问drawio 格式文件怎么打开这里顺带说一句drawio 文件本质是 XML用 draw.io 桌面版或网页版都能直接打开也可以用 VS Code 装 drawio 插件编辑。4.2 让 AI 生成 drawio 可识别的结构描述AI 不能直接画图但可以生成 drawio 能识别的 XML 结构或者生成结构化的节点和连线描述再手动导入。我的做法是让 Codex 输出一个结构化的流程描述格式如下流程名称报表白屏问题处理流程 节点 1. 用户提交工单 [起点] 2. 客服粗筛信息 [处理] 3. 判断是否可复现 [判断] - 可复现 - 转研发排查 - 不可复现 - 生成追问清单 4. 用户补充信息 [处理] 5. 再次判断 [判断] - 定位根因 - 生成修复方案 - 仍未定位 - 升级至二线支持 连线 1 - 2 - 3 3 可复现 - 4a转研发 3 不可复现 - 4b追问 ...拿到这个结构后我可以手动在 drawio 里快速搭出来或者写个小脚本把结构化描述转成 drawio 的 XML。后者适合流程复杂的场景一次配置能反复用。4.3 流程图和 PRD 正文的对应关系这里有个细节很多人忽略流程图里的每个节点都应该能在 PRD 正文里找到对应的文字描述。反过来PRD 里的每个功能点也应该在流程图里有体现。两者是互相校验的关系。我通常会让 Codex 做一次交叉检查请对比流程图节点和 PRD 正文指出哪些节点在正文中没有对应描述哪些正文功能在流程图中缺失。这一步能抓出不少遗漏尤其是异常分支很容易在写正文时被忘掉。5. 实测中踩到的坑与应对方案5.1 上下文超长导致输出质量断崖式下降这是最典型的问题。当我把工单原文、历史案例、产品文档全部塞进上下文时AI 的输出会开始糊——前面说的和后面说的对不上或者干脆漏掉关键约束。我的应对是分层处理不要一次性喂。第一轮只喂工单信息拿到结构化需求第二轮把结构化需求 产品文档喂进去拿到 PRD 草稿第三轮单独做流程图。每一轮的上下文都控制在合理范围内输出质量稳定得多。如果你用的是支持长上下文的工具也别贪心。上下文越长模型对中间部分的注意力越弱这是普遍现象不是某个工具的问题。5.2 AI 会编造不存在的功能依赖有一次 Codex 在 PRD 里写本功能依赖现有的权限中心 v2.3 接口但我们根本没有这个接口。它是根据上下文里的只言片语推断出来的听起来很合理实际是幻觉。应对方法是在提示词里加一条硬约束只使用我提供的功能清单不得推断或编造任何未提及的依赖项。如果不确定标注待确认。加上这条之后幻觉明显减少而且待确认标记反而帮我发现了几个真实存在的依赖盲区。5.3 追问清单过度发散早期我让 AI 自由生成追问清单结果它列了二十几个问题从浏览器版本问到用户的使用习惯很多问题对定位根因毫无帮助。后来我加了约束每个问题必须能排除至少一种根因可能且问题总数不超过 8 个。这样倒逼它做优先级排序只留最有价值的问题。实测下来8 个问题基本能覆盖 90% 的常见根因。5.4 流程图节点粒度过细或过粗AI 生成流程描述时粒度控制是个难点。太细会变成几十个节点图没法看太粗又会丢失关键分支。我的经验是按角色切换来划分节点。每当处理角色发生变化用户到客服、客服到研发就是一个新节点。这样划分出来的流程图节点数量通常在 8 到 15 个之间既完整又可读。6. 这套工作流的效率账与适用边界6.1 实测效率对比我拿同一个售后工单做了对比测试。传统手工方式从拿到工单到产出可交付的 PRD 加流程图大约需要 2 到 3 小时其中大部分时间花在信息整理和画图上。用这套工作流全流程压缩到 40 分钟左右其中人工粗筛和最终审核占了大头AI 处理部分只占十几分钟。但要注意这个效率提升的前提是工单本身信息量足够。如果工单只有一句话用户说不好用那 AI 也变不出花来追问环节会占掉大部分时间。6.2 什么情况下不该用这套流程有三种情况我建议直接手工处理一是需求极其简单比如改个文案用 AI 反而是杀鸡用牛刀二是涉及高度敏感的决策需要人来承担判断责任三是工单信息本身已经非常结构化直接填模板就行。工具的价值在于处理模糊到清晰的转换如果输入本身已经清晰那转换环节就是多余的。6.3 关于工具选型的几句实在话热词里工具名一大堆Codex、Coze、Dify、n8n 都有人提。我的看法是别被工具绑架。这套工作流的核心是分层处理 结构化约束 交叉校验这三个方法论用什么工具实现都行。Codex 适合做推理和文档生成Coze 和 Dify 适合做流程编排n8n 适合做自动化触发。如果你只是想验证这套方法用一个顺手的对话工具就够了不用一上来就搭复杂的工作流平台。等流程跑顺了再考虑用编排工具把它自动化那时候你才知道哪些环节值得自动化、哪些环节必须留人工。我自己现在的做法是核心推理环节用 Codex重复性的格式转换写个小脚本整个链路没有用任何重型平台。轻量、可控、好维护出问题也好排查。最后分享一个我踩过好几次才总结出来的小技巧每次 AI 输出后别急着用先让它自己挑毛病。加一句请指出你刚才输出中可能存在的不确定或需要人工确认的地方它往往能主动标出几个自己没把握的点。这几个点恰恰就是你最该人工复核的地方。这个习惯帮我避免了好几次把 AI 幻觉直接写进 PRD 的尴尬。