企业官网建设流程全解析

1. 从一张售后工单说起：AI PM 工作流到底在解决什么问题

售后工单这个场景，做过产品经理的人都懂，它属于那种"看起来不起眼、做起来要命"的典型需求。一张工单从用户提交到最终闭环，中间要经过客服初审、分类打标、责任判定、跨部门流转、方案确认、用户回访、数据归档等一连串环节。传统做法是产品经理先花两三天写一份 PRD，画几张流程图，然后拉上研发、客服、运营开评审会，来回扯皮一两周，最后上线一个"能用但不好用"的系统。

我最近拿一个真实的售后工单案例，完整跑了一遍以 AI 为核心的新工作流，从需求梳理到 PRD 产出、从流程图绘制到原型验证，整个链路压缩到了原来的三分之一时间。这篇文章就把这套流程拆开讲清楚，包括我用了哪些工具、每个环节为什么这么设计、踩了哪些坑、哪些地方 AI 还靠不住需要人工兜底。

先说清楚这套工作流适合谁：一是正在做 B 端系统、中后台产品的产品经理，尤其是售后、客服、工单、审批这类流程型系统；二是想用 AI 提效但不知道怎么落地的技术同学；三是对 AI Agent、Codex 这类工具感兴趣、想找个真实场景练手的开发者。不需要你有多深的 AI 背景，但得对产品流程有基本认知。

核心思路其实一句话：把 AI 当成一个能干活但需要明确指令的初级同事，而不是一个许愿池。你给它模糊的需求，它给你模糊的结果；你把流程拆细、把约束讲清楚、把验收标准定死，它才能真正帮你省时间。下面我按实际操作的顺序，一层层拆。

2. 整体工作流设计与工具选型思路

2.1 为什么是"AI 主导 + 人工卡点"而不是全自动

很多人一上来就想搞全自动，需求丢给 AI，PRD 自动生成，流程图自动画，原型自动出。我试过，结论是：现阶段全自动在流程型系统上必翻车。原因很简单，售后工单这类需求的核心难点不在"写文档"，而在"业务规则的边界判定"。比如"什么情况下工单可以自动关闭""跨部门流转时责任怎么划分""超时升级的阈值定多少"，这些是需要跟业务方反复确认的，AI 没有业务上下文，它只能猜。

所以我设计的工作流是"AI 主导产出 + 人工在关键节点卡点"：

这个表格是我实际跑下来总结的，不是拍脑袋。你会发现人工卡点全部集中在"业务判断"和"体验判断"上，而 AI 承担的是"结构化输出"和"批量生成"这类重复劳动。分工清楚了，效率才上得去。

2.2 工具链选型：Codex、drawio、PRD 模板怎么配合

工具选型这块我踩过不少坑，说几个关键决策。

代码与逻辑验证用 Codex。售后工单系统里有很多状态流转逻辑，比如工单从"待处理"到"处理中"到"待确认"到"已关闭"，中间还有"挂起""转派""升级"这些分支。这些逻辑用自然语言描述容易有歧义，但用代码表达就非常精确。我会让 Codex 帮我把状态机写成伪代码或者直接写成可运行的状态流转函数，这样研发一看就懂，评审时也少扯皮。Codex 在这类"把业务规则翻译成代码"的任务上表现相当稳，尤其是它能理解上下文，你给它一个状态定义，它能帮你补全所有可能的转移路径。

流程图用 drawio。为什么不用那些在线的流程图工具？因为 drawio 的文件格式是开放的 XML，AI 可以直接生成这个 XML，你打开就能编辑，不用手动重画。这一点太关键了。我让 AI 生成 drawio 格式的流程图，它输出的是一段 XML，我保存成.drawio文件，双击就能用 drawio 打开，节点、连线、文字全都在，还能继续拖拽调整。如果你还不清楚 drawio 格式文件怎么打开，最简单的办法就是去 drawio 官网下载桌面版，或者用它的网页版直接导入文件，不需要装什么特殊插件。

PRD 用结构化模板 + AI 填充。PRD 最怕的是"想到哪写到哪"，所以我固定了一套模板：背景与目标、用户角色、核心流程、字段定义、状态机、异常处理、验收标准。每次让 AI 按这个骨架填，填完我再逐项审。模板固定了，AI 的输出质量会稳定很多，因为它知道每一节该写什么。

2.3 工作流的三个阶段划分

整套流程我分成三个阶段，每个阶段有明确的输入和输出：

1. 需求解构阶段：输入是业务方的口头需求或者零散文档，输出是结构化的需求清单和业务规则表。这个阶段 AI 帮你把"一团乱麻"理成"一条条线"。
2. 方案产出阶段：输入是需求清单，输出是 PRD 初稿、drawio 流程图、状态机代码。这个阶段是 AI 的主力战场。
3. 验证迭代阶段：输入是方案，输出是测试用例、边界问题清单、修订版方案。这个阶段 AI 帮你查漏，人工做最终判断。

三个阶段串起来，就是一个完整的闭环。下面我逐个拆开讲实操细节。

3. 需求解构：把一团乱麻理成可执行清单

3.1 售后工单的核心业务规则拆解

