OpenClaw（小龙虾）答疑课干货整理：真正该掌握的，不是“会不会用”，而是“怎么把它用顺”

最近听完一场关于 OpenClaw（小龙虾）的答疑课，我最大的感受不是“这个工具功能好多”，而是：很多人其实不是不会用 AI，而是不会把 AI 放进一条完整的工作链路里。

大家提的问题五花八门：
有问微信机器人能不能搭的，有问能不能做网页、小程序的，有问模型怎么选的，有问本地文件怎么读的，也有问飞书怎么接、知识管理怎么做、多个对话怎么整理的。

表面看是零散问题，底层其实就几件事：

第一，小龙虾到底适合干什么。
第二，怎么避免把它用成一个“聊天玩具”。
第三，怎么把它真正嵌进自己的业务流和工作流里。

这篇文章，我就按“少废话、重结论、重落地”的方式，给你捋清楚。

---

一、小龙虾最容易被误解的地方：它不是单点工具，而是一个工作台

很多人第一次用小龙虾，会把它当成“另一个聊天框”。
但如果只这么理解，基本就浪费了它一半以上的价值。

小龙虾真正强的，不是单轮问答本身，而是它可以围绕一个任务，逐步串起：

• 对话

• Skill 调用

• 本地文件读取

• 网页生成

• 浏览器操作

• 子 agent 协同

• 定时任务

• 多模型配合

也就是说，它更像一个可持续工作的 AI 工作台，不是一个纯聊天机器人。

答疑里有个很重要的点：单个对话里其实可以同时调用多个不同 skill。
这意味着你完全可以在同一个任务上下文里，让它边看资料、边生成内容、边调用工具，而不是每干一步就换一个系统。

但这里也有一个认知误区：
虽然技术上可以混着用，不代表你在使用习惯上也应该混乱。

更高效的做法是：
一个对话尽量只承载一类任务。

比如：

• 一个对话专门写公众号

• 一个对话专门做经营分析

• 一个对话专门处理小红书选题

• 一个对话专门做网页或 H5 调试

这样做不是因为系统强制要求，而是因为人脑管理上下文的成本比系统切换成本更高。

很多人觉得“AI 越自由越好”，但真实情况恰恰相反：
你给 AI 的任务边界越清楚，它越容易稳定输出。

---

二、关于“对话管理”：别把历史记录丢了，也别把任务搅乱了

很多人用小龙虾会有一种挫败感：
“我明明新建了一个对话，为什么找不到？”
“我刚才的内容是不是丢了？”
“左上角怎么没刷新？”

这类问题，本质不是能力问题，是产品使用习惯问题。

答疑里讲得很明确：

• 新建后如果没真正开始对话，可能不会立刻出现在列表里

• 有时标签刷新有延迟，但并不影响实际保存

• 找不到旧对话时，去左侧列表按时间排序找

这些听起来像“小问题”，但它们会直接影响你的使用信心。
因为一旦用户对“记录是否保存”没有安全感，就不敢把重要任务放进来长期做。

所以，一个很实用的建议是：

建立你自己的“小龙虾任务归档规则”

比如你可以固定这么分：

1. 按任务类型分

• 写作类

• 代码类

• 知识整理类

• 网页/H5类

• 自动化类

2. 按业务项目分

• 客户A

• 客户B

• 课程内容

• 自媒体内容

• 产品规划

3. 按输出阶段分

• 收集资料

• 初稿整理

• 深度加工

• 定稿发布

这样做的好处很直接：
你不是在“找聊天记录”，而是在“管理工作资产”。

这两者差别很大。
前者是被动找回，后者是主动沉淀。

---

三、关于模型选择：OpenAI 负责“想”，Codex 更偏向“做”

答疑里还有一个非常关键、也非常实用的判断：

OpenAI 更适合文本推理和文案生成。
OpenAI Codex 更适合写代码和本地工具调用。
一句话概括就是：

OpenAI 想得多，Codex 做得多。

这句话很值钱，因为很多人选模型，全靠感觉。
结果就是：明明是要写代码，却选了更偏长文本表达的模型；
明明是要做分析和写文案，却选了偏执行型的模型。

更合理的方式是这样分：

适合用 OpenAI 的场景

• 写文章

• 改文案

• 做分析

• 提炼观点

• 梳理框架

• 角色扮演式推演

• 复杂问题解释

适合用 Codex 的场景

• 写网页代码

• 改脚本

• 做工具调用

• 与本地环境交互

• 自动化编排

• Debug

如果你是新手，还有一个建议也很重要：
优先用官方模型，不要一开始就折腾非官方集成模型。

因为非官方模型常见问题不是“能力不够”，而是：

