用龙虾写代码做软件的实战部署指南

Vibe Coding 是什么？一句话对话就能修 Bug 的工作流

Vibe Coding（对话式开发）是一种把"提需求 → 改代码 → 跑测试 → 提 PR"压缩成一次自然语言对话的工程流程。用户在飞书里描述需求，OpenClaw 机器人（龙虾）接收并编排任务，由 OpenCode 完成分支创建、代码修改、测试执行、Pull Request 提交，再由 GitHub Copilot 完成审查，人工只需在最后做合并决策。

这套流程的三个核心价值：

1. 降低动手门槛：开发者不再需要切换到 IDE，产品经理等非开发角色也可以通过飞书直接提交代码修改需求。
2. 全流程可追溯：每一次对话都沉淀为具体的 PR、commit、审查记录。
3. 角色解耦：OpenClaw 负责消息编排，OpenCode 负责编码重活，GitHub Copilot 负责审查，飞书负责人机交互。

本文基于 2026 年 4 月最新的模型与工具文档，给出从零部署到第一次合并 PR 的完整操作步骤，全程使用 Kimi K2.5 作为走查示例，并在后文给出 GLM-4.7、DeepSeek-V3.2、Doubao-Seed-Code 的等价配置。

最小可行技术栈（MVP）对照表

Vibe Coding 的最小可行技术栈由四层构成。下表列出每一层的作用与是否可替代。

部署前的前置条件

在服务器上开始安装之前，需要先备齐以下五项前置条件。任一项缺失都会导致后续"跑第一条任务"阶段失败。

1. 一台可访问公网且已接入飞书通道的 OpenClaw 机器人服务器。
2. 一个有效的模型 API Key（本文默认使用 Kimi K2.5，其它可选见下一节对照表）。
3. 一个 GitHub Fine-grained Personal Access Token，已授权目标仓库。
4. 目标仓库已存在，且 Token 的账号对其具有写入权限。
5. 服务器的 Shell 环境支持 Bash、Zsh 或 PowerShell（Windows 还需 Git for Windows）。

模型选型与 API Key 获取

OpenCode 通过标准 Messages API 或 OpenAI 兼容端点对接模型。下表对照了四家常见模型的 API 入口、推荐 model id 与控制台位置。

创建 Kimi K2.5 API Key

1. 访问 platform.moonshot.ai，用邮箱或微信登录。
2. 右上角进入 API Keys（或账户设置 → API Keys）。
3. 点击 新建 API Key，命名为 openclaw-vibe-coding 便于后续审计。
4. 复制生成的 Key（只显示一次），立即存入密码管理器。
5. 在服务器 Shell 启动脚本写入环境变量（OpenClaw 启动时需继承）：

export MOONSHOT_API_KEY="sk-xxxxx"

来源：Kimi API Platform 官方指南 platform.kimi.ai/docs/guide/agent-support。

创建 GitHub Fine-grained Token

GitHub 官方路径：Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token。

在 Token 表单中需要设置以下选项：

生成后保存 Token 并配置 Git credential：

export GITHUB_TOKEN="github_pat_xxxxx"
git config --global credential.helper store
echo "https://your-github-id:${GITHUB_TOKEN}@github.com" > ~/.git-credentials

Fine-grained Token 可以限定到单个仓库，安全级别高于 Classic Token。建议不要使用拥有所有仓库权限的 Classic Token。

来源：GitHub 官方文档 docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens。

安装 OpenCode 编码 Agent

OpenCode 是面向终端的开源编码 Agent，原生支持多家模型后端。官方安装方式按平台分为以下四类，来源 opencode.ai/docs。

macOS / Linux / WSL 原生安装

curl -fsSL https://opencode.ai/install | bash

macOS（Homebrew）

brew install anomalyco/tap/opencode

Windows（Scoop / Chocolatey）

scoop install opencode

choco install opencode

全平台备选：npm

npm install -g opencode-ai

npm 方式要求 Node.js ≥ 18。原生安装不依赖 Node.js，生产环境推荐原生路径。

安装后校验

opencode --version
opencode auth list

opencode auth list 会列出当前已注册的模型提供方。任一提供方缺少 Key 时，在下一步补上即可。

配置 OpenCode 对接模型