先说说这个售后工单案例的背景。业务方的原始需求大概是这样的："用户买了东西有问题，要能提交售后，客服要能处理，处理不了要转给相关部门，最后要能统计。"就这么几句话，信息量极少，但要做成一个系统，背后要补的规则一大堆。

我做的第一件事，是让 AI 帮我把这些模糊描述拆成具体问题。我给它的提示词大意是："这是一个售后工单系统的原始需求，请你以资深产品经理的视角，列出所有需要跟业务方确认的关键问题，按优先级排序。"它给我列了几十条，我挑出真正关键的：

• 工单的来源渠道有哪些？只有 App 还是包括电话、邮件、第三方平台？
• 工单的分类维度是什么？按商品、按问题类型、按紧急程度？
• 什么情况下工单可以自动关闭？用户多久不回复算超时？
• 跨部门流转时，责任怎么判定？谁有权限转派？
• 升级机制怎么设计？超时多久升级、升级给谁？
• 工单的优先级怎么定？是用户选还是系统算？

这些问题如果靠我自己想，可能会漏掉几个，但 AI 一次性列全了，我拿着这个清单去跟业务方对，效率高很多。这就是 AI 在需求阶段最大的价值：它不会累，不会烦，能把一个需求的边边角角都翻一遍。

3.2 用 AI 补全遗漏项和边界场景

业务方回答完上面那些问题后，我手里就有了一份相对完整的规则。但这时候还不能直接写 PRD，因为还有大量边界场景没覆盖。我继续让 AI 做"边界场景穷举"。

举个例子，工单状态流转里有个"转派"操作。正常情况是客服 A 把工单转给客服 B。但边界情况呢？

• 转派时 B 正在休假怎么办？
• 转派后 A 还能不能看到这个工单？
• 转派次数有没有上限？无限转派怎么办？
• 转派后原来的处理记录要不要保留？
• 用户能不能看到工单被转派了？

这些场景 AI 能帮你想出一大半。我的做法是给它一个具体的功能点，让它"列出所有可能的异常情况和边界条件"。它列出来的我逐条判断，合理的纳入 PRD，不合理的丢弃。实测下来，AI 在边界场景穷举上的覆盖率能到七八成，剩下两三成需要靠经验补，但已经省了大量时间。

提示：让 AI 穷举边界场景时，一定要给它具体的功能点，不要给它整个系统。范围越小，它想得越细。给整个系统它只会给你泛泛而谈。

3.3 业务规则表的整理与确认

拆解完之后，我把所有规则整理成一张业务规则表，这是后续 PRD 和状态机的输入。表格大概长这样：

这张表的价值在于，它把散落在各处的规则集中管理，后面写状态机、写测试用例、做验收，全都以这张表为准。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，结果写到后面它把前面定义的状态名都改了，评审时被研发当场指出，非常尴尬。后来改成逐节生成，再没出现过这个问题。

5.3 人工卡点的判断标准

最后说说人工卡点怎么判断。我的标准是三条：涉及钱、涉及权限、涉及用户体验的地方，必须人工确认。涉及钱的比如退款金额计算、赔付规则；涉及权限的比如谁能转派、谁能关闭；涉及用户体验的比如提示文案、操作路径。这三类 AI 可以给建议，但最终决定必须人来拍板。

其他纯结构化的内容，比如字段定义、状态枚举、接口参数，AI 生成后我快速扫一遍就行，不用逐字审。把精力集中在真正需要判断的地方，这才是人机协作的正确姿势。

6. 我在这套工作流里踩过的坑和总结的技巧

6.1 提示词写不好，后面全是坑

我最大的体会是：这套工作流的上限，取决于你写提示词的水平。同样一个需求，提示词写得模糊，AI 给你的就是一堆正确的废话；提示词写得具体，AI 给你的就是能直接用的东西。

我的提示词一般包含四要素：角色设定、任务描述、输入材料、输出格式。比如"你是一个有十年经验的 B 端产品经理，请根据以下业务规则表，生成工单状态机的定义，输出格式为表格，包含状态名、进入条件、退出条件、可执行操作四列"。这样写，AI 的输出基本不用大改。

6.2 不要指望 AI 一次做对

另一个坑是期望值管理。AI 不是一次就能给你完美结果，它更像是一个需要反复沟通的同事。我的习惯是：第一轮让它出初稿，第二轮针对问题让它改，第三轮做细节打磨。三轮下来，质量基本能到可用水平。指望一轮到位，只会失望。

6.3 工具是死的，流程是活的

最后一点，工具选型不是重点，流程设计才是。Codex、drawio 这些工具只是载体，真正决定效率的是你有没有把流程拆清楚、把卡点设对。我见过有人工具用得很溜，但流程一团乱，产出还是不行。也见过工具很朴素，但流程清晰，效率照样高。先把流程想明白，再选工具，顺序不能反。

这套工作流我还在持续迭代，后面打算把测试用例生成和自动化测试再串起来，让验证环节也尽量自动化。不过那是下一步的事了，眼下这套已经能实打实省下不少时间。如果你也在做类似的中后台系统，不妨拿一个真实需求试试，跑一遍就知道哪里适合 AI、哪里还得靠自己。