企业官网建设流程全解析

AI生活化应用月度总结：从功能堆叠到场景驱动的转型

一、月度数据的反思：功能数量翻倍但用户满意度未同步提升

7月的AI生活化应用开发中，产品功能从月初的5个增长到月底的12个，包括晨间简报、情绪日记、待办分析、菜谱推荐、语音备忘、睡眠记录、周报生成等。但用户满意度数据显示了一条与功能增长不同步的曲线。

NPS（净推荐值）在月初为32分（功能较少但核心体验流畅），到中旬降至24分（功能增多但复杂度上升），月末回升至35分（核心场景梳理完成、辅助功能优化）。这组数据揭示了一个模式：用户对产品的评价不完全取决于"能做多少事"，更取决于"常做的事做得多好"。

更细致的分析显示，12个功能中，前4个功能（晨间简报、情绪日记、待办分析、菜谱推荐）贡献了82%的日活跃交互，而其余8个功能合计仅贡献18%。尤其"周报生成"功能尽管开发投入3天时间，日均使用次数仅为2.3次。这暴露了功能堆叠模式的根本问题——大量开发资源被投入到用户并不高频使用的边缘场景中。

按月维度复盘，最大的收获是认识到"场景驱动"比"功能驱动"更有价值。场景驱动意味着不是逐个实现独立功能，而是围绕用户的真实生活场景（晨间准备、晚间回顾、情绪波动期、饮食决策时）来组织AI能力。同一场景可能联动多个功能——晨间准备场景同时涉及天气查询、日程概览、情绪状态提示和穿搭建议，但用户感知的是一次完整的体验而非4个独立功能。

二、从功能到场景的架构转型：统一上下文共享层

架构转型的关键在于引入统一的上下文共享层。月初的功能驱动模式下，每个功能各自维护一份用户上下文数据：晨间简报拉取天气和日历，情绪日记拉取历史情绪记录，两者互不知晓。月末的场景驱动模式下，一个场景（如晨间准备）同时消费天气、日历和历史情绪数据，都从同一上下文层获取。

共享上下文层包含三个核心组件：用户画像（静态偏好+动态状态）、时间线数据（所有事件按时间排序的统一存储）、情绪连续性追踪（跨场景的情绪标签序列）。场景逻辑层只负责编排和交互设计，不持有任何数据。

重构后，新增一个场景的开发投入从约3天降至约1天——因为上下文数据已就绪，场景只需定义编排逻辑和交互界面。更重要的是，跨场景联动（如晚间回顾自动引用晨间简报中的核心事件）从不可能变为可能。

三、场景编排器的核心实现