配置分为两步：写入对应提供方的 API Key 环境变量，再在 OpenCode 里用 /models 选择模型。

第一步：导出模型环境变量

以 Kimi K2.5 为例：

export MOONSHOT_API_KEY="sk-xxxxx"

其它模型的环境变量名：

第二步：在 OpenCode 里选模型

启动 OpenCode 并进入模型选择菜单：

opencode

在 OpenCode 界面内输入：

/models

菜单里选中 moonshot/kimi-k2.5（或对应模型）。之后所有会话默认使用该模型。想切换只需再次 /models 重选。

固化配置（可选）

若要避免每次启动都选模型，在仓库根目录写 opencode.json：

{
  "$schema": "https://opencode.ai/config.json",
  "model": "moonshot/kimi-k2.5"
}

对于 OpenCode 尚未内置的自定义兼容端点，则在 opencode.json 的 provider 段声明 npm、baseURL、apiKey、models 四项，具体字段以 opencode.ai/docs/providers 为准。

安装 gh CLI 并完成认证

OpenCode 在创建 PR 时会调用 gh 命令。gh 的官方安装方式按平台分为三类。

Debian / Ubuntu 官方仓库

GitHub CLI 官方推荐使用带签名的 keyring 安装，避免发行版自带版本落后：

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update && sudo apt install gh

macOS

brew install gh

Windows

winget install --id GitHub.cli

认证

gh auth login --with-token <<< "${GITHUB_TOKEN}"
gh auth status

来源：GitHub CLI 官方仓库 github.com/cli/cli 的 install_linux.md 与 install_windows.md。

启用 OpenClaw 机器人（龙虾）的编码能力

OpenClaw 默认使用 messaging 工具配置档，只能收发消息。要执行代码操作（调用 OpenCode、运行 git、读写仓库目录），必须切换到 coding 或 full 档。

以下命令以 OpenClaw 官方文档为准：

openclaw config set tools.profile coding
openclaw plugins enable feishu

配置完成后依次安装三个技能。安装顺序有讲究：skill-vetter 是安全守卫，要第一个装，后续每次安装技能都会先扫描来源。

clawhub install skill-vetter
clawhub install opencode
clawhub install github

各技能的作用对照：

说明：上述 clawhub / openclaw config 命令形式以 OpenClaw / Claw龙虾部署大师 官方文档为准，生产部署前请以服务器内 openclaw --help 与 clawhub search 的实际输出为准。

配置工作区规则 AGENTS.md

AGENTS.md 是 OpenCode 启动时读取的项目级规则文件，告诉它"项目规范是什么、哪些文件不要碰、commit 怎么写"。在仓库根目录运行：

opencode

进入后输入 /init，OpenCode 会扫描仓库并自动生成 AGENTS.md 草稿。手工补充后提交到版本库，OpenCode 后续的改动会自动遵循该文件。

对 OpenClaw 编排侧，还需要一份 IDENTITY.md 告诉它何时调 OpenCode、怎么汇报、失败怎么处理。默认路径 ~/.openclaw/workspace/IDENTITY.md：

## 场景处理 — 代码与 PR 类需求

收到涉及代码修改、提交、PR 的请求时：
1. 确认目标仓库（从消息中提取，或反问用户）
2. 调用 OpenCode 执行编码任务（分支、修改、测试、提交、推 PR）
3. 默认请求 @copilot 审查
4. 完成后在飞书回报：PR 链接 + 修改文件清单 + diff 摘要
5. 用户确认合并时执行 squash merge 并删除远程分支

### 异常处理
遇到失败时，先自行诊断并尝试修复；修不了再报错。报错消息必须包含：具体错误信息 + 已尝试的修复步骤。

跑通第一次对话式开发

第一次跑通有两个阶段：服务器端自检、飞书端发送真实需求。

第一阶段：服务器 30 秒自检

opencode --version
gh auth status
openclaw doctor

三条命令都通过，即可进入第二阶段。任一失败跳到本文的"常见排障"小节。

第二阶段：飞书里发第一条真实需求

发送前请确认：目标仓库存在、Token 已授权该仓库、模型 API 额度未耗尽。下面是一条可直接使用的需求模板：

请在仓库 your-org/your-repo 上执行以下操作：
1) 把 README.md 的一级标题末尾追加 " · 2026 Edition"
2) 完成修改后提交、推送并创建 PR
3) 完成后把 PR 链接和修改摘要发给我