• 稳定性差

• 接口偶发异常

• 行为不一致

• UI 或能力映射不完整

这对老手可能还能忍，但对新手来说，最致命的是：
你分不清到底是你不会用，还是模型接得不对。

所以前期别给自己增加诊断成本。
先跑通，再优化。

---

四、关于本地文件读取：真正高效的方法，不是上传，而是直接读文件夹

这一条，几乎是整场答疑里最有价值的实操点之一。

很多人习惯性认为：
“我要让 AI 处理文件，就得上传。”

但答疑里给出的建议很明确：
尽量不要上传文件，而是把文件直接放到本地文件夹，让小龙虾去读本地目录。

这个方法好处很多：

1. 规避上传限制

大文件、多个文件、重复上传，都会消耗时间和精力。

2. 保护本地数据

很多人选择本地化工具，本来就是因为不希望资料反复上传外流。

3. 更适合批量处理

你可以把一批资料统一放进目录，然后让它做读取、整理、归类、提炼。

4. 更接近真实工作流

真实工作中，资料本来就散落在本地文件夹里，不可能每次手动上传一遍。

但这里还有一个很现实的问题：
不是所有格式都一样好读。

答疑里给出的经验很实在：

• PPT：尽量转 PDF

• Word：尽量转 TXT 或纯文本

• PDF：通常最稳

原因很简单。PDF 是公开标准，兼容性普遍更好；
而 Word、PPT 这些格式，常常会受不同软件版本、排版结构、嵌入对象影响，导致读取不稳定。

所以别在“为什么它读我这个 PPT 有点怪”这种问题上死磕。
更高效的思路是：

先把输入格式标准化，再让 AI 干活。

谁能把输入端整理好，谁就比别人更容易把 AI 用顺。

---

五、关于知识管理：既然有大模型，就别再手工贴一堆标签了

很多人用 AI 做资料整理时，还停留在传统知识管理思路里：

• 我要不要建很多标签？

• 要不要手工分类？

• 要不要一个个文件夹细分？

这套方法不能说完全没用，但在大模型时代，确实可以换个思路了。

答疑里的观点非常直接：
既然已经有了大语言模型，很多分类、关联、归纳，本来就应该交给 AI。

这背后不是偷懒，而是分工逻辑变了。

以前人工贴标签，是因为机器理解能力不够；
现在模型已经具备较强的语义聚类和关系抽取能力，你再靠人工做大量基础归类，边际收益就很低。

更推荐的做法是：

1. 先把资料集中放到同一个本地目录

不要急着细分到过度复杂。

2. 让 AI 先做一轮自动分类

按主题、项目、时间、来源、重要程度去归纳。

3. 输出成结构化成果

比如：

• HTML 网页

• 知识图谱页面

• 主题索引页

• 文献综述式笔记

4. 最后再做人工校正

把高价值的信息节点固定下来。

这套思路的重点是：
人负责判断和定方向，AI 负责搬运、归类、连接。

答疑里还提到一个很实用的方向：
可以参考论文写作的方法，把不同来源的观点做引用和标注，再整理成关联结构。
这个思路特别适合做：

• 行业研究

• 课程资料整合

• 客户需求归档

• 项目复盘

• 多轮对话内容沉淀

如果再往前走一步，输出成 HTML 页面，比普通文档更适合查看复杂关系。
因为网页可以做节点跳转、层级展开、关系可视化，尤其适合“资料很多、关系复杂”的场景。

---

六、关于建网页、做 H5：真正难的不是生成，而是部署上线

很多人被 AI 生成网页震撼，其实这只是第一步。

答疑里把这个问题说得很透：
生成网页本身不难，真正难的是最后把它部署上线，让别人能访问。

这句话很关键。
因为很多 AI 工具的问题就在于：
它很会生成，但不负责闭环。

而真正想把东西做出来的人，不能只盯着“生成效果”，要盯着完整链路：

• 需求描述

• 代码生成

• 本地调试

• 上传服务器

• 域名解析

• 备案

• 访问测试

• 后续迭代

答疑中提到，用 FileZilla 这类 FTP 工具把本地网页上传到服务器，就是一个非常实用、很接地气的方案。
不花哨，但有效。

这里最值得记住的，不是某个软件名，而是一个执行原则：

不要一直在本地想象问题，先上线，再针对真实问题逐个修。

这是做产品的人和只会讨论的人之间最大的区别。
很多项目死掉，不是因为做不出来，而是因为永远停留在“本地再改改”。

---

七、关于备案、小程序、服务器：你想赚谁的钱，就要适应谁的规则

答疑里有一句很狠但很真实的话，大意是：

