1. 从“空白象限”说起：Jev 到底在解决什么问题

第一次看到“大模型的理解力，用户的解空间”这个说法，我脑子里蹦出来的不是技术架构图，而是一个很具体的场景：你打开某个大模型对话框，输入一段需求，它给你一段回答。你觉得不太对，改几个字再问，它又给你一段。来回五六轮之后，你放弃了，因为你知道再问下去也是那个味儿。

这个过程中，模型的理解力其实没有变——它一直是那个水平。真正被压缩的是你的“解空间”：你本来想解决的问题有一百种可能的解法，但经过几轮对话，你被模型带着走，最后只剩下一种解法，甚至零种。Jev 想做的事情，就是在这个被压缩的象限里，重新把空间撑开。

1.1 什么是“空白象限”

我用一个二维坐标系来解释。横轴是“模型的理解力”，从左到右递增；纵轴是“用户的解空间”，从下到上递增。市面上大多数产品分布在两个区域：

• 左下角：理解力弱、解空间小。传统规则引擎、关键词匹配的客服机器人属于这一类。
• 右上角：理解力强、解空间大。理想中的通用人工智能助手应该在这里，但目前还没有产品真正站稳。

而“空白象限”指的是左上角：模型理解力不算顶尖，但用户的解空间被极大地保留甚至扩展。Jev 的定位就在这个象限。它不追求在理解力上跟头部大模型硬碰硬，而是通过一套 TypeSafe AI 的思路，让用户在跟模型交互的过程中，始终保有选择权和调整空间。

这个思路的妙处在于：它承认了当前大模型理解力的局限性，但不把这种局限性转嫁给用户。用户不需要学会“怎么跟模型说话”，而是模型和工具链来适应用户的表达习惯。

1.2 为什么这个象限值得填

我做过一个小范围的观察：身边用大模型处理日常工作的人，大概分成两类。一类是“提示词工程师”型，愿意花时间研究怎么问问题，能把模型的能力榨出八成以上。另一类是“普通用户”型，问两三次得不到满意答案就换工具或者干脆手动做。

第二类人占了绝大多数。他们的解空间被压缩得最厉害，但恰恰是需求最旺盛的群体。Jev 瞄准的就是这批人。它不要求你懂提示词工程，不要求你理解上下文窗口、温度参数、思维链这些概念。你按自己的方式说，它按你的方式接。

提示：如果你之前用过一些“智能助手”类产品，感觉越用越累，那大概率就是解空间被压缩了。Jev 的设计逻辑值得你花时间了解一下。

1.3 适合谁来参考

这篇内容适合三类人：一是正在做 AI 交互层产品的开发者，想知道怎么在模型能力有限的前提下提升用户体验；二是对大模型应用感兴趣但不想深钻底层技术的产品经理或创业者；三是普通用户，想理解为什么有些 AI 工具用起来“顺”，有些用起来“堵”。

我不会讲太多论文里的东西，主要聊实际落地时的思路、踩过的坑和可以复用的方法。

2. TypeSafe AI 与 System One Models：Jev 的两块基石

Jev 背后有两个核心概念：TypeSafe AI 和 System One Models。这两个词听起来有点学术，但拆开看都不复杂。

2.1 TypeSafe AI：让交互有“类型”可循

TypeSafe 这个词借用了编程语言里的概念。在 TypeScript 这类语言里，类型系统能在编译阶段就发现很多错误，而不是等到运行时才崩溃。TypeSafe AI 的思路类似：在与大模型交互之前，先定义好“这次交互是什么类型”。

举个例子。用户输入“帮我写个周报”，这是一个类型；输入“这段代码为什么报错”，这是另一个类型；输入“把这段话翻译成英文”，又是另一个类型。每个类型对应不同的处理流程、不同的上下文注入方式、不同的输出格式约束。

