软件不再是你找功能，而是功能主动理解你。这不是AI的革命，这是交互设计本应有的样子。

上周在医院门诊大厅，我看到一个特别的“白大褂”——医疗数字人“灵童”。它眨着大眼睛，耐心地为患者家属解答各种问题。家属只需自然地说出需求，灵童就能理解意图，快速给出科室指引、专家排班信息，甚至能调出相关的健康知识卡片。

这不是科幻电影，这是青岛市妇女儿童医院真实的智慧服务场景，由泽瑞集团提供全链路私有化部署的医疗数字人解决方案。

看着家属们自然地与灵童对话，我突然意识到：这才应该是企业软件的交互方式——不是用户去适应复杂的菜单结构，而是系统主动理解用户意图，提供恰到好处的服务。

不是AI要改变什么，而是我们本就该这样工作

最近团队在落地几个Agent项目，和产品、设计、后端一起开会时，大家问得最多的问题是：“Agent到底能做什么不一样的事情？”

我的回答是：它不做“不一样”的事情，而是让事情“以对的方式”发生。
让我用医疗场景举个例子。

传统的医院系统逻辑：家属要知道“去哪里”——导诊台；要记住“怎么问”——科室名称要准确；要明白“流程”——先登记还是先挂号。

数字人的逻辑：家属只需要说“孩子咳嗽三天了，应该看哪个科”。
系统自己会判断：这需要分析症状关键词→匹配对应专科→查看专家排班→提供就诊建议。整个过程在自然对话中完成，用户不需要记住复杂的科室分类，不需要提前学习系统用法，只需要说出需求。

这不就是我们一直想要的“智能化”吗？

界面不是消失了，而是变得更“聪明”

有人担心：Agent会不会让精心设计的页面变得无用？
恰恰相反。好的Agent不是替代界面，而是让界面“活”起来。
第一版的智能柜成功上线让我们备受鼓舞，我们快速迭代了小程序侧进行了上线。在方案预研中，我发现鸿蒙生态天然的适配RICH 设计范式。

鸿蒙的多窗口交互，折叠屏展开态、平板等大屏幕设备，具有多任务并行和效率型任务处理的先天优势。
系统提供了悬浮窗、分屏、画中画三种多窗口交互，为用户在大屏幕设备上的多任务并行、便捷的临时任务处理提供更佳的使用体验。

想象一下这种体验：

1. 家属询问：“半夜小孩发烧到39.5度，需要马上看急诊吗？”
2. 系统理解：这是急症咨询场景，需要调用发热处理流程、急诊等待时间、医生建议
3. 界面响应：左侧显示发热处理指引卡片，中间展示当前急诊等候人数，右侧提供线上咨询快速入口
4. 家属可以：查看详细指引，预约急诊时段。

界面元素依然存在，但它们的出现时机、组合方式、信息呈现都根据用户的紧急程度和具体需求动态决定。

这就是“混合渲染”——不是全盘推倒重来，而是让静态的页面框架，搭载动态的医疗服务卡片和交互组件。

鸿蒙开发者的新角色：从“页面建造者”到“交互架构师”

（图例来自蚂蚁开源项目）

这种变化对鸿蒙开发者意味着什么？
在借鉴吸收了RICH 设计范式后，昨天的我还需要纠结这个按钮的border-radius是6px还是8px，今天的我需要思考的是：这个组件如何向AI描述自己？

在鸿蒙生态中，我们的组件开发范式正在经历深刻的变革。这种变化不仅仅是API设计的不同，更是组件从"被动渲染"到"主动服务"的思维转变。

传统鸿蒙组件开发

// ArkTS中传统的日期选择器组件
@Component
struct DatePickerComponent {
  @State selectedDate: string = '2024-01-01'
  
  build() {
    DatePicker({
      start: '2020-01-01',
      end: '2030-12-31',
      selected: this.selectedDate
    })
    .onChange((value: DatePickerResult) => {
      this.selectedDate = `${value.year}-${value.month}-${value.day}`
      // 这里需要手动触发所有关联组件的更新
      postUpdateEvent('dateChanged', this.selectedDate)
    })
  }
}

使用RICH 设计模式开发鸿蒙组件

1. 语义自描述

@SmartComponent({
  semantic: "用药提醒时间设置器",
  medicalContext: {
    supports: ['medication_schedule', 'dosage_timing'],
    constraints: ['must_align_with_meal', 'no_overlapping_meds']
  }
})

2. 自动能力发现

// 组件自动声明其能力
@Capability({
  name: 'medical_timeline_integration',
  description: '可自动集成到患者病程时间轴',
  api: MedicalTimelineAPI
})

3. 上下文感知

@Component
struct ContextAwareComponent {
  @Prop
  @MedicalContext({
    patientAge: true,
    currentDiagnosis: true,
    medicationList: true
  })
  medicalContext: MedicalContextData
  
  build() {
    // 根据患者年龄自动调整界面
    if (this.medicalContext.patientAge < 12) {
      // 儿童友好的界面
      ChildFriendlyDatePicker()
    } else {
      // 成人标准界面
      StandardDatePicker()
    }
  }
}

4. 工作流自动化

@WorkflowIntegration({
  trigger: 'appointment_scheduled',
  actions: [
    'update_doctor_calendar',
    'generate_patient_reminder',
    'prepare_medical_records'
  ]
})

我们的工作重心，正在从**“如何把页面画好”，转向“如何让系统理解每个组件的用途”**。

设计模式演进：新的问题需要新的解决方案（鸿蒙6新特性应用）

在真实的医疗Agent项目中，我们遇到了很多传统B端设计没遇到过的问题。