如果你想赚国内用户的钱，那国内这套规则你就得提前解决。

这背后主要包括几件事：

1. 国内服务器通常要做ICP备案

不管个人还是公司，都可以备案。
麻烦归麻烦，但这一步绕不过。

2. 微信小程序如果涉及 AI，可能还要面临额外要求

比普通 H5 更复杂。

3. 海外服务器虽然省备案，但会带来别的问题

比如：

• 国内访问速度可能慢

• 微信内打开可能有安全提示

• 用户体验打折扣

所以，如果你的目标就是服务中文用户、做国内转化，那最现实的建议通常就是：

老老实实把国内部署链路走通。

这听起来不性感，但它是经营层面的正确动作。
很多人老想着“有没有更省事的办法”，其实是在逃避基础设施建设。

---

八、关于微信机器人：别把它想得太简单，也别低估成本

答疑中关于微信群 AI 小助手的部分，信息量很大。

结论先说：

微信接入不是不能做，但绝对不是普通人随手就能低成本稳定搭出来的。

课程里提到，市面上很多公开方案都被封了，而现有稳定方案之所以能跑，是因为背后有人长期维护，而且成本不低，基础年费就已经不便宜。

这对很多人是个提醒：

你不要被互联网上那些“几分钟搞定微信机器人”的宣传带偏。
很多东西不是不能演示，而是难以长期稳定商用。

真正要问的不是：

“有没有办法接上微信？”

而是：

• 稳不稳定？

• 封号风险高不高？

• 维护成本谁承担？

• 能不能长期可用？

• 是演示级方案还是业务级方案？

这就是工具思维和业务思维的区别。
前者只看“能不能跑通”，后者看“能不能长期跑”。

---

九、关于飞书集成：这是更现实、更适合团队化协作的方向

和微信相比，飞书的接入和协作场景明显更友好。

答疑里的路径也很清楚：

• 在飞书后台创建机器人

• 创建独立群聊

• 把机器人加到群里

• 拿到会话 ID

• 在小龙虾里给对应子 agent 绑定

这样做的好处是：

1. 可以按功能拆分群聊

比如：

• 内容群

• 数据分析群

• 客户支持群

• 项目推进群

2. 可以让不同 agent 干不同任务

比全塞进一个入口清晰得多。

3. 更适合多人共享

尤其团队内协作，飞书天然比个人微信方案更容易管理。

但这里也有一个必须注意的点：
默认小龙虾更偏个人使用，多人共用一定要提前设规则。

尤其敏感信息、权限边界、回复范围这些事，必须先定规矩。
否则工具越强，越容易在组织内部制造新的风险。

---

十、最值得记住的一条方法论：别在原地讨论假想问题，先往目标方向走

整场答疑里，我觉得最有穿透力的一句话是这个意思：

先往目标方向走，走的过程中出现什么问题，再解决什么问题。不要一直在原地讨论假想问题。

这句话不只是小龙虾使用方法，它其实是所有 AI 落地的核心方法论。

很多人学 AI，最大的问题不是学不会，而是：

• 迟迟不开始

• 永远在比较工具

• 一直担心后面会不会有坑

• 没上线就开始假想各种异常

• 没做项目就想把架构设计到极致

结果就是：
看起来研究了很多，实际上没有形成任何产出闭环。

而真正能把小龙虾用起来的人，通常都具备一种很朴素的能力：

先跑通一条最小闭环。

比如：

• 先让它读一个文件夹

• 先让它整理一批 PDF

• 先做一个最简单的 H5 页面

• 先把一个 agent 接进飞书群

• 先把一个固定业务场景跑顺

当你真的跑通一个闭环后，很多问题根本不需要问了。
因为你会在真实使用中自然知道哪里要补、哪里该改、哪里值得投入。

---

结语：真正厉害的，不是“会用小龙虾的人”，而是“能把小龙虾接进业务里的人”

最后把这场答疑课浓缩成一句话：

小龙虾的价值，不在于它能回答你多少问题，而在于它能不能成为你工作链路里稳定的一环。

如果只是偶尔聊两句，它当然也能用。
但那样，你得到的只是一个“还不错的 AI”。

只有当你开始把它用于：

• 文件整理

• 内容生产

• 知识沉淀

• 网页生成

• 团队协作

• agent 拆分

• 本地工作流

它才真正从一个聊天工具，变成一个能帮你持续产出的系统。

所以，别再问“这个工具到底厉不厉害”。
更该问的是：

你有没有把自己的任务拆清楚？
你有没有给它稳定的输入和边界？
你有没有跑通一条真实闭环？

谁先做到这三件事，谁就会比别人更早感受到小龙虾真正的威力。