AI进入服务交付，
改变的不只是界面
当用户可以直接表达目标、AI可以调用系统，服务体验的设计对象便从触点延伸到完整任务。
数字化曾让越来越多服务从柜台、电话和纸质表单转向自助界面。它提高了可访问性，也常常把企业内部的复杂度交给用户：阅读规则、填写信息、判断路径、跨系统追进度。
生成式 AI 为这种分配提供了另一种可能。在经过授权、连接可靠知识与工具的条件下，AI 能协助完成需求整理、资料核验、信息比较及部分受控操作。用户可以少学几个系统、少重复一次背景，员工可以将更多精力投入难以标准化的判断和关系维护。
从操作界面到完成任务
减少完成目标所需的无意义步骤，而不只是优化每一步的点击。
从单个触点到协同服务
把官网、员工、流程、系统与外部伙伴纳入完整旅程。
从执行自动化到责任设计
清楚界定 AI 何时提供信息、提出建议、拟办或执行。
从“用户跑流程”到“系统协同完成任务”
但更少的界面并不总是更好的体验。复杂交易、重要承诺和高风险决策仍需要明确的解释、比较与确认。用户拥有的信息可能被机器处理得更快，却未必被理解得更清楚。因而服务设计需要同时关注效率、服务质量与人的自主权。
AI服务设计，不必
从零建立理论
服务蓝图、价值共创和服务生态系统，为讨论新的服务参与者提供了坚实起点。
服务蓝图：看见用户体验背后的组织
Shostack 于1984年提出系统地设计与管理服务过程的重要性。她指出，许多服务失败与缺少系统化设计和控制有关，蓝图有助于提前发现问题和创新机会。[01] Bitner、Ostrom 与 Morgan 在2008年进一步说明，服务蓝图可以将用户体验与员工、技术和后台支持活动之间的依赖关系可视化。[02]
这套思想在 AI 场景中依然成立。AI 客服的错误答复，可能来自模型生成偏差，也可能来自产品政策版本冲突、权限不清、业务流程断点或数据同步延迟。若不追查服务系统中的原因，单纯修改提示词可能无法解决问题。
服务主导逻辑：价值在使用中形成
服务主导逻辑强调多方资源整合和价值共创。[03] AI 提升了信息处理和协同能力，但机器给出答案并不意味着服务已经创造价值。客户能否据此完成采购、员工能否据此准确履约、组织能否承担承诺，才决定结果。
服务生态系统：规则与制度同样需要被设计
Vink 等人的研究将服务设计进一步连接到多参与者系统中的制度安排和依赖关系。[04] 对企业 AI 项目来说，这意味着需要回答谁维护知识、谁批准敏感操作、谁可以查看客户信息，以及不同部门如何共同交付承诺。
AI不是经典服务设计的替代者。它扩大了经典服务设计需要协调的参与者、行动能力和不确定性。
COMMA咖墨｜基于经典理论的研究判断本研究因此将 AI 视作服务系统中可能执行部分行动的技术参与者，同时坚持：AI 的行动能力不能被等同于独立法律责任，相关责任仍需依照具体业务、合同与适用法律界定。
系统替用户减重
把应当由服务系统承担的复杂度，重新交还给系统。
许多数字化项目看上去减少了员工操作，却没有减少用户付出的努力。用户必须自己理解业务术语、反复填写资料、跨渠道等待答复，甚至协调企业内部部门。
COMMA咖墨把一种服务设计工作原则暂称为“系统替用户减重”：通过信息结构、流程、组织协作与技术能力的重新设计，减少用户为完成合理目标而承担的不必要成本，同时保留必要的知情权、判断权与控制权。
用户承担的六种服务负担
减重的三个约束条件
- 1不把负担隐藏或转嫁
用户少花十分钟，但员工增加大量补救工作，可能只是把成本转到了别处。需要同时观察客户、员工和系统维护方。
- 2不以减少步骤替代结果质量
某些确认、解释和比较具有保护作用。高风险行动越容易自动执行，越需要明确授权与适度摩擦。
- 3不以效率牺牲人的自主权
用户应知道什么正在被处理，能够查看关键依据，并在必要时撤销授权、寻求人工帮助或纠正结果。
“系统替用户减重”不是既有学术文献中的统一成熟概念，而是咖墨正在通过服务实践进一步定义的工作原则。它能否发挥作用，需要由具体场景中的端到端任务完成、用户投入与总服务成本共同验证。
一条用户旅程，
重新组织四个企业系统
延续 COMMA咖墨现有的服务体验重构框架，把 AI 纳入既有的品牌、业务、组织与技术关系。
用户不会按企业的部门架构体验服务。一个潜在客户需要的可能只是找到适合的解决方案，得到可信答复，顺利采购并持续获得支持。但在企业内部，这个目标会跨越品牌内容、业务运营、组织协作和数字技术。
因此，我们在官网已有的服务体验重构框架上，维持“一条用户旅程、四个企业系统、五个实施阶段”的主结构。AI 是贯穿各系统的能力，不另造一套与原有服务体系脱节的部门或平行系统。查看咖墨服务设计框架 ↗
我们承诺什么，用户如何理解与信任。
如何创造价值，以及如何兑现商业承诺。
谁参与服务，谁交接，谁对结果负责。
知识、数据、接口、产品与 AI 如何支撑服务。
图 3｜“一条用户旅程、四个企业系统、五个实施阶段”框架的可视化。AI 是贯穿各系统的协同能力，并非额外增加一个独立系统。
举例来说，一个品牌官网可以让客户理解产品优势；销售系统负责评估需求；工程团队对复杂适配性作出确认；技术平台承接信息、审批及交付进度。AI 若进入这个过程，应帮助不同参与者更有依据地完成任务，而不是让每个部门分别增加一个与其他系统不连通的机器人。
AI协同服务蓝图
在经典服务蓝图中，补上 AI 行为、授权边界、人机交接和异常恢复。
传统服务蓝图有力地揭示了用户动作、前台活动、后台流程与支持系统之间的关系。AI 使这些关系更加动态：一个回答可能调用多种知识；一次预约可能跨多个系统；一次操作可能要求用户、员工和 AI 连续确认。
COMMA咖墨将扩展后的工作草案称为 AI协同服务蓝图（AI Service Blueprint，工作框架 V0.5）。它不取代经典蓝图，而是在保留交互线、可视线和内部交互线的基础上增加新的诊断层次。为避免混淆，这里不将版本号“2.0”描述为行业通用标准。
图 4｜AI协同服务蓝图结构示意。泳道和经典边界用于工作讨论，不代表任何客户真实系统架构；实际项目需依业务区分前后台与各参与者。
一张可实施的蓝图，还应回答五个问题
- 1AI代表谁？
区分企业提供的 AI 服务、员工使用的内部助手及由用户授权的外部代理，避免把不同主体的权限混为一谈。
- 2AI依据什么作出行动？
标明知识来源、适用版本、业务规则和调用的系统。避免把未经核验的模型生成内容当成业务事实。
- 3AI可以做到哪一步？
将信息提供、方案建议、业务拟办和授权执行分开设计，风险越高越需要具体的权限控制。
- 4交接时留下什么？
转交已获授权的上下文、已完成动作、待决事项和关键依据，让员工能够判断，而不是要求客户重新开始。
- 5失败后如何恢复？
明确错误答案、系统超时、拒绝授权、重复执行、不可用接口与人工未接手等异常路径和责任。
在复杂 AI 系统中，模型自述的“置信度”不应直接视为可靠的业务概率。是否进入人工流程，需要结合规则、风险、来源可验证性、工具结果及任务约束共同确定。
从人服务人，
到混合服务接触
当 AI 可能既是提供者，也可能是使用者，服务设计必须明确“谁向谁提供服务”。
Mortati 与 Freitas 在2025年在线发表、2026年正式刊载的研究提出混合人机服务接触框架，依据服务提供者和服务使用者分别是人或 AI，区分四种关系。[05] 下图依据该研究进行简化转述，并用企业服务情境解释其用途。
人工顾问、客户经理及专业服务。关注信任、情境理解、关系维护与技术辅助。
销售或客服与客户侧 AI 代理沟通。关注机器可理解的信息、代理身份与真实授权。
企业智能客服和员工助手。关注事实可靠性、解释方式、干预与退出机制。
客户代理与企业系统交互。关注能力接口、协议、安全范围、记录与追溯。
研究示意｜箭头由服务提供方指向服务接受方。四类关系依据 Mortati 与 Freitas 的研究；场景解释由本文整理，并非咖墨独创四象限。
这一框架的重要启示是：同一家企业未来可能同时为人和机器提供信息与服务。但“机器能读取信息”不等于“机器能被授权执行业务”。公共产品资料、需要登录的客户资料与具有商业法律后果的交易操作，应当处于不同的能力和权限层级。
在面向客户的官网、小程序或业务平台上，应优先做好准确、清晰、可验证的信息与稳定的用户服务；只有在确有业务价值、具备授权与控制条件时，再发展更复杂的机器调用能力。
AI做到什么，
人与组织负责什么
分工不是技术先进程度排行榜；它由服务价值、结果风险与控制能力共同决定。
Huang 与 Rust 的研究讨论了不同类型 AI 与服务任务之间的适配。[06] 在实际项目中，我们还需要结合后果严重性、可逆性、数据可靠性与业务责任，明确行动权限。
根据任务条件设计参与方式
| 任务区间 | 较适合的场景 | AI 可以做什么 | 人的角色与控制 |
|---|---|---|---|
| Zone A AI 主导 | 规则清晰、低风险、可核验且易撤销 | 状态查询、常见解释、标准资料整理、受控操作 | 预先定义规则、监控质量、处理例外 |
| Zone B 人机协同 | 需要综合判断、存在一定商业影响 | 澄清需求、准备方案、核对材料、拟办任务 | 检查依据、批准关键承诺、必要时接管 |
| Zone C 人主导 | 重大承诺、敏感情境、高风险或强关系服务 | 整理背景、提供备选信息与辅助分析 | 完成专业判断、沟通与责任承担 |
同一项任务在不同场景下可能落入不同区间。高价值设备退货、低价商品退款和特殊医疗判断，其后果和责任结构无法用同一条自动化规则概括。
FOUR PERMISSION LEVELS
之间，还有授权边界。
01 · 信息提供
检索、组织并解释可公开或被授权的信息。
02 · 方案建议
给出备选方案，说明依据、不确定性与限制。
03 · 业务拟办
形成可审阅的操作草稿，等待用户或员工确认。
04 · 授权执行
在明确范围、规则与记录机制下执行指定动作。
人工介入必须是有效控制，而不能只是象征性的审核按钮。审核者需要看得到必要依据、具备判断能力、拥有实际干预权限，并有足够时间处理问题。
NIST 的 AI 风险管理框架及生成式 AI 专题文件、OECD AI 原则与 ISO/IEC 42001 标准，均可为持续风险识别、管理和治理提供依据，但不能代替具体场景的法律评估与业务责任划分。[07][08][09]
服务设计如何进入
真实的企业问题
从复杂技术服务的客户沟通，到跨境 B2B 采购、会员组织运营和高端教育数字服务，四个项目呈现了服务设计在不同业务环境中的具体作用。
服务往往从一个看似明确的需求开始：优化销售材料、升级企业官网、建设小程序，或者维护数字平台。但当工作深入到客户实际的使用和决策过程，问题就会超出单个触点。信息如何被理解，任务如何顺利交接，后台如何承接承诺，以及服务如何持续更新，都需要放进同一条用户旅程中审视。
四个项目，四种服务设计切面
安畅网络｜让复杂技术能力进入客户听得懂的服务对话
2026 年，咖墨与安畅网络启动服务设计陪跑咨询，首阶段聚焦 AI 云服务业务中的客户首次交流。对于服务能力复杂的技术企业，客户提出的往往是业务场景、实施顾虑与结果期待，而销售团队习惯使用的则是技术架构、产品能力和专业术语。两套语言之间如果缺少有效转换，技术优势很难在第一次沟通中成为客户可以判断的合作理由。
项目围绕销售首访梳理客户问题识别、场景理解、价值表达与下一步行动的连接方式，并开展售前能力相关共创。设计工作所关注的，不止是一份演示材料是否完整，还包括销售如何提出问题、如何界定可兑现的服务承诺，以及何时需要技术和后续服务团队共同介入。
Tim&soul｜让企业官网更好地支持跨境采购决策
Tim&soul 面向海外美妆品牌提供化妆品包材开发与供应链服务。围绕其官网升级，咖墨形成的方案将视角放在韩国、美国等目标市场的 B2B 采购者身上：采购者需要了解产品种类，也需要判断材质、应用场景、开发与定制能力、协作流程，以及企业是否具备可靠的供应链服务能力。
因此，方案从目标客户的判断路径出发，规划产品信息架构、专业内容层级、视觉呈现与咨询入口，并将客户关系和后续服务的数字化支持纳入升级讨论。官网在这里承担的角色，是帮助客户从初步认识企业逐步走向产品评估和商务沟通，而非单纯陈列产品图片。该项目目前以已形成的官网升级方案为讨论依据。
上海市安徽商会｜把会员需求与秘书处工作放在同一条服务链路中
上海市安徽商会的会员服务涉及活动组织、供需对接和企业联系。原有微信群、表单和 Excel 能完成单项沟通，却难以让活动信息、会员身份与运营记录持续衔接。咖墨以会员的高频任务为起点，规划并开发“云上徽商”小程序，同时设计秘书处管理后台和组织权限体系。平台于 2025 年 5 月 30 日正式上线。
在活动服务中，发布、报名、信息收集、现场签到和数据留存被组织为相互衔接的过程；会员通讯录与企业、职级、专业委员会等组织信息建立关联，供需信息也形成了更便于查找和管理的入口。前台服务是否方便，取决于后台能否持续承接日常运营，而这一点从产品规划阶段就需要共同设计。
复旦大学管理学院｜沿着学员关系的变化持续建设数字体验
咖墨自 2016 年起持续参与复旦大学管理学院相关数字项目，合作由复旦大学—华盛顿大学 EMBA 官网运维开始，逐步延伸至搜索优化、微信服务、互动内容、复旦奥林 EMBA 小程序，以及 EE 官网升级与持续运维。对高端管理教育而言，潜在学员了解课程、作出申请判断，学员参与课程和活动，校友保持长期联系，对应着不同阶段的服务需求。
这类数字服务没有单一的“完成时刻”。招生信息、课程安排、活动和技术环境都在变化，网站与小程序必须随业务节奏持续更新。咖墨的工作由早期网站维护，延伸至产品策划、UX/UI、开发与运营支持，体现了设计、技术与长期服务之间的连续关系。
四个场景的业务性质不同，却指向同一件事：服务设计需要连接用户正在完成的任务与组织真正能够提供的能力。AI 为这些连接提供了新的技术手段，也对信息质量、任务边界和协同机制提出了更高要求。真正值得被重新设计的，是从客户理解、服务承诺到实际交付的完整过程。
这些实践，对应哪些企业需要解决的问题？
COMMA咖墨以服务设计连接品牌表达、数字产品、组织流程与持续运营。面对跨部门服务割裂、B2B官网难以支持采购判断、会员服务依赖分散工具或长期数字平台需要演进等问题，可以从用户旅程与前后台协同切入。实际合作范围由具体项目需求、现状和交付条件确定。
识别客户旅程断点，明确前后台任务与责任。
组织能力、产品资料与可信证据，支持客户理解和选择。
把会员、业务流程、权限和运营联成可使用的服务。
从一个已上线的服务场景，
推演未来 AI 机会
当一项数字服务已经建立起清晰的业务流程和信息结构，AI 还可能在哪些环节提供新的帮助？以“云上徽商”的会员服务场景为例，进一步讨论可供验证的设计方向。
“云上徽商”已经将活动管理、供需对接、会员通讯录与相应后台流程组织起来。下一步若评估 AI 机会，可以从一个具体任务开始：会员希望找到某类企业资源时，能否更准确地表达需求、筛选信息，并获得适当的后续服务？
| 可讨论的未来机会 | 可能的 AI 辅助任务 | 实施前必须确认 |
|---|---|---|
| 会员资源发现 | 把自然语言需求转成结构化搜索条件，推荐符合条件的公开会员资料 | 资料权限、更新状态、匹配依据与结果可解释性 |
| 活动服务 | 解释活动规则、提示报名材料、辅助整理工作人员待办 | 活动政策版本、真实报名状态、异常与人工处理 |
| 秘书处运营 | 整理已授权的信息、生成审核草稿、识别重复工作 | 个人信息访问、审批权限、操作日志与责任归属 |
这三项机会是否值得实施，还需要进一步进行用户研究、数据质量检查、权限评估和成本测算。如果结构化检索或普通规则引擎已经足够解决问题，就没有必要增加生成式 AI。
同样，一旦涉及会员联系方式、企业商业资料或组织身份信息，AI 系统的可见范围必须遵守相应授权，不能以“便捷推荐”为理由自动开放数据。
一个成熟的 AI 服务设计项目，应该允许最后的结论是：这里暂时不需要 AI。
COMMA咖墨｜方法判断如何开始一个
AI服务设计项目
从一条真实旅程出发，先理解既有服务，再判断 AI 应当进入哪里。
五阶段项目路径：从问题到持续验证
研究｜识别重要负担
选取有价值的用户任务，观察用户、员工和系统目前如何完成它；记录等待、错误、重复与决策难点。
定义｜画出现状蓝图
连接品牌、业务、组织、技术；识别流程依赖、知识归属、权限、责任人与已有非 AI 改进空间。
共创｜设计未来服务
明确哪些步骤应消失、哪些应由规则自动处理、哪些由 AI 辅助、哪些必须由人判断。
实现｜用真实情境测试
测试正常流程、模糊需求、知识缺失、系统超时、拒绝授权及人工交接，不只展示理想演示。
迭代｜观察服务是否真的改善
将上线后的运行状态与原型假设对照，定期检查客户任务完成、员工负担、业务效果及风险事件；持续更新知识、流程和治理规则。
项目启动前，可先回答这六个问题
- 客户究竟要完成什么，而不仅是“使用哪个触点”？
- 目前最昂贵的等待、重复、误解或失败发生在哪里？
- 哪些问题无需 AI，调整流程或结构化数据就能解决？
- AI 需要访问哪些资料、工具和行动权限？
- 何时由人介入，出现错误后如何撤销和恢复？
- 如何证明服务改善，并避免成本或风险转嫁？
这些问题能帮助企业避免从技术清单开始定义项目。真正的实施路线还应随业务复杂度、组织能力和风险等级调整，不能机械套用统一的人力配置、成本预算或周期。
怎样衡量 AI 服务设计
有没有创造价值
不要只看自动化率；需要观察完整任务、总成本、用户与员工体验，以及安全治理。
评价的是完整服务，而非单个模型
| 维度 | 可观察指标 | 常见误判 |
|---|---|---|
| 用户结果 | 端到端任务完成率、完成时间、用户努力度、满意度、重复操作 | AI作出回复不等于问题被解决 |
| 运营效率 | 一次解决率、平均等待、返工、服务总处理成本 | 局部节省不等于组织整体降本 |
| AI可靠性 | 信息正确性、依据可核查性、工具执行成功、异常识别 | 回答流畅不等于业务准确 |
| 人机协作 | 交接完整度、人工修正量、员工工作负荷、例外处理 | 转人工少未必代表服务更好 |
| 商业价值 | 合格咨询、成交周期、履约质量、留存、复购（按项目选择） | AI参与不代表创造了增量价值 |
| 风险与治理 | 越权事件、错误承诺、审计与追溯覆盖、错误恢复时间 | 未报告事故不代表不存在风险 |
指标应围绕具体项目预先定义。售后场景的“完成”可能需要工单状态和客户确认，复杂售前场景的“完成”则可能是需求被正确记录并得到具有权限的专家判断。不同场景不宜用一个未经验证的总分评价。
对于重要项目，应在实施前保留可比较的服务基线，并在实际运行中记录失败、未完成、受限和人工补救的情况。若使用试点组和对照组，也需说明任务复杂度、用户结构及观察时间的差异。
仍待研究的五个问题
研究的严谨性，首先来自对边界的承认。
- 01AI如何真正代表人的利益？
用户授权与用户利益并非一回事。代理是否理解约束、如何处理利益冲突和撤销授权，需要持续验证。
- 02自动化减少了谁的负担，又增加了谁的负担？
当客户少操作、员工却需要大量纠错，服务是否真的改善？应同时观察多方的时间、认知和协作成本。
- 03人机交接何时比更高自动化率更有价值？
复杂任务可能更依赖充分的信息上下文与准确的人类判断，需要从完整任务质量中寻找答案。
- 04AI与AI之间的服务怎样保持人的控制？
机器间调用可能提高效率，但授权主体、接口权限、不可逆操作与审计机制不能因此变得模糊。
- 05品牌、艺术与技术如何在智能服务中共同创造意义？
准确性与效率是必要条件，清晰、信任、包容性、情感和长期品牌体验仍需被设计和验证。
本白皮书属于综合研究与框架草案，未开展对“系统替用户减重”的跨行业定量检验，也未宣称 AI 协同服务蓝图优于其他成熟设计工具。下一阶段更有价值的研究工作，是在获得授权的真实项目中记录现状、设计决策、验证条件及结果差异。
企业准备应用 AI 时，
还需要回答什么？
围绕常见的项目采购与服务设计判断，给出适用条件明确的简答。
企业什么情况下需要做 AI 服务设计，而不仅是增加一个 Agent？
当客户为了完成一项任务必须跨官网、销售、客服和后台系统反复提供信息，或者多个 AI 工具上线后仍无法形成完整服务时，企业应首先梳理用户旅程、前后台流程、知识依赖与责任分工。Agent 可以是方案的一部分，但不能替代服务系统诊断。
AI 协同服务蓝图与传统服务蓝图有什么区别？
经典服务蓝图用于描述用户行为、前台活动、后台流程与支持系统。COMMA咖墨提出的 AI 协同服务蓝图保留这些基本边界，并补充 AI 的角色、行动权限、人与 AI 的交接、模型与业务系统依赖，以及失败和恢复路径，便于跨团队共同定义可实施的服务。
哪些服务适合 AI 主导，哪些必须保留人工？
关键取决于任务的规则清晰度、信息可靠性、风险程度、可逆性及用户需要的判断。标准查询可优先考虑受控自动处理；需要复杂情境判断的服务适合 AI 拟办、人员确认；重大承诺或高风险决策应由具备相应权限和能力的人主导。分区并非企业成熟度排名。
一家企业的官网为什么也属于 AI 服务系统的一部分？
官网承担企业能力说明、产品信息组织、证据呈现和咨询承接任务。当客户自己阅读，或通过 AI 代理检索企业资料时，准确、可访问且持续维护的内容能够降低理解成本。但企业官网能被搜索、被引用，不等于 AI 已能获得授权去执行订单、报价或其他业务动作。
怎样评价 AI 服务设计项目是否成功？
应按具体业务记录改造前后的任务完成率、端到端处理时间、用户与员工负担、人工交接质量、结果准确性、总服务成本及风险事件。模型响应速度和自动回复比例只是局部指标；没有基线或可比较的数据时，应如实记录阶段性观察，不直接宣称产生了经营增长。
选择服务设计合作伙伴时，应该重点看什么？
首先确认对方能否围绕真实用户任务解释业务问题，再核查是否具有用户研究、服务蓝图、跨部门协作、数字产品实施和持续验证的相关能力与项目证据。COMMA咖墨在品牌体验、官网与数字产品、会员服务系统及相关项目运营中拥有不同类型的公开实践；具体 AI 项目能力与交付边界应按实际需求单独确认。
服务越智能，
越需要被认真设计
互联网让服务更容易被找到，移动设备让服务随时可以发生，而 AI 为理解需求、组织信息和推动任务提供了新的可能。但技术的能力，不会自动转化为人的良好体验。
企业可以拥有先进的模型，却仍然缺少准确的知识；可以拥有多个 Agent，却仍然存在部门割裂；可以提高自动回复比例，却没有真正缩短客户完成任务的过程。
这些问题最终仍指向服务设计长期面对的命题：企业如何把自己的能力组织起来，让客户在真实情境中获得可靠、有价值的结果。
未来的服务可能减少很多界面和操作，也可能在重要时刻保留更充分的解释、审查与人的参与。应该让多少工作交给 AI，从来不应只由模型能力决定，而需要与业务价值、用户权利、服务风险及组织责任共同判断。
从设计人如何使用服务，进一步走向设计人、AI与组织如何共同完成服务。
COMMA咖墨｜本白皮书的核心研究命题这不是一次脱离历史的专业重启，而是服务设计面对新技术、新组织关系时的继续发展。它要求我们保持对人的理解，也理解机器；重视前台体验，也进入后台系统；关注价值创造，也承担失败时的修复与责任。
主要参考文献与
研究来源
优先链接学术出版方、研究机构和标准制定机构的原始信息。
- [01]Shostack, G. L. (1984). Designing Services That Deliver. Harvard Business Review.hbr.org/1984/01/designing-services-that-deliver ↗
- [02]Bitner, M. J., Ostrom, A. L., & Morgan, F. N. (2008). Service Blueprinting: A Practical Technique for Service Innovation. California Management Review, 50(3), 66–94.doi.org/10.2307/41166446 ↗
- [03]Vargo, S. L., & Lusch, R. F. (2008). Service-dominant logic: Continuing the evolution. Journal of the Academy of Marketing Science, 36, 1–10.doi.org/10.1007/s11747-007-0069-6 ↗
- [04]Vink, J., Koskela-Huotari, K., Tronvoll, B., Edvardsson, B., & Wetter-Edman, K. (2021). Service Ecosystem Design: Propositions, Process Model, and Future Research Agenda. Journal of Service Research, 24(2), 168–186.doi.org/10.1177/1094670520952537 ↗
- [05]Mortati, M., & Viana Mundstock Freitas, G. (2026). AI in Service Design: A New Framework for Hybrid Human–AI Service Encounters. Journal of Service Research, 29(1), 81–96. 2025-06-18 在线首发，2026-02 正式见刊。doi.org/10.1177/10946705251344387 ↗
- [06]Huang, M.-H., & Rust, R. T. (2021). Engaged to a Robot? The Role of AI in Service. Journal of Service Research, 24(1), 30–41.doi.org/10.1177/1094670520902266 ↗
- [07]NIST. (2023; 2024). Artificial Intelligence Risk Management Framework (AI RMF 1.0), and Generative AI Profile. AI RMF 1.0 截至本文校核时仍在修订过程中，应以 NIST 官方页面为准。nist.gov/itl/ai-risk-management-framework ↗
- [08]OECD. (2019; updated 2024). OECD AI Principles. 涵盖人类权利、透明、安全、问责及有关治理原则。oecd.ai/en/ai-principles ↗
- [09]ISO/IEC. (2023). ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. iso.org/standard/81230.html ↗