和龙虾协作的基本方式

Posted on In
了解龙虾的角色定位、双区工作方式、三阶执行流程，以及怎么说需求它才能听懂。

系列目录

和龙虾协作的基本方式

一、前言

上篇把安装说完了，这篇聊点更重要的——怎么用。

很多人第一次用龙虾，习惯性地把它当搜索引擎使唤：”帮我查一下这个技术方案”、”介绍一下 React”，然后得到一堆文字回复，觉得不过如此。

这不是龙虾的正确打开方式。

它不是来回答问题的，它是来帮你做事的。这一个本质区别，决定了你和它协作的方式完全不一样。

二、OpenClaw 的整体架构

在使用龙虾之前，理解它是怎么组织的会让你用起来更顺手。第一篇里有一张简略的系统架构拓扑图，这篇把每个模块拆开说清楚。

📌 第一篇也有简略介绍：龙虾的安装与初始化 - 系统架构拓扑图

这篇先介绍我们的协作框架（意图识别体系），再拆开讲 OpenClaw 的四大模块。

2.1 意图识别体系

它是怎么工作的：利用龙虾自身的能力 + 我们约定的协作规范

龙虾天然具备三种能力：理解用户意图、拆解成计划任务、调用工具链。我们做的事情，是在 AGENTS.md 和 MEMORY.md 里约定一套规则，把它的这些能力引导到我们设定的工作流程里。

具体来说：

约定一：按意图分流

龙虾收到需求后，先判断你的意图是临时性的还是项目性的：

  • 临时意图（查个问题、写段代码、用完就走）→ 触发临时区，龙虾直接给结果，不留文档
  • 项目意图（要搭一个系统、分阶段推进、需要记忆上下文）→ 导航到项目区，走设计→执行→沉淀流程

判断依据是文件路径：~/projects/ 下的操作默认项目区，~/.openclaw/workspace/ 下的系统文件操作默认临时区。

约定二：任务分流

判断完区之后，龙虾再决定怎么处理这个任务：

任务特征 处理方式
耗时操作（构建、部署、CI/CD） 派生子任务，不占用主会话
多文件并行改动 派生子任务，主会话保持简洁
3步内的简单任务 主 agent 直接执行
需要你来拍板的决策 主 agent 停下，确认再继续

约定三：工具链分发

最后，根据需求里的关键词，龙虾调用对应的 Skill：

需求关键词 调用的工具
「同步到飞书」「读写飞书文档」 feishu_doc/wiki/drive
「创建仓库」「查看 CI 状态」 github/gh
「查天气」 weather
「派生子任务」「管理任务」 taskflow
其他日常需求 Agent 自身能力

整个流程不是，龙虾自己在猜，而是我们的约定在引导它的行为。约定写在 AGENTS.md 里，龙虾每次启动时读一遍，就知道该怎么处理你的需求了。

2.2 Skills 系统

Skills 是龙虾的能力模块，装了就能解锁新功能：

  • feishu-doc/wiki/drive — 读写飞书文档和知识库
  • github/gh — 操作 GitHub 仓库、issue、PR
  • weather — 查天气
  • taskflow — 管理工作流和子任务

安装方式：openclaw skill install 技能名
查看已安装：openclaw skill list

更多技能在 clawhub.ai

官方能力 vs 我们的场景

官方 Skill 列表在 clawhub.ai，任何人都可以发布。我们重度依赖这些技能：

技能 我们怎么用
feishu-doc/wiki/drive 所有文档同步飞书知识库
github/gh 管理 GitHub 仓库、创建 issue、查看 CI 状态
weather 偶尔查天气
taskflow 管理工作流和子任务

我们还通过 OpenClaw 的 Skill 机制配置了 Git 双端推送、飞书消息通道等。

2.3 Subagents（子任务）

当一个任务耗时或可以并行时，龙虾会派生子任务独立执行，完成后自动汇报结果。子任务不占用主会话，适合：构建、部署、CI/CD 等。

官方能力 vs 我们的场景

官方建议：耗时任务、并行任务用子任务。我们在项目区里把所有复杂任务都派生子任务：

