龙虾养殖从开始到崩溃–一个零基础牛马的OpenClaw踩坑指南

前言：背（fei）景（hua）

欢迎观赏零基础牛马的OpenClaw踩坑记录并发出爆笑

我，作为一个完全没有计算机背景、百分之百零基础的大厂牛马，实名感谢公司提供的完全免费的 AI 应用（免费版的 AI 应用居然调用的是 Claude，我司真的我哭死）和部门提供的完全本地化的大模型（没事的，36B 模型也没事的，数据是安全的就好了），不然我也不会如此迅速地走上 AI 办公程度可达 50% 的道路。

所以我决定把白嫖的资产以建议的形式回馈社会——我把这两个月和 OpenClaw 斗智斗勇过程中有价值的信息”蒸馏”成这篇文章，如果恰好你也是纯小白，听惯了养虾养马这些热门词汇但仍然不知如何下手，那么你可以跟着以下内容体验一下我的血和泪。如果让你在心疼我的同时还能给你一些参考，那就真的很值当了。

那么，这篇文章能给你的不是任何技术讲解，而是一个没有技术背景的傻子从零开始摸索到初见成效的真实过程。那些顺利的、踩坑的、让我崩溃的、让我觉得值得的，都在这里了。

一、我现在的配置长什么样

目前我的 AI Agent 配置分工作和个人两条线。

工作条线，主要使用 OpenClaw + 本地大模型处理所有涉及项目信息的任务，同时，使用公司内部的 AI 应用 CatDesk 处理不包含一丝丝项目内容的、需要联网了解信息的任务，但其实它最大的使命是充当 OpenClaw 的监护人——帮我监控并解决 OpenClaw 时不时出现的各种幺蛾子。

比如，最开始我会让 CatDesk 帮我写几个 Skill 并给 OpenClaw 装好，这些是我日常工作中比较重要、数据量较大且相对流程化的步骤；然后我设定了定时任务，让 CatDesk 每天自己去网上找工作领域相关的知识、最新规定和案例，把学到的内容记录在一个固定的地方，要求它每天学习的内容不能和之前重复；之后每隔一段时间我会让 CatDesk 读一下自己的学习笔记，然后让它告诉我当前的skill设计有没有需要进化的地方，有的话帮我更新。

个人这条线，使用 OpenClaw + Kimi（真的便宜，穷鬼上手太友好了），同时用 WorkBuddy 充当 OpenClaw 的监护人。根据我个人的体感，WorkBuddy 免费版使用的模型（具体是什么我还真不知道）和 CatDesk 背后的 Claude 比起来确实是小学鸡，但是我个人的任务相对简单，包括帮我制定学习计划、每天督促学习、准备材料出考题、帮我复盘，或者是帮我整理文章素材和剪视频素材之类的轻量任务，所以擅长处理长文本的 Kimi 对我来说刚刚好。（不想拉踩所以夸一句，WorkBuddy的ppt做的还是很棒的）

郑重声明：这篇文章不是 AI 写的，血泪史必须坚持手搓。

二、AI 应用，用还是不用，这是个怎么用的问题

我觉得这个问题的核心，是你的使用场景对数据安全性的要求有多高，以及你预期的投入产出比。

先确定到底需要用什么

我自己的情况是：所有工作信息不可以离开部门管控，所以部门整体部署的是本地大模型（不收 token 费简直就是人间美好）。这种情况下，大厂发布的各类 AI Agent 产品化封装——也就是我私下叫的”二手虾”——基本都不适用了，因为它们都需要把数据发到外部服务器处理，存在第三方截流信息用于训练自己大模型的可能性。

如果你需要处理的数据保密级别很高，那么原生 OpenClaw 接本地模型，是这种场景下几乎唯一可行的路径。

但如果你的数据安全需求没有高到这个程度，能接受信息”出去转一圈”——发给大模型处理，处理完再返回来——那你完全可以用 OpenClaw然后通过 API 调用你想要的大模型，你甚至同时配好几个不同能力和不同费用级别的大模型供你差遣（这是这条动不动就死给我看的虾最大的优势了），可以根据任务类型和难度手动切换。

这里顺带提一嘴：其实大模型本身没有任何记忆功能，它就是个加工流水线上的机器，你把面粉倒进去，它做成面包送出来，机器里既不保留面包，也不留存面粉。但商业化的大模型公司会不会在后台额外收集数据，我确实没有把握给出明确的结论——如果你对这一点有顾虑，建议认真研究一下。

