企业官网建设流程全解析

如果你最近逛技术社区，多少都会刷到 OpenClaw 这个名字。它跟 Claude Code、Codex CLI 属于同一类东西——一个跑在终端里的 AI 编程与执行助手，你敲一段自然语言指令，它能在你的命令行环境里帮你写代码、跑命令、读日志、改配置。和很多把 AI 放在网页聊天框里的工具相比，OpenClaw 最大的特点是交出了“操作权”：它不仅能回答问题，还能直接在你的机器上执行命令。

这篇东西不是官方文档的纯翻译，更像是我自己从安装、初始化到日常高频使用，整理出来的一份“命令参考 + 踩坑记录”。文章里所有命令都尽量按“命令 / 作用 / 说明”这种结构给出，装完之后可以直接对着敲。如果你刚接触这类终端 AI 工具，建议先看第一部分，搞清楚它到底是干什么的，再去看命令，否则容易一头雾水。下面直接开始。

1. OpenClaw 是什么，先想清楚再装

1.1 它和普通对话式 AI 到底差在哪

很多人第一次打开 OpenClaw 交互界面时会有点不适：没有漂亮的网页聊天框，就是一个终端窗口，光标在等你的指令。这恰恰是它的核心设计思路——AI 不再只是一问一答的“智囊团”，而是直接参与工作流的“执行者”。你告诉它“帮我分析一下项目里哪个函数调用次数最多”，它会自己翻代码，然后跑一段分析命令，再把结果整理给你。

这种交互方式能成立的底层逻辑是“工具调用（Tool Use）”。传统聊天 AI 只能基于已有知识回答，而 OpenClaw 被允许调用一组工具：读取文件、执行命令、搜索目录、修改代码。打个不精确的比方，网页聊天 AI 像请人指路，OpenClaw 则更像把车钥匙交给一个靠谱的朋友，让他直接帮你开到目的地，前提是你设好了权限和路线。

也正因为它能直接操作系统，权限、安全、可追溯这些概念就变得很重要。OpenClaw 在执行危险操作前通常会有确认机制，这个细节后面专门讲。

1.2 什么人适合用命令行版 AI 助手

先说结论：OpenClaw 不是给所有人的工具。如果你日常工作已经被 IDE 里的 AI 插件覆盖得很好，聊天窗口用得也顺手，那不一定非要迁移到终端来。但如果你是这几类人，很值得试一试：

• 程序员，尤其是后端、脚本、自动化相关，天天跟终端打交道，顺手就能把 AI 接进现有工作流。
• 运维和 DevOps 工程师，需要快速查日志、看服务状态、批量处理文件，OpenClaw 能直接在这些操作上帮上忙。
• 喜欢研究新工具、愿意折腾配置的技术爱好者，OpenClaw 的部署、模型接入和技能系统本身就有极强的可玩性。

反过来，如果你只是想要一个随叫随到的问答机器人，对命令行不熟，也不想学终端操作，那 OpenClaw 的学习成本对你来说就不划算。终端 AI 工具的上手曲线，主要不在安装，而在“你是否有用命令表达需求”的思维习惯。

2. 安装与初始化命令：从零到能跑

2.1 安装、版本与帮助信息

OpenClaw 的安装方式和很多现代 CLI 工具一样，支持包管理器安装和官方脚本安装。以我在 Linux 服务器和 Windows 上折腾的经验，最快的方式是看官方 README 里的安装命令。装完第一件事不是急着跑，而是先看版本和帮助：

openclaw --version openclaw --help

这两条命令恐怕是我用得最多的“元命令”。我建议你把openclaw --help的输出存个截图或者保存到本地文件，因为不同版本之间的子命令可能会有细微差别，以你当前版本的帮助信息为准，永远是最稳妥的做法。如果你发现某个命令敲进去提示 unknown command，多半不是你的问题，而是版本差异，回到--help里查就行。

如果帮助信息里能看到install、init、config、skill、doctor这些常见子命令，说明这个版本的功能比较完整。顺带一提，遇到功能异常时，先跑一下openclaw doctor这类诊断命令，它会检查环境变量、Node 版本、配置完整性，很多莫名问题能直接定位。

2.2 初始化与登录：让 OpenClaw 认识你的项目

安装完成后通常需要初始化。初始化这个动作要做的事情很简单：生成默认配置文件、建立会话存储目录、绑定默认模型。不同版本用的初始化命令可能不太一样，常见的是init或者setup：

