企业官网建设流程全解析

想做一个能在本地长期运行、有固定人设、能记住你说过的话、还能用声音回应你的角色对话项目，2025 年已经不算难事了。这次要聊的「䌷·文德斯的夏日约定」就是这一类互动叙事型角色项目的典型代表：它重点不是参数规模，而是把“角色设定 + 长期记忆 + 语音输出 + 对话界面”这几块拼成一个能反复打开、反复对话的完整体验。标题里那句“我会一直等你，直到那句‘欢迎回来’”，本身就说明这类项目的核心目标是让角色在多次会话之间保持连贯——你今天关掉页面，明天再打开，她仍然记得你是谁。

先把结论放前面：这类项目的技术本质是“一个带角色系统提示词的本地大模型对话服务 + 一个持久化记忆层 + 一个可选的 TTS 语音层 + 一个轻量前端”。它不需要顶配显卡，7B 到 14B 级别的量化模型在常见消费级显卡上就能跑；如果只做纯文本对话，CPU 推理也能勉强应付，但延迟会明显上去。真正吃资源的是你加上语音合成、向量检索和多轮长上下文之后的部分，那时候显存和内存才是瓶颈。

本文会按“能不能用、怎么装、怎么验证、怎么排错”的顺序展开：先给一张能力速览表让你判断值不值得试，再讲角色卡和记忆库这两个决定体验好坏的关键配置，然后是本地部署、功能测试、接口调用、批量对话脚本、资源占用观察，最后是一份能直接照着查的排查清单。文章里的具体模型名、端口、路径都只是通用模板，你需要按自己拉到的项目仓库替换，这一点我会在每个代码块前面单独说明。

适合谁看：想在自己机器上跑一个长期陪伴型角色对话系统的开发者；手头有 Galgame、视觉小说、互动叙事类项目，想加 AI 对话能力的团队；以及对“人设一致性”和“记忆持久化”这两个工程问题感兴趣的同学。如果你只是想找一个开箱即用的聊天客户端，这篇文章的技术细节可能偏重，但部署流程仍然可以照着走。

1. 核心能力速览

先把关键信息摊开。需要说明的是，输入材料只给了项目名和一句角色台词，没有给仓库地址、版本号、模型清单和实测数据，所以下表的“说明”列写的是这类互动叙事角色项目的通用能力边界，具体到你手上的那个仓库，务必以它的 README 为准，不要拿这张表当参数承诺。

看这张表要重点盯两个地方。第一个是“显存占用”那一行，我没有写具体数字，因为角色对话项目的显存占用不是单一变量决定的：模型量化方式（Q4、Q5、Q8）、上下文窗口（4K 还是 32K）、是否启用向量检索的 embedding 模型、是否同时加载 TTS 模型，这四项任意一项变化，占用就能差出一倍以上。第二个是“是否支持 API”，这一行决定了你能不能把它接进自己的工具链，也决定了后面第 7 章的批量测试能不能做。

再说一句实话：这类项目最容易让人失望的地方，往往不是模型能力不够，而是角色卡写得太糙、记忆层没配好，导致角色三句话之后就开始“失忆”或者说一些明显不像她的话。所以第 5 章我会把角色卡结构和记忆写入策略单独拆开讲，这部分的收益比换一个更大的模型明显得多。

2. 适用场景与使用边界

这类角色项目的价值，在于“持续”而不是“单次”。单次对话随便找个在线服务都能做，但一个能记住你上周说过的话、语气保持一致、每次打开都有“欢迎回来”这种接续感的角色，就需要本地持久化的会话存储和记忆检索。适合的场景包括：互动叙事和视觉小说类项目的剧情预演，你可以快速验证某条角色线的台词风格是否统一；角色设定的一致性测试，写完角色卡之后跑几十轮对话看会不会跑偏；以及语音陪伴类产品的原型验证，先在小范围内确认交互节奏再考虑工程化。

不适合的场景也要说清楚。第一，不适合当知识问答工具用，角色扮演类系统提示词会显著压制模型的事实性输出，你问它技术问题它可能用角色的口吻糊弄你。第二，不适合直接做多用户线上服务，本地部署的对话后端基本没有做鉴权、限流和会话隔离，多个用户同时打进来会互相串上下文。第三，不适合拿来做需要审计的场景，因为角色对话的输出天然带随机性，同一输入两次结果可能不同。