还有第三种情况：如果你的主要使用场景相关数据并不敏感，其实反而推荐你先去试试大厂封装好的 AI 应用。上手简单，很少出错，你发一句自然语言它就孜孜不倦地给你写 Python 一行一行又一行，情绪价值拉满，经济成本也相对可控。

当你确定了方案，接下来就可以摸摸钱包了

如果你要走 OpenClaw 接 API 这条路，成本是必须提前想清楚的问题。OpenClaw 出了名地”烧 token”，原因在于它没有记忆功能（是的大模型也没有），每一轮对话都是把整个对话框的内容、加上 memory 和 soul 这些固定文档内容打包全部发给大模型，以此来实现表现上的连续性。所以对话越长，文本越长，消耗的 token 就越多，平均 2～3 个中文字符就是1 个 token，费用消耗规模可想而知。

所以在上车之前，值得先想清楚两件事：你的场景是否真的需要原生 OpenClaw，以及你打算选择什么费用级别的模型，这时候如果是自费使用的话可能需要更多的考虑一下投入产出比。

想好了吗？想好了来安装吧

安装这件事，有两条路：一是自己装 Node.js、用命令行全局安装再手动编辑配置文件；二是用 CatDesk 这类集成工具，帮你处理大部分配置。Mac 上整体顺滑，Windows 上麻烦一些——路径里的反斜杠、系统权限、防火墙对本地端口的拦截都是潜在的障碍，不是不能突破，只是很烧耐心。

我的踩坑从装机开始，纯粹是折磨——彼时的我连能用 AI 工具全程代劳这件事都完全不知道（老艺术家坚持手搓 2.0）。我先在 Mac 上手动装了一遍，又在 Windows 上装了一遍，对着命令行一行一行地敲，OpenClaw 怎么用不知道，但常用命令行现在倒是背得滚瓜烂熟。然后突然不知道哪里就开始报错，报错了去搜，搜完改，改完又报错，再搜。

那段时间基本上每天对着电脑十个小时，有九个半小时处于崩溃边缘——不是戏剧性的崩溃，是那种感叹”闲鱼上装机 499 的报价真的不高”的，安静的、持续的、消耗性的崩溃。但其实也就这么磕下来了。

三、最重要的建议！必看！

好了这时候你已经装好了 OpenClaw，那么接下来是最重要的一条建议：绝对！千万！一定！不要把你的 OpenClaw 命名成你喜欢的人或动物或任何你有感情的东西的名字！相信我！

我的虾最开始给它起了个名叫周可可，是一个我超喜欢的IP，超级可爱。后来在它把任务做得一塌糊涂、胡说八道、胡编乱造、说了也不改的时候，我怒火中烧的时候！一想到它可怜兮兮的样子，完全舍不得说硬话！然后，它摆烂，我纵容（我甚至会 CPU 自己怎么可以跟一个程序生气），从而形成完美的恶性循环。

直到后来我幡然醒悟，把它的名字改成了一个我讨厌的人的代称，很好从此骂得异常流畅，毫无心理负担，工作效率直线上升。

这不是玩笑，这是最扎实的生产力建议，答应我好吗好的。

四、废话说完了，可以来观赏我的踩坑表演了

第一类坑：虾说真的是瞎说——它不光会编数据，还能连着骗你三次

之前我让 OpenClaw 帮我分析一个表格里的数据，它给了我一堆头头是道的分析结果（编的！）。我看着有点不对劲，就问它确定吗。它说当然确定（扯淡！）。我说再检查一遍。它说检查过了没问题（它检查了个寂寞）。我说我不信你再看一次。它说我看了我保证这是准确的（我真的不知道要怎样才能把证据甩在它脸上）。崩溃进度直接干到 50%。

后来学习了一些知识以后才知道，这个问题叫幻觉（Hallucination），是所有 AI 目前都暂时没有解决的共性问题。

它不是在故意骗你，而是当它无法真正读懂数据的时候，不会说”我不知道”，而是会用听起来合理的数字把答案”补全”。更要命的是，你让它保证，它就保证，但”保证”对它来说只是语言，和它实际有没有读懂数据是两件完全独立的事。