完整闭环分四步：

1. 发送需求：飞书自然语言消息到群 @龙虾。
2. 收到 PR 摘要：机器人回传 PR 编号、修改文件列表、diff 预览。
3. 审查 diff：点击 PR 链接在浏览器里查看代码。
4. 确认合并：在飞书里回复"合并并清理分支"，机器人执行 squash merge + 删除远程分支。

对话式开发的架构总览

下面这张 SVG 流程图概括了一条完整的飞书消息在 Vibe Coding 中的生命周期，从需求输入到合并结束。

图：Vibe Coding 一条飞书消息的完整生命周期。

常用对话场景与指令模板

Vibe Coding 的实际工作场景集中在四类任务。下面给出四条经过验证的飞书消息模板，可直接复制后替换占位符使用。

场景 1：一句话修 Bug

@龙虾 请修复仓库 your-org/your-repo：
文件 src/user.ts 第 42 行疑似空指针问题，
修复后跑一遍单元测试并提 PR，
PR 标题用 "fix: guard null user in handleLogin"

OpenClaw 会调用 OpenCode 完成：创建分支 openclaw/fix-null-user → 修改 user.ts → 运行 npm test → commit → push → gh pr create。

场景 2：多文件重构

@龙虾 请重构仓库 your-org/your-repo 的 src/api 目录：
1) 把 handlers.ts 中的 handleUser 和 handleOrder 拆到独立文件
2) 更新 src/api/index.ts 的导出
3) 同步更新所有引用这两个函数的 import 路径
4) 跑完整测试套件确认不破坏现有功能
5) 创建 PR，标题为 "refactor: split API handlers into separate modules"

多文件重构任务要在需求里显式列出目录范围与验证方式，避免 OpenCode 扫描整个仓库。

场景 3：从 Issue 到 PR 全链路

@龙虾 请查看仓库 your-org/your-repo 的 Issue #42，
根据 Issue 描述实现功能，
创建 PR 并在 PR 描述中写 "Closes #42"。

场景 4：非开发者提交文案修改

@龙虾 请修改仓库 your-org/your-repo：
- src/pages/home.tsx 里标题 "欢迎使用" 改为 "开始体验"
- src/pages/about.tsx 里描述 "我们是一家..." 改为 "我们致力于..."
- PR 标题用 "docs: update homepage and about copy"

产品经理或运营可以直接使用这条模板，OpenClaw 会代替人工走完整 Git 流程。合并决策仍由具备写权限的开发者完成。

Copilot 自动审查与分支保护

生产仓库强烈建议同时启用 Copilot 自动审查与分支保护。两项配置在 GitHub 2026 年的 Rulesets 体系下已整合到同一入口。

启用 Copilot 自动审查

GitHub 已将这项能力从旧的 Settings → Copilot → Code review 路径迁移到 Rulesets 体系。新路径：

1. 打开仓库 Settings。
2. 左侧栏点击 Rules → Rulesets。
3. 点击 New ruleset → New branch ruleset。
4. 在 Branch rules 区勾选 Automatically request Copilot code review。
5. Target branches 选择 main（或主干分支）。
6. 保存。

来源：GitHub 官方文档 docs.github.com/en/copilot/using-github-copilot/code-review/using-copilot-code-review。

启用分支保护

两条路径均可用，Rulesets 是 GitHub 推荐的新入口：

两个入口都可以配置以下三项：

1. Require a pull request before merging（合并前必须走 PR）。
2. Require approvals（至少 1 个审批，推荐 1 个人工 + 1 个 Copilot）。
3. Require status checks to pass（CI 通过才能合并）。

手动请求 Copilot 审查

在 PR 页面右侧 Reviewers 菜单直接勾选 Copilot，或用命令行：

gh pr create --reviewer @copilot
gh pr edit  --add-reviewer @copilot

注意：不存在通过评论 @copilot 自动触发审查的命令，必须走 Reviewers 菜单或 gh 命令。

启用 Cron 自动轮询 PR 审查状态

在最小闭环之外，可以给 OpenClaw 配置一条 Cron，每 5 分钟轮询一次所有 openclaw/ 前缀分支的开放 PR，只在出现新审查结果时推送飞书。