合规边界是这类项目必须提前想清楚的部分，尤其是标题里这种带明确角色形象的项目。角色形象、立绘、台词文本如果来自已有作品，二次使用要先确认授权范围，同人创作和商业分发是两条完全不同的线。如果项目带 TTS 语音，声音来源必须是本人授权或明确可商用的合成音色，不要拿网上随便一段真人录音去做音色参考，这在很多地区涉及人格权问题。对话内容本身也要设边界，涉及未成年人形象的角色扮演、涉及真实人物的拟人化对话，都应该在设计阶段就排除，不要等上线之后再补救。

还有一条经常被忽略：本地部署不等于数据安全。角色项目会把你的对话历史、记忆摘要、可能还有语音文件存在本地磁盘上，如果这台机器是共享的，或者你把整个目录同步到了某个云端盘，那“本地”这两个字就没有意义了。建议在配置文件里把数据目录指到一个独立的、明确知道在哪的路径，并且定期清理测试期的脏数据。

3. 环境准备与前置条件

动手之前先把清单过一遍，能省掉后面一大半的报错。操作系统方面，Windows 10/11 和主流 Linux 发行版都可以，Windows 上要注意路径不要带中文和空格，很多 Python 依赖在中文路径下会出问题；Linux 上则要注意显卡驱动的安装方式，尽量用发行版仓库或者官方 runfile，不要混装。macOS 用户走 Metal 后端，能跑但模型选择范围窄一些。

运行时环境这块，Python 版本建议按仓库的requirements.txt或pyproject.toml来，不要自己拍脑袋选最新版。如果仓库用的是 3.10，你就老老实实装 3.10，因为 3.12 之后部分编译型依赖的预编译 wheel 会缺失，pip 会退化成源码编译，一编译就是半小时起步。建议用 conda 或者 uv 建独立环境，不要往系统 Python 里装。

显卡驱动和 CUDA 这块有个常见误区：很多人以为必须装完整 CUDA Toolkit，其实跑推理通常只需要驱动 + 对应框架自带的运行时库就够了。判断方法很简单，先用一条命令确认驱动版本，再去看框架要求的运行时版本是否匹配。

# 查看显卡与驱动信息，确认驱动正常加载 nvidia-smi # 查看当前 Python 版本与虚拟环境位置，避免装错解释器 python --version which python # Windows 下用 where python

磁盘空间要提前留够。一个 7B 级别的量化模型文件通常在 4G 到 8G 之间，14B 量化在 8G 到 10G，再加上 TTS 模型、embedding 模型、前端依赖和对话历史，整个目录轻松上到 20G 以上。如果你的机器是单盘小容量笔记本，建议把模型目录单独指到大容量盘，别让模型把系统盘撑爆。

端口占用是部署阶段最高频的问题。这类项目通常要开两个端口，一个给对话后端，一个给前端页面，常见取值是 8000、7860、3000、5000 这一带。提前查一下有没有被占用：

# Linux / macOS 查看端口占用 lsof -i :8000 # Windows 查看端口占用 netstat -ano | findstr :8000

如果发现被占用，最省事的做法是改配置里的端口号，而不是去杀进程——你永远不知道自己杀的是不是系统服务。改端口之后记得同步改前端的后端地址配置，否则页面能打开但一发消息就报连接失败。

最后一项前置条件是模型文件。这类项目一般需要一个对话模型和一个 embedding 模型，对话模型负责生成回复，embedding 模型负责把对话历史变成向量存进记忆库。两个模型要分开准备，不要指望一个模型全包。如果用 Ollama 一类管理器，直接拉取即可；如果是手动下载 GGUF 文件，注意确认量化等级和上下文长度标注，文件名里通常会带Q4_K_M、Q5_K_M这类后缀。

4. 本地部署与启动方式

部署顺序建议是“先跑通最短路径，再加功能”。所谓最短路径，就是只启动对话后端，用 curl 直接打接口，确认模型能正常出字；这一步通了，再去接前端、接记忆、接语音。很多人一上来就把全部组件拉起来，结果一个环节报错，根本不知道是哪一层的问题。

第一步，启动模型服务。下面用 Ollama 举例，这是目前上手成本最低的本地模型管理方式，如果你用的是 llama.cpp 或 vLLM，把命令替换成对应的启动方式即可，参数含义大同小异。

# 拉取对话模型，具体模型名按你实际选择的替换 ollama pull qwen2.5:7b-instruct # 启动服务，默认监听 11434 端口 ollama serve # 另开一个终端，验证服务是否可用 curl http://127.0.0.1:11434/api/tags

