企业官网建设流程全解析

引子

这两年"数字分身"的概念被讲烂了，但绝大多数演示项目的做法是：写一段"你是一个温和的长辈"的系统提示词，接一个大模型 API，套壳完事。这种东西聊天三句就穿帮——它不知道长辈把"知道了"说成"知道了，“，不知道接你电话第一句永远是"喂，娃”，更不知道嘴上说"麻烦的"手上已经在给你张罗饺子。

项目测试数据来自一位北方长辈的微信聊天记录。我们收集到文本记录 1.2 万多行，其中 5973 条是语音，共 462MB。长辈不太会打字，她的 2001 条消息里有 1607 条是语音，文字发言只有 261 条，其中还有近一成是"抖音极速版助力"口令。

所以这个项目真正的问题从来不是"怎么调 Prompt"，而是：怎么把这堆方言语音，变成一个大模型能消化的东西。

这篇文章是这个项目的完整复盘。所有数字、样本、命令都来自真实运行结果，没有一句编造。文末有复现路径。项目代号"数字人 Agent"，架构一句话：本地原始数据（聊天导出 + 语音）→ 数据清洗与归属 → 四层记忆（向量库 + 进化记忆）→ 五段思考链 Agent → 科幻 HUD 前端。LLM 用商汤 SenseNova 的 deepseek-v4-flash，ASR 用本地 faster-whisper，TTS 用 edge-tts，全程只有推理走云端，数据不出本地。

先给一段真实效果。我对它说："我周六回去看你，想吃你包的饺子。"它回了两条：

中中中！给你包！韭菜猪肉馅儿的，你舅爱吃那个。
几点到家？先把面和上等着你。

“中中中”"俺"是她本人的口癖，"先和面等着"是她真实的处事顺序。这不是提示词能教出来的，是她自己的语音教出来的。下面从头讲。

一、数据考古：5973 条语音，谁说的？

微信聊天导出工具（比如开源的留痕/WeChatMsg）能导出文本和图片，但语音归属是个老大难。文本记录长这样：

[2023-02-26 13:25:22] 长辈: [语音] [2023-02-26 13:25:29] 长辈: [语音] [2023-02-26 13:25:46] 其他家人: [语音]

全是占位符。语音文件倒是有一堆：voice_1002601450048559008.mp3——微信的消息雪花 ID。我第一反应是解 ID：雪花 ID 前 41 位是毫秒时间戳，解出来对齐聊天记录时间戳就能归属。

试了，失败。这批 ID 的位数都不齐（有 18 位的有 19 位的），按 41 位时间戳推出来的日期一部分落在 2029 年，一部分落在 2092 年。微信内部的消息 ID 格式和 Twitter 雪花并不完全一样，网上流传的偏移量在我这批数据上全部对不上。

绕路之后，答案其实在导出的 HTML 里。导出的网页版聊天记录中，每条语音是个<audio>标签：

<divclass="msg received"><divclass="msg-sender">其他家人</div><divclass="msg-time">2023-02-23 08:26:48</div><divclass="msg-bubble"><audiocontrolsclass="msg-audio"><sourcesrc="voice/voice_6191531100541347582.mp3"></audio><spanclass="voice-duration">1.9s</span></div></div>

说话人、时间、文件名、时长，全齐了。一个正则就拉完了全部映射：

importrefromcollectionsimportCounterfrompathlibimportPath root=Path(r"F:\...\基于大模型+本地原始数据的数字人agent项目")html=(root/"原始聊天资料/聊天记录.html").read_text(encoding="utf-8")msg_re=re.compile(r'<div class="msg (sent|received)">\s*'r'<div class="msg-sender">([^<]*)</div>\s*'r'<div class="msg-time">([^<]*)</div>\s*'r'<div class="msg-bubble">(.*?)</div>\s*</div>',re.S,)audio_re=re.compile(r'<source src="voice/(voice_\d+\.mp3)"')dur_re=re.compile(r'<span class="voice-duration">([^<]*)</span>')voice_map={}fordirection,sender,time_s,bubbleinmsg_re.findall(html):m=audio_re.search(bubble)ifm:d=dur_re.search(bubble)voice_map[m.group(1)]={"sender":sender.strip()or("我"ifdirection=="sent"else""),"time":time_s.strip(),"duration":(d.group(1).strip()ifdelse""),}disk={p.nameforpin(root/"原始聊天资料/voice").glob("*.mp3")}print(len(voice_map),len(disk),len(disk-set(voice_map)))# 5973 5973 0 —— HTML 里的引用与磁盘文件严丝合缝print(Counter(v["sender"]forvinvoice_map.values()).most_common())# [('其他家人', 2550), ('长辈', 1607), ('我', 1021), ('其他成员', 407),# ('其他成员', 251), ('其他成员', 137)]