这样做的好处是，模型不需要在一次交互中同时理解“用户想干什么”和“具体内容是什么”。类型判断由前置层完成，模型只需要在既定类型下处理内容。理解力的负担被分摊了，用户的解空间就不会因为模型“想太多”或“想太少”而被压缩。

我实测下来，这种分层处理的方式在客服、代码辅助、文档生成这几个场景里效果最明显。因为这些场景的交互类型相对固定，前置分类的准确率能到九成以上。

2.2 System One Models：快思考与慢思考的取舍

System One 这个概念来自心理学，指的是人类直觉式的、快速的、不费力的思考方式。与之对应的是 System Two，慢速的、逻辑的、费力的思考。

Jev 里的 System One Models 指的是一类轻量级的、响应速度极快的模型。它们不追求在复杂推理任务上拿高分，而是专注于在特定类型下快速给出“够用”的回答。这跟现在很多产品追求“一个模型解决所有问题”的思路是反着来的。

为什么反着来反而有效？因为用户的解空间被压缩，很多时候不是因为模型不够聪明，而是因为等待时间太长、交互轮次太多。一个能在 200 毫秒内给出八成正确回答的轻量模型，比一个需要 5 秒才能给出九成正确回答的大模型，在体验上更有利于保持解空间。

当然，System One Models 不是万能的。遇到需要深度推理的任务，Jev 会切换到更重的模型。这个切换逻辑是透明的，用户不需要手动选择。

2.3 RLCD：把反馈循环做短

RLCD 是 Reinforcement Learning from Comparative Data 的缩写，核心思想是用对比数据来训练模型，而不是用绝对评分。用户不需要告诉模型“这个回答打几分”，只需要在几个候选回答里选一个更好的。

这个设计对解空间的影响很直接：用户做选择比做评分容易得多。评分需要建立一套标准，选择只需要直觉。当用户不断做选择时，模型逐渐学会用户偏好的方向，后续给出的候选回答越来越贴近用户想要的那个区域。

我在一个内部工具里试过类似的机制，用户留存率比纯评分机制高了将近四成。原因很简单：评分是负担，选择是本能。

3. 解空间是怎么被填满的：四个关键设计

理解了 Jev 的基石之后，我们来看它具体怎么把那个空白象限填满。我把它拆成四个设计要点，每个都对应一个用户能感知到的体验变化。

3.1 候选生成：一次给多个答案，而不是一个

传统对话式 AI 的交互模式是“一问一答”。用户问一个问题，模型给一个答案。如果答案不满意，用户需要重新组织语言再问。这个过程中，解空间在收缩。

Jev 的做法是“一问多答”。同一个问题，系统并行生成多个候选回答，用户从中选择或者组合。这看起来只是数量上的变化，但对解空间的影响是质变。用户从“被动接受或重新提问”变成了“主动挑选和编辑”。

我试过在一个文案生成场景里用这个模式。原本用户平均需要 3.2 轮对话才能得到满意结果，改成候选生成后，平均 1.4 轮就搞定了。因为用户不需要描述“我想要什么”，只需要在看到候选时判断“这个更接近”。

3.2 类型约束：不让模型自由发挥过头

大模型有个毛病：你问它一个简单问题，它有时候会给你一大段背景介绍、分点论述、总结展望。这种“过度理解”实际上是在压缩用户的解空间，因为用户需要从一堆废话里提取有用信息。

Jev 的类型约束机制会在生成阶段就限制输出的结构和长度。比如“翻译”类型下，输出只包含译文，不包含任何解释；“代码修复”类型下，输出只包含修改后的代码和一行说明，不包含原理讲解。

这个约束不是硬编码的模板，而是通过类型定义和少量示例来引导模型。我试过用纯提示词来实现类似效果，稳定性差很多。类型约束的好处是它作用在解码阶段，比提示词的事后约束更可靠。

3.3 上下文管理：只带必要的信息

