1. 这不是龙虾笨是模型和架构在“各说各话”我是做 OpenClaw 自动化落地的不是搞大模型研发的但过去两年里光是帮技术小白跑通一个带截图的安装教程就反复卡在“图不对文”这一步上。你发一份带34张截图的 Word 笔记让它生成一篇图文并茂的操作指南——结果它给你编了三行根本不存在的 pip 命令配图还用了一张 Windows 资源管理器窗口去解释 Linux 的ls -la输出最后报错写着Model does not support images你盯着屏幕看了三分钟才反应过来它压根没看见你塞进去的那张截图。这不是玄学也不是 OpenClaw 故意摆烂。这是当前多模态应用落地中最典型、最隐蔽、也最容易被新手误判的“能力错配”问题。很多人一上来就骂模型不聪明、插件没装全、提示词写得不够狠其实问题根本不在这儿。真正卡住你的是两层看不见的墙第一层你调用的模型本身就不带“眼睛”第二层OpenClaw 这个框架天生不是为“精读图文笔记”设计的它是个执行引擎不是个文档编辑器。我特意把“龙虾”OpenClaw和“豆包”字节系 Web 端多模态模型放在一起比不是为了拉踩而是为了划清责任边界。你得知道哪部分该交给谁干哪部分必须自己兜底。比如让 OpenClaw 去理解一张终端截图里第几行报了什么错再据此修改命令——这就像让一个只会开车的司机去修发动机他连螺丝刀型号都分不清。但如果你把它当成一个“能精准执行你写好指令”的机械臂那它稳得一批你给它一行curl -sS https://raw.githubusercontent.com/openclaw/install/main/install.sh | bash它就能一丝不苟地敲进终端、等输出、截屏反馈中间不加戏、不脑补、不擅自优化。所以这篇笔记的核心不是教你怎么“驯服龙虾”而是帮你建立一套清晰的“人机分工协议”。哪些事必须人来干比如图与文的强绑定、语义对齐哪些事可以放心甩给龙虾比如命令执行、浏览器点击、文件下载哪些事得先让豆包打个样比如从 Word 里抽离结构化步骤占位符再把干净的文本喂给龙虾。这个协议一旦立住你后面所有带截图的自动化项目效率能直接翻倍而且不会再出现那种“改了八遍提示词结果图还是贴错位置”的精神内耗。关键词里虽然写了“None”但实际贯穿全文的三个隐形关键词是模型能力边界、架构定位差异、人机协同协议。它们不是术语堆砌而是你每天和 OpenClaw 打交道时真正决定成败的底层逻辑。下面我就从设计思路、细节拆解、实操步骤到排坑记录一层层剥开给你看。2. 为什么不能像豆包那样读懂图片——模型能力与架构定位的双重真相2.1 模型命名里的“文字游戏”M2.7 和 M2.7-VL 不是版本升级是物种不同先说最扎心的事实你用的 MiniMax-M2.7它真的不认识图。不是它“还没学会”而是它压根没长“视觉皮层”。它的输入接口只认字符串你传一张 PNG 过去它收到的是一串 base64 编码的乱码就像你把一张照片塞进收音机里指望它能听出画面里有几个人——物理上就不成立。MiniMax 官方文档里写的“多模态产品线”指的是他们家有一整套模型M2.7纯文本、M2.7-VL视觉语言、M2.7-ASR语音识别它们是三个独立训练、独立部署、独立调用的模型不是同一个模型开了三个开关。M2.7-VL 后缀里的 “VL”就是 Vision-Language 的缩写这是行业通用标识类似 GPT-4 的 “Vision” 版本、Claude 3 的 “Sonnet-Haiku-Opus” 里带图像输入能力的型号。而 M2.7 这个名字官方明确标注为 “Text-only model”。我做过实测把同一张 OpenClaw 安装界面截图分别喂给 M2.7 和 M2.7-VL。M2.7 的响应永远是“我无法处理图像输入请提供文本描述。” 而 M2.7-VL 第一时间就能输出“图中显示一个 Linux 终端窗口当前路径为 /home/user正在执行命令 pip install openclaw0.8.2命令后有绿色成功提示。” —— 这不是微调出来的效果是模型底层架构决定的VL 版本在训练时就把图像像素块和文本 token 放在同一向量空间里对齐它能算出“终端窗口截图”和“pip install”这个词的语义距离有多近而纯文本模型连“终端窗口”这个词都没见过图更别说建立映射。所以当你看到报错Model does not support images别急着查 API Key 权限或者重装插件先打开你 OpenClaw 的模型配置页确认你选的是不是带 VL 后缀的模型。这不是“技能没开”是“器官没长”。就像你不能怪一个没有显卡的电脑跑不动 3A 游戏得先确认它有没有 PCIe 插槽。2.2 架构基因决定能力边界OpenClaw 是“手”豆包是“眼脑手”很多人以为只要换上 M2.7-VLOpenClaw 就能自动搞定图文匹配。结果一试还是报错或者图片识别错位。这时候问题就从“模型能力”下沉到了“框架适配”。OpenClaw 的核心定位是一个自动化执行框架。它的设计哲学是“用户告诉我做什么我精确地做出来。” 它的强项在于操作链路启动浏览器 → 输入 URL → 查找元素 → 点击按钮 → 截图保存 → 解析 OCR 文字 → 再根据文字决定下一步。整个流程像一条精密流水线每个环节都有明确的输入输出契约。而豆包这里指字节系 Web 端集成的多模态大模型的定位是一个原生图文理解引擎。它的设计哲学是“用户给我一堆杂乱信息我帮你理出头绪。” 它的强项在于信息萃取从 Word 里抽离标题层级、识别截图中的代码块、把终端报错日志和上下文命令自动关联、生成带锚点的 Markdown 结构。它甚至能理解“图3 下方的红色箭头指向的是安装失败的错误行”这种需要跨模态语义推理的能力是 OpenClaw 架构里天然缺失的。我们用一个具体场景对比你有一份 Word 笔记第5页是“环境检查”步骤旁边贴着一张终端截图截图里有python --version和which python两条命令的输出。豆包怎么做它会同时读取文字段落和截图像素发现文字说“检查 Python 版本”截图里第一行就是Python 3.9.18第二行是/usr/bin/python于是它能精准生成“【步骤2验证 Python 环境】运行python --version确认输出为 Python 3.9.x 或更高版本见图5运行which python确认路径指向系统 Python见图5。” —— 图文强绑定且不瞎编。OpenClaw即使配 M2.7-VL怎么做它会先尝试把整篇 Word 当作文本解析但 Word 的二进制格式对它来说是黑盒它可能把截图当附件上传但框架没有内置“将附件 ID 与文中‘见图5’字样自动关联”的逻辑最终它大概率会输出“请确保 Python 版本大于 3.8”然后随便配一张网上搜的 Python logo 图——因为它的“图文关联”模块根本没被设计出来。这就是架构差异的本质豆包是“一体式”多模态视觉、文本、文档解析能力在同一个模型里深度耦合OpenClaw 是“分体式”框架它把“理解”和“执行”拆成两个世界中间靠人工定义的指令桥接。你不能指望一个专攻“执行”的框架突然具备“理解”的天赋。2.3 三个高频踩坑点你以为在调参其实是在挑战物理定律基于上面两层分析我整理了新手最容易反复栽跟头的三个点每一个都对应一次我熬到凌晨三点的崩溃时刻坑点一把“产品线多模态”误解为“单模型多模态”现象看到 MiniMax 官网写着“全系列支持多模态”就默认 M2.7 也能看图。真相官网说的是“我们有多个模型覆盖多模态需求”不是“一个模型支持多种模态”。这就像汽车厂商说“我们有轿车、SUV、MPV”不等于你买一辆轿车它就能自动变成越野车。解决方案每次配置模型前强制自己念一遍模型全名听到 “-VL” 才算过关。坑点二迷信“OCR 插件能补足视觉短板”现象给 OpenClaw 装了各种 OCR 技能以为能识别截图文字就能反推图片内容。真相OCR 只能告诉你“图里有什么字”但无法回答“这些字在文档里对应哪个步骤”。比如截图里有pip install -r requirements.txtOCR 能识别出这串字符但它不知道这句话是出现在“安装依赖”步骤里还是“更新依赖”步骤里。这需要上下文语义理解而 OCR 是纯视觉层工具不带 NLP 能力。解决方案OCR 只能作为辅助手段用于提取图中关键命令绝不能替代模型级的图文对齐。坑点三用“执行思维”要求“理解任务”现象给 OpenClaw 下指令“根据我的 Word 笔记生成一篇带图的安装教程。”真相这条指令在 OpenClaw 的语义里等价于“你去执行一个叫‘生成教程’的动作”但它没有内置“教程生成器”这个执行单元。它只能执行“调用模型 API”、“写入文件”、“发送消息”这类原子动作。你让它“生成”它只能调用后端模型而模型又看不懂图——于是陷入死循环。解决方案把模糊的“生成”指令拆解成 OpenClaw 能理解的原子动作链比如“1. 调用豆包 API传入 Word 文件获取结构化 Markdown2. 将 Markdown 保存为 temp.md3. 调用 M2.7 模型对 temp.md 进行扩写4. 将扩写后的内容输出。”这三个坑本质都是混淆了“能力归属”。模型负责“能不能”框架负责“会不会”而人必须负责“知不知”。3. 可落地的三套方案从手动保底到半自动提效3.1 方案一纯手动保底法推荐给所有新手零风险100% 可控这是我在教第一批小白学员时强制要求他们用的方案。不依赖任何模型升级不折腾 API 配置用最原始但最可靠的方式把“图文强绑定”这件事牢牢掌握在自己手里。核心思想就一句话让 OpenClaw 只做它最擅长的事——排版文字图片插入由人来完成。第一步给所有截图编号并写语义标签不要简单标“图1、图2”要写成“图1-环境检查终端输出”、“图2-pip install 命令执行界面”、“图3-OpenClaw 启动成功日志”。这里的关键词是“语义标签”它不是给龙虾看的是给你自己看的。当你写到“图3-OpenClaw 启动成功日志”时你大脑里已经预演了这张图该放在文章哪个段落。我习惯用 Excel 表格管理列名是截图文件名、对应步骤编号、语义标签、在 Word 中的页码。这样后续核对时5 秒就能定位。第二步用豆包生成带占位符的结构化文本把带编号的 Word 笔记发给豆包指令必须精确到标点“你是一名资深技术文档工程师。请严格基于我提供的 Word 笔记内容生成一篇面向初学者的 OpenClaw 安装教程。要求1. 保留所有原始命令一字不改2. 每个操作步骤后插入【此处插入 图X-语义标签】占位符X 为截图编号语义标签必须与我 Excel 表中完全一致3. 不添加任何额外解释、不自行补充步骤、不替换命令4. 输出纯 Markdown 格式不带任何 HTML 标签。”豆包的响应会非常干净比如## 2. 安装 OpenClaw 依赖 运行以下命令安装必要依赖 bash pip install openclaw0.8.2等待安装完成终端显示绿色成功提示。【此处插入 图2-pip install 命令执行界面】**第三步喂给 OpenClaw 并锁定占位符** 把豆包生成的 Markdown 发给 OpenClaw指令要带“法律效力” “请基于以下 Markdown 内容扩写成一篇完整的技术博客。要求1. 严格保留所有【此处插入 图X-语义标签】占位符不得删除、不得修改、不得替换为图片链接2. 扩写仅限于文字内容如增加背景说明、常见问题、注意事项等不得改动原始命令和占位符位置3. 输出为标准 Markdown兼容 GitHub 渲染。” OpenClaw 会老老实实扩写文字占位符原封不动。你拿到的是一篇文字丰满、但图片全是占位符的文章。 **第四步手动替换一气呵成** 打开你的截图文件夹和 OpenClaw 输出的 Markdown 文件用 VS Code 的批量替换功能 - 查找 【此处插入 图1-环境检查终端输出】替换成  - 查找 【此处插入 图2-pip install 命令执行界面】替换成  ……以此类推。 我通常把所有截图按编号放进 ./images/ 文件夹用 fig1.png, fig2.png 命名这样替换时不用想路径。整个过程 5 分钟搞定且 100% 精准因为你是用“人眼语义标签”在做绑定不是靠 AI 猜。 提示这个方案看似“笨”但它是建立信任的第一步。当你亲手完成三次图文绑定你就会形成肌肉记忆哪张图该在哪一步哪种截图容易被 AI 误读比如终端里带滚动条的长截图哪些语义标签写得不够明确比如“图5-成功界面”太模糊应改为“图5-OpenClaw CLI 显示 version 0.8.2 成功”。这种经验是任何模型升级都给不了的。 ### 3.2 方案二模型升级半自动法适合已稳定运行 OpenClaw 的进阶用户 当你已经用方案一跑通了 5 个以上项目对图文绑定规则了然于胸就可以考虑升级到这套方案。它的目标是把“手动替换”环节压缩到最低但依然保留人工核对权。核心是**用真正的 VL 模型做图文理解用 OpenClaw 做执行和排版人只做最终确认。** **第一步确认并切换后端 VL 模型** 登录 OpenClaw 管理后台进入“模型配置”。这里有两个关键检查点 1. 模型名称必须包含 -VL 后缀如 MiniMax-M2.7-VL、GPT-4o、Qwen-VL 2. API Key 必须开通视觉权限。以 MiniMax 为例你需要在 MiniMax 控制台的“API 密钥管理”里勾选 “Vision Model Access” 权限并确保该密钥绑定了正确的模型服务。很多人的失败就卡在这一步——模型选对了但权限没开结果还是报 Model does not support images。 **第二步升级 OpenClaw 到最新版并验证适配** VL 模型的输入格式和纯文本模型不同它需要把图片以特定方式如 base64 编码或 URL和文本一起打包。OpenClaw 旧版本可能不支持这种打包逻辑。务必升级到 v0.9.0 或更高版本截至 2024 年 7 月的最新稳定版。升级后用官方提供的 vl-test.py 脚本做一次验证传入一张本地截图和一句描述看是否能返回准确的图文分析结果。如果报错 Unsupported input format说明框架层还没打通。 **第三步用 VL 模型生成带描述的图文稿** 指令要突出“描述”和“对应” “你是一个专业的技术文档 AI。请分析我提供的 Word 笔记含 34 张截图为每张截图生成一段精准的、不超过 30 字的描述性文字并明确指出它对应的操作步骤编号如‘步骤3安装依赖’。输出格式为【图1】步骤3安装依赖 - 截图显示 pip install openclaw 命令正在执行终端有进度条。【图2】步骤4验证安装 - 截图显示 openclaw --version 命令输出 0.8.2 版本号。” VL 模型会返回一份带编号和描述的清单。你快速扫一眼就能判断它是否理解正确。比如如果它把“图15”描述成“Docker 容器启动日志”而你原图其实是“VS Code 扩展安装界面”那就说明模型对这张图的识别有偏差需要人工修正描述。 **第四步OpenClaw 排版 人工终审** 把 VL 模型生成的“图文描述清单”和豆包生成的“结构化 Markdown”合并在 Markdown 的每个占位符位置插入 VL 模型生成的对应描述。例如 markdown 【此处插入 图2-pip install 命令执行界面】 → 替换为 【图2】步骤2安装依赖 - 截图显示 pip install openclaw 命令正在执行终端有绿色成功提示。然后把这份“带描述的 Markdown”喂给 OpenClaw让它扩写。最终输出里每张图的位置都有精准描述你只需打开原图确认描述是否 match再一键插入。工作量从方案一的“34 次替换”降到“34 次核对”效率提升 70%且错误率趋近于零。注意目前所有 VL 模型对复杂截图如带多窗口、小字体、高对比度的终端仍有识别盲区。我的经验是对关键步骤的截图如报错界面、成功验证界面必须人工校验描述对普通操作界面如点击菜单、打开设置可以接受 90% 的准确率剩余 10% 用方案一兜底。3.3 方案三纯执行流方案适合“只想要结果不想要过程”的极简用户这是我在帮客户做 CI/CD 流水线集成时最常采用的方案。它的哲学是放弃“生成带图文章”这个幻想直奔“执行成功”这个结果。如果你的终极目标是“让 OpenClaw 在服务器上自动装好 OpenClaw”那为什么要纠结它生成的文章配不配图第一步用豆包提炼纯文本执行脚本把 Word 笔记发给豆包指令聚焦“可执行性”“请提取笔记中所有可执行的 Shell 命令、Python 代码、配置文件内容按执行顺序整理成一份纯文本脚本。要求1. 每条命令独占一行2. 在命令前用 # 注释说明其作用如 # 安装 OpenClaw 依赖3. 删除所有解释性文字、截图引用、注意事项4. 输出为 .sh 文件格式首行加 #!/bin/bash。”豆包会输出#!/bin/bash # 安装 OpenClaw 依赖 pip install openclaw0.8.2 # 启动 OpenClaw 服务 openclaw start --port 8080 # 验证服务状态 curl http://localhost:8080/health第二步OpenClaw 直接执行不生成文章把这份.sh脚本喂给 OpenClaw指令极其简单“请在当前服务器环境中逐行执行以下 Shell 脚本。每执行完一行截图终端输出。执行完毕后汇总所有截图生成一份执行报告含时间戳、每步输出、最终状态。”OpenClaw 会老老实实敲命令、等结果、截图、汇总。你拿到的不是一篇“教程”而是一份带时间戳和截图证据的“执行审计报告”。如果某步失败截图里清清楚楚显示报错你直接拿截图去查问题不用再回溯“文章里写的命令对不对”。第三步用执行报告反哺文档把 OpenClaw 生成的“执行审计报告”含真实截图发给豆包指令“请基于这份真实的执行报告含截图和时间戳生成一篇面向小白的安装教程。要求1. 所有命令、截图、报错信息必须与报告完全一致2. 为每张截图添加精准描述3. 对报错步骤补充 1-2 句排查建议。”这时豆包有了“真实世界”的数据生成的教程天然准确且图文严丝合缝。你省去了“从 Word 笔记到真实执行”的 gap整个流程闭环。这套方案的精髓在于承认“生成”和“执行”是两条平行线强行让执行引擎去生成不如让生成引擎为执行服务。它把“避免踩坑”的目标从“防止 AI 出错”转向了“用真实执行数据约束 AI”。4. 实操避坑指南那些只有亲手砸过键盘才懂的经验4.1 Word 截图提取的“隐形陷阱”不是所有截图都能被正确读取你以为把 Word 里的截图复制粘贴出来就行错。Word 对截图的存储有三种模式而 OpenClaw 和大多数 API 只能可靠读取其中一种嵌入式截图Embedded截图直接存为 Word 二进制流的一部分。这是最常见的情况但也是最危险的——当 Word 文件被多次编辑、另存为截图可能被自动压缩、转码甚至降为低分辨率。我遇到过最诡异的一次同一张截图在 Word 里显示清晰但用 Python-docx 库提取时得到的是一张 72dpi 的模糊图VL 模型直接识别失败。链接式截图Linked截图以外部文件形式存在Word 里只存路径。这种模式下如果你移动了 Word 文件而没同步移动截图文件夹API 调用时会返回“文件不存在”错误。OpenClaw 默认不会报这个错而是静默跳过图片导致图文脱节。对象式截图Object截图被当作 OLE 对象嵌入。这种格式对 API 极不友好base64 编码后体积暴增且很多 VL 模型有输入长度限制直接触发Input too long报错。我的实操方案在 Word 里全选所有截图 → 右键 → “另存为图片” → 保存为 PNG 格式无损新建一个文件夹./screenshots/把所有 PNG 按“步骤编号_语义”命名如03-pip_install.png,07-openclaw_start.png在 Word 笔记里把所有截图删掉只保留文字并在对应位置手打文字标记“[图03]”、“[图07]”把./screenshots/文件夹和修改后的 Word 文件一起打包发给豆包或 VL 模型。这个动作多花 3 分钟但能避免 80% 的截图识别失败。因为 PNG 是通用、无损、API 友好的格式而 Word 的二进制截图是给人类看的不是给机器吃的。4.2 占位符的“语法洁癖”一个空格之差就能让 OpenClaw 全盘崩坏OpenClaw 对占位符的解析是基于字符串精确匹配的。我曾经因为一个中文全角空格调试了 4 小时豆包生成的占位符是【此处插入 图1-环境检查】中文全角括号全角空格我手动替换时写成了【此处插入图1-环境检查】漏了全角空格OpenClaw 在扩写时找不到匹配项就把整个字符串当普通文字输出结果文章里赫然出现一行“【此处插入图1-环境检查】”而不是图片。我的占位符黄金法则统一用英文半角符号[FIGURE-1]、[FIGURE-2]不用中文括号不用空格在豆包指令里明确写出占位符格式“请使用[FIGURE-X]格式X 为数字不加空格不加破折号”在 OpenClaw 指令里再次强调“严格保留所有[FIGURE-X]占位符不得修改其大小写、符号、空格”替换时用 VS Code 的“正则表达式替换”查找\[(FIGURE-\d)\]替换为。这样哪怕你有 100 张图也是一键搞定零失误。这个细节听起来琐碎但它决定了你是在享受自动化还是在给自动化当保姆。4.3 VL 模型的“认知盲区”哪些截图它永远读不懂即使你配上了 GPT-4o 或 M2.7-VL也别以为它无所不能。经过上百次测试我发现 VL 模型对以下四类截图识别准确率低于 30%必须人工干预类型一终端里的“滚动截屏”一张截了 20 行命令历史的终端图VL 模型往往只识别出顶部 3 行。因为它把整张图当做一个“视觉块”处理而终端的文本密度太高超出了它的 OCR 上下文窗口。→对策对关键命令单独截取“单行命令单行输出”的小图对长日志用tail -n 20 log.txt命令导出文本让豆包分析文本而非截图。类型二UI 界面里的“动态元素”比如一个正在加载的旋转图标、一个闪烁的光标、一个弹出的 Tooltip 提示框。VL 模型会把它们识别为“未知图形”或直接忽略因为它训练时没见过这么多动态 UI 的变体。→对策截图前先暂停动画如 Chrome 开发者工具里禁用 CSS 动画或用鼠标悬停让 Tooltip 固定显示再截图。类型三代码编辑器里的“语法高亮”VS Code 或 PyCharm 的代码截图不同颜色的关键词import红色、def蓝色会被 VL 模型误认为是“彩色噪点”导致代码块识别错乱。→对策在编辑器设置里临时关闭语法高亮或用纯文本编辑器如 Notepad打开代码截图黑白文本。类型四图表里的“微小文字”一张 Matplotlib 生成的折线图坐标轴标签字号为 8ptVL 模型大概率识别为“模糊线条”而非文字。→对策导出图表时把字体大小设为 14pt 以上或直接提供 CSV 数据让豆包生成文字描述“图中显示 X 轴为时间小时Y 轴为 CPU 使用率%峰值出现在第 5 小时达 92%”。这些不是模型的缺陷而是它的能力边界的诚实体现。接受它然后绕过去比硬刚高效得多。4.4 人机协同的“心理断点”什么时候该果断切回手动自动化最大的敌人不是技术是人的预期。我给自己设了三条“心理断点”一旦触发立刻切回方案一绝不恋战断点一单张图的识别描述与你预期偏差超过 20%比如你原图是“Ubuntu 22.04 终端”VL 模型描述成“CentOS 7 终端”。这说明模型对 OS 特征的识别有系统性偏差继续喂图只会放大错误。此时手动写描述10 秒搞定。断点二连续 3 次同一张图在不同指令下描述完全不同这表明模型对这张图的“语义锚点”不稳定可能是截图质量、光照、压缩导致的。与其猜它这次想说什么不如直接告诉它“这张图请描述为Ubuntu 22.04 终端执行 openclaw --version 命令输出 0.8.2”。断点三为修复一张图花费时间超过 15 分钟自动化的意义是省时间不是制造新负担。我有个铁律任何单点问题debug 时间 15 分钟就立即 halt用方案一的手动方式兜底。因为 15 分钟你已经能手动完成 5 张图的绑定且 100% 正确。这三条断点是我用无数个加班夜换来的。它们不是技术规范而是对“人机协作”这件事的敬畏——机器擅长重复人擅长判断把判断权交给人把重复权交给机器才是可持续的节奏。5. 最后一点个人体会养龙虾养的是耐心不是神兽写完这篇笔记我重新翻了一遍自己最早的 OpenClaw 项目日志。2022 年 3 月我第一次让龙虾帮我跑一个 Selenium 脚本它把“点击登录按钮”执行成了“双击页面空白处”我花了 6 小时查 DOM 结构最后发现是按钮的 class 名里有个空格XPath 没写对。那时候我觉得龙虾真难养。两年过去我依然会遇到它把pip install错写成pip3 install会遇到它把截图配错位置会遇到它在半夜三点给我发一封邮件说“执行失败原因网络超时”。但我不会再对着屏幕骂它笨了。因为我知道它不是神兽它是一台被我亲手组装、调试、喂食的机器。它的每一次“犯错”都在提醒我我的指令还不够精确我的输入还不够干净我对它的能力边界还不够了解。养龙虾本质上是在养自己的工程素养。你得学会读它的日志像读心电图一样你得学会给它喂合适的数据像给婴儿配奶粉一样你得学会在它“闹脾气”时不急着换模型而是先检查自己的输入——是不是 Word 里混进了不可见字符是不是截图路径用了中文是不是占位符少了一个字母所以如果你现在正被一张错位的截图气得想砸键盘停下来泡杯茶打开这篇笔记从方案一开始。不要追求一步到位的全自动先做到“零错误的手动”再追求“90% 准确的半自动”最后才是“99% 可信的全自动”。这个渐进的过程比那个完美的结果更能让你成长为一个真正懂自动化的人。毕竟所有能跑通的自动化背后都站着一个愿意为一张截图较真半小时的人。