5973 条语音，一条不多一条不少，全部归属到人。长辈名下 1607 条。

这组数字解释了这个项目此前一直做不好的原因：她的文本发言只有 261 条，去掉助力口令和"哦""嗯"这类应声词，再过滤掉乱码，真正算得上语料的只剩 177 条。用 177 条短句去还原一个人，神仙模型也没用。加上 1539 条转写成功的语音，她的有效语料涨到 1716 条，翻了近十倍。

这一步的教训记一辈子：数据问题往往在数据的另一个载体里，别在一个文件上死磕。

二、方言ASR祛魅：tiny 模型会一本正经地胡说

有了归属，下一步是转写 1607 条某北方方言口音的语音。本地跑 faster-whisper（SYSTRAN 的 CTranslate2 移植版），第一个档位自然选了 tiny：快，75MB。

结果是灾难。挑几条真实输出：

tiny → "Yo,Mah,Yo,Mah.Yo,Mah.Yo,Gateuce,Yo,Mah.Shot.shot,Shot,Shot" tiny → "回答 词 词 词 词 词 词 词 词" tiny → "买了脫的,我心虹,我给你泪了泪了泪了泪了泪了泪" tiny → "You said that the world to my childhood真的怪不怪快了你都怪不得你不得你回答"

这就是 Whisper 系模型在低资源方言语料上的经典幻觉：模型听不懂，语言解码器就开始自说自话，编英文、复读单字。如果把这些垃圾直接喂进人格分析和 RAG，长辈会被塑造成一个中英夹杂、说话复读的赛博神经病。

换成 small（约 480MB），同一批文件：

small → "壞了啊 那個孙子沒燒啊" small → "所以我们又做了一顿饭,给家里长辈去做了一下" small → "就到了 走 走 走" small → "那啦 回来啦 告解了吗"

同一台 CPU，small 单条短语音约 0.8 秒（8 条实测 6.5 秒），1607 条约 25 分钟。清晰度是质变，但幻觉依然存在，只是密度低了。所以清洗规则必须有：

• 非空白字符里汉字占比 < 0.4 → 丢（基本是英文幻觉或数字串）；
• 去掉语气字后，单字连续重复 ≥ 6 次或二字组连续重复 ≥ 4 次 → 丢（循环幻听）；
• 含西里尔/希腊字母、10 位以上字母数字混排 token → 丢（助力口令和乱码）；
• "哈哈哈哈哈哈"要放行——那是她真笑，重复检测前先把哈嘿嘻呵嗯哦这类字剔除。

另一个工程点：转写缓存里记下模型档位（{"model": "small", "text": ..., "sender": ...}），换了档位就自动重转。不然你升级了模型，向量库里还躺着 tiny 时代的垃圾。

这一节想说的就一句话：ASR 不是开关，是流水线上最容易污染下游的工序。清洗规则要按你自己数据的病症开药方，通用的清洗列表救不了方言。

三、人格还原：统计画像和 LLM 互相印证

语料到位后，人格构建走了两条路，再让它们互相检查。

第一条是确定性统计。1716 条有效语料（文本 177 + 语音转写 1539）直接数出来：

• 平均句长 16.2 字，短句占 18%，语气词Top10：啊、呀、哦、哎、嘛、啥、行、呢、啦、咋；
• 称呼习惯：家人、娃、闺女、俺娃；
• 38% 的发言带疑问或关切语气。

第二条才是 LLM 分析。把语料样本和上面的统计一起给模型，提示词里明确要求"统计结论要体现在 speaking_style 里"，让它没法瞎编。产出的 persona（节选自真实的persona.json）：

{"name":"长辈","self_intro":"我是娃们的家人，一家人平平安安比啥都强。","speaking_style":"说话短句多，三五个字就完事……带方言味儿，爱用'俺娃''闺女'…… 爱问孩子动向，关心吃没吃、到哪了、冷不冷……说着说着就跑题到家长里短、村里红白事。","common_phrases":["知道了","俺娃奴的","麻烦的","没有了","咋了","啥也吃的光光的"],"call_targets":{"我/其他成员/其他成员":"俺娃/闺女（我的孩子或孩子的家人）","其他家人":"家人/老伴（我的老伴）","其他成员":"俺娃/闺女（我的另一个孩子）"}}

