1. 售后工单这个场景为什么值得拿来验证AI工作流售后工单是所有To B业务里最脏、最累、最容易被低估的一块。它不像营销页面那样有明确的视觉产出也不像数据看板那样有漂亮的图表它是一堆带着情绪、带着截图、带着半截日志的文本散落在客服系统、邮件、IM群聊里。我做过三年SaaS产品的售后侧需求最深的体会是工单处理效率的提升从来不是靠加人而是靠把“信息搬运”和“格式转换”这两件事自动化掉。这次我拿一个真实的售后工单案例跑了一遍从需求接收到PRD产出、再到流程图绘制的完整链路用的工具组合是Codex加drawio中间穿插了AI Agent做信息抽取和结构化。核心目的不是炫技而是验证一件事AI PM的新工作流到底能不能在“非理想输入”下跑通。所谓非理想输入就是用户发来的那段话里既有产品版本号又有情绪化描述还有一张模糊的报错截图甚至夹杂着“你们这个功能到底能不能用”这种无效信息。这个验证适合谁看如果你是产品经理、技术负责人、或者正在尝试把AI Agent嵌入到实际业务流程里的开发者这篇内容可以直接抄作业。如果你只是好奇AI能不能写PRD那也可以看看真实场景下的边界在哪里。我全程没有用任何需要特殊网络环境才能访问的服务所有工具都是本地或公开可获取的这一点先说明白。整个验证的核心逻辑是把售后工单当作一个“非结构化需求输入”用AI Agent做第一轮清洗和分类然后用Codex做PRD框架生成和细节补全最后用drawio做流程可视化。每一步都有明确的输入输出定义以及人工介入的检查点。下面我拆开讲包括为什么这么选、每一步的实际操作、踩过的坑以及最终产出的质量评估。2. 整体工作流设计与工具选型逻辑2.1 为什么是Codex加drawio这个组合Codex在这个链路里的角色是“结构化文本生成器”不是“代码生成器”。很多人一提到Codex就想到写代码但在PM工作流里它最值钱的能力是把你脑子里模糊的需求描述转成有层级、有边界、有验收标准的PRD文本。我试过用通用聊天型AI直接写PRD出来的东西往往太“飘”缺少字段级定义和异常分支。Codex因为底层对结构化输出有更强的约束配合合适的提示词能稳定产出带表格、带字段说明、带状态机的文档。drawio的选择更直接它是本地可用的流程图工具格式开放支持XML级别的编辑。AI生成的流程描述可以直接转成drawio的XML节点和连线不需要手动拖拽。我实测下来用AI生成drawio的XML比让它生成Mermaid更可控因为drawio的XML结构更显式节点ID和连线关系可以精确指定不会出现Mermaid那种渲染出来布局乱掉的情况。这里有一个关键决策我没有用“AI一键生成完整PRD”这种模式。原因很简单售后工单里的信息密度太低直接生成会大量脑补。我的做法是分三段第一段用AI Agent做信息抽取和分类第二段用Codex做PRD骨架和字段补全第三段用drawio做流程校验。每一段都有明确的人工检查点确保AI没有偏离原始工单的核心诉求。2.2 工作流的三个核心阶段整个工作流分三个阶段每个阶段的输入输出和检查点如下阶段输入核心动作输出人工检查点信息抽取原始工单文本截图描述实体识别、意图分类、优先级判断结构化JSON实体是否遗漏、意图是否误判PRD生成结构化JSON产品上下文需求拆解、字段定义、异常分支Markdown格式PRD字段是否可落地、边界是否清晰流程可视化PRD中的状态流转描述节点抽取、连线生成、布局调整drawio XML文件状态是否闭环、分支是否完整这个表格看起来简单但实际跑的时候第一阶段的信息抽取最容易出问题。售后工单里经常出现“我昨天还能用今天就不行了”这种时间描述AI很容易把它当成一个独立需求实际上它只是用户情绪表达的一部分。我在提示词里加了一条硬规则所有时间描述必须关联到具体操作步骤否则标记为“低信息量”并忽略。2.3 工具链的版本与配置要点Codex的安装和配置网上教程很多我说几个实际用下来必须注意的点。第一Codex CLI在Windows桌面版和macOS上的行为有差异Windows下路径分隔符和换行符容易导致配置文件解析失败建议统一用UTF-8无BOM格式保存配置文件。第二如果你在配置里写了不支持的模型名称Codex会直接报“model is not supported”并拒绝启动这时候不要反复重装先检查配置文件里的模型字段是否和当前版本匹配。drawio这边我建议直接用桌面版而不是网页版因为AI生成的XML需要频繁导入导出桌面版的文件读写更稳定。drawio的XML结构里每个节点是一个mxCell连线是另一个mxCellsource和target属性指向节点ID。AI生成的时候最容易出错的是节点ID重复和连线指向不存在的节点所以生成后必须用脚本做一轮校验检查所有source和target是否都能在节点列表里找到。注意Codex的配置文件里如果出现拼写错误它会提示“ignoring unrecognized configuration setting”这个提示不会导致启动失败但会导致你的自定义配置不生效。建议每次修改配置后用codex --verbose启动一次确认所有配置项都被正确加载。3. 售后工单案例的完整拆解与实操3.1 原始工单的信息清洗与实体抽取我拿到的原始工单是这样的用户反馈“批量导出功能点击后一直转圈等了五分钟没反应换了浏览器也不行昨天还是好的我们这边有二十多个人等着用麻烦尽快处理”。附带一张截图截图里是浏览器控制台的一段报错关键信息是“TimeoutError: request to /api/export/batch exceeded 30000ms”。这段文本里有效信息其实只有三条功能点是批量导出、现象是超时、报错是30秒超时。其余的都是情绪和上下文。我用AI Agent做抽取的时候提示词是这样写的你是一个售后工单信息抽取器。从以下文本中提取 1. 功能模块名称必须是一个名词短语 2. 异常现象必须是一个可观测的行为描述 3. 错误码或错误信息如果有原样保留 4. 影响范围人数、业务线、紧急程度 5. 用户已尝试的操作如果有 输出为JSON不要添加任何解释。跑出来的结果很干净功能模块是“批量导出”异常现象是“点击后持续加载超过5分钟无响应”错误信息是“TimeoutError: request to /api/export/batch exceeded 30000ms”影响范围是“二十多人”已尝试操作是“更换浏览器无效”。这个JSON就是后续PRD生成的唯一输入原始工单文本不再参与后续流程避免情绪化描述污染PRD。这里有一个实操心得AI Agent做抽取的时候一定要限制输出格式并且要求它“不要解释”。我试过不加这条限制结果AI在JSON外面加了一段“根据您的描述我提取了以下信息”的废话导致后续解析失败。另外错误信息里的路径“/api/export/batch”要原样保留这是后续定位问题的关键线索。3.2 从结构化JSON到PRD骨架的生成过程拿到JSON之后我把它和产品上下文一起喂给Codex。产品上下文包括当前版本号、批量导出的设计上限单次最多5000条、后端超时配置默认30秒、前端轮询间隔2秒。这些信息是我作为PM必须提前准备的AI不会知道你的系统配置。Codex的提示词分两部分系统提示词定义角色和输出格式用户提示词提供具体输入。系统提示词我写的是你是一个资深B端产品经理擅长写售后缺陷类PRD。输出必须包含以下章节 1. 问题描述基于输入JSON不要添加猜测 2. 影响范围与优先级 3. 复现路径步骤化 4. 根因假设最多三条按可能性排序 5. 修复方案分前端、后端、配置三个维度 6. 验收标准可量化 7. 异常分支与回滚方案 每个章节必须有实质内容不允许写“待补充”。用户提示词就是把JSON和产品上下文贴进去。Codex跑出来的PRD骨架质量超出我预期尤其是“根因假设”部分它给出了三条后端查询超时、前端未做分片请求、导出任务队列积压。这三条和后来开发实际排查的结果完全吻合。验收标准部分它写了“批量导出5000条数据在30秒内返回完整文件”这个量化标准直接可以用。但有一个问题Codex在“修复方案”里写了一条“建议将超时时间调整为60秒”这个方案我没有采纳因为调大超时只是掩盖问题没有解决查询效率。这说明AI生成的PRD必须经过人工评审尤其是涉及架构决策的部分不能直接照搬。3.3 用drawio绘制状态流转图的实操细节PRD里有一段描述批量导出的状态流转用户点击导出后前端发起请求后端创建导出任务任务进入队列队列消费后生成文件文件写入对象存储前端轮询获取下载链接。这个流程用文字描述很清楚但用图表达更容易发现遗漏。我用Codex生成drawio的XML提示词是根据以下状态描述生成drawio可导入的XML。要求 1. 每个状态是一个矩形节点节点ID用state_前缀加序号 2. 连线用箭头标注触发条件 3. 包含开始和结束节点 4. 异常分支用红色虚线箭头 5. 输出纯XML不要包含markdown代码块标记Codex生成的XML我导入drawio后发现两个问题一是“队列消费”节点没有异常分支实际上队列可能为空或消费失败二是“前端轮询”节点缺少超时后的重试逻辑。这两个问题在文字PRD里没有暴露但画成图之后一眼就能看出来。我手动补了两个节点和三条连线整个状态机才闭环。这里有一个避坑技巧drawio的XML里节点的几何信息x, y, width, height如果AI生成得不合理导入后会所有节点叠在一起。我的做法是让AI只生成节点和连线关系几何信息统一用脚本批量设置按层级自动布局。这样比让AI直接生成坐标更可靠。4. 实操过程中遇到的典型问题与排查记录4.1 Codex配置加载失败的三种常见原因第一种是配置文件路径不对。Codex默认读取用户目录下的配置文件如果你把配置文件放在项目目录里需要在启动时显式指定路径。我一开始把配置文件放在项目根目录结果Codex一直用默认配置后来加了--config参数才生效。第二种是配置项名称拼写错误。Codex对配置项名称是大小写敏感的比如model写成Model就不会被识别而且它只会提示“ignoring unrecognized configuration setting”不会报错退出。这个坑很隐蔽因为程序能启动但你的配置就是不生效。我的做法是每次修改配置后用codex config list命令打印当前生效的配置逐项核对。第三种是模型名称不匹配。如果你在配置里写了一个当前版本不支持的模型名称Codex会直接报错并拒绝启动。这时候不要急着重装先检查官方文档里当前版本支持的模型列表把名称改对即可。我遇到过“gpt-5.6-sol”这种名称明显是版本不匹配改成文档里列出的名称就正常了。4.2 AI生成PRD时的信息脑补问题AI在生成PRD时最大的风险是“脑补”。比如原始工单里只说了“批量导出超时”AI在“根因假设”里写了一条“可能是数据库索引缺失”。这个假设本身合理但它没有依据因为工单里没有提到任何数据库相关信息。如果PM直接把这条写进PRD开发可能会花时间排查一个不存在的问题。我的应对策略是在提示词里加一条硬约束“所有根因假设必须能追溯到输入JSON中的某个字段如果无法追溯标记为‘低置信度’并单独列出。”这样AI会把“数据库索引缺失”标记为低置信度我在评审时就会知道这条需要人工验证而不是直接采纳。另一个脑补重灾区是“验收标准”。AI倾向于写“功能正常”“性能良好”这种无法量化的标准。我在提示词里要求“验收标准必须包含具体的数值、时间、或可观测的状态”这样它就会写出“5000条数据在30秒内返回完整文件”这种可执行的条目。4.3 drawio XML导入后的布局错乱修复AI生成的drawio XML导入后最常见的现象是所有节点叠在左上角。原因是AI生成的几何信息要么缺失要么所有节点用了相同的坐标。修复方法有两种一是手动在drawio里点“布局”菜单选择“垂直树”或“水平树”自动排列二是用脚本批量修改XML里的坐标按节点层级计算x和y值。我推荐第二种因为自动布局有时候会把异常分支的连线拉得很乱。我的脚本逻辑是先解析XML里所有节点的层级关系根节点x100y100每个子节点x递增200y递增100异常分支节点y额外加50。这样布局出来的图层次清晰连线也不会交叉。还有一个细节drawio的XML里连线的样式通过style属性控制。AI生成的style经常缺少edgeStyleorthogonalEdgeStyle导致连线是斜线而不是直角线。我在提示词里明确要求“所有连线使用orthogonalEdgeStyle”生成出来的图就规整多了。4.4 常见问题速查表问题现象可能原因排查方法解决方式Codex启动报模型不支持配置的模型名称与版本不匹配检查配置文件model字段改为官方文档列出的模型名称配置修改后不生效配置项拼写错误或路径不对用config list打印生效配置修正拼写指定正确路径AI生成的PRD有脑补内容提示词缺少追溯约束检查根因假设是否可追溯加“低置信度”标记人工验证drawio节点全部叠在一起XML缺少几何信息或坐标重复查看XML中mxGeometry节点用脚本批量设置坐标或手动布局drawio连线是斜线style缺少orthogonalEdgeStyle检查mxCell的style属性在style中追加edgeStyle参数AI抽取的实体遗漏关键信息提示词未限制输出格式对比原始工单和JSON加“不要解释”和字段白名单5. 这套工作流的实际效果与适用边界5.1 效率提升的量化对比我拿同一个工单做了两组对比一组是传统方式人工阅读工单、手动写PRD、手动画流程图另一组是AI工作流AI抽取加Codex生成加drawio自动布局。传统方式从接到工单到PRD初稿完成耗时约2小时其中信息整理30分钟PRD撰写60分钟流程图绘制30分钟。AI工作流耗时约35分钟其中信息抽取5分钟PRD生成10分钟人工评审和修改15分钟流程图生成和调整5分钟。效率提升是明显的但更重要的是质量一致性。人工写PRD时不同的人写出来的详细程度差异很大有的人会写异常分支有的人只写主流程。AI工作流因为提示词里固定了章节结构每次产出的PRD都包含完整的七个章节不会遗漏异常分支和回滚方案。这一点对于团队协作来说价值更大因为下游开发拿到的文档格式统一减少了很多沟通成本。5.2 什么情况下这套工作流会失效第一种情况是工单信息极度缺失。如果用户只发了一句“功能坏了”没有任何截图、报错、操作步骤AI抽取出来的JSON几乎是空的后续PRD生成就会变成纯脑补。这种情况下正确做法是先让客服补充信息而不是硬跑AI工作流。第二种情况是涉及架构级变更。如果工单暴露的问题需要重新设计数据模型或调整服务拆分AI生成的PRD只能作为参考不能作为决策依据。因为架构决策需要考虑历史包袱、团队技术栈、运维成本等因素这些信息AI无法从工单里获取。第三种情况是合规敏感场景。如果工单涉及用户数据导出、权限变更等敏感操作AI生成的PRD必须经过安全评审不能直接进入开发。我在提示词里加了一条“如果涉及用户数据必须在PRD中标注数据脱敏要求”但最终判断还是需要人工。5.3 后续可以扩展的方向这套工作流目前只覆盖了“缺陷类工单”到“PRD”的链路实际上还可以往前和往后延伸。往前延伸可以接入客服系统的API自动拉取新工单并触发AI抽取减少人工复制粘贴。往后延伸可以把PRD里的验收标准自动转成测试用例直接对接测试管理平台。另一个扩展方向是多工单聚合。当同一时间段内出现多个相似工单时AI可以自动聚类识别出共性问题生成一份合并PRD。这个在版本发布后特别有用因为用户反馈往往集中在几个功能点上聚合后可以减少重复分析的工作量。我在实际使用中发现这套工作流最值钱的地方不是“快”而是“不遗漏”。人工写PRD时很容易因为时间压力跳过异常分支和回滚方案但AI不会只要你提示词里写了它就会按结构填满。当然填的内容质量需要人工把关但至少框架是完整的不会出现“开发做到一半发现少了一个状态”这种情况。最后分享一个小技巧Codex生成PRD后不要直接复制到文档里先让它自己跑一遍“自检”提示词是“检查上述PRD中是否存在前后矛盾的字段定义、未闭环的状态流转、以及无法量化的验收标准列出所有问题”。这一步能抓出不少低级错误比如字段类型前后不一致、状态机缺少终止状态等。我实测下来自检能发现约30%的明显问题剩下的70%还是需要人工评审但已经省了很多返工时间。