任务类型 处理方式
3步内的简单任务 主 agent 直接执行
耗时的构建/部署 派生子任务
涉及多文件改动 派生子任务，避免主会话过于冗长

子任务完成后自动汇报结果，我们不用盯着。

2.4 Memory 记忆系统

  • 每日 memory：每次会话结束后，龙虾把重要内容写入 memory/YYYY-MM-DD.md，作为短期记忆
  • 长期记忆：重要内容定期提炼到 MEMORY.md，作为跨会话的持久记忆

官方能力 vs 我们的场景

官方定义：会话结束后内容消失，仅通过文件恢复。

我们把它设计成两层记忆体系：

记忆层 存储位置 更新时机 内容
短期记忆 memory/YYYY-MM-DD.md 每次会话结束 当天做了什么决策、变了什么
长期记忆 MEMORY.md 定期提炼 项目清单、协作规范、关键配置

这套体系保证：即使龙虾某次上下文丢了，文件里还有完整的上下文可以恢复。

2.5 Gateway 路由层

Gateway 是消息进出的大门：

1
即时通讯消息 → Gateway → Agent（处理）→ Skills/Workspace/Subagents → 结果 → Gateway → 即时通讯/外部

配置在 ~/.openclaw/ 下的 openclaw.json，包括：AI 模型参数、飞书凭证、消息通道、插件配置等。

官方能力 vs 我们的场景

官方定义：Gateway 是消息路由层，负责接收消息、分发技能、返回结果。配置文件 openclaw.json 管理所有参数。

我们用它管理这些配置：

配置项 我们怎么用
消息通道 飞书（主要）、webchat（备用）
AI 模型 MiniMax M2（日常）、Claude（复杂任务）
定时任务 每天 10:00 变更汇报、HEARTBEAT 定期检查
插件配置 GitHub CI/CD 触发通知等

Gateway 重启命令：openclaw gateway restart，改了配置后要执行这步才生效。

2.6 入口：用户怎么触达这些能力

上面四大模块（Skills、Subagents、Memory、Gateway）和意图识别体系，都需要通过用户入口才能被触发。入口即用户和龙虾交互的渠道，以下是 OpenClaw 支持的几种主要入口：

即时通讯消息 — 日常主力入口，对接各类 IM 软件（飞书、QQ、企业微信等），发消息即可触达所有能力：

  • 通过意图识别，自动分流到临时区或项目区
  • 调用 Skills（读写飞书文档、管理 GitHub）
  • 派生子任务处理耗时操作
  • 读写 Memory 文件，记忆上下文

命令行 — 触达系统级操作：

  • openclaw skill install <技能名> — 安装技能
  • openclaw skill list — 查看已安装技能
  • openclaw config — 调整配置
  • openclaw gateway restart — 重启服务使配置生效

Web 管理后台（http://127.0.0.1:18789/）— 触达监控和调试能力：

  • 查看运行状态和配置
  • 调试日志输出
  • 技能管理和配置查看

心跳定时（cron） — 自动触发的后台入口：

  • 每日 10:00 推送昨日变更汇报
  • 定期检查会话变更并更新 MEMORY.md

这四种入口覆盖了从日常对话到系统管理的全部场景。即时通讯是日常主力，命令行和 Web 后台是管理入口，心跳是无人值守时的自动触发入口。

三、龙虾的角色定位：不是搜索引擎，是执行者

搜索引擎的逻辑是：你问，它答，结束。

执行者的逻辑是：你交代一件事，它想办法把它做完。

举个例子。你说”帮我了解一下 OpenClaw”，一个搜索引擎会给你一段介绍。龙虾会怎么做？它可能会直接去读你的配置文件、看看你装了哪些技能、查一下项目状态，然后告诉你”我看了下，你现在基本配好了，就是飞书还没连，要不要现在连？”

看到了吗？它不是在回答问题，它是在推进事情。

这个定位很重要。想明白这一点，你和龙虾的对话质量会完全不一样。

它适合做什么：

  • 读代码、改代码、跑命令
  • 帮你规划一个项目怎么搭
  • 帮你写文档、整理文档、推送文档
  • 帮你做决策分析，列选项
  • 帮你记住上下文，下次接着干