我的应对方式：当你刚开始和一只虾联合办公的时候，不要一次给它太多步骤的任务。比如你想让它读文件、总结、提取指定信息，不要一句话全说完，而是一步一步来——先说”你去读一下某文档，告诉我你看到什么了”，等它这一步的回答和文件内容没有差异，再给下一个命令。任务细分，每步验证，再往下走，不相信任何口头保证，只相信自己亲眼验证的结果。

此外，幻觉的出现往往是有触发场景的，我自己感受到的有三种情况。

一是催促。OpenClaw 并没有主动报告任务进度的机制，他必须接受一个输入才会说话，所以当它在执行后台任务时我会时不时去询问进度——但它的默认理解是”主人不耐烦了，先给个回复先给个结论”，于是任务完成的优先级反而排到了随便给个什么回应的后面，然后他就开始乱讲。

所以我的解决方案是告诉它：”我只是在确认进度和运行状态，不需要回应我的催促，不论什么时候先把任务做完。”然后让它把这句话写进 memory.md（等于请他刻在他的DNA里），这样的规则建立之后就会好很多。

第二是错误积累。当一个任务的某一步因为环境问题或脚本没写好导致它持续犯错超过三次还没解决，对话框里关于这个问题的错误尝试就会占据比较长的篇幅。还记得前面我们说 OpenClaw 会把上下文打包发给大模型吗，其实大模型的工作机制本质就是词语接龙，通过参数、向量去计算出当前情境下最高概率的下文，如果错误内容占据了太多篇幅，自然会让它越接越错、越来越笨。

那么我遇到这种情况就会重新开一个对话窗口，把之前没完成的任务重新说一遍，亲测有效。因为这时候openclaw打包发给大模型的内容里并不包含那些错误信息，干扰自然就少了。

第三是上下文太长。同一个对话框里内容积累到一定长度，OpenClaw 就开始不把所有信息完全的都发给大模型，而是会先做 context compression，也就是把上下文压缩成概要再发送，那这个过程必然会丢失一些信息。如果丢失的恰好是执行下一步必要的条件，它就会越跑越偏，你会发现它做着做着就忘了最开始设定的要求，答非所问胡编乱造。

所以同一个会话不能太长，切换任务或话题时一定要重开一个会话窗口。

虾说的瞎说还有一个典型场景：它说写了，其实并没有

OpenClaw 有长期记忆机制（很难评这个功能），理论上它可以把重要信息存下来，以后的对话就都还记得。你让它记住某些内容，它会干脆地告诉你”好的，我记住了”。你信了，继续干别的。结果过几天去检查，什么都没有。

这个问题的根源和幻觉一样：它的”说话”和”干活”是两件独立的事。

但是这个表现后面还有一个更隐蔽的问题：就算你逼着他真的写进去了，OpenClaw 的记忆写入默认行为是覆盖而不是追加（咱也不懂这个设定到底是为啥）。你之前存下来的内容，可能因为一次新的写入就消失了，它不会提醒你并且会美滋滋的等你夸奖。

我感觉比较有效的应对方式是：凡是涉及需要长期执行或每个任务都默认要遵守的条件，要明确告诉它”把这些内容写进 memory.md”，同时，它说”写完了”之后一定要让它打开文档检查——写了没有、写了些什么。另外，指令里要明确说”在现有内容基础上追加，不要覆盖”，或者让它先把现有内容读出来，修改后再整体写回去。不然就会像我一样，两周时间设定了好几条长期规定，打开一看，很好，只剩最近的一条，其他全部被覆盖了。

第二类坑：它是画饼大师

它答应的事，你就当它没答应吧

某天你交代了一个多步骤任务，它可乖巧了它跟你说”好的，我会逐步完成，每完成一步给你汇报进度”。然后它开始干了，然后那个承诺过的进度报告从来没出现过，甚至后台任务的结果报告你也要等到天荒地老。

原因很简单还是上面提到的那个逻辑：它生成了”我会汇报进度”这句话，但这句话本身不会触发任何实际的汇报行为。语言是语言，执行是执行，没有强绑定。跟openclaw斗智斗勇就跟玩狼人杀一样，你得“听发言，看投票”。不要相信它任何具有主观能动性的表述，一个字都不要信，那就是纯画饼。

我的做法是把多步任务拆开，每一步让它把结果给我发到对话框，我手动确认完成之后再进行下一步。

复杂任务？不存在的

openclaw有一个神奇的魔法，当它开始执行复杂任务中途遇到小障碍之后，倾向于停下来给你一个“哎呀我觉得绕开这一步也挺好的”这样的建议，吃苦耐劳迎难而上对它来说是不存在的。当你以为它在认真汇报，其实真相是它只是在把球踢回给你。

