← 返回全部案例

CASE STUDY

2026.01.24–01.30 · 多模态迭代 · 个人项目 · AI 协作

整理于约 5 分钟

角色聊天:发了一张图,AI 怎么把人设忘了?

AI-role-chat 是我较早的全栈练习。2026 年 1 月的目标很直接:让读者创建角色,设置性格与行为约束,再与它连续对话。代码由 AI 编程工具生成和修改,我负责需求、交互与运行检查。

加入图片以后,项目不再只是把一段提示词交给聊天模型。原有复盘记录了角色一致性减弱的问题,提交历史则留下了 1 月 26 日引入两阶段图片处理的修改。

先描述图片,再带着角色设定回复

改进将第一步交给视觉识别,生成不带角色扮演要求的图片描述;第二步把描述作为上下文,再由对话模型结合完整角色设定回答。

这让两段职责可以分别检查:视觉层是否看对,回复层是否拿到了性格、背景和行为约束。聊天服务中也能看到构建系统提示词与调用识别的对应路径。

它同时增加了代价。一次图片消息需要两段处理,前一步的遗漏会传到后一步,图片里的细节也可能在文字描述中丢失。架构改变可以缓解上下文组织问题,当前记录没有给出系统性的角色一致性评测,不能写成已经解决所有偏离。

流式回复需要检查真正的数据路径

项目还尝试 SSE:前端逐块消费响应,让新内容随着服务端返回而出现。对读者来说,等待期间看得到输出更容易理解;对实现来说,需要处理断流、失败和消息保存。

页面上有打字效果,不能直接证明用了真实流。核查时要跟到后端输出与前端读取,而不是只看一段动画。这里也没有经过对照实验的响应速度提升数据。

第一条请求失败,可能发生在模型调用之前

后续启动修复记录了前端先启动、后端尚未就绪导致首次请求失败的问题。脚本改为先等后端健康检查,再启动前端开发服务。

这个修复的对象是本地启动顺序。它不能代替部署后的健康检查,也不能证明当前演示服务仍然可用。本轮没有调用模型或访问旧部署。

本文核对固定版本聊天服务与提交记录。下一轮若继续做,应保留同一组图片与角色,分别检查描述错误、角色偏离和超时,再判断两阶段方案是否值得额外等待。

Role chat: keeping a character across an image message

AI-role-chat was an early full-stack exercise. In January 2026 I wanted readers to create a character, set its personality and constraints, and hold a continuing conversation. AI coding tools wrote the code; I set requirements, interactions, and runtime checks.

Image messages complicated that route. The project notes describe weaker character consistency, and a January 26 commit introduced two-stage image processing.

Give image description and character response separate jobs

The first stage produces an image description without role-playing instructions. The second passes that description to the conversation model alongside the character’s full system prompt.

This makes two checks possible: whether the image was described accurately, and whether the reply received the character’s personality, background, and constraints.

It also creates costs. Image messages require two stages; omissions in the description propagate, and visual details can disappear in the intermediate text. The code establishes the approach, without a systematic evaluation proving that character drift has been eliminated.

Follow streaming beyond the typing effect

The project uses SSE and incremental response reading. New content can appear as the server sends it, but interrupted streams, failures, and persistence still need handling.

A typing animation alone cannot establish genuine streaming. Verification must follow server output and client reads. There is no controlled latency-improvement result in this account.

Check failures before the model call

A later startup fix waited for backend health before opening the frontend development server, addressing failed initial requests while the backend was still starting.

That concerns local startup order. It does not establish current deployment health, and I did not call models or visit the older deployment while writing.

I reviewed the fixed-version chat service and history. Further work should reuse a fixed set of images and characters to distinguish description errors, character drift, and timeouts before accepting the extra processing stage.