它不是拿来做什么的：

  • 闲聊天气（虽然它能聊）
  • 当翻译工具（可以用，但有点浪费）
  • 问它”在吗”（直接说事就行）

你把它当执行者用，它才能发挥真正的价值。

四、协作框架：临时区 vs 项目区

龙虾本身不强制规定你怎么组织工作，但我在实际使用中设计了一套协作框架，用来解决三类常见问题：

  • 临时任务和长期项目混在一起，容易丢
  • 复杂任务不知道从哪下手，容易卡
  • 做完之后下次又得从头开始，容易忘

这套框架包括「双区工作方式」和「三阶执行流程」。不是 OpenClaw 自带的，是我自己琢磨出来的用法，但它让龙虾帮我做事的能力真正释放出来了。

4.0 为什么要区分临时区和项目区？

这里有个关键问题：龙虾本质上是个无记忆的会话。

每次对话结束，它不会记得你上次讨论了什么、你做了什么决定、你做到了哪一步。下次开始新的对话，它就是一个全新的龙虾。

这不是 bug，是设计如此。

所以如果你把所有事情都放在「临时区」逻辑里做——每次说完事就结束——龙虾永远只能帮你做单次任务，不能帮你推进一个多天的项目。

项目区的本质，是给龙虾一个「记忆锚点」。

当你告诉它「这个项目是 ai-blog」，它会把这个信息写入 MEMORY.md、工作区配置文件、或者项目文档里。下次对话时，即使上下文丢了，只要它读到这些文件，就能恢复项目的上下文，继续往下走。

换句话说：

  • 临时区：适合不需要龙虾记住的事，它快速响应，用完即走
  • 项目区：适合需要龙虾长期记忆的事，它读文件恢复上下文，一步步推进

这套双区框架，弥补的是 OpenClaw 原生的两个局限：

局限1：会话无法自动保留上下文

解决方案：项目区强制要求文档化（MEMORY.md、设计文档、变更日志），让文件成为龙虾的外部记忆

局限2：没有任务阶段的概念

解决方案：三阶执行流程（规划→执行→沉淀）给龙虾一个可遵循的工作节奏，避免它一拿到需求就闷头开始做

这两个局限如果不解决，龙虾就只能是个「聪明的问答机器」；解决了，它才能成为真正的「工作搭档」。

4.1 临时区 vs 项目区

临时区

临时区是一次性的地方。你扔进来一个问题，它处理完，结束。

适合的场景：

  • 突然有个技术问题想查一下
  • 想让龙虾帮你写一小段代码，用完就走
  • 临时性的分析、翻译、润色任务

自动触发条件：

涉及非项目目录（~/.openclaw/workspace/下系统文件、/tmp/等）的文件读写，或者3步以内可完成的简单需求。

在临时区里，龙虾没有上下文记忆，它不知道你之前在做什么项目、不记得你上次聊了什么。它只知道你这次告诉它的东西。

用临时区做事，就像打一枪换一个地方。高效，但不留痕迹。

意图识别示例：

你的表达 识别结果 处理方式
“帮我查一下这个配置对不对” 临时区 直接给结果
“帮我算一下这个公式” 临时区 直接给结果
“帮我改一下这个文件” 临时区 直接改，不生成文档
“帮我写个正则表达式” 临时区 直接给，用完即走

项目区

项目区是持久的地方。你告诉龙虾”这个文件夹是我的项目”，它会一直记着。

适合的场景：

  • 长期跟进的项目，要分多个阶段做
  • 代码仓库管理，需要上下文连续性
  • 需要龙虾记住你的偏好、你的技术栈、你的工作习惯

自动触发条件：

涉及 ~/projects/ 或 ~/.openclaw/workspace/projects/ 目录下文件的读写，或者需要多轮迭代、需要文档、需要以后复用的任务。

在项目区里，龙虾知道你在做什么、做到哪一步了、下一步该干什么。它能帮你规划、执行、沉淀，能记住你上次为什么选了这个方案。

用项目区做事，像是有了一个不会健忘的搭档。

