最近发现，即使打开新的对话框，Gemini 在回答的时候也会掺杂一些我之前在别的会话中提到过的东西，反问我。我知道Gemini是目前几个知名 AI 辅助工具中上下文支持最长的，但是会话之间继承数据这种方式，我觉得也不太现实。

于是我就随口问了一句“你的对话之间是共享上下文的吗？”没想到他真回答了我。

总结一下大致是这么回事，Gemini系统级别维护了一份 User Summary，这份内容是云端共享的，也就是我无论在哪个终端发起的会话，都会提炼总结聊天内容到User Summary。这种提炼总结的东西，我们姑且称为记忆碎片吧，而User Summary就是这些记忆碎片的集合。当我们打开一个新的会话时，User Summary会作为新会话的上下文，在我们聊天的工程中为大模型提供参考，也就是让大模型知道我们是谁。

这让我突然想到最近爆火的龙虾(openClaw)，跟朋友聊天，说龙虾(openClaw)跟普通 agent 的一个很大区别就是他知道我们是谁，了解我们的喜好。目前看来，这点 Gemini 已经做到了，龙虾(openClaw)要加油挖掘新概念了。

下面是我跟 Gemini 要的我的user summary，大概长这个样子：

以下是我的“大脑”中关于你的核心画像：

### 🛠️ 职业与技术背景

- **核心身份：** 你是一位 **Senior Web Front-End Developer**（资深前端开发工程师）。
    
- **工程偏好：** 追求专业且有数据支撑的 UI/UX 优化，习惯使用 **SUS、HEART、PUEU** 等量化框架来评估设计。
    
- **开发流：** 深度集成 AI 辅助，熟练使用 **Cursor (Agent/Auto 模式)**、Grok 和 Claude Code。
    
- **代码架构观：** 偏好“高内聚低耦合”，比如你提到过的 **Shadow Repository（影子仓库）** 或 Overlay 策略，用于在开发复杂开源项目时保持核心代码与业务逻辑的分离。
    

### 🚀 核心在研项目

- xxx
    
- **设计美学：** 你对这个xxx有着非常明确的审美要求——**“文人感（Literary）”**。你追求像“白纸（White Paper）”一样的极简体验，以及符合亚洲标准的传统脚本格式，极其讨厌干扰性的边框。
    
- **技术深度：** 你在探索用 **知识图谱（Knowledge Graph）** 来处理xxx。
    

### 📝 知识管理与习惯

- **Obsidian 深度用户：** 利用 **Dataview** 和标签系统组织关于 AI 架构（如 Transformer 复杂度）的技术笔记。
    
- **AI 角色化管理：** 你有一套自己的 **AI Role Framework**，会将任务拆解给不同的“AI 助手”（如翻译助手、周报生成助手）。
    

### 🎸 个人生活碎片

- **技能树：** 正在学习吉他，能熟练演奏单音，练过《500 Miles》。
    
- **生活角色：** 是一位细心的观察者，会研究婴儿行为逻辑（科学育儿），并尝试向长辈（Papa）进行科普。
    

从上面的信息看，整理得挺细的，我日常问他的几个方面的东西都有总结到，难怪总感觉 Gemini 很了解我呢。

前段时间千问奶茶免单很火，可以直接在 chat 界面输入“千问，帮我点杯奶茶”，后续就像我们自己操作一样，一步一步完成下单。

我们知道， AI chat 现在比较普遍的数据交互是 markdown，markdown 是渲染不出这种交互式UI 的，必须借助 HTML+CSS+JS 的能力才能做到。那么千问是怎么实现的呢？是交互过程中生成的 UI，前端做渲染吗？我感觉这个选项可以首先排除，具体原因下面会做分析。

一、方案概览

目前实现这种效果的常见方案主要有以下几种：

1. 硬编码规则，根据服务端返回的特定格式的数据结构，映射到封装好的固定 UI。
2. 让 AI 生成 html ，缺点是效果不稳定，需要持续调 prompt，这也是为什么我一开始觉得千问用的应该不是这个方案的原因。
3. 定制一些卡片模板，告诉模型 input schema ，模型按数据结果填进来，缺点是模版还需要人力开发。
4. google/a2ui 这类方案，让 AI Agent 直接驱动或生成用户界面，实现“对话即操作”“自然语言即界面”，与第二点的差异在于，前面 AI 输出的是代码，而这个方案生成的是schema，由引擎去解析，而不是直接渲染。

二、实现简介

首先应该有个输出定制的过程，输出格式可能是这样

// 硬编码规则
{
  "title": "标题",
  "summary": "总结",
  "bullets": ["要点1", "要点2", "要点3"]
}
// AI 生成 HTML
"<section><h3>标题</h3><p>内容</p></section>"
// 定制卡片模板
[
  { "type": "metric", "title": "成本", "value": "低", "desc": "描述" },
  { "type": "step", "title": "步骤", "items": ["A", "B", "C"] }
]
// google/a2ui 类方案
{
  "type": "container",
  "children": [
    { "type": "text", "variant": "title", "content": "A2UI 风格标题" },
    { "type": "text", "content": "这里是可组合 UI schema 示例" },
    { "type": "list", "items": ["项1", "项2", "项3"] }
  ]
}

然后每一种方案的交互模式不一样的，可能是这样：

• 硬编码规则：自然语言 → 模型映射固定字段 → 按结构化内容渲染 UI
• AI 生成 HTML：自然语言 → 模型直接生成 HTML 字符串 → 渲染页面
• 模块化卡片模板：自然语言 → 映射为预定义模板 → 渲染模块卡片
• A2UI（组合式 Schema）：自然语言 → Agent 生成 UI Schema → 引擎解析Schema，动态组件组合 → 渲染 UI

当然上面只是简单的流程，具体实现这里就不赘述了

三、方案对比

下面我通过一个实验 demo 来对比一下这几个方案，对比维度如下：

• 首次可用率（一次返回即可渲染）
• 回退率（需要重试/修复）
• 可控性（是否偏离预期结构）
• 开发成本（前端模板/解释器工作量）
• 迭代成本（改需求时改 prompt 还是改代码）

实验场长下面这样，我会在四种模式下各跑一次剧本生成流程，最终导出实验报告。

压测包含的场景

• 正常输入
• missing-fields（结构缺失）
• wrong-types（类型错误）
• html-unsafe（HTML 注入噪声）
• schema-noise（Schema 噪声）

下面是生成的报告

报告基本跟我的预期一致，不过数据准确性还得靠指标，我的指标计算也不一定对，仅供参考。

这篇文章写了有一段时间了，整理到掘金合集。