把常见 AI 编程工具的接入流程，整理成一套更容易上手的中文文档。

是什么

把它理解成“长期待在终端里的代码协作者”会比较容易：你给目标、边界和上下文，它负责理解仓库、提出步骤、生成补丁，并在必要时配合命令执行。

• 适合处理跨文件修改、重构、测试补全、文档整理这类需要连续推理的工作。
• 比单次问答更强调“计划 → 执行 → 检查”的过程，因此更适合真实工程环境。
• 如果你已经有代理地址或统一网关，通常可以把它接到同一套模型配置上。

环境要求与安装思路

在正式装工具前，先确认终端、Git、项目依赖管理器和路径变量都已就绪。终端型助手最常见的问题不是模型本身，而是 PATH、权限和工作目录混乱。

安装命令会因发行版不同而变化。建议优先使用官方发布页、包管理器或团队内打包版本，并在安装后立即做版本检查。

API 配置

一般只需要三项：密钥、接口地址、默认模型名。若你走的是兼容层或代理层，把 Base URL 配好往往比反复换密钥更重要。

ANTHROPIC_API_KEY=replace-with-your-key
ANTHROPIC_BASE_URL=https://your-provider.example/v1
CLAUDE_CODE_MODEL=your-default-model

如果你接的是统一服务入口，也可以把多个工具都指向同一个 Base URL，再用各自的模型名和限流策略区分用途。

基本使用

1. 在仓库根目录启动工具，先让它用只读方式概览项目结构。
2. 明确告诉它边界，比如“先出三步计划，不要立刻修改”。
3. 确认计划合理后，再让它按模块逐步提交改动，避免一次改太多。

一个实用的开场方式是：先让它解释入口文件、状态管理、构建流程，再进入具体编码任务。这样生成的补丁通常更稳。

常用命令与提示方式

• 只读分析：“先分析，不修改，告诉我入口文件和数据流。”
• 小步改动：“先修改一个文件并给出 diff，再继续下一步。”
• 验证优先：“改完后只运行和本模块相关的测试，不要扫全量。”
• 风险控制：“遇到删除、覆盖、重命名操作前先停下来征求确认。”

这类工具最重要的不是“背命令”，而是把任务目标、范围和停止条件说清楚。

MCP 接入思路

MCP 可以理解成一层“额外能力接线板”。当你希望工具安全地访问浏览器、文档库、Issue 系统或内部脚本时，MCP 会很有用。

{
  "servers": {
    "workspace-docs": {
      "command": "node",
      "args": ["./scripts/mcp-docs-server.js"],
      "env": {
        "DOCS_ROOT": "./docs"
      }
    }
  }
}

建议只开放完成任务所需的最小能力，不要把整个系统权限都暴露给代理层。

技巧

• 用“先计划，再执行”的方式开场，能显著降低跑偏率。
• 把大任务拆成可以独立回滚的小补丁，便于审查。
• 让它先复述需求，再开始改代码，可以提前暴露理解偏差。
• 涉及外部系统时，先让它生成操作清单，不要直接触发高风险动作。

FAQ

是什么

Roo Code 更像“编辑器侧的工作搭子”。它的优势不在于命令行执行，而在于你可以一边看文件、一边圈定范围、一边让 AI 修改当前上下文。

• 适合 UI 调整、单文件重构、对当前选区解释或补齐实现。
• 在需要快速试错、频繁查看代码细节时，插件型体验通常比终端型更顺手。
• 如果你习惯用工作区规则控制风格和约束，这类工具也更容易落地。

安装插件

做法通常很直接：在支持的编辑器市场中搜索插件、安装、授予工作区信任，然后重启编辑器。第一次启动时建议只打开一个小项目来做验证。

如果编辑器本身带有代理或同步设置，先确认它不会拦截你的 API 请求，再继续填入密钥。

API 配置

插件类工具一般会把提供商设置放进图形界面：选择 Provider、填写 Base URL、输入 API Key、选择默认模型，然后保存。