意图识别示例：

你的表达 识别结果 处理方式
“帮我做一个新闻推荐系统” 项目区 先出设计文档，再执行
“把这个项目同步到飞书” 项目区 走设计→确认→执行流程
“构建一个自动化流程” 项目区 先规划，再派子任务
“长期跟进这个需求” 项目区 建立项目上下文

什么时候用哪个

给你一个简单的判断标准：

这件事做完之后，下次还需要继续吗？

需要 → 项目区
不需要 → 临时区

比如你想让龙虾帮你分析某个开源项目的结构，这是一次性的研究，用临时区。但如果你在做自己的博客，要分几次迭代开发，那就是项目区。

还有一种情况：你一开始不确定这件事会不会继续，那就先用临时区试一下，发现要做下去了，再切到项目区。不用一上来就建项目区，但也不要一直用临时区拖着。

五、三阶执行流程：规划 → 执行 → 沉淀

龙虾帮你做事，最好有个节奏感。我自己总结了一套三阶流程，用下来觉得挺顺的。

5.1 第一阶：规划

动手之前，先让它说说打算怎么做。

你扔一个需求给它，不要让它直接动手，而是先问：”这个你觉得怎么实现？”或者”如果要达成这个目标，大概要分哪几步？”

龙虾会给你一个实现方案。你可以认可、修改、或者提异议。这一步的目的，是让双方对”做什么”达成共识。

为什么要先规划？因为龙虾虽然执行力强，但它不像你一样脑子里有完整的上下文。你可能觉得方案A理所当然，但它不一定知道你的约束条件。规划这一步，就是把上下文补齐。

5.2 第二阶：执行

规划确认了，接下来让它动手。

这个阶段让它自己做就行。你可以问进展，但不要一边盯着它一边指手画脚。龙虾执行任务的时候，你干预得越多，它越容易卡住。

给它足够的时间和环境，让它把事情做完。如果中途出了问题，它会主动停下来问你。这时候再介入，讨论清楚，再让它继续。

5.3 第三阶：沉淀

做完事情不等于结束。

好的工作方式，是让龙虾把重要的东西记下来。比如：

  • “把这个项目的技术选型记录到 MEMORY.md 里”
  • “把这次的决策结论写到项目文档中”
  • “把这个方案的关键点同步到飞书知识库”

沉淀这一步，是为了让下一次你们合作的时候，它还能记得之前发生了什么。没有沉淀，下一次就得从头开始；有了沉淀，它能真正成为一个了解你项目的搭档。

三阶流程不需要每次都完整走完。有时候一个任务很小，规划、执行两步就结束了。但当事情复杂、周期长的时候，这套流程能帮你保持节奏感。

六、协作话术示例：怎么说需求

和龙虾协作，说需求的方式很重要。同样一件事，说法不同，结果可能完全不一样。

6.1 例子一：模糊需求 vs 清晰需求

模糊说法：

“帮我看看这个项目有什么问题”

龙虾可能会给你一段泛泛的分析，像是代码审查报告，但实际上它不知道你在意什么问题。是性能问题？是代码风格问题？还是业务逻辑问题？

清晰说法：

“这个项目现在访问速度慢，帮我排查一下性能瓶颈，重点看数据库查询和缓存这两块”

这个说法告诉了龙虾：问题是什么（访问慢）、要查什么（性能瓶颈）、范围是什么（数据库和缓存）。龙虾会直接切入重点，而不是给你一段通用分析。

6.2 例子二：给约束条件

不给约束：

“帮我写一个新闻推荐系统”

龙虾可能会给你搭一个功能完整但技术栈完全不是你想要的系统，或者写得过于复杂用不上。

给约束：

“帮我写一个新闻推荐系统，用 Node.js + Express，数据存本地 JSON 文件就行，不需要上数据库，代码要简洁能看懂，后面我自己改”

这样它就知道：用什么语言和框架、数据怎么存、技术栈简单优先、代码可读性重要。给你的东西不会跑偏。

6.3 例子三：说目标而不是说步骤

说步骤：

“去 GitHub 上找个开源博客框架，clone 下来，改一下配色，上传到我的仓库”