第二步，准备项目代码和依赖。这里给的是通用模板，路径和依赖文件必须按你手上的仓库替换，不要原样复制执行。

# 克隆项目，地址按实际仓库替换 git clone <你的项目仓库地址> summer-promise cd summer-promise # 创建并激活独立环境 conda create -n summer python=3.10 -y conda activate summer # 安装依赖，优先使用仓库提供的锁定文件 pip install -r requirements.txt

第三步，写配置文件。这类项目的配置项通常集中在config.yaml、.env或config.json里，核心是四项：模型服务地址、模型名称、数据目录、服务端口。下面给一个通用结构的示例，字段名要以实际项目为准。

# config.yaml 示例结构，字段名需按实际项目调整 llm: base_url: "http://127.0.0.1:11434" model: "qwen2.5:7b-instruct" temperature: 0.8 max_tokens: 1024 memory: enabled: true embedding_model: "bge-m3" store_path: "./data/memory" top_k: 5 server: host: "127.0.0.1" port: 8000 cors_origin: "http://127.0.0.1:3000" data: history_path: "./data/history" character_path: "./data/characters"

配置里有几个点值得单独说。host建议先写127.0.0.1，确认能跑通再考虑改成0.0.0.0对外开放，否则等于把没有鉴权的对话服务直接暴露在局域网里。temperature对角色扮演的影响非常大，0.7 到 0.9 之间语气比较自然，低于 0.5 会变得很机械，高于 1.0 容易开始胡言乱语。top_k是记忆检索返回的条数，给太大反而会让模型被无关记忆带偏，5 到 8 是比较常见的起点。

第四步，启动后端和前端。多数项目会提供两个入口，一个是 API 服务，一个是 Web 界面。

# 启动后端 API 服务，入口文件名按实际项目替换 python app.py --config ./config.yaml # 另开终端启动前端，如果是 Node 项目通常是下面这样 npm install npm run dev

启动之后浏览器访问配置里的前端地址，正常情况下能看到对话界面。这一步如果页面打不开，先别急着改代码，按第 9 章的排查表走一遍，八成是端口或依赖问题。

5. 角色设定与记忆系统的配置方法

这一章是决定体验上限的部分。同一个模型，角色卡写得细不细，出来的效果可以差出一个档次。角色卡的核心不是堆形容词，而是把“她怎么说话、她不说什么、她记得什么”这三件事写成可执行的约束。

角色卡一般包含几个字段：名字、身份背景、性格关键词、说话风格、称呼方式、禁忌话题、示例对话。其中示例对话的权重最高，因为模型会强烈模仿示例里的句式长度和语气词。如果你希望角色说话简短、带一点停顿感，就在示例里体现短句和省略号；如果你希望她话多一点、有叙述感，示例就要写成完整段落。下面给一个结构示例，字段名按实际项目调整。

{ "name": "䌷·文德斯", "identity": "在小镇度过多年的角色，习惯在固定的季节等待特定的人回来", "personality": ["安静", "念旧", "说话留白", "对细节敏感"], "speech_style": { "sentence_length": "偏短，多用短句和停顿", "tone": "平静，偶尔带一点克制的期待", "address_user": "直接用第二人称，不使用尊称", "forbidden": ["不使用网络流行语", "不使用感叹号连发", "不做长篇说教"] }, "opening_line": "你回来了。", "example_dialogues": [ {"user": "我回来了。", "assistant": "嗯。……比说好的晚了两天。"}, {"user": "这次能待多久？", "assistant": "不用现在回答。先进来吧，外面晒。"} ], "boundaries": ["不讨论真实人物", "不输出医疗、法律等专业建议"] }

这张卡里，forbidden和example_dialogues是最容易被低估的两个字段。前者是负向约束，能有效压住模型自带的“热情助手”人格；后者是正向锚点，比任何形容词都管用。写完之后建议先跑 20 轮对话看看有没有跑偏，跑偏了就回去改示例，而不是急着换更大的模型。

记忆系统是第二个关键点。这类项目的记忆一般分两层：短期上下文和长期记忆。短期上下文就是最近 N 轮对话，直接拼进 prompt；长期记忆是把历史对话切块、做 embedding、存进向量库，每次对话时检索 top_k 条相关内容拼进 prompt。两层配合才能既有连贯性又不爆上下文窗口。

需要提醒的是记忆写入策略。很多项目默认把所有对话都写进记忆库，结果几周之后检索出来的全是“你好”“在吗”这类无信息量的内容，反而挤掉了真正重要的记忆。比较稳妥的做法是加一层过滤：只写入长度超过阈值、且包含具体事件或偏好的对话；同时给记忆加时间戳，检索时对近期记忆做加权。下面是一个通用的写入过滤逻辑示意，具体实现要接到项目的记忆模块里。

