文字对话和可读的聊天演示图并不是同一种内容。文档可以依赖标题、舞台说明和长段落，聊天界面却会一条一条呈现信息。因此，转换过程需要重新决定背景、身份、节奏以及每个屏幕上能够看到的内容。
这套流程适合产品概念、教程、培训案例、课堂材料、研究原型和明确标注的虚构故事，不适合伪造私人记录。公开发布时应使用虚构身份、删除敏感信息，并在可能引起误解时说明内容为模拟。
建议先确定目的和消息顺序，再打开 Chat Simulator 工作区 进行角色、时间戳、播放和导出设置。
一、确定读者和唯一核心信息
用一句话写清楚谁会看这张图，以及看完后应理解什么。产品经理评审流程需要的细节，与新用户阅读教程完全不同。
删除不能支持核心信息的交流。真实聊天会有寒暄、玩笑和重复确认，但教学素材只需保留必要背景。
二、把台词与制作说明分开
把角色真正说出的消息放在一列，把“这里暂停”“展示附件”“切换移动端”等制作指令放在另一列，避免说明误入对话。
记录每个角色的职责、目标、语气和已知信息，防止角色说出不可能知道的内容，也能让多次修改后的声音保持一致。
三、把长段落拆成消息单元
每条消息通常只承担一个动作、问题、事实或反应。说话目的改变、读者需要停顿或操作步骤切换时，就应拆分。
不要为了热闹而制造几十个过短气泡。属于同一意思的碎片可以合并，并通过朗读发现不自然的断点。
- 需要回答时，每条消息只问一个主要问题。
- 重要限制单独成条，避免被忽略。
- 操作步骤使用简短编号序列。
- 不影响屏幕流程的背景信息放到文章正文。
四、建立清楚但不冒充真人的身份
使用简短名称和容易区分的头像。公开示例应选择虚构姓名、抽象头像、字母头像或原创插画，不复制真实个人的头像、账号、认证标志和组织身份。
机器人、客服、教师和活动组织者都要明确标注职责，让读者知道每句话由谁负责。
五、根据事件逻辑设置时间戳
先确定事件顺序，再填写时间。快速澄清可能只需几十秒，需要阅读、出行或审批的步骤应留出更大间隔。
时间戳用于帮助理解，而不是制造真实感。不要用模拟时间暗示虚构承诺、购买或客服响应真实发生过。
六、先做最少样式的第一版
先输入角色和消息，再处理颜色和装饰。根据发布渠道选择 Web 或 Mobile，并检查脚本能否在目标尺寸自然容纳。
中性第一版最容易暴露结构问题。如果没有配色就无法理解，说明缺失的是背景或顺序，而不是视觉效果。
七、用播放功能做编辑检查
不看原稿播放整段对话，记录哪些回复在问题尚未清楚时出现、哪些角色突然改变语气、哪些信息根本没有展示。
让未参与编写的人看一次并复述情境。对方的复述比“是否好看”更能衡量清晰度。一次只改一个问题，再重新播放。
八、为真实发布环境导出
手机信息流和竖屏教程适合 Mobile，文档和桌面演示适合 Web。小字号和界面细节较多时优先 PNG；使用 JPG 时要检查压缩后的浅色文字和头像边缘。
按最终显示宽度预览文件，检查裁剪、安全边距、对比度、文件大小、替代文字和模拟标签。
九、补充上下文和透明说明
标题、说明文字和文章正文应说明演示图用途。“模拟对话”“虚构示例”“培训场景”和“产品概念”都简短清楚。
不要把虚构交流当作客户评价、私人泄露、付款证明、客服承诺或第三方推荐。透明说明能保护读者，也方便素材长期复用。
常见问题
消息数量没有固定答案。保留完成教学目标所需的最少消息；内容过长时拆成多张图，不要不断缩小文字。
熟悉的界面结构有助于理解，但不必像素级复制某个平台。使用独立视觉、不放官方标志并清楚说明用途更稳妥。AI 可以辅助起草，但发布前仍需人工核对事实、版权、语气、重复度和隐私。
最终制作清单
- 读者和核心信息已经明确。
- 每条消息都服务于内容目的。
- 身份为虚构或已获授权，并容易区分。
- 时间戳符合事件逻辑。
- 播放时没有缺失背景。
- 最终尺寸清晰且具有可访问性。
- 模拟属性已经清楚说明。