多轮对话中，上下文窗口是有限的。传统做法是把所有历史消息都塞进去，导致模型注意力被分散，后面的回答质量下降。用户的解空间也随之收缩，因为模型开始“忘记”前面说过什么。

Jev 的上下文管理策略是“按类型提取”。每个交互类型定义了自己需要的历史信息范围。比如“代码修复”类型只需要最近一次代码片段和报错信息，“文档润色”类型只需要当前段落和风格偏好。其他历史信息不进入上下文。

这个策略让有效上下文长度大幅缩短，模型能在更长的对话中保持稳定。我实测过一个连续 50 轮的代码调试场景，传统方式在第 20 轮左右开始出现明显的上下文遗忘，Jev 的方式到第 45 轮仍然稳定。

3.4 反馈闭环：让用户的选择直接变成训练信号

前面提到的 RLCD 在这里落地。用户每次在候选回答中做选择，这个选择就被记录下来，作为对比数据用于后续的模型微调。用户不需要做任何额外操作，选择本身就是反馈。

这个闭环的关键在于“短”。从用户选择到模型更新，中间的链路越短越好。Jev 的做法是在会话级别做轻量级的偏好学习，而不是等到积累大量数据后再做全量微调。这样用户能在几次交互后就感受到模型“变懂我了”。

注意：反馈闭环涉及用户数据的收集和使用，在实际产品中需要做好隐私说明和用户授权。技术上的可行性不等于产品上的合规性。

4. 实操：怎么在自己的项目里复现类似思路

如果你是一个开发者，想在自己的产品里借鉴 Jev 的思路，下面是我整理的一套可落地的方案。不需要完全照搬，挑适合自己场景的部分用就行。

4.1 第一步：定义交互类型

先别急着接大模型。拿一张纸，把你产品里用户可能发起的交互列出来。比如一个写作辅助工具，交互类型可能有：续写、改写、扩写、缩写、翻译、纠错、风格调整。

每个类型写清楚三件事：输入是什么格式、输出是什么格式、需要哪些上下文信息。这一步做完，你会发现很多类型之间可以合并，最终可能只剩五六个核心类型。

# 交互类型定义的伪代码示例 interaction_types = { "continue_writing": { "input": "current_paragraph", "output": "extended_paragraph", "context": ["previous_paragraph", "style_preference"], "max_tokens": 300 }, "rewrite": { "input": "selected_text", "output": "rewritten_text", "context": ["tone_preference"], "max_tokens": 500 } }

这个定义不需要很复杂，关键是让后续的模型调用有据可依。

4.2 第二步：搭建类型判断层

类型判断可以用小模型做，也可以用规则做，取决于你的场景复杂度。我建议先用规则跑通流程，等积累了一定量的真实用户输入后，再训练一个轻量级的分类模型。

规则判断的核心是关键词和句式匹配。比如输入里包含“翻译成”“英文”“日语”等词，就归到翻译类型；包含“报错”“异常”“不工作”等词，就归到问题排查类型。准确率不用追求百分之百，八成以上就能显著改善体验。

4.3 第三步：实现候选生成

候选生成的技术实现有两种路线。一种是调用同一个模型多次，每次用不同的温度参数或随机种子；另一种是调用多个不同的模型，各生成一个候选。

第一种路线成本低，但候选之间的差异性可能不够大。第二种路线成本高，但候选的多样性更好。我建议根据场景选择：创意类场景用第二种，功能类场景用第一种。

# 候选生成的简化示例 def generate_candidates(prompt, n=3): candidates = [] for i in range(n): response = model.generate( prompt, temperature=0.7 + i * 0.1, # 不同温度增加多样性 max_tokens=500 ) candidates.append(response) return candidates

温度参数的调整范围建议在 0.5 到 1.0 之间。太低会导致候选雷同，太高会导致质量下降。

4.4 第四步：设计选择界面

候选生成之后，用户需要一种方式来选择。最简单的做法是并排展示，用户点击选择。稍微复杂一点的做法是允许用户对候选进行编辑和组合。

