前一阵子在讨论大模型能力边界时我抛出一个问题如果一个 AI 从来没有“看见”过任何东西它能不能给你讲清楚“怎么戴美瞳”当时大部分人的第一反应是不可能戴美瞳是个纯视觉操作手要扒眼皮眼睛要看镜子没眼睛的 AI 凭什么教你但事实是这类模型不需要眼睛也能给出逻辑完整、步骤清晰的答案。这不是魔术而是大语言模型的一种底层能力——把物理世界的操作知识编码成文本。理解了这个机制你就能同时想明白另外两件事为什么 AI Agent 经常能在看不见的情况下给出“看起来很有道理”的方案以及当它什么时候会开始胡扯。这篇文章会从“没有视觉的大模型如何学会一项视觉依赖型任务”切入完整演示一次文本型 AI 输出操作指导的过程然后拆解它的能力边界最后给出工程上如何通过 Agent、视觉模型和工具调用来补足这个短板。整篇文章的目标是让你对一个 AI 系统的能力形成准确判断它哪里强哪里弱什么时候该相信什么时候必须保持怀疑。1. 先别急着说“不可能”这个问题到底在问什么“一个没有眼睛的 AI教你怎么戴美瞳”表面看是一个玩笑式的话题其实包含三个非常严肃的技术问题。第一个问题大语言模型到底如何理解物理世界的操作模型没有眼球、没有触觉、没有本体感受它的全部训练数据是互联网上的文本。这意味着它所有关于“扒开下眼睑”“把镜片放在指尖”“眼球向上看”的知识全部来自文字描述而不是来自第一视角的视觉经验。第二个问题文本知识是否可以替代感官经验完成一部分操作指导如果读者对美瞳毫无概念大模型给出的步骤描述能不能让读者听懂并完成操作这里其实是在测试知识表征的“可传递性”。第三个问题也是工程上最重要的问题当 AI 缺失某种感知通道时它给出的建议应该被如何看待是做执行依据还是做背景参考这直接关系到 AI Agent 在现实任务中的可信度设计。把这三个问题拆开以后“没有眼睛的 AI 教人戴美瞳”就不再是段子了。它是一种非常典型的人机协作场景机器没有感知但有知识人类有感知但缺经验。AI 用文本方式把经验编码并传递人类用自己的感官去验证和反馈。从开发者的角度来理解这个场景和“没有数据库权限的 AI 教你写 SQL”“没有 GPU 的 AI 教你做大模型推理优化”是同构的。AI 提供的是认知层面的指引而执行和验证发生在物理世界或真实系统中。分清这两层是使用任何 AI 系统最基本的前提。2. 没有眼睛AI 是怎么“学会”戴美瞳的这里需要先澄清一个常见的误解文本模型不是通过“看见”美瞳来学习戴美瞳的它是通过阅读海量文本学会了描述“戴美瞳”这个动作的语言模式。大语言模型本质上是语言概率模型。训练阶段模型在海量文本上学习词语之间的条件概率关系。当语料里反复出现类似“把镜片放在食指指尖”“用另一只手扒开下眼睑”“眼睛向下看”这样的序列模型就会把这些语言模式固化进参数里。下次遇到“请告诉我怎么戴美瞳”的指令时模型会根据指令与训练语料的语义相似度按概率生成一组连贯的步骤。这个机制可以用一个简化类比来说明一个从没吃过火锅的人读了 1000 份火锅测评背熟了所有菜品的口感描述和涮煮时间。他确实没有味觉但是当别人问“毛肚应该涮几秒”时他能给出大致准确的回答。这就是语言知识表征与感知经验的差异。所以大语言模型获取知识的过程本质上是一种“阅读归纳”而不是“体验学习”。它归纳的是语言中关于动作、步骤、物体、顺序的描述规律而不是动作本身的物理反馈。这一步对技术人有一个重要启发模型的输出质量极度依赖训练语料中相关知识的覆盖度和一致性。如果语料中关于戴美瞳的操作描述互相矛盾模型生成的步骤也可能自相矛盾。换句话说模型的“知识”不是对世界的准确反映而是对文本中世界描述的一种统计拟合。这就是为什么大模型经常会出现“一本正经地说错”的情况。它不是在撒谎而是它学习到的语言模式本来就有歧义。理解这一点是正确使用 AI 的前提。可以用下面这张表来对比人类学习和语言模型学习的本质差异维度人类通过视觉学习语言模型通过文本学习输入信号图像、深度、触觉、运动反馈纯文本符号学习方式观察示范、动手试错统计语言序列共现概率知识表征多模态感知记忆含身体经验参数化的语义关联输出能力可执行、可修正、可感知异常生成合乎语言规律的描述核心弱点难以快速规模化传递缺乏物理验证可能偏离现实模型“知道怎么戴美瞳”和一个人“会戴美瞳”是两个层面的事。前者是语言层面的能力后者是物理世界的熟练操作。AI 产品设计中最常见的翻车点就是混淆了这两者。3. 实际演示让文本 AI 生成一份完整的美瞳佩戴指南为了证明“没有眼睛的 AI 也能给出结构化操作指南”这里我直接通过 API 调用一个大语言模型让它输出完整的佩戴步骤。下面的代码使用 OpenAI 兼容接口的常见调用方式你可以把它改成任意支持 chat/completions 协议的模型服务。# -*- coding: utf-8 -*- 演示文本型大模型生成美瞳佩戴步骤 环境Python 3.9 / openai1.0 说明仅用于演示模型对操作知识的文本生成能力不构成医疗或产品建议。 from openai import OpenAI client OpenAI( base_urlhttps://your-model-endpoint.example.com/v1, api_keyyour-api-key, ) prompt 你是一名有经验的隐形眼镜佩戴指导者。 请用清晰的步骤向一个完全没有佩戴过美瞳的新手讲解 如何洗手、如何区分正反面、如何佩戴、如何摘取、佩戴中的注意事项。 请用编号列表输出注意逻辑顺序与安全提醒。 response client.chat.completions.create( modelyour-model-name, messages[ { role: user, content: prompt, } ], temperature0.3, ) print(response.choices[0].message.content)这段代码的本质是向模型发送一个纯文本指令。模型没有接收任何图片信息它完全依靠自己的语言先验知识来组织答案。运行后模型可能会输出类似下面的内容1. 准备阶段 - 洗手并擦干确保手指没有毛絮或化妆品残留。 - 取出美瞳放在干净的手指或专用佩戴棒上。 2. 区分正反面 - 观察镜片边缘如果呈碗状边缘向内收是正面。 - 如果边缘向外翻呈碟状是反面。 3. 佩戴 - 用一只手的中指扒开下眼睑。 - 另一只手食指托住镜片。 - 眼睛平视或向下看将镜片轻贴眼球。 - 松开眼睑轻轻转动眼球镜片贴合。 4. 摘取 - 洗手擦干。 - 用中指扒开下眼睑。 - 食指指腹轻触镜片下缘将镜片滑向眼白处。 - 用拇指和食指轻轻捏下镜片。 5. 注意事项 - 佩戴时间不宜超过厂商建议时长。 - 出现红眼、刺痛、流泪应立刻停戴并咨询眼科医生。 - 美瞳属于第三类医疗器械应在专业验配后使用。从语言层面看这份输出是连贯、完整的。它甚至提到“美瞳属于第三类医疗器械应在专业验配后使用”这说明模型在训练语料中不仅学到了操作步骤还学到了安全提示和社会规范类文本。这算不算“会戴美瞳”严格说不算。它缺少几个关键能力它不知道你眼睛的基弧是否匹配不知道你的泪液分泌是否适合佩戴也无法实时判断镜片是否已经贴合到位。但作为一份“入门引导”它的确能让一个完全不了解美瞳的人建立起基本认知。这就是文本模型的真正价值它适合做知识引导和流程梳理不适合做感知判断和实时反馈。把这一点刻在脑子里你设计 AI 产品时就会少走很多弯路。4. 为什么 AI 的答案看起来“像见过一样”细想一下上面的输出确实有点神奇。模型没有眼睛为什么能描述“镜片边缘向内收是正面”这种视觉特征答案是视觉特征已经被语言化了。在人类写的科普文章和隐形眼镜使用指南里作者会把“正面看起来像碗”“反面看起来像碟”这种视觉判断翻译成文字。语言模型学到的是这组翻译后的符号而不是真实的图像特征。这背后有一个更底层的机制模型的参数中存储了大量关于世界的“文本化描述”。这些描述不是零散的而是形成了某种结构化的知识网络。当用户问“怎么区分美瞳正反面”时模型并不仅仅是检索到了一个句子它激活了与“美瞳”“正反面”“碗状”“边缘”“镜片”相关的所有语义节点然后根据概率生成一段协调的回答。所以与其说模型在“回忆”知识不如说它在“重建”知识。这种重建能力来自 Transformer 架构的注意力机制——模型可以跨句子、跨段落地关联语义信息而不是简单背诵原文。这种能力带来的好处是模型可以组合不同来源的知识生成训练语料中从未完整出现过的回答。比如训练语料里可能有“如何洗手”和“如何戴美瞳”的分别描述但模型可以生成“戴美瞳之前应该如何洗手”这个组合性建议。这种组合生成能力是传统搜索引擎做不到的。用工程语言说语言模型学到的不是“文档”而是“文档背后的规律”。它能实现一定程度的“举一反三”。但这种“举一反三”也需要警惕组合出来的内容可能吻合语言规律却不吻合物理定律。举个例子一个模型可能组合出这样的建议“将美瞳放入微波炉加热 3 秒可以让镜片更贴合。”这句话的语法完全正确也从语义上与“镜片”“贴合”“加热”产生关联。但是物理上这绝对是个灾难性建议。模型会不会生成这种内容取决于训练语料里这种行为是否出现过、以及 RLHF 对齐阶段是否专门做了安全约束。这就是为什么“AI 看起来知道”和“AI 真的知道”之间有一道鸿沟。语言的流畅性会制造一种“能力错觉”让用户高估模型的真实理解水平。作为开发者在设计用户界面和产品功能时一定要用交互设计来破掉这种错觉。5. 能力边界拆解哪些环节 AI 能帮上忙哪些帮不上现在我们从工程角度把“戴美瞳”这个过程拆成多个子任务逐个判断文本 AI 能提供什么价值。第一个子任务是“知识科普”解释美瞳材质、透氧量、含水量、基弧、直径这些参数的含义。这个任务完全落在文本模型的优势区。训练语料里包含大量关于隐形眼镜参数的科普内容模型可以给出基本正确的解释甚至能对比不同参数对佩戴体验的影响。第二个子任务是“流程指导”提供佩戴、摘取、清洁、保存的标准步骤。这个任务也适合文本模型。因为操作类知识已经被大量文字化模型有充足的语料可以效仿。第三个子任务是“视觉判断”判断镜片正反、识别镜片是否有破损、确认镜片位置。这个任务文本模型无法独立完成。它看不到当前的镜片状态只能基于概率猜测。真正执行时需要用户自己用眼睛判断或者接一个视觉模型。第四个子任务是“个体适配”评估用户的眼睛健康状况、判断基弧是否合适、预测佩戴舒适度。这个任务连文本加视觉都不够需要专业的眼科检查数据作为输入。这也是为什么美瞳被归为医疗器械而不是普通美妆产品。第五个子任务是“实时安全监测”提示佩戴者角膜缺氧、干眼、感染的早期迹象。这个任务需要结合用户反馈的体感数据模型可以给出参考性的风险提示但无法取代医生的诊断。把这五个子任务放在一张表里可以看得更清楚子任务文本 AI 能力视觉 AI 能力真实系统需求结论参数科普强无知识库检索文本 AI 可独立承担步骤指导强无流程引擎文本 AI 可独立承担镜片正反判断弱强摄像头 图像识别需要视觉模型个体适配评估弱弱眼科检查数据 验配师决策需要专业医疗介入实时安全监测中弱用户反馈 医生判断需要多模态融合这张表就是我们常说的“AI 能力边界”的一种具体化表达。一个成熟的 AI 产品不会尝试用文本模型包打天下而是会在文本模型的外围加上视觉模型、规则引擎和人工审核。产品设计上的关键点是把任务路由做到位判断当前用户的请求属于哪个子任务然后决定是直接由文本模型回答还是转人工还是启动多模态分析流程。这个过程在工程上被称为“能力编排”。6. 多模态模型和 Agent怎么给没有眼睛的 AI“装上眼睛”既然文本 AI 看不到美瞳那是不是换一个多模态大模型就能解决答案是部分解决但不能完全解决。多模态大模型可以接收图像输入它确实能看到镜片的静态画面。你可以拍一张美瞳放在指尖的照片让它判断正反模型会基于训练时见过的海量图片给出判断。在静态识别任务上多模态模型的表现已经相当可用。但戴美瞳是一个动态过程。镜片进入眼睛瞬间的位置、贴合状态、用户的眨眼反应这些都需要连续帧的视频理解和实时反馈。当前多模态模型对视频的理解能力还在发展阶段逐帧分析的延迟和成本都比较高很难做到像真人指导者那样的实时交互。工程上更务实的方案不是等待模型变强而是用 Agent 架构来组合现有能力。具体来说就是让一个中央大模型当“大脑”调度多个专用工具。一个可行的 Mini Agent 设计如下# 伪代码给文本 AI 接入视觉工具实现“看图判断镜片正反” def judge_lens_direction(image_path: str) - str: 使用视觉模型判断镜片正反。 # 这里可以接入任意视觉理解服务 vision_result vision_model_infer(image_path) # 输出bowl正面或 dish反面 return vision_result def agent_guide_with_vision(user_input: str, image_path: str None): if image_path is not None: direction judge_lens_direction(image_path) return f根据图片分析镜片当前是{正面 if direction bowl else 反面}。 else: # 无图时走文本知识回答 return text_model_guide(user_input)这里的思路是不要让大模型自己去“看”图片而是把图片交给专门的视觉模型处理再把视觉模型的结果重新转成文本交给主模型组织回答。这种“工具调用 模型编排”的模式就是当前 AI Agent 落地的主流方式。OpenAI 的 Function Calling、Anthropic 的 Tool Use、Spring AI 的 Tool Calling本质上都是为了实现这种能力编排。大模型负责判断“当前任务需要调用什么工具”工具负责执行“模型不擅长的感知或计算任务”最后模型再把结果整理成自然语言。一旦把视觉能力和 Agent 编排结合起来整个系统的能力就发生了变化能力层无工具有视觉工具有视觉 Agent 编排知识问答可以可以可以静态图片理解不可以可以可以多步骤工具调度不可以有限可以动态反馈不可以有限可以端到端自动执行不可以有限可以也就是说Agent 架构解决的核心问题不是让模型本身变强而是让模型可以触达原本够不着的世界。一个会写代码的文本模型通过终端工具调用就能操作真实系统一个没有视觉的文本模型通过视觉模型工具就能“看见”图片。但这里必须保持清醒工具可以扩展感知却不能替代判断。视觉模型可能判断错误工具可能返回异常数据Agent 在编排时也可能选错工具。工程上必须设计一个验证和兜底机制而不是盲目信任 Agent 给出来的任何结论。7. 工程落地时的安全边界与风险控制把“AI 教戴美瞳”这个场景泛化到生产环境你会发现所有 AI Agent 类产品都面临同一个问题模型给出的建议一旦被用户实际执行就可能带来真实后果。美瞳佩戴不当引发角结膜损伤SQL 误操作导致数据库字段被清空代码生成引入安全漏洞这些都是同一个风险模型。因此工程落地时至少要设置四道防线。第一道防线是角色边界。在系统提示词中明确告诉模型你是知识提供者不是医疗决策者你的回答仅供参考不替代专业验配。这能显著降低模型过度承诺的概率。SYSTEM_PROMPT 你是隐形眼镜知识助手。 你必须遵守以下规则 1. 你提供的是通用科普和操作流程知识。 2. 你无法获取用户的眼部健康数据不能做个性化诊断。 3. 涉及视力异常、疼痛、感染时必须建议用户咨询眼科医生。 4. 美瞳属于第三类医疗器械请提示用户在专业验配师指导下使用。 5. 不要给出主观的医疗判断不要承诺佩戴效果。 第二道防线是工具权限的最小化。Agent 系统如果只是做科普答疑就不该挂载数据库写权限、文件删除权限或任何敏感系统接口。真实项目中我曾经见过一个 AI 对话机器人被赋予了服务器 Shell 执行权限结果用户用自然语言让 AI 删除了临时目录。权限过大永远是安全事故的第一原因。第三道防线是输出校验。在模型生成回答之后通过针对性的规则做一次二次检查。比如检测是否出现“禁止”“禁忌”“过敏史”“就医”等安全关键词缺失的情况如果回答包含步骤编号检查编号是否完整如果涉及医疗类指令确保回答中带有免责声明。这些规则无法解决所有问题但可以过滤掉相当一部分“模型一本正经地冒险”的输出。def safety_check(response: str) - bool: required_keywords [眼科医生, 医疗器械, 洗手] for kw in required_keywords: if kw not in response: return False return True第四道防线是用户反馈闭环。在回答末尾主动询问用户的实际佩戴体验建立一种“AI 给建议用户进行物理验证然后反馈结果”的协作机制。如果用户反馈与 AI 建议冲突AI 应立刻降级为保守策略——建议停用并寻求专业帮助。这四道防线的核心逻辑完全适用于其它生产级 AgentAI 可以大胆建议但系统必须保证“建议不会造成不可逆伤害”。这个原则比任何大模型优化技巧都重要。8. 从段子到工程启示AI 产品的使用边界与协作模式回到文章标题“一个没有眼睛的 AI教你怎么戴美瞳”如果你把它当成段子它只是一个反差感极强的玩笑但如果你把它当成一个产品需求它其实是“以不足的感知能力完成高感知要求的任务”的一种典型挑战。这个挑战在 AI 工程领域无处不在。没有实时运行日志的 AI要指导你排查线上故障没有代码库读取权限的 AI要帮你定位代码 Bug没有数据库统计信息的 AI要告诉你如何优化慢查询。这些场景和没有眼睛教戴美瞳本质上是同一类问题。当你意识到这一点你的 AI 产品设计方法论就会发生变化。你不再纠结于“模型强不强”而是开始思考三个更实际的问题这个任务对模型的哪些能力有硬依赖模型缺失的能力可以通过哪些工具补充模型输出之后系统如何验证结果的安全性从另一个角度看这篇文章也回答了很多人对 AI 的困惑AI 的表现为什么有时惊人地好有时惊人地差因为它的强项在于语言知识重组弱项在于物理感知与验证。凡是能够被充分文本化的知识AI 都可以做得很好凡是需要与真实世界实时交互的任务AI 的可靠性就会断崖式下降。这也是多模态模型和 Agent 重要性的根本来源。视觉模型给系统提供了“看”的能力终端工具给系统提供了“做”的能力向量检索给系统提供了“记忆”的能力。这些外围能力组合起来才能让 AI 从“纸上谈兵”走向“落地执行”。但纸上谈兵的能力本身也不是没有价值。在缺乏专家指导的场景中一份结构化的操作指南、一份严谨的安全检查清单已经能够帮助用户建立基本的操作框架。关键是产品设计者要诚实地标注 AI 的能力边界而不是让用户误以为 AI 什么都能做。9. 实践建议这类 AI 内容应该怎么用起来如果你要把这类“能力边界型 AI”落地到实际项目中这里有几条可以直接参考的建议。第一把 AI 定位成“带上下文的向导”而不是“自动执行的机器人”。向导负责指路执行和确认必须由用户或受控系统完成。这个定位能避开绝大多数安全风险。第二用结构化输出弥合知识差异。让 AI 生成带编号步骤、带注意事项、带常见误区提示的内容。结构化输出更容易被用户理解和记忆也更容易被规则引擎校验。第三对关键场景做“人工复核留痕”。尤其是医疗、金融、法律、数据库操作等高危场景AI 给出的结论一定要经过人工或规则复核并保留完整日志。这是审计需要也是责任追溯的基础。第四测试重点放在“失败场景”而不是“成功场景”。不要只测“AI 能否给出完美答案”要测“当输入不完整、图片模糊、用户描述矛盾时AI 是否知道拒绝或降低承诺”。一个知道说“我不确定请提供更多信息”的 AI比一个永远自信的 AI 更可靠。第五迭代路径是从文本到多模态再到 Agent。先跑通文本知识问答再接入视觉工具完成静态识别最后再做完整的多工具编排。每一步都验证清楚再进入下一步不要试图一步到位。落到“AI 教戴美瞳”这个例子理想的产品形态不是让 AI 直接给一段通用指南就结束而是一个多轮对话系统先了解用户是否有佩戴经验再询问眼睛是否干涩、镜片基弧参数然后给个性化步骤。用户佩戴后如果出现不适AI 能根据反馈给出安全指引。这个交互链路里文本模型只承担 30% 的工作剩下的靠规则引擎、用户反馈结构和安全兜底逻辑共同完成。这个方法论复制到任何领域都成立。下次你再看到某个“AI 做得不太好”的场景别急着下结论说 AI 没用。正确的思路是先拆任务再看模型缺什么感知能力再决定是加视觉模型、加工具还是加人工兜底。把这个分析框架装进脑子里你评估任何 AI 项目时都会比别人多一个维度。