用户说“帮我改简历”，其实想要的是“我为什么拿不到面试”。做 AI 产品，第一课不是写代码，是问对问题。用户嘴上说的和他真正要的，经常是两回事。需求想清楚了，接下来是把活串起来——工作流；做 AI 产品，工作流设计比模型选择重要。好的工作流，用户视角只有几步：输入一次、看一次结果，中间怎么折腾是系统的事。前期多花一个小时想清楚，后期少花一个月返工。
W3 课件：需求分析 + 工作流设计
这节课要解决的问题：从一个模糊的想法，怎么追问出一份能落地的需求文档；怎么设计工作流，让 AI 在正确的时机干正确的事。
开场（5 分钟）
先讲个真事。
去年有个朋友找我，说他想做一个”AI 简历优化工具”。我说好啊，你跟我说说想怎么做。他说：”就是把简历贴进去，AI 帮我改得更好嘛。”
我问了他几个问题：
- 优化方向是什么？措辞？结构？还是匹配 JD？
- 用户是谁？应届生还是跳槽的？
- 用户贴完简历，你要不要他再贴一个目标 JD？
- 优化完了，用户怎么知道你改了哪里、为什么这么改？
他一个都答不上来。
三个月后他那个产品上线了，用户量惨淡。为什么？因为”贴简历进去，AI 帮我改”这件事，跟市面上几十个简历工具没区别，用户凭什么用你的？
这就是没做需求分析的下场。你以为你在解决问题，其实你只是把”帮我改简历”这句话翻译成了一个产品。用户的真实问题不是”帮我改简历”，是”我投了 100 份简历都没面试机会，到底是哪里出了问题”。
今天这节课，就教你怎么从一个模糊的想法，追问到真正值得做的那个问题。
第一部分：需求追问七步法（40 分钟）
用户说的不等于用户要的
做产品的人有个常识：用户嘴上说的，和他真正要的，经常是两回事。
亨利·福特那句老话：”如果我当年问客户想要什么，他们会说一匹更快的马。”用户不是产品经理，他没法告诉你他需要汽车，他只能告诉你他觉得不方便的地方。
所以需求分析不是”收集用户想要什么”，是”从用户抱怨的地方，挖出来他真正的问题是什么”。
七步追问法
我把需求追问拆成七步，你以后拿到任何一个想法，都按这七步过一遍。
第一步：你想解决谁的什么问题？
注意，这里有两个关键词：谁、什么问题。
“谁”要具体。不是”职场人”，是”工作 3 年左右、第一次带团队的互联网人”。”什么问题”要具体。不是”效率低”，是”每周写周报要翻三天聊天记录，太费时间”。
越具体，你越知道该怎么做。越模糊，你做出来的东西谁都觉得好像有点用、但谁都不会真的用。
第二步：这个问题现在是怎么解决的？
这一步特别重要。用户现在怎么对付这个问题的？用 Excel？找同事帮忙？忍着？
你得知道现状，才能知道你是在替代一个解决方案，还是在创造一个新方案。如果用户现在用一个笨办法解决得挺好，你做个新东西未必有人买账。
第三步：现有方案有什么不爽的地方？
用户不是没有方案，是对现有方案不满意。哪里不满意？太慢？太贵？太麻烦？不靠谱？
这些”不爽”就是你的机会点。你不是凭空创造需求，你是在用户已有的抱怨里找机会。
第四步：用户长什么样？
用户的画像越具体越好。他多大？做什么工作？每天在什么场景下遇到这个问题？用什么设备？他愿意为解决这个问题花多少钱？
你画不出这个画像，你就不知道该把产品做成什么样。
第五步：成功长什么样？
你做的这个东西，用了之后，用户的状态发生了什么变化？
“省了 2 小时”是成功。”用户从 100 份简历没面试到拿到面试”是成功。”写周报从翻三天聊天记录变成十分钟搞定”是成功。
说不清成功长什么样，你就没法判断自己做对了没有。
第六步：AI 在里面干什么？
这是 AI 产品特有的一步。在整个流程里，AI 负责什么？哪一步是 AI 干的？哪一步是人干的？哪一步 AI 干完还要人确认？
很多人做 AI 产品的思路是”全交给 AI”，这往往是错的。AI 干擅长的事（理解、生成、总结），人干需要判断和负责的事。这个分工想清楚了，产品才靠谱。
第七步：用户怎么知道你做对了？
用户怎么判断你这个产品好用？他的评判标准是什么？
是结果好不好？是快不快？是省了多少钱？还是用起来顺不顺？
你得知道用户拿什么尺子量你，才能往那个方向使劲。
需求澄清表
把这七步填完，就是一张需求澄清表。以后不管谁找你说”我有个产品想法”，你把这张表丢给他，让他填。填不上来的部分，就是他还没想清楚的地方。
这张表不是走形式。我见过太多产品，做到一半发现”哦原来用户不是这么想的”，推倒重来。前期多花一个小时想清楚，后期少花一个月返工。
第二部分：工作流设计（40 分钟）
需求想清楚了，接下来设计工作流。
什么是工作流
工作流就是：用户的一个请求进来，系统按什么顺序、走哪些步骤、每一步干什么、出错了怎么办。
你可以把工作流理解成一张流程图：开始 → 判断 → 调工具 → 调 AI → 人工确认 → 结束。
做 AI 产品，工作流设计比模型选择重要得多。同一个模型，工作流设计得好，效果就好；工作流设计得烂，再贵的模型也救不回来。
工作流的基本节点
一个典型的 AI 工作流，会用到这几种节点：
开始节点：用户输入进来了。
条件判断节点：根据输入判断走哪条路。比如用户问的是物流问题还是退款问题？判断完了走不同分支。
LLM 节点：调用大模型干一件事。理解用户意图、生成一段文案、总结一份文档、分类一段内容。
知识库节点：去知识库里查相关信息。比如查公司产品手册、查政策文件、查历史对话。
接口节点：调用外部系统的 API。查物流、查订单、发邮件、发短信。
代码节点：跑一段代码。做数据计算、格式转换、数据清洗。
人工节点：AI 干不了的，或者风险高的，转给人来处理。
结束节点：把结果返回给用户。
四种 AI 工作模式
这几年 AI 产品的工作流，总结下来就四种基本模式：
第一种：Reflection（反思模式）
AI 干了一件事，然后自己检查一遍：”我写的这个东西对不对？有没有问题？”检查完了再输出。
适合什么场景？需要高准确性的场景。比如写正式邮件、写代码、写法律条款。AI 写完自己审一遍，比直接输出靠谱得多。
第二种：Tool Use（工具使用模式）
AI 不直接回答，它先判断”我需不需要查个工具”。需要的话就去查，查完了再回答。
适合什么场景？需要实时信息的场景。比如查天气、查股价、查物流。AI 自己不知道这些信息，得调接口查。
第三种：Planning（规划模式）
面对复杂任务，AI 先拆解步骤：”这个事要干成，得先做 A，再做 B，再做 C。”拆完了一步一步执行。
适合什么场景？多步骤的复杂任务。比如”帮我策划一次营销活动”，AI 先拆成：定主题、选渠道、写文案、做排期，然后一步步来。
第四种：Multi-agent（多智能体模式）
多个 AI 角色分工合作。一个负责写、一个负责审、一个负责改，最后汇总。
适合什么场景？需要多视角、多角色的复杂任务。比如”评审一份方案”，让”产品经理””设计师””工程师”三个角色分别提意见，最后汇总。
工作流设计的三个坑
坑一：什么都想自动化
我见过太多人，工作流设计得全是自动化节点，一个人工节点都没有。结果就是 AI 一旦出错，错得离谱，用户根本不知道。
设计工作流的时候，问自己：哪一步出错的代价最大？那一步必须加人工节点。比如涉及钱、涉及用户隐私、涉及对外发出的内容，AI 干完必须让人看一眼。
坑二：不考虑失败情况
工作流图画得特别顺，一路绿灯到结束。现实中呢？知识库查不到怎么办？接口超时了怎么办？大模型回答跑偏了怎么办？
这些失败场景你不设计好，上线之后全是线上事故。每个节点都要想：如果这一步失败了，系统怎么办？是重试？是降级？是转人工？
坑三：工作流太复杂
有些人为了”完整”，设计了十几步的工作流，用户进来走半天才能到结果。用户等不及，也看不懂。
好的工作流应该是：用户视角只有几步，背后的复杂逻辑藏在系统里。用户只需要输入一次、看一次结果，中间怎么折腾是系统的事。
案例拆解（30 分钟）
大厂案例：智能标书系统
我们看一个复杂一点的：一个帮企业写投标标书的系统。
这个系统的需求是什么？企业要投标，得写一份几十上百页的标书。以前靠投标专员写，一份标书写一两周，还得反复改。
工作流大概是这样的：
- 开始：企业上传招标文件
- LLM 节点：大模型读招标文件，提取关键要求（评分标准、资质要求、截止日期）
- 知识库节点：从公司资料库调取历史标书、公司资质、案例
- LLM 节点：根据提取的要求 + 公司资料，生成标书初稿
- 人工节点：投标专员审核初稿，修改
- LLM 节点：根据专家评审视角，自动检查标书有没有遗漏评分项
- 结束：输出终版
这个工作流里，AI 干的是”读、写、检查”，人干的是”审、改、定”。分工很清楚。
关键设计在哪？第 6 步——AI 自己检查评分项。这个设计把投标专员从”从头看到尾”变成”只看 AI 标出来的问题”，效率高了好几倍。
本地案例：服务企业的 AI 接待 + 工单分流
我们本地有一家做售后服务的公司，客户打电话进来投诉或者咨询，以前全靠人工接。接起来之后，先听用户说问题，再判断是哪个部门的事，再转给对应部门。高峰期接不过来，客户就骂。
后来做了一套 AI 接待 + 工单分流系统。工作流是这样的：
- 开始：用户打电话/发消息进来
- LLM 节点：理解用户说的是什么问题（是产品故障？还是服务投诉？还是咨询价格？）
- 条件判断：
- 简单问题（比如”你们几点下班”）→ AI 直接回答
- 需要查订单的 → 调订单 API，查完了回答
- 复杂投诉 → 生成工单，按问题类型分流到对应部门
- 人工节点：部门负责人收到工单，确认后处理
- 结束：给用户回个进度
这个工作流的关键设计在第 2 步：意图识别。AI 能不能准确判断用户是哪类问题，决定了后面整个流程走得对不对。
我们调这个意图识别模型调了很久。刚开始准确率只有 60% 多，经常把”退款”分到”物流”去。后来加了几百条真实对话数据做微调，加上一些关键词规则兜底，才提到 90% 以上。
这就是真实项目的样子：不是设计完就完了，得反复调、反复测，调到达标为止。
现场动手（30 分钟）
现在分成小组。每组选一个你们组感兴趣的场景（可以是你自己工作中的痛点，也可以是刚才案例里延伸出来的）。
做两件事：
第一件：填需求澄清表
用刚才讲的七步追问法，把这个场景的需求澄清表填出来。七步每步都要填，填不出来的就是没想清楚的地方。
第二件：画工作流
根据澄清后的需求，画出工作流。要求：
- 至少用到 3 种不同的节点类型
- 至少有 1 个人工节点
- 标注出哪个地方可能出错、出错了怎么办
画完了组间交换看，互相挑毛病：这个工作流有没有遗漏？有没有不合理的地方？
课后作业
必做：需求分析文档（≤2 小时）
写一份你自己项目的需求分析文档，包含三部分：
1. 需求澄清表
七步追问，一步不能少。
2. 意图分类
你的产品面对用户输入，要分几类？每一类怎么识别？列出分类标准和判断规则。
3. 竞品简表
找 2–3 个跟你做的事情类似的产品，简单列一下：它们怎么做的？有什么不足？你跟它们有什么不一样？
合格标准：澄清表七步齐全 + 意图分类说得清 + 竞品不是随便抄个官网描述，是真的看了之后写的判断。
选做：工作流设计图
画出你产品的工作流图，标注每个节点的类型、输入输出、失败处理。这个选做，但如果你做了，下节课现场可以直接用你的工作流来设计 Agent 结构。
本节课顾问团动作
这节课的作业，你要丢给你的顾问团评审。
怎么评审？打开你的顾问团，把需求文档发给他们，让每个顾问从自己的视角提意见：
- 梁宁会问：你这个真需求还是伪需求？用户是嘴上想要，还是真愿意买单？
- Cagan 会问：你这里面最大的风险是什么？技术风险？价值风险？可用性风险？
- 俞军会问：用户的价值公式是什么？他得到了什么？付出了什么？值不值？
把顾问团的意见记下来，跟你自己原来的想法对比一下。你会发现，同一份需求文档，不同视角看出来的问题完全不一样。这个碰撞过程，就是你把需求想透的过程。
下节课预告
W4 我们讲 Agent 结构和 Skill 设计。
前面我们讲了工作流、讲了需求分析，这节课讲怎么把工作流拆成一个个可复用的”技能模块”——Skill。你可以理解成，工作流是整条流水线，Skill 是流水线上的每个工位。
学会了 Skill 设计，你就能把复杂的 AI 产品拆成一个个小模块，拼来拼去搭出不同的东西。这个能力，后面不管你做什么 AI 产品都用得上。
讲师手记
这节课内容比较多，我知道你可能一下消化不了。没关系，这节课的核心不是让你记住所有节点类型，是建立两个意识：
第一个意识：需求要追问，不要听风就是雨。用户说什么你做什么，最后做出来的东西没人用。你得追问到”他真正的问题是什么”，才值得动手做。
第二个意识：工作流要设计失败路径。一路绿灯的流程图是给老板看的，真正上线的系统，得把所有翻车场景都想到。AI 出错不可怕，可怕的是出错了你不知道。
这两个意识，比记住多少个节点类型都重要。节点类型忘了可以查，意识没建立，做出来的产品迟早要出事。
下节课见。