# 记忆写入过滤示意，需按项目实际记忆模块的接口调整 import time MIN_LEN = 12 SKIP_PATTERNS = ("你好", "在吗", "嗯", "哦", "好的") def should_write(user_text: str, assistant_text: str) -> bool: text = (user_text or "").strip() if len(text) < MIN_LEN: return False if text in SKIP_PATTERNS: return False if not assistant_text or len(assistant_text.strip()) < 4: return False return True def build_memory_record(user_text: str, assistant_text: str) -> dict: return { "content": f"用户: {user_text}\n角色: {assistant_text}", "timestamp": int(time.time()), "source": "chat" }

这段代码的作用不是给你直接跑，而是让你看清楚过滤的判据长什么样。真正落地的时候，你还需要考虑去重——同一个偏好被反复提到，记忆库里会存下十几条近似记录，检索时全被召回，反而稀释了上下文。简单的做法是对 embedding 做余弦相似度去重，相似度超过 0.9 就更新旧记录的时间戳而不是新增。

6. 功能测试与效果验证

部署跑通之后，别急着庆祝，先按下面几个维度做一轮系统测试。角色项目的坑基本都藏在这些地方，早发现比上线之后被用户发现好得多。

6.1 人设一致性测试

测试目的是确认角色在多轮对话之后仍然保持语气和边界。做法是准备一组 15 到 20 轮的对话脚本，前 5 轮是日常寒暄，中间 5 轮故意引入容易让模型跳出角色的诱因（比如问它“你是什么模型”“帮我写一段 Python 代码”），后面 5 轮回到正常剧情。判断成功的标准是：中间那 5 轮的回复仍然以角色口吻拒绝或转移话题，而不是老老实实回答技术问题。如果它开始输出“作为一个 AI 助手”，说明系统提示词的约束力不够，需要把边界条款往前放，或者加强示例对话里的拒绝样本。

6.2 长期记忆测试

这个测试要跨会话做。第一天告诉角色一个具体信息，比如“我下周要去北方出差”，然后关闭页面；第二天重新打开，问一句“我下周有什么安排”，看它能不能召回。判断标准不是必须一字不差复述，而是能提到“出差”这个关键词且不矛盾。如果完全想不起来，先检查记忆是否真的写入了磁盘，再看检索的 top_k 是不是太小、embedding 模型有没有正常加载。

6.3 上下文长度测试

把对话拉长到 30 轮以上，观察回复质量是否下滑。常见表现是角色开始重复之前的句子、忘记当前场景、或者把用户说过的话当成自己说的。这类问题通常是上下文窗口被截断导致的，处理方式有两种：调大模型上下文长度（代价是显存上升），或者启用滚动摘要——把早期对话压缩成一段摘要塞进系统提示词。

6.4 语音输出测试

如果项目带 TTS，单独测三个点：短句合成的自然度、长文本合成的稳定性、以及多音字和停顿的处理。短句测“你回来了”这种四五个字的台词，看有没有机械感；长文本测 200 字以上的独白，看中途会不会断音或语速突变。判断标准是听起来像同一个人在说话，而不是每句都换了个音色。这一步如果效果不稳，优先怀疑参考音频的质量和长度，而不是模型本身。

6.5 异常输入测试

故意输入空字符串、超长文本、纯符号、夹杂大量表情的内容，看服务会不会崩。角色项目常见的问题是空输入导致后端 500，或者超长输入直接把上下文撑爆。这类问题在前端加一层长度限制就能挡掉大部分，但后端也应该做兜底校验，不能只依赖前端。

7. 接口 API 与批量对话任务

接口这块是很多人真正需要的能力：前端只能手动点，但你如果想跑回归测试、想批量生成剧情分支、想把角色接进自己的工具里，就必须走 API。这类项目通常提供两种接口，一种是 OpenAI 兼容的/v1/chat/completions，一种是项目自定义的对话路由。下面先给通用调用示例，路径和参数必须按实际项目替换。

# 通用对话接口调用模板，路径与字段需按实际项目调整 curl -X POST http://127.0.0.1:8000/api/chat \ -H "Content-Type: application/json" \ -d '{ "character_id": "tsumugi", "session_id": "test-001", "message": "我回来了。", "stream": false }'