{
  "provider": "custom-compatible",
  "baseUrl": "https://your-provider.example/v1",
  "apiKey": "replace-with-your-key",
  "model": "your-default-model"
}

若你有多个模型，建议分别配置“对话型”“代码生成型”“长上下文型”三种预设，避免频繁改参数。

基本使用

1. 打开项目后，先让工具解释当前目录或当前文件的职责。
2. 处理单个改动时，用选区或文件标签把范围限制在最小可行单元。
3. 让它先输出实现思路，再决定是否应用更改。

对插件型工具来说，“当前上下文”就是最大的优势。你只要善用选区、打开的标签页和工作区边界，它的答复就会更贴近你眼前的代码。

技巧

• 为项目准备一份简短的工作区规则，统一命名方式、测试要求和禁止事项。
• 改 UI 时附上期望效果，改后端时附上输入输出示例，提示会更稳。
• 不要把所有打开文件都塞给模型；保持上下文干净，回复更准确。
• 遇到大改动时，先让它拆成多个提交建议，而不是一次应用整块变更。

FAQ

是什么

这类工具的核心价值在于“你能控制它怎么连模型、怎么保存默认值、怎么为不同项目切换不同策略”。如果你经常在多个服务商之间切换，OpenCode 会比较顺手。

安装

安装方式通常分为两条：使用发行版提供的包管理器命令，或者直接下载二进制文件加入 PATH。完成后先跑一次帮助命令或版本命令，确认入口已可用。

# 方式 A：使用你选择的包管理器安装
<package-manager> install <opencode-package>

# 方式 B：验证命令入口
opencode --help

服务商配置

先选一个默认 Provider，再补上备用 Provider，是比较稳妥的做法。默认 Provider 用于日常开发，备用 Provider 用于高峰期或模型策略切换。

• 把 Base URL、默认模型、超时和重试策略明确下来。
• 如果你要走统一兼容层，优先确认模型名映射规则。
• 不同 Provider 的限流策略可能不同，必要时为编码任务单独设定并发。

配置文件

OpenCode 往往允许全局配置和项目配置并存。推荐做法是：全局里放默认 Provider，项目里只覆盖模型、上下文长度和实验参数。

{
  "provider": "primary-gateway",
  "baseUrl": "https://your-provider.example/v1",
  "apiKeyEnv": "AI_API_KEY",
  "model": "your-default-model",
  "temperature": 0.2,
  "maxTokens": 16000
}

基本使用

首次进入项目时，先让它读取目录结构并生成一份概览；随后再发具体任务，例如“补测试”“重写 README”“解释部署脚本”。这种流程比一上来直接改代码更稳。

如果你的项目需要不同模型完成不同任务，建议把它们分别配置成“说明型”“编码型”“长上下文型”三个档位。

技巧

• 项目级配置尽量只覆盖必要字段，避免和全局配置冲突。
• 温度参数建议保持偏低，尤其在生成补丁和配置文件时。
• 把常用提示词整理成模板，例如“先解释、后改动、最后验证”。
• 记录每个项目最终使用的模型与 Provider，方便复盘和迁移。

FAQ

是什么

你可以把 Codex 看成“会计划的终端助手”。它通常不会只给一段代码，而是会先理解任务，再决定下一步要读哪些文件、改哪些内容、运行哪些验证。

• 适合修 bug、补文档、加测试、搭脚手架等需要逐步落地的任务。
• 如果你注重执行边界、审阅节奏和变更可追踪性，这类工具会比单轮对话更实用。

安装

Codex 一般通过终端分发，安装后建议马上确认版本号、帮助信息和工作目录权限是否正常。若你的环境有公司代理或自建入口，先把网络路径确认好。

若你使用的是 Node 发行版、独立二进制或团队封装版本，实际安装命令会不同；以你所选分发方式为准即可。

配置

Codex 侧最常见的配置是密钥、Base URL、默认模型、沙箱策略和审批模式。团队场景下，建议把“是否允许写文件、是否允许执行命令”这些策略提前约定。

