文档：送祝福和AI音频

PART1上屏功能UX体验

上屏交互统一存在的

1.手机操作体验现状：可以上屏的功能被划分为多个大图标，与AI写歌等并列问题：每个一屏只能看到两个大图标，无法快速找到想要的功能，或者无法概览所有功能建议：缩小图标大小，或增加完整功能列表

2.交互后反馈现状：用户提交上屏请求后，显示提交成功的提示问题：因为从提交到大屏幕反应有延迟，用户可能会感到困惑，以为卡了，或不知道是否成功建议：手机端增加时刻显示的提示（正在发送到大屏幕）

送祝福体验

1.素材内容现状：素材的规格和生产时代不统一，有GIF转成的视频，有审美老旧的特效，也有新做的全屏内容建议：1.统一素材的规格（技术和内容层面）2.逐步替换老旧内容

2.全屏祝福现状1：激活后，会无提示打断正在播放的歌曲，可能导致唱歌的人尴尬建议1：播放全屏祝福之前给予提示，或将正在播放的音乐淡出后再开始播放

现状2：全屏素材的音量和正在播放的其他内容可能不匹配建议2：对全屏播放的素材音量进行标准化处理

3.用户自定义卡片现状3：UGC祝福卡片无法选择模板，只有一种样式建议3：提供多种样式供用户选择

送祝福的AI UGC内容

可以使用户使用内置的AI功能，生成指定风格的艺术字效果作为祝福海报->参考图技术路径：提示词工程 - 根据几种风格预置系统提示词，接入LLM 提供AI辅助风格生成（帮用户构建更好看的风格）用户输入 -> 违规词审查 -> LLM优化 -> 拼接系统提示词 -> 生图接口 -> 返回图片 -> 用户可以确定发送或重新尝试生成成本 - AI API调用 - LLM中等规格的模型（无思考） - 图片生成 国内代理 Nano Banano 2 （零售API 0.2元/次）

发表情

现状：部分素材过于老旧，从GIF转制视频，音效和动画不同步（音效会先播放完）建议：将音轨和视频轨合并，对于老硬件设备，可以优化播放逻辑

发图片

现状：用户可以上传1～9张图，根据图片数量自动以不同模板进行展示建议：1.提供拼图选项，使多图内容可以在一张图内显示，或让用户可以选择模板，该交互的需求是即时快速的分享内容到公共视野中。2.允许用户上传短视频（30秒以内），视频附带的声音可能会打断屏幕上播放的其他音频，因此长度需要受限（不然就变成投屏了）。

发弹幕

现状：用户发送预设的，或者AI编写的，或者自己编写的文本到大屏幕上建议：弹幕营造的氛围感需要弹幕的数量来支持，因此可以借助AI使用户一次发送多条弹幕，或者一键发送预设的弹幕雨

-----

PART2 热舞秀AI音频生成

->试听

技术实现方法

选定参考音频 -> 剪辑特征部分 -> 变调和增噪处理（绕过suno版权内容检测）-> 可用参考片段 (mp3)获取参考音频的歌词 -> 提示词工程（AI歌词改编专家）-> 新的改编歌词（脱离原歌词，保留歌曲段落结构）(txt)AI分析参考音频乐理风格 -> suno风格提示词将参考片段+新的歌词+风格提示词 输入suno -> 产生新的歌曲（多次生成直到获取理想曲目，或进行逐句编辑 - 高级功能需要会员订阅）

MINIMAX Audio - 开源 - 不支持参考音频，不支持细节控制 - 支持中文 - 音质好

SUNO - 闭源 - 指令遵循好，支持中文 （平均2分钟完成）

UDIO - 闭源 - 无法严格遵循歌词（平均2分钟）

SongBloom - 本地 - 最大 300s（平均8分钟 - RTX4090）- 不支持细节控制

成本预估：

LLM-高级模型-Gemini3Suno4.5或v5（需要订阅）- 8美元/月/500次 & 96美元/年国内中转API调用 - 0.45人民币/次 ×无法确保企业级SLA（非用户侧的无影响）相比人类编曲的成本低

自动化：

多agent流程，自动完成多AI协作输出结果，需要软件工程，或使用低代码平台搭建工作流（比如n8n）人工剪辑也可以被替代 - 自动识别歌曲的副歌部分

产能：

需要根据实际品质需求指标来确定，目前demo的产能是 5首/工作日，外部供应商目前没发现，可以先咨询在网络上提供此类服务的商家

相比人类编曲的劣势：

会存在一些小瑕疵（比如吐字，部分歌词和节奏的匹配问题）音质不如人类编曲（v5模型有改善，但仍不如人类编曲）

讨论（是否满足需求？），（版权问题，AI生成的内容中依然会包含原曲的标志性特征 - 这样才能做到不是一首歌但是听起来一下就想到那首歌）

suno的用户协议 - 订阅用户可以将AI生成的内容用于商业用途

排除使用开源模型 - 目前无法进行精细控制，生成速度慢，对多语言的支持差。