界面上要注意的是：不要让用户觉得“选择”是一个负担。候选数量控制在 3 到 5 个比较合适，太多了选择困难，太少了没有意义。每个候选的展示要简洁，突出差异点，而不是把完整内容都铺开。

4.5 第五步：收集反馈并迭代

用户的选择数据要记录下来，格式至少包含：输入内容、候选列表、用户选择、时间戳。这些数据积累到一定量之后，可以用来做几件事：

• 分析哪些类型的候选差异度不够，需要调整生成策略
• 训练一个偏好模型，用于后续的候选排序
• 发现用户输入中的新模式，补充到类型定义里

我自己的经验是，前 1000 条选择数据就能看出明显的模式。比如用户在某些类型下总是选择更短的候选，在另一些类型下总是选择更详细的候选。这些模式可以直接用来优化默认参数。

5. 常见问题与排查技巧实录

在实际落地过程中，我遇到过不少问题。有些是技术层面的，有些是产品层面的。挑几个典型的分享出来，希望能帮你少走弯路。

5.1 类型判断不准怎么办

这是最常见的问题。用户输入“帮我看看这段代码”，你判断成“代码生成”类型，但实际上用户想要的是“代码审查”。类型判断错了，后面的流程全错。

排查思路：先看训练数据里有没有类似的边界案例。如果没有，手动补充几十条；如果有但模型还是判错，检查特征工程是否到位。关键词匹配的规则要定期更新，因为用户的表达方式会变化。

一个实用的技巧是：在类型判断层加一个“置信度”输出。置信度低于阈值的输入，不强行分类，而是走一个通用的兜底流程，或者直接询问用户“你是想要 A 还是 B”。这个询问本身也是在帮用户明确自己的需求，对解空间是正向的。

5.2 候选质量不稳定

有时候三个候选里两个是废的，用户没得选。这个问题通常出在生成策略上。

排查方向：一是检查温度参数是否设置合理，二是检查提示词模板是否对不同类型做了适配，三是检查模型本身在这个类型上的能力边界。如果某个类型下候选质量持续偏低，可能是这个类型本身就不适合用当前模型来做，需要考虑换模型或者换方案。

我遇到过一个案例：在“诗歌生成”类型下，候选质量波动很大。后来发现是因为诗歌的评判标准主观性太强，模型很难稳定输出。最后的解决方案是把这个类型拆成“古体诗”和“现代诗”两个子类型，分别用不同的提示词模板，稳定性明显提升。

5.3 用户不愿意做选择

有些用户就是想要一个答案，不想在多个候选里挑。这时候强制展示多个候选反而增加了负担。

解决方案是提供“默认选择”模式。系统根据历史数据或通用偏好，自动选一个推荐候选，其他候选折叠起来。用户如果满意就直接用，不满意再展开看其他选项。这样既保留了解空间，又不强制用户做选择。

5.4 反馈闭环启动慢

RLCD 需要积累一定量的对比数据才能见效。冷启动阶段，模型还没有学到用户偏好，候选排序可能不理想。

我的做法是在冷启动阶段用规则做候选排序，比如按长度、按置信度、按生成顺序。等积累了几百条选择数据后，再切换到模型排序。切换的时机可以通过 A/B 测试来确定，看模型排序是否在关键指标上超过了规则排序。

5.5 常见问题速查表

5.6 几个容易忽略的细节

第一个细节是候选的展示顺序。用户倾向于选择第一个或最后一个候选，中间的被选概率明显偏低。如果你的候选生成有质量差异，要把质量高的放在首尾位置。如果质量差不多，可以随机打乱顺序，避免位置偏差影响反馈数据的质量。

第二个细节是错误处理。候选生成过程中如果某个候选失败了，不要直接报错给用户，而是用剩余候选继续。用户不需要知道背后有几个候选失败了，只需要看到可用的选项。