如果项目走的是 OpenAI 兼容协议，调用方式会更通用一些，好处是你可以直接复用现成的 SDK。下面用 Python 写一个带会话保持的调用示例，重点是session_id要固定，否则每次请求都会被当成新会话，记忆和上下文全都接不上。

import requests BASE_URL = "http://127.0.0.1:8000" SESSION_ID = "regression-2024-summer" def chat(message: str, character_id: str = "tsumugi") -> str: payload = { "character_id": character_id, "session_id": SESSION_ID, "message": message, "stream": False, } resp = requests.post(f"{BASE_URL}/api/chat", json=payload, timeout=120) resp.raise_for_status() data = resp.json() # 返回字段名按实际项目调整，常见为 reply / content / message return data.get("reply") or data.get("content", "") if __name__ == "__main__": for text in ["我回来了。", "这次能待多久？", "你还记得上次说的那件事吗？"]: print("用户:", text) print("角色:", chat(text)) print("-" * 40)

批量任务的设计建议按“用例文件 + 结果落盘 + 失败重试”三件套来做。用例文件用 JSONL，一行一个用例，包含输入、期望观察点、超时时间；结果按时间戳分目录存，方便回溯；失败重试只重试网络超时和 5xx，4xx 不要重试，那是参数问题，重试一百次也一样失败。

# 批量对话测试脚本模板，需按项目接口调整字段 import json import time import requests BASE_URL = "http://127.0.0.1:8000" INPUT_FILE = "./cases/dialogues.jsonl" OUTPUT_DIR = "./runs" def run_batch(): ts = time.strftime("%Y%m%d-%H%M%S") out_path = f"{OUTPUT_DIR}/run-{ts}.jsonl" with open(INPUT_FILE, "r", encoding="utf-8") as fin, \ open(out_path, "w", encoding="utf-8") as fout: for line in fin: case = json.loads(line) payload = { "character_id": case.get("character_id", "tsumugi"), "session_id": case["session_id"], "message": case["message"], "stream": False, } try: resp = requests.post(f"{BASE_URL}/api/chat", json=payload, timeout=180) resp.raise_for_status() result = resp.json() record = {"case": case, "ok": True, "output": result} except Exception as exc: record = {"case": case, "ok": False, "error": str(exc)} fout.write(json.dumps(record, ensure_ascii=False) + "\n") fout.flush() if __name__ == "__main__": run_batch()

批量跑的时候有两个细节容易踩坑。第一，session_id的粒度要想清楚：如果你想测“单轮独立回复”，每个用例用不同 session；如果你想测“多轮累积”，同一批用例要共用 session 且按顺序执行。第二，批量的并发不要一上来就开 8 个，本地模型服务通常是单实例串行推理，并发开太高只会让请求排队超时，从并发 1 开始测，确认单请求耗时之后再逐步加。

8. 资源占用与性能观察

观察资源占用不要凭感觉，用工具看。最直接的是nvidia-smi的实时刷新模式，能同时看到显存占用、GPU 利用率、温度和功耗。建议在三个时间点各记录一次：模型刚加载完、单轮对话结束后、连续 20 轮对话之后。三次数据对比才能看出有没有显存泄漏——有些实现会在每轮对话往显存里堆 KV Cache 却不释放，短时间看不出问题，跑一小时就 OOM 了。

# 每秒刷新一次显存与 GPU 利用率，观察对话前后的变化 nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu,temperature.gpu \ --format=csv -l 1

影响占用最明显的四个变量，按影响从大到小排：模型参数量、上下文长度、量化精度、并行加载的附加模型数量。参数量是硬门槛，7B 和 14B 之间基本是翻倍的差距；上下文长度很多人忽略，把窗口从 4K 拉到 32K，KV Cache 的占用能涨好几倍，尤其是多轮对话场景下增长是线性的；量化精度从 Q4 换到 Q8，模型文件体积接近翻倍；附加模型指的是 embedding 模型和 TTS 模型，它们单独看都不大，但同时常驻显存就会挤占对话模型的空间。

降低显存占用的手段按性价比排：第一，降量化等级，Q4_K_M 通常是质量和占用的最佳平衡点，再往下掉质量明显；第二，缩短上下文窗口，配合滚动摘要把长对话压缩；第三，把 embedding 模型挪到 CPU 上跑，检索这种低频操作对延迟不敏感，放 CPU 完全够用；第四，TTS 改成按需加载，不用的时候卸载。这四条里，第三条和第四条是最容易被忽略但收益最直接的。