openclaw init openclaw config list

openclaw config list是我建议你初始化后立刻执行的命令，把当前配置全部看一遍，确认默认模型是哪个、API Base 指向哪、密钥文件在哪里。很多人的问题出在这一步：安装好了，初始化也过了，但对话时模型不响应，回头看配置才发现 API Key 没填进去。

配置类命令要注意的一点：OpenClaw 支持通过环境变量、配置文件、命令行参数三种方式传递配置，优先级是命令行 > 环境变量 > 配置文件。我踩过的一个坑是，环境变量里临时设了一个模型参数，导致配置文件里怎么改都没效果，排查到最后才发现是环境变量在捣乱。所以当你改配置发现“没生效”，先检查是不是有环境变量覆盖了。

2.3 Windows 安装与 Companion 配置

Windows 上安装 OpenClaw 的路径和 Linux 不太一样，很多新手卡在“OpenClaw Windows Companion 怎么配置”这一步。这里先说清一个背景：Windows 的权限模型、路径规则和进程管理与 Linux 差异巨大，OpenClaw 跑 Windows 版本时，往往需要搭配一个叫 Companion 的组件来桥接操作系统的权限和文件访问。

我第一次在 Windows 上装完 OpenClaw，也遇到了 Companion 连不上的问题。查了半天，发现核心原因就三个：

• 版本不匹配。OpenClaw 主程序版本和 Companion 版本对不上，握手失败。解决办法是先升级 OpenClaw，再重新安装匹配版本的 Companion。
• 端口没放开。Companion 会在本机监听一个端口，防火墙拦截后从主程序看就是“连接被拒绝”。这时候去防火墙里放行对应端口就行。
• Windows 的执行策略限制。有些脚本在 PowerShell 下不能直接跑，需要以管理员身份启动终端，或者修改执行策略。

我的建议是：Windows 用户把 OpenClaw 装在一个路径里没有中文、没有空格的目录，然后以普通用户身份跑通一个最简单的任务，再考虑加权限。不要一上来就搞复杂的系统交互，很多时候只是目录环境的问题。

2.4 安卓 Termux 部署和手机端限制

热心网友折腾 OpenClaw 的一个热门方向是“手机版”——在安卓上用 Termux 跑 OpenClaw。思路本身没问题：Termux 就是安卓上的 Linux 终端环境，能装 Node、Python、Git 等一大堆工具。只要 OpenClaw 是纯 CLI 实现的，理论上就能在 Termux 里跑起来。

但手机部署有几个客观限制，先说清楚，免得你白忙活：

• 文件隔离。Termux 默认只能访问自己的数据目录，要用termux-setup-storage授权才能读到手机内置存储里的文件。
• 资源有限。手机 RAM 和 CPU 和服务器没法比，OpenClaw 在手机端跑重任务会明显卡顿，适合做轻量操作和“出门在外应急查个东西”。
• 后台限制。安卓系统对后台进程有严格管理，Termux 会话一挂后台，OpenClaw 可能就被系统回收了。真要长时间运行，建议配合termux-wake-lock。

手机部署的安装步骤和桌面版基本一致：先pkg install nodejs，然后用包管理器安装 OpenClaw，再openclaw init初始化。区别是手机端模型配置建议优先连远程 API 或者局域网里的 Ollama 服务，别指望手机本地跑大模型，效果太感人。

2.5 升级与卸载的干净姿势

再说说容易被忽略的升级和卸载。升级这件事看起来简单，但直接覆盖装新版可能留下旧会话和旧配置残留。我习惯先备份配置文件，再执行升级命令，升级完看一眼--version和config list，确认关键配置还在。

卸载也是同理。有些人卸载完 OpenClaw，又重装，发现旧会话、旧日志全回来了，这是因为配置目录没被清理。卸载命令只会删主程序文件，不会主动删你的个人配置目录。如果你确定不要了，可以手动把~/.openclaw之类的目录一起删掉。备份之前先确认里面没有你想留的会话记录，别手滑。

3. 日常会话与高频交互命令

3.1 新建、恢复、切换会话：管理你的“记忆空间”

OpenClaw 的日常使用核心是会话（Session）。每条指令、每次执行，都会沉淀到当前会话的上下文中。会话管理命令直接决定了你能否高效地和 AI 协作。

进入交互模式很简单，终端里直接敲：