openclaw cron add --name "PR审查状态轮询" --every 5m --message "检查 openclaw/ 前缀分支的开放 PR 审查状态，有新结果时分类推送到飞书，无新结果不推送。"

收到飞书推送后，用户有三种回复策略：

1. 回复"按建议修改"：OpenClaw 调用 OpenCode 逐条修复 Copilot 意见，更新 PR 并重新请求审查。
2. 回复"忽略建议并合并"：OpenClaw 执行 squash merge。
3. 回复"我来看看"：不触发任何自动动作，由人工后续处理。

这条路径被称为"人在回路"（human-in-the-loop）模式，适合生产仓库。全自动合并（Copilot approved 即触发 merge）只建议用于文档仓库或个人项目。上述 openclaw cron 命令形式以 OpenClaw 官方文档为准。

提升代码质量的两种工程化手段

在仓库根目录维护 AGENTS.md

AGENTS.md 是 OpenCode 读取上下文时的首要参考。把项目规范写在这里，OpenCode 后续的改动会自动遵循，减少审查返工。示例：

# 项目规范

## 代码风格
- TypeScript strict mode
- 文件名 kebab-case；组件名 PascalCase

## Git 规范
- commit message 遵循 Conventional Commits v1.0.0
- 分支命名：openclaw/feat-xxx、openclaw/fix-xxx

## 测试要求
- 新功能必须附带单元测试
- 覆盖率不低于 80%