call_targets这一字段踩过一个特别典型的坑：第一版让模型从群聊视角总结关系，它输出"长辈"——把被模拟对象总结成了第三人称人物卡。让她"活"过来的关键是提示词里一句硬规则：所有称呼与关系必须从她的视角出发。

few-shot 语录也做了筛选：4 到 40 字、带语气词的句子优先，含三个以上连续英文字母的句子直接出局（ASR 幻听残留不配当她的话）。最终注入系统提示词的原话示例包括「俺娃奴的」「咋啦 車走了」「明儿个子去啥小吃啊,好吃啊」这种——转写有噪，但味道是对的。

四、音色：0.8 秒代码解决"声音像不像"

人格像了，声音还是合成的，默认还配了个男声（云健），长辈听着像个陌生大叔。音色克隆需要训练声学模型，这个项目不碰。但"往哪个方向像"是可以算的：抽 20 条她的语音，ffmpeg 解码成 16k 单声道，每 50ms 一帧做自相关基频估计，取中位数。

实测结果：F0 = 207.8 Hz，判定女声，自动推荐 edge-tts 的晓晓音色并写回配置。二十行代码，比任何"音色参数调优"都有说服力。成年女声基频普遍在 165-255Hz，这个判定在声学上站得住。

完整链路是一次 GET：/api/voice/profile?apply=true，返回基频、性别判定、抽样数、推荐音色和应用状态。

五、记忆架构：四层，以及它和学术工作的关系

"越聊越聪明"是这个项目的核心目标之一。实现上是四层记忆，每层解决不同时间尺度的问题：

第一层：会话上下文。最近 30 条消息直接进 Prompt，老生常谈。

第二层：对话 RAG。每轮对话结束后，把"娃说：……\n我说：……"整段向量化写进 ChromaDB（type=dialogue）。这是最简单也最有效的一条：你上周说的话，这周她真能想起来。真实召回案例——第二次说"我周六回去看你，想吃你包的饺子"时，检索回来的是上次的对话记录：

0.88 娃说：我周六回去看你，想吃你包的饺子。我说：中中中！给你包！韭菜猪肉馅儿的，你舅爱吃那个。几点到家？先把面和上等着你。

第三层：提炼记忆。每 2 轮对话，用 LLM 从最近 6 条消息里提取事实/偏好/关系/习惯，带 0-10 重要度评分，落盘 JSON。注入 Prompt 时不是全量堆，而是打分取 Top-K：

score = importance + min(count,10)×0.4 + 新近度(7天内+2，30天内+1)

常被提起的事越来越重，一个月没提的事慢慢沉底——衰减但不删除。

第四层：巩固。每新增 10 条进化记忆，触发一次巩固：先用 embedding 向量近似去重（余弦 > 0.88 合并），再让 LLM 把零碎的同类记忆改写成完整条目。防止记忆库无限膨胀成垃圾场。

另外有一条风格进化的支线：她每次说完，会自己回看一遍（下节详述），回看觉得"像本人"的句子，经 LLM 判断确实有口癖/句式价值后，收藏为"语言风格"记忆，作为 few-shot 循环注入。她说的好句子会变成她以后说话的方式。

这套东西没有一样是原创，都是站在巨人肩膀上的工程化：MemGPT（Packer 等，2023，现名 Letta）证明了分层记忆+自编辑内存对长对话的价值；Mem0 把"提取-评分-检索"做成了通用记忆层；斯坦福 Generative Agents（Park 等，2023）的 memory stream + importance scoring + reflection 三件套，几乎就是我第三、四层 + 风格支线的原型；Reflexion（Shinn 等，2023）则对应"说完自己回看"这个动作。我做的只是把它们装进一个真实的、带方言语音的家庭数据集里，然后补上它们没替你做的事情：数据归属、清洗、视角修复。