openclaw

这样会进入一个 REPL 式的对话界面，之后的所有指令都在这个会话里进行。你也可以不开交互界面，直接传一段任务：

openclaw "统计一下当前目录下所有Python文件的行数"

这种一次性调用适合脚本化和自动化场景，输出结果后进程就退出，不会挂在那里等你继续问。

会话恢复是另一个高频操作。关掉终端再打开，想接着上次的上下文继续聊，就需要恢复会话命令。常见的做法是/resume或openclaw resume，具体以版本帮助为准。这里我强烈建议你养成习惯：重要任务做完前不要频繁新建会话，因为你每次 /exit 再重开，上下文就断了，OpenClaw 对你的项目背景理解需要重新建立。

3.2 会话内四大高频斜杠命令

进入交互模式后，有一批以斜杠开头的内置命令。这里把最常用的几个整理成表格，方便你对照：

这里面/compact是我最早忽略、后来真香的一个命令。长时间对话后上下文会越来越长，超过模型窗口后不是报错就是效果变差，让 OpenClaw 自己把历史压缩成摘要再继续，相当于给会话“减肥”。不过压缩会丢失一些细节，重要信息最好在压缩前让它先存档到文件里，这个习惯很重要。

/model同样实用。本地 Ollama 跑一个小模型日常够用，遇到复杂重构时临时切到 API 上的大模型，一个会话里就能完成“轻量问答”和“重量级代码生成”两种任务的切换，不必重启会话。

3.3 让 OpenClaw 替你执行终端命令的权限逻辑

OpenClaw 最核心、也是风险最高的能力就是执行终端命令。它要跑命令之前，一般会经过权限确认。这里我不去逐字描述界面文案，只讲清逻辑：默认情况下，OpenClaw 会检查命令本身的风险级别和当前目录的信任状态。如果你在项目目录里授权过一次，后续同类命令就会放行；如果命令涉及删除、覆盖、全盘扫描、系统配置变更这类高风险动作，它会停下来等你确认。

我的实操建议是：

• 只对项目目录授权。让 OpenClaw 在一个明确的、低风险的目录里执行操作，不要稀里糊涂地给整个用户目录或根目录授权。
• 高危命令一定人工确认。比如rm -rf、dd、chmod -R这类，不管它怎么保证没问题，先看一遍再放行。
• 用git diff检查改动。让 OpenClaw 改完代码后，先让它跑git diff给你看，确认改动符合预期，再决定要不要接受。

权限配置一般集中在config里，有一个“允许自动执行的命令模式”之类的配置项。我的建议是默认保守一些，宁可多确认几次，不要为了省事把所有权限全部放开。OpenClaw 的能力边界最终是用户自己划定的，这个责任没法外包给 AI。

3.4 任务队列与并行执行

如果你熟悉 shell，自然会产生一个念头：能不能让它同时跑多个任务？答案是可以，但要注意方式。OpenClaw 支持多条指示并发处理，有些任务之间没有依赖，确实可以并行，显著提升效率。但并行执行有一个副作用：多个任务同时读上下文，可能导致上下文污染，任务 A 的结果跑到任务 B 里去了。

我更推荐的做法是分两类处理：相互独立的简单任务，可以并行，发现上下文串了立刻/exit重开会话；有依赖关系的任务，老老实实按顺序排队，避免出问题后反而更浪费时间。还有一种模式是在一个任务里用&&串联命令，让 OpenClaw 连跑一串 git 操作或测试命令，这种一次性脚本式的写法也省心。

4. Skills 技能系统与自定义命令扩展

4.1 技能列表、开关和状态查看

Skills 是 OpenClaw 体系里让我最兴奋的部分。简单说，技能就是一组预设的指令模板和脚本，让 OpenClaw 针对特定场景具备“专业知识”。比如你可以给它一个“代码审查”技能，它看到代码时就按指定的检查清单逐项审视；或者给它一个“日志分析”技能，它拿到日志文件就知道先用哪些命令提取关键词。

技能相关的高频命令基本围绕“查看、启用、禁用”展开：

openclaw skill list openclaw skill enable <name> openclaw skill disable <name>

在交互界面里，/skills命令也能完成类似操作，还能顺带看到每个技能的说明和适用场景。我强烈建议你把默认仓库里的技能全看一遍，很多你以为是“功能缺失”的问题，其实只是没启用对应技能。比如让 OpenClaw 读 PDF、分析 Markdown 文档结构、跑数据库查询，这些在很多版本里都对应着现成技能。

