如果你没戴过美瞳，永远不知道“把一片透明塑料贴到眼球上”这件事能有多难。手一抖，镜片掉地上；好不容易放上去，眼睛一眨又掉出来；甚至有些新手在镜子前折腾半小时，最后以“感觉镜片在眼皮里”告终。更麻烦的是，网上能找到的教程都是文字加视频，但视频没法实时响应你卡在哪一步。这时候，如果有个助手能听懂你“我现在看不到镜片在哪”“镜片好像粘在眼皮上了”这些描述，然后一步步告诉你该怎么做，是不是会友好很多？
我最近就在做这样一个原型：一个没有视觉能力的 AI 助手，只靠多轮对话，教用户戴美瞳。它没有摄像头画面输入，不依赖任何图像识别模型，甚至连一张照片都不看。它只做一件事：听懂你的描述，匹配到对应的佩戴阶段，然后用结构化的指令帮你解决问题。这个项目很小，但背后涉及的 Prompt 工程、对话状态管理、知识库组织和安全提示设计，几乎可以复用到所有“精细操作类指导”场景。
这篇文章我会从项目构思讲起，带你走一遍完整的技术实现路径：如何设计知识结构、如何写系统提示词、如何用 FastAPI 封装一个可调用的接口，以及部署到真实环境前必须注意哪些工程问题。你可以把它当成一个“垂直领域对话机器人”的迷你实战教程。
1. 这篇文章真正要解决的问题
戴美瞳和戴普通框架眼镜不一样，它需要把镜片直接贴在角膜表面。对于新手来说，主要难点有三个：
- 眼睛有天然的防御反射，手还没靠近，眼睑就已经闭紧了。
- 镜片本身是透明的，在指尖上很容易分不清正反。
- 一旦镜片贴上去位置不对，会明显感觉到异物感，这时候不知道应该继续调整还是取出来重戴。
传统的图文教程是“静态知识”，它假设所有人和所有镜片情况都一样。但实际佩戴过程中，每个人的手型、眼睛敏感程度、镜片曲率都不一样，卡住的环节也各不相同。这时候，用户需要的不是一个固定步骤列表，而是一个能根据反馈动态调整的“真人教练式”指导。
这正是对话式 AI 的用武之地。大语言模型虽然不能直接“看见”镜片位置，但它可以从用户的语言描述中推断出当前状态。比如用户说“我戴上后看东西有点模糊”，模型能判断可能是镜片没有贴合好、正反戴反，或者镜片上有蛋白质沉淀，然后给出分类化的解决建议。
所以这个项目要解决的核心问题是：在没有视觉输入的条件下，如何通过多轮对话维护用户的操作状态，并给出准确、安全、可执行的下一步指令。同时，它也是一个很好的大模型应用示例，清楚展示了 Prompt 编写、知识注入、会话管理、安全兜底这些工程实践。
适合读这篇文章的读者有两类。一类是刚接触大模型应用的开发者，想看一个完整的、小而美的案例；另一类是自己本身戴美瞳、又对 AI 工程感兴趣的人，在阅读的时候会更有代入感。即使你完全不懂眼科知识，也能通过这个项目理解“垂类知识 + 对话模型”如何组合成产品。
2. 基础概念与核心原理
2.1 什么是“没有眼睛的 AI”
这里的“没有眼睛”是指 AI 没有视觉感知模块。你可以用纯文本大模型，比如 GPT、文心一言、通义千问，通过 API 接入，完全不使用视觉模型，也不需要用户拍照或录视频上传。
为什么不做成“拍照识别”呢？因为在实际场景里，让一个正在戴美瞳的人对着眼睛拍一张高清照片，本身就很困难，而且角膜和镜片都是透明的，普通摄像头很难拍出足够清晰的特征。更自然的方式是让用户用自然语言描述自己卡在哪一步，AI 再给出针对性的指导。这也正好避开了一个很常见的产品误区：不是所有场景都必须上多模态，文本交互往往更轻、更快、更符合用户实际行为。
从技术角度看，纯文本交互意味着我们可以把一个复杂的操作流程拆解成一个“状态机”。每个状态对应佩戴过程中的一个阶段，AI 根据用户的话判断当前状态，然后输出下一个动作。这种设计让问题的复杂度大大降低，也让错误处理变得更可控。
2.2 戴美瞳的标准步骤
要想让 AI 教得好，首先得把专业知识结构化。综合眼科护理资料，戴美瞳的标准流程通常可以拆成以下 7 个阶段：
| 阶段 | 操作说明 |
|---|---|
| 洗手准备 | 用中性洗手液洗净双手，不要留长指甲，避免划伤镜片或角膜 |
| 取出镜片 | 从护理液中使用专用镊子或指腹轻轻取出镜片 |
| 检查正反 | 将镜片放在食指指腹上，对着光源看边缘：碗状是正面，碟状是反面 |
| 拉开眼睑 | 一只手的中指拉下下眼睑，另一只手的中指提上上眼睑 |
| 佩戴镜片 | 注视前方镜子里的景象，将镜片轻轻贴近眼球 |
| 闭眼调整 | 闭眼转动眼球，让镜片与角膜完全贴合 |
| 完成收尾 | 确认无不适后，护理并收纳镜盒 |
这些步骤看起来简单，但每一步都可能出现异常情况。例如取出时镜片粘连、检查时看不出正反、戴上后镜片滑到眼白处、眼睛过度泛红。知识库的设计应该把这些异常场景一并覆盖。
2.3 对话式指导的核心原理
大语言模型本身并不“知道”用户当前处于哪一步。我们需要通过两种机制来弥补：
- 显式状态管理：服务端保存一个 state 字段，AI 每次回复后判断下一步状态。
- 隐式状态推断：直接把整段对话历史交给模型，让模型从上下文中自己判断。
对于这个项目，我推荐用隐式状态推断为主 + 关键规则兜底。原因是状态数量少、对话轮次短，模型完全可以胜任判断。如果业务状态非常多、分支很复杂，再引入显式状态机也不迟。
会话管理上，最简单的做法是“session_id -> 消息历史”。用户每次调用接口时，把新的用户消息追加到历史中，再连同系统提示词一起发送给模型。这样模型就能记住前面聊了什么，避免用户重复描述。后面在代码实现部分，我会直接展示这套逻辑。
3. 环境准备与前置条件
这个项目使用 Python 构建，因为 Python 生态对大模型的 SDK 支持最好，FastAPI 也很适合快速暴露 HTTP 接口。
需要准备的环境如下：
- Python 3.10 或更高版本。代码中使用了
str | None这类新语法，所以版本不能太低。 - 一个可用的 Open