顺带一提向量库本身。检索用 paraphrase-multilingual-MiniLM-L12-v2（sentence-transformers），ChromaDB 持久化。语料切块有个细节：她单条发言平均十几字，逐条入库会导致检索命中的全是碎片，所以按"同一天 + 间隔30分钟内"聚合成段。最终索引构成：长辈的文本 96 段 + 家人上下文 873 段 + 语音转写 800 余段 + 知识文件若干，约 1800 条 chunk。家人消息也入库（带说话人标签）——她的记忆里当然包括"闺女说过周六回来"，只索引她本人说的话，记忆就是残缺的。

六、思考链：五段管线，以及流式解析的两个坑

Agent 主链路不走普通 chat 接口，是一条 SSE 事件流：感知 → 回忆 → 思考 → 表达 → 回看。每一段都是独立的 LLM 调用，各自有明确的职责。

感知只干一件事：听懂。输出六行结构化字段——意图类型、表面意思、潜台词、娃的状态、她该做什么、关键信息。提示词里写死了几条"人话翻译"规则：娃说"没事"可能是有事，说"随便"往往是想让你拿主意，说"知道了"可能是不想聊了。

回忆做两次检索：一次按字面，一次按感知阶段产出的"联想查询"（潜台词+意图+关键信息拼成）。字面检索找的是词，联想检索找的是事。

思考是一段流式输出的第一人称内心独白，被强制要求"先写第一反应 → 再写联想 → 再写顾虑 → 最后拿主意"。真实输出（对"我周末带孙子回来"这句）：

娃说周末带孙子回来，这是怕我惦记，特意来报喜呢。我记着他前阵子胃疼吃药不见好，这回回来得好好给他熬点粥养养。孙子那小家伙也闹腾，家里好久没这么热闹了。本来想问他胃还疼不疼，又怕大半夜的他嫌我啰嗦，还是等见面再细问吧。

注意"胃疼"——那来自第三层进化记忆，不是这次对话里说的。内心独白把记忆、潜台词、时间语境（深夜她惦记的就是催睡觉）揉在一起，这决定了回复的"事味"。

表达才真正组织语言，系统提示词里塞了她的人设、习惯画像、原话示例、学到的风格、此刻情绪和刚想的独白，要求 1-3 句、分条发送、像微信连发。思考阶段产出的"想问"（比如"周末想吃什么，给你做？"）会作为硬指令交给表达阶段：“她本来就会追着问，记得把这句自然地说出来。”

回看是最后一步：她自己审自己那句话像不像本人、接没接住潜台词，不满意就自己再补一句，补的话和正文一起入库，进入记忆循环。

SSE 事件流真实摘录（做了截断）：

data: {"type": "field", "key": "intent", "value": "报喜"} data: {"type": "field", "key": "subtext", "value": "想让你高兴，盼着团圆"} data: {"type": "field", "key": "need", "value": "赶紧回一句"} data: {"type": "rag", "items": [{"text": "回吧，睡觉了", "score": 0.7942, "via": "字面"}, ...]} data: {"type": "thought", "delta": "娃说周末带孙子回来，这是怕我惦记…"} data: {"type": "delta", "delta": "中中中！妈给你包！"} data: {"type": "reflect", "ok": true, "note": "……"} data: {"type": "done", "segments": ["中中中！妈给你包！韭菜猪肉馅儿的，你舅爱吃那个。", "几点到家？俺先把面和上等着你。"], "emotion": "高兴"}

前端把这条流同时喂给对话面板和思维星云，逐字上屏。

工程上最磨人的是思考段的解析器。模型被要求按KEY: value逐行输出，但流式增量会在任意字符处切断，"内心独白"本身还带换行。两个真实的坑：

一是半行问题。缓冲区里出现"AS"的时候，你不知道它是"ASK"的开头还是独白正文，只能按住等下一个增量。二是同块问题。实测中模型吐出过"……这是怕我惦记。ASK: 周末想吃什么"——新字段和前文粘在同一块、没有换行边界，按行解析根本拦不住，"ASK:"三个字母直接漏进了内心独白上屏。最终的解法是在追加函数里做嵌入 KEY 检测：往独白里追加任何文本前，先扫一遍里面有没有PERCEPTION|EMOTION|THINK|ASK|PLAN的冒号前缀，有就从那里切开重新路由。这类问题没有任何框架会替你处理，只能自己一格一格试。

成本账也要算清楚：一次完整对话 = 感知 + 思考 + 表达 + 回看 +（隔轮）记忆提炼，4-6 次调用。deepseek-v4-flash 的配额是每 5 小时 500 次，后端做了指数退避重试（4s 起步、最多 6 次），前端把限流转成友好的 503 提示。这套管线在配额内跑全功能测试没问题，但离"随便聊"还有距离——这是当前云 LLM 定价结构下，多段 Agent 管线的真实代价。