4.2 自定义技能怎么写：目录结构与一个知识库实例

自定义技能并不复杂，核心是一个 SKILL.md 文件和可选的脚本目录。以我建过一个“本地知识库问答”技能为例，目录结构大概是这样的：

~/.openclaw/skills/knowledge-base/ ├── SKILL.md └── scripts/ └── search.sh

SKILL.md 里面写清楚技能的名字、描述、使用场景、触发方式，还有提示词模板。描述写得好不好，直接决定 OpenClaw 会不会在合适的场景主动调用这个技能。我第一版技能描述写得太抽象：“用于知识库搜索”，结果 OpenClaw 经常无视它。改成“当用户提到项目文档、知识库、特定资料目录时，使用这个技能搜索并提供原始路径”，触发率立刻上来了。

scripts 目录里放实际执行的脚本。我的知识库检索脚本，本质上就是grep+find的组合，把特定目录里的文本文件扫一遍，输出命中片段和文件路径。后来我用 Python 做了个简单的关键词权重排序，效果更好一些，但原理没变：技能的本质是“把检索逻辑封装成固定动作”。

技能写好后，用openclaw skill list能看到它，启用之后就能在会话里触发。这里要强调：技能里涉及到的路径、权限、依赖脚本，都必须在测试环境先跑通一遍。别指望 OpenClaw 能自动修复技能的运行时错误，它能在运行时发现问题并报告已经很不错了。

4.3 技能生效的常见坑

技能不生效是群里反馈最集中的问题之一。我遇到的典型场景和原因有这么几类：

• 描述与触发场景不匹配。技能描述写得太窄，用户问法稍微变一下，OpenClaw 就不认为该用这个技能。
• 目录位置不对。有些版本要求技能放在项目目录的.openclaw/skills下，而不是全局目录，放错位置自然识别不到。
• 脚本权限没执行位。Linux 环境下，scripts/search.sh没有chmod +x，OpenClaw 执行脚本时直接 permission denied。
• SKILL.md 格式不对。字段名拼错或 YAML 缩进有问题，技能加载时静默失败，在--help或诊断命令里也未必报错。

排查技能问题，我的建议是三步走：先确认技能在skill list里看得到；再检查描述文本是否覆盖了你的提问方式；最后手动跑一遍技能里的脚本，确认纯脚本层面没有错误。三步走完，绝大多数问题都能定位到。

5. 算力与模型接入：别被“只能用 API”带偏

5.1 远程 API 模型接入

模型接入是 OpenClaw 配置里的重头戏。很多人看到“API”就先入为主觉得麻烦，其实流程很固定：拿到模型服务的 API Key，在配置文件或环境变量里填好地址和模型名，然后openclaw init或者重启会话让配置生效。

远程 API 的好处是模型能力上限高、响应速度稳定、不占本地资源。缺点是流量成本、隐私顾虑——你的代码片段和日志内容会发送到服务端处理。对开源项目和公开代码没什么问题，涉密项目就得斟酌了。

5.2 本地模型 Ollama 接入，算力不迷信 API

热搜里有个问题非常典型：“OpenClaw 只能用接入 API 的方式使用算力吗？”答案是否定的。OpenClaw 完全可以接入本地模型服务，最常见的方案就是 Ollama。

我的操作流程是这样的：

ollama serve ollama pull qwen2.5-coder:7b

然后进入 OpenClaw 的配置，把模型地址指向http://localhost:11434，模型名改成qwen2.5-coder:7b，保存后重启会话。OpenClaw 就能直接和本地模型对话了。

接入本地模型后，“算力”这个概念就变得很实在：本地跑模型占用的是你的 CPU/GPU 和内存，不消耗外部 API 额度，也不会有数据传输出去，隐私上放心很多。代价是模型参数规模小，复杂任务的能力上限明显低于顶级 API 模型。

我的实测感受是：如果任务集中在写代码、读日志、文件整理这类结构化操作，7B 乃至更小的模型完全够用，而且没有 API 速率限制，批量处理时反而更稳定。一旦进入深度的代码重构、复杂逻辑推理、多步骤方案设计，本地模型就会露怯，这时候切到远程大模型更靠谱。所以理想配置是“本地模型 + API模型”双轨并行，靠/model命令来回切换。

5.3 模型配置参数的经验