相当会有效一点的应对方式是，给它前情提要讲解清楚：任务开始前约法三章”遇到小问题自己判断处理，不要停下来问我，除非真的无法继续，或者同一个问题尝试三次还是报错”；任务开始前让它先列出执行计划，确认顺序没问题再开始执行，有了明确的路线图，中途找借口停下来的概率会小很多，而且哪一步卡壳了绕出去解决完问题之后，也比较方面的能跟他描述刚刚的任务进行到哪了该从哪里继续。

第三类坑：它崩溃了，比你崩溃的还早还悄无声息

如果说前两类坑还在可控范围内——它骗你、它敷衍你，那它至少还活着，还在给你回应。这一类是真正让人想掀桌子的情况：任务失控、陷入死循环、资源耗尽、或者直接卡死不动。

很多次，我让 OpenClaw 帮我写一段脚本，然后让它自己运行、自己检查结果、发现问题自己修。然后它开始跑了，然后它一直在跑，然后我发现它已经跑了四十分钟还在跑。去看日志：运行脚本，报错，修改脚本，再运行，再报错，再修改，再运行……每一次循环它都觉得自己在”解决问题”，但它缺乏一个”这条路走不通，应该停下来换个思路”的判断机制。

其实这种情况我好像摸索出来的方案也不是很具有普适性，可能，多去看看日志，不要无限等待，一旦陷入循环，可能只能手动打断了。当然如果你有能力且有耐心，可以看看它重复卡住的部分有没有其他解法，通常出现在他自己写脚本执行脚本的时候，这种情况可以考虑有没有一个简单的skill能直接装给他让它调用，而不是每次都自己写。

跟这种情况类似的还有，当OpenClaw 执行的复杂任务是一个任务链时，A 完成触发 B，B 完成触发 C。中间某一步失败了，它不一定会告诉你——可能悄悄跳过那一步，继续往下走，用不完整的中间结果去执行后续任务。最后给你一个看起来完整、但里面有一块是空的或是错的结果，而你不知道。这比直接报错还难处理，因为你拿到结果之后还得自己一步步核对才能发现哪里断了。唯一的应对方式还是那句话：在任务链关键节点手动介入确认每一步的输出，不要一次性给它需要太多步骤的任务。

最过分的：心跳活着，任务死了

OpenClaw 执行长时间任务时有心跳机制，定期生成一句话发给大模型，用于检查自己的健康状况。因为长时间后台任务时我需要主动询问进度，既麻烦又容易被误解成催促，所以我建了一个每五分钟触发一次的 heartbeat 机制，让它检查当前有没有正在进行的任务，有的话报告进度，结束的话报告结果。怎么说呢，确实有效，但我仍然遇到过心跳信号还在发、任务实际上已经卡死的情况，因为心跳和任务执行是两个独立的进程，心跳活着不代表任务活着（这都能让我遇上）。

所以判断方式不能纯粹只看心跳，还要看任务的实际输出有没有在推进。如果心跳在但输出长时间没有变化，就认为它卡了，直接强制重启任务。宁可重来一次，也不要在一个已经死掉的任务上继续等。

后记：差不多就折磨我到这里吧

好了，血泪史差不多没有了（也不能再多了，再多就是我真的崩溃了）。那么这经历了这些挫败、了解了 OpenClaw 和大模型的工作原理之后，现在碰到任务不顺畅的情况已经很少了，磨合有效，深感欣慰。

用了两个月OpenClaw，踩了这么多坑，它让我崩溃过，让我血压飙升过，让我对着屏幕发呆不知道它到底在干什么。但建立了合理的规则之后，它也真的帮我做了很多事情。

我现在对它的理解是：一个能力很强、很强很强，但需要你主动学习如何使用的工具。

但是目前它还不是一个可以彻底放手、用自然语言沟通就能给你想要答案的自动化系统，而是一个需要你盯着、需要你验证、需要你教育和培养、以及需要你在它卡住的时候拉它一把的协作伙伴。这个定位接受了之后，很多坑也就不那么让人崩溃了。因为你不再期待它自己把所有事情都做对，你只是期待它在你的管理下把事情做好。这两种期待，体验差别很大。

希望这篇文章对同样在摸索的你有一点参考价值。（希望踩坑记录不要再有下一期了）