""" 场景编排器：将多个原子能力编排为场景化的用户体验 设计意图：场景层不持有数据，只定义编排逻辑和UI流程 从共享上下文层按需获取数据，降低新增场景的开发成本 """ from typing import Protocol, Optional from dataclasses import dataclass from enum import Enum class TimeOfDay(Enum): MORNING = "morning" AFTERNOON = "afternoon" EVENING = "evening" NIGHT = "night" @dataclass class SceneConfig: name: str trigger_time: TimeOfDay required_data: list[str] # 从上下文层需要的数据库列 ai_capabilities: list[str] # 需要的AI能力 ui_template: str # UI模板名称 class ContextLayer(Protocol): """上下文层接口：所有场景通过此接口获取用户数据""" async def get_user_profile(self, user_id: str) -> dict: ... async def get_timeline(self, user_id: str, date: str) -> list: ... async def get_emotion_continuity(self, user_id: str, days: int) -> list: ... class SceneOrchestrator: """场景编排器核心""" SCENES: dict[str, SceneConfig] = { 'morning_prep': SceneConfig( name='晨间准备', trigger_time=TimeOfDay.MORNING, required_data=['weather', 'calendar', 'emotion_7d_summary', 'sleep'], ai_capabilities=['briefing_gen', 'outfit_suggest'], ui_template='morning_briefing', ), 'evening_review': SceneConfig( name='晚间回顾', trigger_time=TimeOfDay.EVENING, required_data=['diary_today', 'todo_completed', 'emotion_today'], ai_capabilities=['summary_gen', 'gratitude_prompt'], ui_template='evening_review', ), 'mood_episode': SceneConfig( name='情绪波动', trigger_time=None, # 事件触发而非时间触发 required_data=['emotion_7d_detail', 'recent_interactions'], ai_capabilities=['safe_response', 'activity_suggest'], ui_template='mood_support', ), } def __init__(self, context_layer: ContextLayer, ai_dispatcher): self.context = context_layer self.ai = ai_dispatcher async def execute_scene(self, scene_id: str, user_id: str) -> dict: """执行场景编排""" scene = self.SCENES.get(scene_id) if not scene: raise ValueError(f'未知场景: {scene_id}') # 从上下文层并行获取所需数据，而非各子功能独立请求 context_data = {} try: profile = await self.context.get_user_profile(user_id) context_data['profile'] = profile # 按需获取数据，仅拉取场景明确需要的字段 if 'weather' in scene.required_data: context_data['weather'] = await self.fetch_weather(user_id) if 'calendar' in scene.required_data: context_data['calendar'] = await self.fetch_calendar(user_id) if 'emotion_7d_summary' in scene.required_data: context_data['emotion'] = await self.context.get_emotion_continuity(user_id, 7) # 对每个AI能力调用统一调度器，避免场景层直接调用API ai_results = {} for capability in scene.ai_capabilities: try: ai_results[capability] = await self.ai.dispatch({ 'featureType': capability, 'userId': user_id, 'context': context_data, }) except Exception as e: print(f'[SceneOrch] AI能力 {capability} 执行失败: {e}') ai_results[capability] = {'fallback': True} return { 'scene_id': scene_id, 'data': context_data, 'ai': ai_results, 'ui_template': scene.ui_template, } except Exception as e: print(f'[SceneOrch] 场景 {scene_id} 执行异常: {e}') # 场景执行失败的降级：返回最小可用数据 return { 'scene_id': scene_id, 'error': '场景暂不可用', 'ui_template': 'fallback', }

场景编排器的核心原则是"场景不持有数据，只编排组合"。通过场景配置（SceneConfig）声明每个场景需要的数据和AI能力，编排器按图索骥从上下文层获取数据、调用AI能力。新增场景只需要一个SceneConfig定义和对应的UI模板，无需触碰数据层和AI层的代码。

四、场景驱动的边界：当场景划分本身成为负担

场景驱动模式在带来架构清晰度的同时，也存在自身边界。最突出的是场景边界模糊——用户的真实生活并不严格按照"晨间""晚间""情绪波动"来分割。下午3点的焦虑情绪属于哪个场景？属于"情绪波动"场景的触发条件但发生在"午后"时段，不属于任何预设场景。

这类边界模糊的交互不能简单归入任一已定义场景，否则体验会显得生硬。解决方案是引入"无场景模式"——当用户输入不匹配任何预设场景时，不强行映射，而是以自由对话模式兜底。但这又引入了场景驱动与通用对话两套并行的交互模式，增加了架构复杂度。

适用判断：当产品有≥3个高频场景且场景间的上下文重叠≥50%时，场景驱动模式收益最大。如果多数交互是自由对话形式，场景划分反而限制了灵活性。

五、总结

7月AI生活化应用开发的核心教训：

1. 功能堆叠≠体验提升：NPS数据显示核心功能贡献82%交互，边缘功能投入产出比低。
2. 场景驱动替代功能驱动：围绕用户真实生活场景组织AI能力，而非逐个开发独立功能。
3. 统一上下文层：用户画像+时间线+情绪连续性的三元结构，支持跨场景数据共享。
4. 场景不持有数据：场景编排器只负责编排逻辑，数据和AI能力由下层提供。
5. 边界模糊处理：不匹配任何场景的交互通过自由对话模式兜底，避免生硬匹配。
6. 开发效率提升：新增场景从3天降至1天，核心原因是上下文数据已就绪、无需重复建设。