模型接入相关的配置项，最核心的就三个：模型服务地址、API Key、模型名称。除此之外，上下窗口长度也是关键参数，直接影响会话能容纳多少历史内容。我踩过的坑是：模型服务支持 128K 上下文，但 OpenClaw 配置文件里只写了 8K，导致 OpenClaw 早早触发/compact，浪费了很多上下文空间。模型能力几斤几两，配置时最好先查清楚。

还有一个容易忽略的参数是“请求超时时间”。本地模型如果跑在小机器上，一个长任务的生成时间可能超过默认超时，OpenClaw 会报超时错误。这时候不是模型坏了，而是超时时间设置太短，调大一些就好。

6. 常见问题排查与避坑速查

6.1 问题排查速查表

把我在实际使用中遇到的高频问题整理成一个速查表，方便你直接对号入座：

6.2 Windows 下命令闪退与 Companion 连不上的排查

Windows 命令闪退是非常典型的用户问题，我在 2.3 节提过一层，这里再展开说。闪退通常不是你操作错误，而是运行环境不完整。最常见的三个原因：

• PATH 里缺少 Node.js 环境。OpenClaw 依赖 Node 运行时，如果从别的终端能启动，从你的终端启动就闪退，先查node --version确认。
• 版本兼容问题。Windows 上 OpenClaw 和 Companion 的版本需要匹配，一个太新一个太旧就会闪退。把两边都升级到最新版，再重新启动。
• 权限问题。某些目录需要管理员权限才能写入，启动时直接报错退出。用管理员身份跑一次，如果把问题解决了，后面再把目录权限配好。

Companion 连接失败还有一种隐蔽情况：端口被占用。Companion 默认监听固定端口，如果电脑上其他程序抢先占用了这个端口，连接必然失败。排查方法是用netstat -ano | findstr <端口>，找到占用进程，关掉冲突进程或者修改 Companion 配置换一个端口。

6.3 Shell 环境被弄乱的判断方法

热搜里有一条“top 命令被改变 怎么办”，虽然不是 OpenClaw 特有的问题，但用终端 AI 工具的人多多少少会遇到 shell 环境异常。判断思路很简单：先看命令是否真的被替换了，还是路径被劫持。运行：

type -a top command -v top echo $PATH

如果type显示的路径奇怪，或者 PATH 里有异常目录，大概率是 shell 配置文件里被加了 alias 或 PATH 注入。先检查~/.bashrc、~/.zshrc里的 alias 和 export，把可疑行删掉，再开新终端验证。

这里也帮 OpenClaw 澄清一句：它不会主动改你的系统命令，除非你明确授权让它去改。如果你发现命令行为异常，先怀疑自己之前是不是执行过什么来源不明的脚本，或者不小心采纳了 AI 给出的“改 PATH/alias”建议。用终端 AI 工具时，很好的一条原则是：它给你的每条修改命令，都先看懂再执行，看不懂就不执行。

6.4 关于 WorkBuddy 与 OpenClaw 生态的一个观察

热搜里有人问“WorkBuddy 这种是不是参考了 OpenClaw 才搞出来的，时间对得上吗？”这类问题我见过很多，背后的情绪是好奇工具之间的“血缘关系”。客观来说，2024 年到 2025 年这波终端 AI Agent 工具的集中爆发，几乎是所有主流产品站在同一个浪潮上，互相借鉴是常态。你问 OpenClaw 和 Claude Code、Codex CLI 之间有没有互相参考，我想任何从业者都会坦诚地说：一定有。

但作为使用者，我有个更实在的建议：与其纠结谁先谁后，不如关注三条更本质的维度——能不能帮你完成真实任务、权限模型安不安全、技能生态扩展性强不强。OpenClaw 的 Skills 机制和终端命令执行边界设计得比较清晰，这一点让它成为我日常主力工具之一。工具之间的“借鉴”从来不是问题，用得顺手、维护得当才是真的生产力。

从我个人的角度看，OpenClaw 最让人服气的一点是它把复杂能力封装成了足够简单的命令。你不用懂模型调用细节，不用懂 Agent 框架原理，记住几个常见命令就能开始干活。而真正值得投入时间去学习的，不是命令列表本身，是你自己的工作流：什么该交给它、什么必须自己确认、什么时候该切模型、什么时候该开新会话。这些边界感，才是在终端 AI 时代用好工具的核心能力。