“我们想做个 AI 助手”这种需求没法直接开发——不知道给谁用、在什么时刻用、替代了原来的哪个动作，写出来的东西大概率没人用。服务设计解决的就是这一段：把用户旅程摊开，找到 AI 真正能插进去的那几个节点，用纸面原型或极简 Demo 先验一遍，再决定要不要写代码。
适用对象
- 产品形态还没想清楚，但已经有预算和时间窗口
- 多个部门对同一个 AI 项目的期待不一致，需要一次把话说开
- 面向 C 端或一线员工的 AI 产品，体验决定用不用
- 不适合：需求已经明确到可以写技术文档的。那就直接进 AI 智能体落地
我们怎么做
- 用户走访：找 6–10 个真实用户，看他们现在怎么做这件事、卡在哪
- 旅程梳理：画出完整服务旅程，标出情绪低谷与等待时间最长的节点
- 共创工作坊：跨部门一起出方案，现场收敛到 2–3 个候选
- 原型与验证：做可点击原型或人工模拟版，拿回去给真实用户试
- 产品定义：输出可开发的需求文档与验收标准
交付物
- 用户走访记录与洞察清单
- 服务旅程图（现状 / 目标）
- 候选方案与取舍记录
- 可点击原型 + 用户验证结论
- 产品需求文档与验收标准
常见问题
- Design Thinking 和需求调研有什么区别？
- 需求调研问用户想要什么，得到的往往是"要个更快的马"。服务设计看用户实际怎么做事、在哪卡住，再判断 AI 能插进哪个节点。产出是可开发的产品定义，不是需求清单。
- 工作坊要哪些人参加？
- 业务负责人、一线代表、产品或 IT，缺一不可。只来管理层，方案落不到真实流程；只来一线，做不了取舍。
- 原型是能跑的产品吗？
- 不是。原型是可点击的界面或人工模拟版（背后是人在操作），目的是在写代码前先验证用户会不会用。验证通过才进开发。
- 做完一定要接着做开发吗？
- 不一定，而且"验证不通过、不做了"是合法结论。这正是服务设计省钱的地方——在几周内证伪，比上线后发现没人用便宜得多。
- 有做过的案例吗？
- 果麦文化：400 个 AI 伴读智能体、10000 本书知识图谱。诺华：数字人智能营销。