第三个细节是性能监控。类型判断的耗时、候选生成的耗时、用户选择的耗时，这三个指标要分开监控。任何一个环节变慢都会影响体验，但原因和解决方案完全不同。

6. 从 Jev 的思路延伸：还能怎么用

Jev 的这套思路不局限于对话式 AI。任何需要在大模型能力和用户需求之间做匹配的场景，都可以借鉴。

6.1 在代码辅助工具中的应用

代码补全工具面临的问题和对话式 AI 类似：模型给出的补全建议只有一个，用户要么接受要么重新输入。如果改成给出多个补全候选，按类型区分（比如“补全当前行”“补全整个函数”“补全测试用例”），用户的解空间会大很多。

我试过在一个内部代码助手项目里用这个思路。原本的补全接受率在 30% 左右，改成多候选后提升到了 55%。提升主要来自两个方面：一是用户有了更多选择，二是类型约束让补全内容更符合当前编码意图。

6.2 在数据分析场景中的应用

数据分析师用大模型处理数据时，经常遇到“模型理解错了我的意图”的情况。比如你想让它算同比，它给你算了环比。传统做法是重新描述需求，但更好的做法是让模型同时给出多种计算口径的结果，用户选择正确的那一个。

这个场景下，类型定义可以围绕“分析意图”来做：趋势分析、对比分析、异常检测、相关性分析。每种意图对应不同的输出格式和计算逻辑。用户不需要懂统计学术语，只需要看到结果后判断“这个是我要的”。

6.3 在内容创作中的应用

内容创作者用大模型辅助写作时，最大的痛点是“风格不对”。你让模型写一段科技评论，它给你写成营销文案。解决思路不是让用户去学怎么描述风格，而是让模型同时生成几种不同风格的版本，用户选择最接近的，然后在此基础上微调。

风格类型可以定义得细一些：正式、轻松、专业、通俗、激进、保守。每种风格对应不同的提示词模板和示例。用户选择之后，后续的生成都沿用这个风格偏好，形成个性化的风格档案。

6.4 在教育培训中的应用

教育场景下，同一个知识点需要针对不同水平的学生给出不同深度的解释。传统做法是老师手动准备多套材料，成本很高。用 Jev 的思路，可以让模型同时生成“基础版”“进阶版”“挑战版”三个解释，学生根据自己的理解程度选择。

这个场景的关键是类型定义要跟学习目标挂钩。比如“概念理解”类型下，基础版只讲定义和例子，进阶版讲原理和推导，挑战版讲边界条件和反例。学生选择的过程本身也是一种元认知训练。

7. 我个人的一些体会

这套东西我断断续续折腾了大半年，最大的感受是：大模型应用的门槛不在模型本身，而在交互设计。同样的模型能力，交互设计得好，用户觉得“这 AI 真懂我”；交互设计得差，用户觉得“这 AI 真笨”。Jev 的价值在于它把交互设计这件事系统化了，而不是靠零散的提示词技巧。

另一个体会是，解空间这个概念比“用户体验”更具体、更可操作。用户体验是一个模糊的感知，解空间是一个可以观察和度量的东西。你可以数一数用户在一个交互中面临多少个选择，每个选择的成本是多少，选择之后的反馈路径有多长。这些数字比“用户觉得好不好用”更能指导优化方向。

最后分享一个小技巧：如果你在做类似的产品，不妨在每次交互后加一个隐性的“解空间检查”。问自己三个问题——用户在这个环节有没有被强制接受一个结果？用户如果想调整，需要付出多少额外操作？用户的选择有没有被系统记住并用于后续优化？这三个问题的答案，基本能反映你的产品在解空间上的表现。

这个方向后续还可以往多模态扩展。现在 Jev 主要处理文本交互，如果把图像、语音、结构化数据也纳入类型系统，解空间会更大。不过多模态的类型定义比文本复杂得多，我目前还在摸索阶段，等有成熟经验了再分享。