核心原理与实现流程
混阅的核心是：让大模型保留中文句子，只把少量适合学习的词替换为英文，再把结果显示回网页。
浏览器插件基于 fishjar/kiss-translator 开发，负责提取网页段落、发起请求和展示结果。混阅后端原来负责选择提示词、转发模型请求、缓存、记录和额度管理。
原来的在线流程
网页中的中文段落
→ 插件按网站规则提取正文
→ POST /hy_article/ai/translate（携带混阅 API Key）
→ 后端检查 Key、额度，跳过纯链接或邮箱等文本
→ 根据 Key 的 level，从 hy_prompts 读取 mixed_zh2en Prompt
→ 开启缓存时，先尝试查找已有结果
→ 否则请求大模型：system = Prompt，user = 原始段落
→ 取 choices[0].message.content 作为转换结果
→ 更新额度，按用户设置记录译文
→ 插件以“仅显示译文”模式替换网页显示后端实际使用聊天补全格式调用模型，主要入口是 hy_api/src/hy_article/hy_article.controller.ts，模型请求封装在 hy_api/src/utils/translate_text_util.ts。
中文转混阅使用数据库 hy_prompts 中 category=mixed_zh2en、level 与用户难度相同的那一条记录。历史实现通过豆包模型接口生成正文；并不是在服务器上用词典逐个机械替换中文单词。代码中还留有早期分词和词典转换接口，与这里公开的 AI 翻译流程不同。
Prompt 如何控制难度
简单模式要求每段替换 1 个词语；中等模式要求替换 3～4 个；全英文模式要求整段翻译。四级、六级、考研模式通过文字描述限定词汇范围。所有数据库原文均在 Prompt 页面。
这些要求由模型理解后执行。原实现没有通过固定考试词表核验每个词，也没有程序保证替换数量，所以它们是生成目标，不是严格约束。
Prompt 中的“先翻译为英文，再选择词语”是给同一次模型调用的指令。后端没有先请求一次完整英文，再请求第二次混排；中间英文也不需要展示给用户。
去掉服务端之后
中文网页
→ KISS Translator 提取段落
→ 直接请求自己电脑上的本地模型
system: 所选混阅 Prompt
user: 当前段落
→ 模型返回中夹英正文
→ 插件在原网页显示结果模型直接执行相同任务，因此不需要部署 NestJS、不需要安装 MongoDB，也不需要混阅账号或额度系统。公开的 Prompt 已经把需要的数据库内容提取出来。
本地方案不会继续使用原站的云端记录、词频统计、账户、订单和实时消息功能。网站适配规则、模型选择和提示词由你在上游插件中管理。
为什么先关闭聚合翻译
这些原始 Prompt 接受一段文本并返回一段纯文本。插件的聚合模式通常把多个段落打包，要求返回带 ID 的 JSON、LINE 或 XML。直接把原 Prompt 填进聚合模板会造成格式不匹配。
先关闭聚合，使用 System Prompt = 混阅原文，User Prompt = {{text}}。每次处理一个段落，最接近原服务的调用方式。之后若自行设计聚合模板，需要保留每段 ID 并满足插件的对应输出协议。