这条需求看起来很具体，但它是按你的步骤来的，你让它当一个听话的工具人，而不是一个有判断力的搭档。

说目标：

“我想做一个个人博客，技术栈不限，但要能让我用 Markdown 写文章，部署简单，后续维护不用太操心。你帮我选型，定了之后搭好框架”

这样龙虾可以发挥它的判断力，选一个真正适合你的方案，而不是机械执行你给的每一步。

七、模糊时怎么做：列选项而非猜测

这一点很重要，专门说一下。

有时候你给的需求不完整，或者你自己也不确定要什么。这种情况很常见，不要紧，但要避免一件事：不要让龙虾替你做没把握的决定，然后默认就执行了。

正确的方式是让它列出选项，你来选。

反例：

“帮我把这个 API 改成 REST 风格的吧”

龙虾：（默默改了，然后给你一套 REST API）

结果可能不是你想要的风格，但它已经改完了，你还得让它改回来。

正例：

“帮我把这个 API 整理一下，我不确定用什么风格，你帮我分析一下几个方案的优劣，最后让我选”

龙虾会给你列出选项，分析每个方案的利弊，最后由你拍板。

遇到需求不明确的时候，最佳实践是：

让龙虾问问题，而不是猜答案。

你可以直接说：”这个需求里有几个地方我也没想清楚，你先问清楚再动手。”它会很有条理地跟你确认关键问题，而不是一上来就按自己的理解硬来。

八、验证与回顾

用龙虾干活一段时间后，建议做两件事：验证它还在正常工作，以及回顾一下你们协作的效果。

8.1 验证消息通道

定期检查消息通道是否畅通。简单发一条”在吗”或者”报个数”，看它有没有回应。如果没有响应，再检查网络和配置。

这一步听起来简单，但有时候你改了配置或者网络环境变了，龙虾会暂时断线。主动验证比等到要用的时候才发现问题要好。

8.2 版本化管理

用 Git 管理工作区是个值得养成的习惯。不只是代码项目，文档、脚本、配置文件都可以纳入版本化管理。

我现在的做法是同时推 GitHub 和 Gitee，通过 git pushall 一次推两个平台。这样既有了异地备份，访问也更有保障。

操作示例：

1
2
3
4
5
6
7
8
# 添加文件
git add .

# 提交
git commit -m "更新项目文档"

# 双端推送
git pushall

git pushall 是个别名，同时执行 git push origin master 和 git push gitee master。这样不用记两套命令，一句完成两地同步。

把工作区纳入版本化管理之后，你可以随时回溯到任何一个历史状态，不用担心改着改着就回不去了。这也是给自己留的一条退路。

8.3 安装 GitHub CLI

如果你需要经常和 GitHub 交互，安装 GitHub CLI 会方便很多。它让你可以在终端里操作 GitHub 的 issue、PR、actions 等，不用每次都打开浏览器。

安装方式：

1
2
3
4
5
# macOS
brew install gh

# 登录
gh auth login

登录之后，你就可以在终端里做这些事情：

1
2
3
4
5
6
7
8
# 查看 issue
gh issue list

# 创建 issue
gh issue create --title "Bug报告" --body "描述"

# 查看 PR 状态
gh pr list

对于需要经常跟进 GitHub 项目的团队或个人，这个工具能显著提升效率。

这些是日常维护操作，下一篇我们进入实战：工作区怎么搭、Git 怎么用、文档怎么同步到飞书知识库。

九、下一步

这篇聊的东西偏方法论，可能有点虚。但你真正用起来的时候，会发现这些原则会直接影响你用龙虾的感受。

用对了方式，它真的是一个执行力很强、从不摸鱼的工作搭档。

用错了方式，你会觉得它”不够聪明”、”答非所问”，然后慢慢就不想用了。

其实它一直都挺能干的，只是你需要给它一个正确的打开方式。

下篇我们聊点更实际的：怎么用龙虾管项目。具体说说工作区的概念、Git 操作、飞书知识库同步、CI/CD 流水线、变更日志追踪——那些你真正用起来会发现离不开的东西。