OPENAI_API_KEY=replace-with-your-key
OPENAI_BASE_URL=https://your-provider.example/v1
OPENAI_MODEL=your-default-model
CODEX_APPROVAL_MODE=on-request

基本使用

1. 在项目根目录启动，先让它总结代码结构和风险点。
2. 对于中等以上任务，要求它先列计划，再按步骤推进。
3. 每次执行后查看 diff，并让它说明为什么这么改。

一个很稳定的模式是：先让它只读理解，再让它给出修改方案，最后才进入实际写文件或运行验证。

常用命令入口

codex --help
codex --version

# 进入交互后，可以用自然语言描述任务：
# 先解释这个仓库的构建流程
# 先出计划，再改登录页
# 补两条和支付模块相关的测试

• 帮助命令用于确认当前发行版支持哪些参数。
• 版本命令用于排查团队内环境是否一致。
• 真正高频的是自然语言任务描述，而不是记忆很多短参数。

是什么

如果你担心 AI 在仓库里“看太多、改太多、跑太多”，OpenClaw 这类工具的价值就在于能把范围、权限、提示与执行策略收拢到一个更清楚的工作区里。

安装

常见做法包括安装 CLI、下载独立二进制，或使用团队打包好的版本。安装完成后，先确认工具能在终端中被识别，再进入工作区初始化。

初始化

初始化的目标是告诉工具：它应该在哪个目录工作、默认读写权限是什么、是否需要审批、以及优先连接哪一个模型入口。

# 以你所用发行版支持的命令为准
openclaw init
openclaw doctor

# 初始化后先确认：
# 1) 当前工作区是否正确
# 2) 模型配置是否可用
# 3) 审批和沙箱策略是否符合预期

配置

建议把配置分为两层：一层负责连接模型，一层负责限定行为。前者包含密钥、Base URL 和模型名；后者包含工作区根目录、审批模式和文件写入策略。

{
  "workspaceRoot": "./",
  "approvalMode": "on-request",
  "sandbox": "workspace-write",
  "provider": {
    "baseUrl": "https://your-provider.example/v1",
    "apiKeyEnv": "AI_API_KEY",
    "model": "your-default-model"
  }
}

基本使用

• 先声明任务目标和目录范围，例如“只处理 docs 目录，不动业务代码”。
• 再让工具给出计划和预计影响面，确认后再进入修改阶段。
• 对于需要执行命令的任务，优先采用审批模式，避免误操作。
• 每次完成后导出或记录关键 diff，方便团队审阅。

是什么

与终端型工具不同，Cherry Studio 更像一个多模型工作台。你可以在同一界面里切换服务商、保存常用提示、建立资料集合，并把不同任务分配给不同模型。

下载安装

桌面端安装通常最简单：下载对应系统版本、完成安装、首次启动后进入设置页。建议第一步就把自动更新与数据存储位置确认好。

API 配置

建议按服务商逐个添加，而不是一次导入一大堆模型。先把一个入口配置通，再复制出其他模型预设，这样最容易定位问题。

{
  "name": "Coding Gateway",
  "baseUrl": "https://your-provider.example/v1",
  "apiKey": "replace-with-your-key",
  "defaultModel": "your-default-model",
  "tags": ["coding", "shared"]
}

基本使用

1. 创建一个“编码助手”会话模板，把系统提示、默认模型和常用工具说明固定下来。
2. 为不同任务建立独立对话，例如“代码解释”“接口联调”“文档润色”，避免上下文相互污染。
3. 需要长期复用的信息，可以整理进知识库或素材库，而不是每次重新粘贴。

技巧

• 为模型打标签，例如“便宜”“长上下文”“代码强”，切换效率会高很多。
• 将常用系统提示保存成模板，避免每次手写。
• 把知识库分主题维护，避免把所有资料堆进一个大集合。
• 当你要把结论落地为代码时，再切回终端型或编辑器型工具执行会更稳。