“我们想做个 AI 助手”这种需求没法直接开发——不知道给谁用、在什么时刻用、替代了原来的哪个动作，写出来的东西大概率没人用。服务设计解决的就是这一段：把用户旅程摊开，找到 AI 真正能插进去的那几个节点，用纸面原型或极简 Demo 先验一遍，再决定要不要写代码。
适用对象
- 产品形态还没想清楚，但已经有预算和时间窗口
- 多个部门对同一个 AI 项目的期待不一致，需要一次把话说开
- 面向 C 端或一线员工的 AI 产品，体验决定用不用
- 不适合：需求已经明确到可以写技术文档的。那就直接进 AI 智能体落地
我们怎么做
- 用户走访：找 6–10 个真实用户，看他们现在怎么做这件事、卡在哪
- 旅程梳理：画出完整服务旅程，标出情绪低谷与等待时间最长的节点
- 共创工作坊：跨部门一起出方案，现场收敛到 2–3 个候选
- 原型与验证：做可点击原型或人工模拟版，拿回去给真实用户试
- 产品定义：输出可开发的需求文档与验收标准
交付物
- 用户走访记录与洞察清单
- 服务旅程图（现状 / 目标）
- 候选方案与取舍记录
- 可点击原型 + 用户验证结论
- 产品需求文档与验收标准
企业服务设计咨询，留下哪些可讨论的材料
设计思维工作坊要把需求变成可验证的选择。AI产品服务设计可围绕以下四类材料展开，具体样式按项目确认：
| 材料 | 要回答的问题 | 评审方式 |
|---|---|---|
| 用户旅程 | 谁在什么时刻遇到障碍 | 由真实用户核对步骤 |
| 服务蓝图 | 前台体验背后由哪个岗位或系统支持 | 跨部门确认责任与依赖 |
| 原型 | 候选方案是否帮助用户完成任务 | 用任务测试记录失败和反馈 |
| 需求定义 | 第一版做什么、哪些不做、如何验收 | 业务与交付负责人共同确认 |
AI需求共创工作坊不是一次头脑风暴结束后的概念汇报。未验证的假设保留为假设，意见分歧记录取舍依据；开发费用与周期在范围清楚后另行评估。可继续看智能体开发采购清单，或联系 Moments 讨论共创对象与目标。
常见问题
- Design Thinking 和需求调研有什么区别？
- 需求调研问用户想要什么，得到的往往是"要个更快的马"。服务设计看用户实际怎么做事、在哪卡住，再判断 AI 能插进哪个节点。产出是可开发的产品定义，不是需求清单。
- 工作坊要哪些人参加？
- 业务负责人、一线代表、产品或 IT，缺一不可。只来管理层，方案落不到真实流程；只来一线，做不了取舍。
- 原型是能跑的产品吗？
- 不是。原型是可点击的界面或人工模拟版（背后是人在操作），目的是在写代码前先验证用户会不会用。验证通过才进开发。
- 做完一定要接着做开发吗？
- 不一定，而且"验证不通过、不做了"是合法结论。这正是服务设计省钱的地方——在几周内证伪，比上线后发现没人用便宜得多。
- 有做过的案例吗？
- 果麦文化：400 个 AI 伴读智能体、10000 本书知识图谱。诺华：数字人智能营销。
聊聊Design Thinking 服务设计的具体需求说明业务目标、已有资料与期望交付，我们先确认适用范围和下一步。