问题一：AI“过度自信”怎么办？

家属说“肚子疼”，AI直接建议“立即手术”——显然会造成恐慌。

我们的方案：医疗场景的分级响应机制。

• 高危症状（胸痛、意识丧失）立即转人工+警报
• 中危症状（高烧、持续呕吐）提供紧急处理建议+医生连接
• 低危症状（轻微咳嗽、皮疹）给予家庭护理指导

问题二：用户描述模糊怎么办？

“我不舒服”——这太宽泛了。

我们的方案：结构化问诊引导。

• 第一步：症状分类（疼痛类、发热类、消化类等）
• 第二步：细节追问（“哪个部位疼？持续多久了？”）
• 第三步：提供可视化部位选择器（点击身体图标记疼痛点）

附加价值配合鸿蒙6跨设备感知协同：不只是数据，更是“情境”

  private async fuseDeviceData() {
    // 智能融合来自不同设备的数据
    return {
      // 从手表获取：心率、血氧、体温趋势
      vitalSigns: this.multiDeviceHealthData.watch?.vitalSigns,
      
      // 从手环获取：活动量、睡眠质量
      activity: this.multiDeviceHealthData.band?.dailyActivity,
      
      // 从环境设备获取：室内温度、湿度
      environment: this.multiDeviceHealthData.thermometer?.roomCondition,
      
      // 鸿蒙6特性：意图感知
      // 自动识别用户是在做饭时、运动后还是睡眠中不适
      situationalIntent: await IntentsKit.recognizeSituationalIntent()
    }
  }

问题三：医疗建议需要个性化怎么办？

同样的症状，儿童和老人的处理方式完全不同。

我们的方案：上下文感知+个性化适配。

• 自动识别患者年龄段
• 结合过往病史（如有权限）
• 提供差异化的处理建议
• 明确标注“建议仅供参考，请及时就医”

Intent Kit 意图识别分发+小艺对话，让问题更精准，“肚子疼”变得立体

@Component
struct CrossDeviceSymptomAnalysis {
  // 鸿蒙6：跨设备传感器智能融合
  @CrossDeviceSensorContext({
    // 同时感知手机、手表、环境设备
    devices: ['huawei_watch', 'harmony_band', 'smart_thermometer'],
    // 智能聚合策略：医疗优先
    fusionPolicy: 'medical_emergency',
    // 实时同步，延迟<100ms
    syncMode: 'realtime'
  })
  multiDeviceHealthData: HealthData
  
  async onSymptomReported(symptom: string) {
    // 1. 融合多设备数据进行精准评估
    const context = await this.fuseDeviceData()
    
    // 2. 通过Intent Kit分发给最合适的处理节点
    const intentResult = await IntentsKit.dispatch({
      intent: 'medical_triage',
      params: {
        symptom: symptom,
        context: context,
        // 附加设备感知数据
        crossDeviceData: this.multiDeviceHealthData
      },
      // 分发策略：基于紧急程度
      strategy: this.calculateEmergencyStrategy(context)
    })
    
    return intentResult
  }
}

那些不会变的东西：GUI为什么依然重要

在大家都热衷讨论自然语言交互时，我想泼一点冷水：GUI不会死，也死不了。
原因很简单：有些交互，用图形就是比用语言高效。

试想一下：

• 在设计工具里微调一个元素的间距：拖拽对齐线 vs “把这个元素向左移动2像素，不对，是1.8像素”
• 在表格里筛选数据：点击表头下拉 vs “筛选出状态为进行中、优先级为高、创建时间在最近一周的任务”
• 在地图上规划路径：拖动路径点 vs “把第三个途经点调整到经度X纬度Y的位置”

GUI的优势在于：所见即所得，直接操作，实时反馈。
而Agent的价值在于：处理那些需要思考、推理、跨域协作的复杂任务。

两者的关系不是替代，而是互补。

所以，未来的B端界面要如何设计？

在人工智能领域，意图通常被定义为用户希望达成的目标，如查询天气情况、办理银行业务、预约服务等。这些意图并不总是直接表达出来，而是隐含在用户的言行之中。

我脑海中浮现的画面是这样的：
一个干净的工作台：没有密密麻麻的菜单，只有几个核心数据看板。
一个随时待命的助手：角落里的对话入口，你可以打字，也可以语音。
一组灵活的能力组件：不是固定的页面，而是可以根据任务动态组合的卡片、图表、表单。

当你需要完成一个任务时：

1. 向助手描述你的目标
2. 系统理解意图，组装合适的组件
3. 你在生成的界面上微调、确认
4. 系统记住你的偏好，下次做得更好
   这听起来像是科幻，但其实技术已经基本就位。缺的不是能力，而是我们作为设计者和开发者的想象力。

写在最后

最近在推动Agent项目落地时，我最常说的一句话是：“别只想着技术能做什么，多想想用户应该怎么工作。”

Agent不是炫技的工具，它应该是缩短想法与结果之间距离的桥梁。

作为前端，我们正站在一个奇妙的转折点上。过去我们关心像素、关心动画、关心性能，这些依然重要。但现在，我们更需要关心：

• 如何让组件变得“可被理解”？
• 如何设计“人机协作”的交互流程？
• 如何平衡“自动决策”和“人工控制”？
  这不是AI的胜利，这是交互设计理念的回归——让技术适应人，而不是让人适应技术。

也许很快，我们就能告别那个需要记住“点击这里、跳转那里、配置这个”的时代。取而代之的，是一个你说“我需要…”，系统回答“好的，已经准备好了”的时代。

那一天到来时，今天的我们，正在为它铺路。