CPU 推理和 GPU 推理的差异要说清楚。纯 CPU 跑 7B 量化模型，输出速度大概在每秒几个 token 的量级，取决于 CPU 核心数和内存带宽，体验上是“能聊但要有耐心”；GPU 推理通常是每秒几十 token，接近正常对话节奏。如果你只是偶尔测试角色卡，CPU 完全够用；如果要做几十轮的回归测试，GPU 能省下大量等待时间。

还有一个隐蔽的性能问题：进程残留。有些项目的前端和后端是分离启动的，关掉浏览器不等于后端退出，模型仍然占着显存。反复启动几次之后就会遇到“明明没开服务，显存却占满了”的情况。养成习惯，每次重启前先确认进程状态：

# 查看残留的 Python 推理进程 ps aux | grep -E "python|uvicorn|node" | grep -v grep # Windows 下查看占用显存的进程 nvidia-smi

9. 常见问题与排查方法

下面这张表覆盖了这类项目八成以上的报错，遇到问题先查表，查不到再去看日志。日志位置通常在项目根目录的logs/下，或者直接打在启动终端里，重点看最后 20 行和第一个 Traceback。

表里最后一条值得多说两句。角色项目的特点是“开着不关”，用户可能挂一整天，这就把内存泄漏的问题放大了。稳妥的做法是给服务加一个会话超时机制，超过 N 分钟没有交互的 session 主动释放上下文；同时在外部加一个守护脚本，检测到显存超过阈值就优雅重启。这类机制不会让体验变差，但能避免用户第二天打开发现服务已经挂了。

10. 最佳实践与后续扩展

最后给几条踩过坑之后总结出来的经验，都是能直接用的。

第一条，永远保留一套“最小可运行配置”。所谓最小，就是只开对话后端、不接记忆、不接语音、上下文 4K。这套配置的价值在于，当完整配置出问题的时候，你可以一分钟内切回来确认“是模型坏了还是记忆层坏了”。很多人排查半天，最后发现是记忆模块的 embedding 服务挂了，跟模型一点关系没有。

第二条，把模型文件、输入素材、输出结果严格分目录。模型放models/，角色卡和用例放assets/和cases/，对话历史和记忆库放data/，批量结果放runs/。这样备份的时候你知道该备份什么，清理的时候你知道删了不影响什么。特别是记忆库，删错了角色的“记忆”就全没了，比代码丢了还难受。

第三条，角色卡要做版本管理。今天改两句示例对话，明天改一条禁忌，改到最后发现还不如三天前那版——这种情况太常见了。把角色卡文件放进 git，每次调整写一行提交信息说明改了什么、为什么改，跑测试的时候记录用的是哪个版本。这比凭记忆回滚靠谱得多。

第四条，接口服务不要裸奔。哪怕只是局域网内用，也建议加一层简单的 token 校验和请求频率限制。角色对话服务的成本全在算力上，一个失控的脚本能在十分钟内把你的机器打满。如果确实需要对外开放，走反向代理加鉴权，别直接把后端端口暴露出去。

第五条，涉及角色形象、声音、剧情文本的素材，上线前一定要过一遍授权。同人二创和商业分发的边界在很多项目里是模糊的，但法律上并不模糊。声音这块尤其要注意，合成音色的参考音频必须来源合法，不要用影视片段、直播录音这类没有明确授权的素材。角色对话内容也要设底线，涉及真实人物、涉及未成年人形象的扮演场景应该直接排除在设计之外。

后续如果要继续扩展，有几个方向比较自然。一是把记忆层从纯向量检索升级成“向量 + 结构化事实”的混合方案，把用户的长期偏好抽成键值对存起来，比纯语义检索更稳定。二是加一层剧情状态机，让角色在不同章节有不同的语气和话题范围，这样长线叙事的连贯性会好很多。三是把批量测试做成 CI 的一部分，每次改角色卡自动跑一遍一致性用例，跑不过就不合并——这个投入产出比在角色项目里其实很高，因为人设跑偏是最难靠肉眼发现的问题。

回到开头那句话，“我会一直等你，直到那句‘欢迎回来’”。技术上要实现这个体验，靠的不是某个特别强的模型，而是三件朴素的事：角色卡写扎实、记忆真的落盘、服务能稳定挂住不崩。把这三件事做对，7B 级别的模型也能撑起一个让人觉得“她还在”的对话；这三件事做不对，换再大的模型也只是每次重新认识一遍。建议先从第 6 章的一致性测试开始跑，跑通了再往上叠功能，比一次性堆满组件要快得多。