生活化AI助手的产品化复盘从单点功能到可维护系统的关键决策一、从Demo到产品的脆弱拐点单点功能为何撑不起真实生活生活化AI助手在Demo阶段通常呈现单一场景惊艳的特征。一个饮食推荐Prompt在Demo中可以流畅给出建议一个情绪日记生成器在录制视频时表现自然。但当这些功能放入同一产品、面向真实用户连续使用超过一周时单点架构的脆弱性就显现了。以晨间简报功能为例初期实现仅调用一个大模型API、传递当天天气与日历数据即可生成摘要。上线两周后用户反馈简报经常缺内容排查发现当日历API超时或天气API返回异常格式时整个生成流程直接中断而非降级为简短版本。这暴露了单点功能产品化时的核心矛盾——功能逻辑与异常处理耦合在一起每个新功能的异常都会波及整体体验。更普遍的问题是多个AI功能晨间简报、情绪记录、待办分析各自拥有独立的Prompt模板、API调用逻辑和缓存策略。三个功能意味着三套完全独立的AI调用链路维护成本随功能数量线性增长而用户期望的智能联动如简报中提及昨天记录的沮丧情绪却无法实现。二、功能解耦与上下文共享AI能力层的统一抽象产品化的第一步是将AI能力从业务逻辑中解耦。上图中的统一AI调度器承担了所有大模型交互的中转职责接收来自不同功能的请求根据功能类型匹配Prompt模板聚合相关的用户上下文调用模型最后统一格式化输出。核心设计是上下文聚合器。它不直接持有用户数据而是按需从数据层拉取与当前功能相关的信息子集。例如晨间简报只需最近7天情绪摘要而非完整的日记内容待办分析则需要未完成事项列表加上最近的情感倾向标签。这种按需聚合模式避免了将所有用户数据塞入Prompt的膨胀问题同时保证了跨功能的信息联动。实测数据显示引入统一调度层后新增一个AI功能的代码量从约400行降至约120行——主要是定义Prompt模板和输出格式规则。异常处理也不再散落在各功能中而是在调度层统一实现重试和降级策略。三、统一调度器的核心实现关注点分离的生产代码// AI能力调度器统一管理大模型调用的入口、异常处理与降级策略 // 设计意图将AI调用逻辑从业务功能中抽离实现关注点分离 interface AIRequest { featureType: morning_brief | emotion_diary | todo_analysis; userId: string; priority: high | normal | low; metadata?: Recordstring, unknown; } interface AIResponse { content: string; tokens: number; fallbackUsed: boolean; latency: number; } class AIDispatcher { private cache: Mapstring, { data: AIResponse; timestamp: number }; private rateLimiter: Mapstring, number[]; constructor( private promptManager: PromptManager, private contextAggregator: ContextAggregator, private llmClient: LLMClient, private config: { maxRetries: number; cacheTTL: number; rateLimitWindow: number } ) { this.cache new Map(); this.rateLimiter new Map(); } async dispatch(request: AIRequest): PromiseAIResponse { const startTime Date.now(); // 速率限制同一用户1分钟内最多3次AI调用 if (this.checkRateLimit(request.userId)) { return this.buildFallbackResponse(稍后再试当前请求过于频繁); } // 缓存优先相同参数的请求在TTL内直接返回缓存 const cacheKey ${request.featureType}:${request.userId}:${JSON.stringify(request.metadata)}; const cached this.checkCache(cacheKey); if (cached) return { ...cached, fallbackUsed: false, latency: Date.now() - startTime }; try { const prompt await this.promptManager.getTemplate( request.featureType, request.metadata ); // 按需聚合上下文而非全量加载 const context await this.contextAggregator.gather( request.userId, request.featureType ); const response await this.callWithRetry(prompt, context, request.metadata); this.setCache(cacheKey, response); return { ...response, fallbackUsed: false, latency: Date.now() - startTime }; } catch (error) { // 统一异常处理记录错误后返回降级响应 console.error([AIDispatcher] 功能 ${request.featureType} 调用失败:, error); return this.buildFallbackResponse(当前服务繁忙请稍后重试); } } private checkRateLimit(userId: string): boolean { const now Date.now(); const window this.config.rateLimitWindow; const timestamps this.rateLimiter.get(userId) || []; const recent timestamps.filter(t now - t window); this.rateLimiter.set(userId, recent); if (recent.length 3) return true; recent.push(now); return false; } private async callWithRetry( prompt: string, context: ContextData, metadata?: Recordstring, unknown ): PromiseAIResponse { let lastError: Error | null null; for (let attempt 0; attempt this.config.maxRetries; attempt) { try { const result await this.llmClient.complete({ systemPrompt: prompt, userContext: JSON.stringify(context), params: metadata }); return { content: result.text, tokens: result.usage.totalTokens }; } catch (error) { lastError error as Error; // 指数退避每次重试等待时间翻倍 await new Promise(r setTimeout(r, Math.pow(2, attempt) * 1000)); } } throw lastError || new Error(所有重试均失败); } private buildFallbackResponse(message: string): AIResponse { return { content: 抱歉${message}。, tokens: 0, fallbackUsed: true, latency: 0 }; } }调度器将Prompt管理、上下文聚合和LLM调用三大职责分离为独立模块。每个AI功能只需声明自己的featureType和少量元数据调度器自动处理缓存、限流和降级。这种设计使功能开发者无需关注底层AI调用的可靠性细节专注于Prompt质量优化。四、统一调度层的边界与成本并非所有场景都适用统一调度层带来了明显的架构收益但也引入了自身的成本和边界。额外延迟上下文聚合器需要从多个数据源拉取信息。在低延迟场景如对话式实时交互中聚合耗时可能超过用户容忍度。实测中含用户偏好、7天摘要和当天数据的完整聚合约需200~400ms如果LLM调用本身只需1秒这一开销占比不小。Prompt模板耦合不同功能共享同一调度器意味着Prompt模板的格式受到约束。当一个功能需要特殊参数如多轮对话历史时调度器的通用接口可能无法很好适配需要不断扩展接口参数最终破坏抽象层的简洁性。适用边界此架构最适用于功能数量≥5个、功能间需要上下文共享的产品。对于仅有1~2个AI功能的早期项目统一调度层属于过度设计直接在业务逻辑中调用API更为高效。禁用场景实时对话场景延迟敏感、异构模型调用场景不同功能使用完全不同的模型提供商以及每个功能的上下文完全不重叠的场景。五、总结AI生活工具从Demo走向产品的核心挑战在于架构设计而非算法精度。关键决策点包括功能解耦将AI调用逻辑从业务代码中剥离为独立调度层减少功能间的代码重复和异常传播。上下文按需聚合避免全量用户数据注入Prompt根据功能类型选择性聚合相关信息降低Token消耗同时保持跨功能联动。统一异常处理在调度层集中实现重试、缓存和降级策略防止单一功能异常影响全局体验。架构时机判断功能数量3时无需引入调度层功能间无共享上下文时无需聚合器延迟敏感场景需评估聚合开销。演变路径先从功能内联调用开始当维护成本和用户对跨功能联动的需求同时上升时再引入统一调度层进行重构。