技术词直接摆到界面上，用户就懵了
界面里常见的技术词 ✗：token、上下文窗口、temperature、embedding、向量检索 ✔ ——
工程内部用没问题 ✔，但用户看到就不知道该怎么办 ✔（见输出可读性那篇的同理 ✔）。
把技术词翻译成"用户能判断的东西" ✔。
一、常见词的人话对照
| 技术词 | 用户看到的应该是 |
|---|---|
| token 上限 | 「最长约 X 字」（并说明超了会怎样 ✔） |
| temperature | 「更稳妥 / 更有创意」（二选一或滑杆 ✔） |
| 上下文窗口 | 「它能记住多长的对话」（给轮数或时长 ✔） |
| 向量检索 | 「在资料库里查找相关内容」（不暴露实现 ✔） |
| 模型版本号 | 「快速模式 / 精确模式」（版本号放详情里 ✔） |
| 幻觉/编造 | 「可能给出不准确的内容，请核对来源」 ✔ |
| 嵌入/索引 | 「资料已准备好 / 还在准备」 ✔ |
要点：给"能判断的选项"而不是"要调参的旋钮" ✗→✔。
二、三处最该翻译的位置
- 设置页（参数名最容易直接暴露 ✔）；
- 错误与限制提示（"超出 context window" ✗ → "内容太长，请拆分后提交" ✔）；
- 等待状态（"正在 embedding" ✗ → "正在准备资料" ✔）。
三、术语一致（与术语表配合）
- 界面词进术语表 ✔（见术语一致性那篇 ✔）；
- 同一个概念全站一个词 ✔（不要一处"模型"一处"引擎" ✔）；
- 英文缩写首次出现给中文 ✔（RAG → 检索增强 ✔）。
四、什么时候可以保留技术词
- 面向开发者的功能（API 文档、参数说明 ✔）；
- 高级模式（明确标注"高级设置" ✔ —— 用户自己选择深入 ✔）；
- 法律/合规必要表述 ✔。
判断标准 ✔：用户需要据此做决定吗？ ✔
需要 → 必须翻译成人话 ✔；不需要 → 不必暴露 ✔。
五、三个反模式
- 把参数名当功能名 ✗（"温度设置" ✔）；
- 翻译过头 ✗（把"检索"说成"魔法" ✔ —— 失去可信度 ✔）；
- 同一个界面混用两套说法 ✗。
六、一条判据
让一个不懂技术的用户读完设置页 ✔，他能否说出"我该选哪个、为什么" ✔？
不能，说明界面还是工程视角 ✗。