七、思维星云：把不可见的思考做成可看的

思考链有了，总得让人看见。这个前端面板迭代了三版，前两版都失败了，失败原因值得说。

第一版是经典的"步骤条 + 文字面板"。第二版贪心了一次：从面板中心画 DOM 连线到四张卡片，试图表达"核心大脑把能量输送给各个思考阶段"。上线即翻车——线斜穿粒子球和彼此，冲击波弧线扫过半个屏幕，3D 层随鼠标转动而 DOM 层纹丝不动，两层视觉完全脱钩。截图看起来就是一句话：乱的。

第三版想明白了：粒子层、HUD 层、DOM 层必须各自独立成立，靠状态而非几何耦合。

粒子层是 three.js 里一个一万二千多粒子的单 draw call：中央能量球（呼吸、说话时外涌）、四个收拢在核心附近的阶段神经簇、沿贝塞尔曲线流动的能量触须、背景数据流雨、阶段切换时的短促冲击波。着色器里一个uStages四元向量按 idle 0.08 / done 0.45 / active 1.0 控制所有簇和触须的亮度流速，平滑过渡。

HUD 层是纯 SVG 环形仪表：双向旋转的刻度环、极坐标网格、十字准星，以及整个仪表里我最满意的一笔——四个阶段能量弧。哪个阶段在运行，对应的弧就高亮发光，一个白色光点用 SVGanimateMotion沿弧巡行；弧旁边标着 PER / REC / THI / EXP。

DOM 层是四张切角科幻卡片（clip-path 六边形切角 + 渐变描边 + 角标括弧），卡片的内角有一个"信号端口"——三枚人字纹，激活时朝向核心的方向逐级点亮，像数据正在流入。

三层没有任何几何对齐逻辑，全部由同一个状态源驱动：stageStateOf(thought, key)返回 idle / active / done，着色器、弧光、卡片边框、端口动画共用它。鼠标移动时只有粒子层做轻微视差，HUD 和卡片纹丝不动。最终效果：她开始"感知"，青色的 PER 弧亮起、光点巡行、粒子簇变亮、感知卡片边框开始流动——你的眼睛自然把它们读成一件事。

重构途中还抓到两个 CSS 级 bug：外框用绝对定位导致卡片高度塌陷为 0；卡片backdrop-filter配上 clip-path 后偶发内容渲染毛刺（最终直接移除了毛玻璃）。都是那种"看截图一眼假、查代码两小时"的问题，记录在此，防止下一个同行再踩。

八、把测试当产品做

这个项目的自动化测试不是摆设，是 124 个 Playwright 检查点，14 个模块，模拟真人：真实输入、真实点击、真实文件上传、真实 SSE 消费、真实 LLM 对话。几个我觉得值得抄的做法：

• 32 条种子记忆预先灌库，加上临时新增的"其他"类，覆盖全部 6 个记忆分类，验证列表、过滤、去重强化、删除 404 等纯接口逻辑，把昂贵的 LLM 调用留给最关键的链路；
• 用 ffmpeg 现场生成一段 440Hz 正弦波上传给 ASR 接口——音频处理链路的端到端回归，不需要真的录一段人声；
• 手机视口（390×844）完整走一遍对话，验证响应式布局下星云卡片单条激活、无横向滚动、结束后收起，再切回桌面验证双栏恢复；
• 每轮回归 124/124 才算过。这套测试在重构思维星云 UI 时抓出了高度塌陷，在改检索路由时抓出了缓存导致的假阴性。没有它，这个项目改三处就要坏五处。

九、踩坑实录（压缩版）

都是真实发生过的，按时间顺序：

