01 / 业务垂类
多垂类
不同垂类具有不同的业务语言、经营指标与常见任务。
餐饮 · 酒旅 · 休闲娱乐
Volcengine · Product Design Test
数据技能市场设计
数据能力的发现与使用体验。
01 / CONTEXT
产品与设计背景
Product
智能数据助手
面向生活服务业务的智能数据助手，支持通过自然语言查数据、问口径和做分析。
使用端
Web 端 · 飞书端
Design scope
设计模块
技能市场
汇集数据处理技能，帮助用户找到并调用适合当前业务任务的模块。
目标用户
生活服务业务 BD · 运营 · 产品经理（非数据岗位）
面向多类垂直行业商家，需要借助数据理解经营表现并推进业务。
02 / USER INSIGHT
用户洞察
从业务环境与非数据岗位用户的信息需求，识别技能市场的设计机会。
02.1 / BUSINESS CONTEXT
业务环境有什么特点？
从业务垂类、经营节奏与当前任务三个维度，理解用户使用技能的业务环境。
→
02 / 经营节奏
强节点
节点前、中、后的工作重点变化，相关技能也随阶段迁移。
日常 · 节点前 · 节点中 · 节点后
→
03 / 当前工作
强任务导向
用户从正在完成的业务任务出发，而不是从技术能力名称出发。
看表现 · 查异动 · 做复盘
设计洞察
技能的组织与排序业务垂类 × 业务节点 × 当前任务，共同决定此刻什么技能更相关。
基于公开活动资料与业务场景形成的设计假设，后续需通过访谈或使用数据验证。
02.2 / USER CHARACTERISTIC
非数据岗位用户如何选择技能？
用户需要看到哪些信息，才能理解并开始使用一个技能？
01 / TASK
能完成什么？
用具体业务任务说明技能的用途。
查询经营表现 · 排查异动 · 生成复盘
02 / INPUT
需要提供什么？
明确完成调用所需的业务信息。
业务对象 · 时间范围 · 指标维度
03 / OUTPUT
会得到什么？
提前呈现结果形式和可交付内容。
数据结果 · 趋势图表 · 判断与报告
04 / EXAMPLE
可以怎么开始？
用接近真实工作的示例帮助首次调用。
“查看这个商家近 30 天的交易表现”
设计洞察
技能的信息呈现技能信息应以非数据岗位熟悉的业务语言呈现，围绕适用任务、所需输入、预期结果与使用示例组织。
基于目标用户属性与产品定位形成的设计假设，后续需通过访谈或使用数据验证。
03 / CURRENT EXPERIENCE
现状分析
从技能的组织方式与现有功能两个层面，理解当前技能市场。
03.1 / CAPABILITY ORGANIZATION
当前技能市场如何组织和分发技能？
基于题目截图，梳理技能的发现方式、供给结构与应用范围。
01 / 发现方式
按业务方向与消费场景快速筛选
02 / 供给结构
官方技能集与专业技能
页面将技能供给区分为两个区域：官方提供的技能集合，以及面向具体任务的专业技能。
03 / 应用范围
前往多个 Agent 应用
技能支持前往多个 Agent 应用。
现状推断
01 / 发现方式
市场以业务语境组织技能，帮助用户从任务场景缩小选择范围。
02 / 供给结构
技能同时存在官方能力集合与专业单项能力，覆盖不同的能力粒度。
03 / 应用范围
技能是可被多个 Agent 使用的独立能力，市场承担跨应用分发作用。
03.2 / PROBLEMS & DIRECTIONS
用户想的是“这件事怎么做”，技能市场展示的是“这里有哪些技能”
将核心问题与对应的设计方向放在同一层展开。
01
搜索驱动，与任务驱动不匹配
现状
用户主动进入市场，通过搜索、筛选和浏览寻找技能。
需求
用户在工作中遇到具体问题时，希望快速匹配并调用合适的技能。
设计方向 / 流程介入
允许用户在工作流程中随时唤起技能市场，并携带当前对话上下文完成匹配与调用。
02
固定组织，难以匹配动态需求
现状
当前市场主要依赖固定分类，以及用户主动搜索和筛选。
需求
生活服务业务跨垂类、强节点；同一用户在不同任务与业务阶段，需要的技能也会变化。
设计方向 / 动态匹配
在活动节点等特殊阶段，根据用户当前负责的业务、正在处理的任务，以及过往同类节点使用过的技能，动态调整推荐与排序。
03
能力描述，难以支持用户决策
现状
官方技能集、专业技能等概念偏向系统语言，能力说明也难以直接回答使用差异。
需求
用户更关心任务结果、所需输入、使用示例，以及真实案例与同类岗位经验。
设计方向 / 信息重构
用非数据岗位能够理解的任务语言，优先呈现结果、输入、场景和真实使用经验。
04 / DESIGN GOAL
让用户在任务中快速匹配技能，也能通过浏览和输入主动探索更多能力。
适用于数据助手对话内匹配、其他平台携带任务上下文进入，以及完整技能市场中的浏览与需求输入。
05 / DESIGN PROPOSITION
01
从当前任务出发，匹配合适的技能
承接来自数据助手对话或其他平台的任务上下文，减少任务中断与重复描述。
理想任务流程
入口 A数据助手对话内
当前对话→唤起技能→自动继承对话上下文
入口 B其他平台
当前任务→进入技能市场→携带任务上下文
共同流程
匹配技能
理解→试用 / 调用→继续任务
05.1 / ENTRY A · ASSISTANT
数据助手对话内，如何发起技能匹配？
在不离开当前对话的前提下，探索主动触发、系统建议与精确指定三种匹配方式。
✓ 选定方案 / 主动触发
对话输入区的技能快捷入口
复用现有的 @、技能或闪电入口。用户主动发起后，系统读取当前对话，并展示匹配的技能。
优点
复用现有入口，容易形成习惯，用户控制感强。
缺点
依赖用户主动触发，可能被部分用户忽略。
注意
需要明确区分“匹配技能”和“调用技能”的入口含义。
方案 02 / 系统建议
在对话过程中智能匹配相关技能
数据助手理解当前任务后，在匹配置信度较高时轻量呈现相关技能，并说明匹配原因。
优点
无需用户先了解技能，可在任务发生时帮助发现能力。
缺点
错误或频繁的建议容易打断任务、降低用户信任，持续理解上下文也会增加技术成本。
方案 03 / 精确指定
针对单条消息查找相关技能
用户从消息操作中选择“查找相关技能”，系统以该消息为核心，并补充必要的对话上下文。
优点
用户可精确指定任务，上下文范围最可控。
缺点
入口相对隐蔽，单条消息也可能缺少完整任务背景。
用户：有没有适合复盘本周活动转化的技能？数据助手：为当前任务匹配到 3 个相关技能……
◐ 部分采用 / 自然语言询问
直接在对话中询问适合当前任务的技能
用户像描述普通任务一样提出需求，数据助手继承当前对话，并在回复中展示相关技能。
优点
交互自然，无需学习新的入口，且能充分利用现有对话上下文。
隐蔽
用户未必知道可以这样提问，能力的可发现性较低。
依赖
匹配质量受用户表达影响，模糊提问可能产生不稳定结果。
受限
纯对话回复的信息密度有限，不利于浏览、比较多个技能。
采用
保留自然语言表达需求，并将后续匹配与比较承接到侧栏分支。
05.2 / SELECTED DIRECTION
以主动触发为统一入口，在对话中完成任务匹配
用户决定何时开始寻找技能；系统继承当前对话，帮助明确任务并缩短匹配路径。
01
主动发起
用户从对话输入区打开技能入口，避免系统在任务过程中主动插入建议。
02
确认当前任务
任务明确时直接进入匹配；识别到多个任务时，系统列出任务摘要，由用户选择或修改。
设计原则：由用户决定何时寻找技能，系统负责理解当前任务并降低匹配成本。
05.3 / ENTRY B
BONUS
从其他平台携带任务，进入技能市场完成匹配
跨平台只传递完成匹配所需的任务摘要，让用户延续当前工作，而无需重新描述需求。
01
当前任务
用户正在其他 Agent 平台推进工作。
02
发起技能匹配
从平台内的技能入口进入技能市场。
03
携带任务摘要
传递任务目标与必要条件，并允许用户确认或修改。
04
展示匹配结果
技能市场基于任务摘要返回相关技能。
未接入上下文能力的平台，可降级为在技能市场中输入或粘贴任务目标。