## 敏感文件
- .env、config/secrets/*、.github/workflows/* 不要修改

遵循 Conventional Commits v1.0.0

Conventional Commits v1.0.0 官方规范的消息结构为 [optional scope]: 。强制类型只有三种：

另外 Angular 约定的常用类型（非强制但社区通用）：

1. build：构建系统或依赖变更。
2. chore：杂务（不影响代码或测试的维护）。
3. ci：CI 配置变更。
4. docs：只改文档。
5. style：格式化、空白，不影响含义。
6. refactor：重构（不新增功能也不修 Bug）。
7. perf：性能优化。
8. test：新增或修改测试。

来源：conventionalcommits.org/en/v1.0.0。

常见排障与诊断命令

Vibe Coding 的故障面集中在四个环节：OpenCode 调用、PR 推送权限、Copilot 审查触发、代码修改质量。以下四个诊断路径覆盖了约 90% 的首跑失败场景。

OpenCode 调用失败

先按顺序跑这四个诊断：

clawhub list | grep opencode
opencode --version
opencode auth list
openclaw logs --limit 50 | grep -iE "opencode|moonshot|deepseek|glm|doubao"

常见原因：

1. opencode 技能未安装：执行 clawhub install opencode。
2. 模型 API Key 未设置或过期：检查 MOONSHOT_API_KEY / DEEPSEEK_API_KEY / ZAI_API_KEY / VOLCENGINE_ARK_API_KEY 是否写入 Shell 启动脚本。
3. OpenCode 二进制不在 PATH 中：检查 ~/.local/bin 是否在 $PATH。
4. 模型额度耗尽：去对应平台的计费页查当月用量（Kimi 在 platform.moonshot.ai/billing，DeepSeek 在 platform.deepseek.com/usage）。

PR 创建失败（Permission denied）

cd /workspace/repos/your-repo
git commit --allow-empty -m "test push"
git push origin test-push
gh auth status

常见原因：

1. Fine-grained Token 没有勾选目标仓库。
2. Token 已过期（默认 30 天）。
3. 组织仓库需要单独的 SSO 授权（登录 GitHub 组织页手动授权）。
4. git-credentials 中的用户名拼错。

Copilot 审查一直 pending

1. 仓库未启用 Copilot 自动审查（回到上一节的 Rulesets 路径检查）。
2. 组织未开通 Copilot Business / Enterprise 许可。
3. PR 改动文件数 > 300，Copilot 可能超时。
4. PR 含大体积二进制文件。

代码修改不符合预期

1. 仓库缺少 AGENTS.md，OpenCode 没有足够上下文。
2. 需求描述过于模糊：改为在飞书里指定具体文件路径。
3. 仓库体量过大：在需求中限定"只修改 src/api 下的文件"。
4. 模型能力不足：/models 切换到更强模型（例如把 GLM-4.5-Air 换成 GLM-4.7 或 Kimi K2.5）。

常见问题（FAQ）

Vibe Coding 需要会编程吗？

不需要会写代码，但需要能说清楚需求。产品经理或设计师可以用自然语言描述"把首页标题从 X 改成 Y"，OpenClaw 和 OpenCode 会完成具体改动并提 PR。最终是否合并仍由有写权限的开发者确认。

只用飞书能给公司代码库提 PR 吗？

可以。前提是服务器上的 OpenClaw 机器人已经接入飞书通道、OpenCode 已安装并配好模型 API Key、GITHUB_TOKEN 已授权目标仓库。达成这三条后，飞书里的一句话即可驱动一次完整的 PR 流程。

Vibe Coding 会不会把测试或密钥误改掉？

OpenCode 默认只做代码变更与建议，不会自动合并。涉及敏感文件（.env、密钥、CI 配置）时需要在 AGENTS.md 里显式标注"不要修改"。生产仓库建议同时启用分支保护，强制 PR + 人工审批。

四家模型怎么选？

按三条标准择优：任务复杂度（长上下文重构优先 Kimi K2.5 的 256K 窗口；短平快改动用 DeepSeek-V3.2 或 GLM-4.5-Air 即可）、预算（DeepSeek 按量计费单价最低，GLM 提供月付 Coding Plan）、延迟（就近机房，国内访问火山方舟 Ark 最稳）。切换只需 /models 重选，无需改代码。

安装了 opencode 技能还需要装 github 技能吗？

首跑不需要。OpenCode 自带 gh 调用，能直接创建 PR。github 技能的作用是让 OpenClaw 主动轮询 PR 审查状态并回推飞书通知，属于增强能力，最小闭环跑通后再加。

OpenCode 和 GitHub Copilot 是竞品吗？

不是。在 Vibe Coding 架构里它们是协作关系：OpenCode 写代码并提交 PR，GitHub Copilot 审查 PR 并留意见。一个做"生产者"，一个做"质检员"。

生产环境可以开全自动合并吗？

不建议。全自动模式（Copilot approved → 自动 merge）仅适合低风险仓库（文档、个人项目）。生产仓库必须保留人工合并环节，并同时配置 Rulesets 下的 Require approvals。

模型 API 额度不够怎么办？

登录对应平台的用量页：Kimi platform.moonshot.ai/billing、DeepSeek platform.deepseek.com/usage、智谱 open.bigmodel.cn/usercenter、火山方舟 console.volcengine.com/ark。短期可升级套餐或开通 Coding Plan 月付包；长期建议按需求分配独立 API Key 与预算上限，隔离不同项目成本。

飞书之外还能用企业微信、Slack 吗？

可以。OpenClaw 的消息编排层与具体 IM 通道解耦，只要把对应通道的 Bot Token 按官方文档配置进去即可。OpenClaw 原生支持飞书、Telegram、Discord、iMessage、Slack 等十余种工具。

部署清单总结

回到整体流程，Vibe Coding 的部署可以归结为下面这张清单：

1. 服务器：已接入飞书的 OpenClaw 机器人 + 工具配置档设为 coding。
2. 凭证：模型 API Key（Kimi / GLM / DeepSeek / Doubao-Seed-Code 四选一）+ GitHub Fine-grained PAT。
3. CLI：OpenCode 原生安装 + gh CLI 官方源安装，二者均通过 --version 校验。
4. 技能：skill-vetter → opencode → 可选 github，按此顺序安装。
5. 工作区规则：仓库根目录 AGENTS.md 写项目规范；~/.openclaw/workspace/IDENTITY.md 写编排策略。
6. 仓库配置：Settings → Rules → Rulesets 配置分支保护 + Copilot 自动审查。
7. 首跑任务：从一条可逆的小改动开始（例如改 README），确认闭环后再扩展到多文件重构。

完成上述七步后，把飞书里的一句话变成一次合规 PR 的全链路就跑通了。

如果不想手动搭建服务器、装依赖、配置通道，可以使用 Claw龙虾部署大师完成 OpenClaw 机器人的一键部署，部署完成后直接进入本文的"启用编码能力"步骤，跳过基础环境搭建。这一步是可选的，对手动部署流程没有强依赖。