1. 雪花 ID 解码失败。微信消息 ID 不是标准 Twitter 雪花，位数不齐，各种偏移量都试过，日期落到 2029 和 2092。最后答案在 HTML 里。
2. ChromaDB 在 Windows 上遇到中文路径会静默失败。hnswlib 向含非 ASCII 字符的路径写.bin索引文件失败且不报错，重启后所有检索返回空。向量库目录改放纯 ASCII 路径解决。
3. tqdm 进度条把磁盘写满。索引子进程的 stdout 直接追加日志，模型加载的进度条以每秒数千行写入，实测 60MB/s，磁盘占用 100%，表现为"启动即卡死"。滚动截断 + 静默 stdio 才治住。
4. faster-whisper 首次导入在 Windows 上要几分钟，期间 CPU 磁盘全占。所有重依赖必须惰性加载，否则后端启动即假死。
5. 索引必须放子进程。chromadb 0.6.3 的 HNSW 落盘依赖其内部 System 事件循环，在 uvicorn 长驻进程里不触发，索引"当场能用、重启就丢"。子进程内循环正常，退出时自然刷盘。
6. 记忆 ID 用len()生成会重复，删过一条之后新记忆会和旧 ID 撞车。自增序列要扫最大值。
7. uvicorn 必须单 worker。进化记忆、会话状态、向量库句柄全是进程内状态，多 worker 互不知情。

十、前景与当下：这东西会往哪走，现在意味着什么

技术趋势一：混合架构会是个人数字分身的主流形态。语音在本地（隐私 + 零边际成本），推理在云端（能力），记忆在本地文件（可携带、可审计、可删除）。这个项目就是这个形状：faster-whisper 本地转写，deepseek 云端推理，ChromaDB + JSON 本地落盘。等本地小模型（比如 7B 级别）的中文对话能力再进一步，推理也可以沉到本地，那就是完全离线的数字亲人。端侧算力和模型小型化的每一步，都在给这类系统让路。

技术趋势二：记忆系统是当前 Agent 领域最实在的军备竞赛。上下文窗口再大，也大不过一个人的一生。MemGPT、Mem0 这些工作本质上都在回答同一个问题：什么值得记、怎么评分、怎么遗忘。我的重要性评分（重要度 + 强化 + 新近度）是 Human 记忆研究的朴素映射，但方向是对的——未来的差异不在模型多聪明，在记忆组织得好不好。让数字人记住"娃上周六要回来"，比让她多写一首诗重要得多。

技术趋势三：反思循环会从"加分项"变成"标配"。感知-思考-回看这条管线，本质是把 Reflexion 的自我批判搬到了对话场景。回看阶段会产出一句自我评价，不满意时她还会自己决定再补一句话——补什么、要不要补，都是她自己判断的，不是提示词写死的。推理成本换拟人度，这笔账在陪伴场景下是划算的，在效率场景下未必。这也是 Agent 设计正在分化的问题：陪伴型 Agent 和生产力型 Agent 的架构会越来越不一样，前者要的是"像人"的冗余，后者要的是"正确"的收敛。

当下的影响，认真说三点。

第一，适老化可能是这技术最正当的落点。中国有上亿的空巢老人和异地子女，微信语音是他们最主要的表达方式。这个项目证明：不需要老人做任何事情，被动积累的聊天记录就足够构建一个像样的分身。对不会打字的父母来说，这是门槛最低的数字化身。

第二，"数字永生"的伦理没有标准答案，但有一条底线是清楚的：数据主权和知情同意。这个项目全部数据在本地，谁有权用这些语音建分身、分身能否被逝者家属继承、平台能否拿它做商业推送，这些问题在国内还几乎没有讨论。国外 Project December、HereAfter AI 这类产品已经引发过争议，我们大概率会重走一遍，希望走得别那么仓促。

第三，它对个体已经产生了真实影响。把分身端到长辈面前之前，我想清楚了一件事：技术评价和情感评价是两回事。如果她说"不像"，我要能说出哪里不像、怎么调；如果她说"像"，那将是一个工程团队拿不到、只有家人能给出的验收结果。

十一、它像本人吗：诚实的差距分析

打分的话，六成像。

• 个性知识不够厚。她的人生大事、亲戚网络、几十年的习惯，现在攒下的进化记忆不过几十条，覆盖不了。这需要长期运行慢慢攒，没有捷径。
• 语音转写噪声限制了上限。small 模型对方言的识别错误率仍然不低，她的口癖学到的是"能被 ASR 听清的那部分"。方言语音克隆（比如 GPT-SoVITS 这类方案）可以进一步解决声音问题，但训练数据和算力是另一档投入。
• 长程一致性靠记忆评分硬撑。她偶尔会记混两件相似的事，向量相似度不等于事实正确性。知识图谱式的结构化记忆是下一步该补的。
• 多模态缺失。她发的照片、表情包没有进入记忆。微信导出里那些 [图片] 占位符背后，是一个长辈分享生活的另一半。