2026 年了，AI 编程工具基本能用了，但选型依然是个事。本文按我作为基础设施运维工程师的实际使用场景做对比，不站队，给场景化建议。

候选工具

• Claude Code：Anthropic 出的 CLI Agent，目前能力最顶
• opencode：开源 Agent CLI，模型可换
• Cursor：VSCode fork，IDE 集成最好
• Continue：VSCode 插件，自托管友好
• Codex CLI：OpenAI 出的 CLI Agent，绑 ChatGPT 订阅

运维特有的需求

跟纯写代码的开发不一样，运维有几个特殊需求：

1. 能跑命令：不只是写脚本，要能 kubectl apply / ceph -s
2. 能 SSH 到远端机器：不是所有事都在本地
3. 能持久化"集群上下文"：每次都要解释一遍 cluster 信息很累
4. 谨慎的破坏性操作确认：误删 PVC 是要命的事
5. 多机/多集群并发能力：批量巡检场景

实测对比

Claude Code

• ✅ 工具用得最聪明，会主动 ls / grep 摸清状况
• ✅ Skills 体系适合封装运维 SOP（见我另一篇）
• ✅ Bash 工具能配 sandbox（命令白名单），生产可用
• ❌ 没有 Pro 订阅给第三方工具用的口子，重度用就是按 token 烧
• ❌ 多机并发要自己拼脚本

适用：日常单集群运维、写 IaC、做架构设计

opencode

• ✅ 开源，model 可换（甚至能接自部署 Llama）
• ✅ 配合 Hermes-agent 能省钱
• ✅ provider 抽象好，切模型不痛苦
• ❌ tool use 稳定性不如 Claude Code，复杂任务偶尔抽风
• ❌ skill 体系不如 Claude Code 成熟

适用：注重成本、想自托管、能容忍偶尔抽风的场景

Cursor

• ✅ IDE 体验最好，diff 视图直接接受拒绝
• ✅ codebase 索引强，问"X 在哪用"特别准
• ❌ 在终端跑命令的能力一般，不适合"做事"
• ❌ 服务器上 SSH 干活用不了

适用：本地写代码 / 写 manifest YAML / 写 ansible playbook

Continue

• ✅ 完全开源，能接私有模型
• ✅ 配置全 yaml，纯 Vim/IDE 玩家舒服
• ❌ Agent 能力一般，更像"加强版补全"
• ❌ tool ecosystem 弱

适用：合规要求严格、必须自托管、用法偏 inline 补全的团队

Codex CLI

• ✅ GPT-5.x 推理强，复杂调试好用
• ✅ ChatGPT 订阅可用
• ❌ tool use 设计不如 Claude Code 优雅
• ❌ 生态比较封闭

适用：已有 ChatGPT 订阅、习惯 OpenAI 风格的人

我自己的组合

不要相信"一个工具搞定一切"。我现在的栈：

• 服务器上日常运维：Claude Code，重度用
• 本地写 Terraform / Ansible / K8s YAML：Cursor
• 跑小批量自动化、试新模型：opencode + Hermes
• 临时跑个想法、不想配环境：claude.ai 网页版

成本：每月 ~200 美刀（Claude 占大头），换算成节省的时间，回本毫无压力。

几条选型反模式

❌ 追新模型频繁切：每次切都要重新建立工作流，得不偿失
❌ 只看 benchmark：跑分高的模型未必擅长你的场景
❌ 完全替代手工 review：AI 改的 PR 一定要看 diff，尤其涉及 IaC
❌ 私密集群信息直接喂给 SaaS 模型：明文 secrets、内网拓扑都要脱敏

选型 checklist

回答这 5 个问题再选：

1. 你的工作有多大比例在终端？（>50% 选 CLI Agent）
2. 你愿意每月花多少钱？（>100$ 选 Claude，<50$ 选 opencode+订阅模式）
3. 数据合规要求？（严的话只能 Continue + 私有模型）
4. 团队还是个人？（团队要选 skill 体系成熟的）
5. 是写代码为主还是做事为主？（写代码选 IDE，做事选 CLI）

教训一句话：工具不是越新越好，选一个用熟，比同时用三个都半生不熟值。

Claude Code 的 Skills 是从 1.x 之后逐渐成型的能力扩展机制，本质是"把一段 markdown 提示词 + 一组 tool 调用约定打包，按需触发"。本文按我自己用了几个月的体感，讲透它的工作原理和写法。

Skill 是什么

最简形态就是一个 SKILL.md：

~/.claude/skills/my-skill/SKILL.md

文件头是 YAML frontmatter，正文是给 Claude 看的指令：

---
name: my-skill
description: 触发条件描述，Claude 看这段决定要不要用
allowed-tools: [Bash, Read, Edit]
---

当用户说 X 的时候，你应该 ...

触发方式有两种：

1. 用户主动：/my-skill 显式调用
2. 自动触发：Claude 看到对话内容匹配 description 就自动加载

一个真实例子：K8s 运维 skill

我团队有个内部 skill kubernetes-ops，触发条件写：

description: Kubernetes 集群智能运维 skill。用户描述目标、现象、资源名或业务问题时，
  Agent 自主完成资源识别、命名空间定位、健康排查、发布核查、故障诊断。

我说"看下 prod 集群里那个 cms 服务为啥 503"，Claude 自动加载这个 skill，里面有：

• 集群连接信息（kubeconfig 路径）
• 命名空间映射表（cms → prod-cms）
• 排查 SOP（先看 endpoints → 再看 pod → 再看 ingress）
• 变更前确认模板

不用我每次都给上下文。

写 skill 的几个原则

1. description 是命脉

Claude 不读 skill 正文，只读 description。description 写不清楚，再好的 skill 也不会被自动调用。

好的 description 包含：

• 场景关键词（"K8s 集群"、"OpenStack 实例"）
• 输入形式（"用户描述目标 / 资源名 / 现象"）
• 不该触发的反例（"非运维场景不要触发"）

2. 正文按"决策树 + 模板"组织

别写成长篇大论。Claude 是按需读的，结构化更好命中：

## 触发后的第一步
立刻读 `cluster.yaml` 拿到 kubeconfig。

## 排查 SOP
1. ...
2. ...

## 变更前 checklist
- 是否生产环境？
- 是否有备份？

3. 用 allowed-tools 约束工具

不写 allowed-tools 时 skill 能用全部工具。生产 skill 一定要列白名单，避免误删：

allowed-tools: [Read, Bash(kubectl get *)]

Bash(kubectl get *) 是命令级 sandbox，只允许 kubectl get 开头的命令。

4. 引用外部文件用相对路径

具体集群信息见 `./clusters.json`。

skill 加载时 Claude 会读这个文件，相对路径基于 skill 目录。

init skill：怎么给一个新项目做上下文

内置的 /init 会扫描项目，生成 CLAUDE.md。我个人的最佳实践：

1. /init 跑一遍生成草稿
2. 手动补充：分支策略、测试命令、特殊约定
3. 删掉所有"显而易见"的内容（"用 git 管理版本"这种没用）

CLAUDE.md 越短越好，每行都得是"不读会出问题"的信息。

全局 skill vs 项目 skill

• ~/.claude/skills/：全局，所有项目可用
• <project>/.claude/skills/：项目级，只在该项目目录下生效

我的习惯：

• 全局：通用工具（k8s-ops、openstack-ops、git-flow）
• 项目级：业务 SOP（"如何发布"、"如何回滚"）

别滥用 skill

skill 的"自动触发"特性意味着每次对话开始 Claude 都会扫 description 列表。100 个 skill 你 context 就废了。我自己的上限是 15 个，按季度清理一次。

教训一句话：skill 是"压缩的提示词 + 工具白名单"，把 description 写清楚比把正文写漂亮重要 10 倍。

公司内部用 GPT/Claude 有数据合规风险。本文记录我们私有化部署 LLM 给 50 人小团队用的方案。

选型

50 人小团队推荐 Qwen2.5-32B，性价比最好。

推理框架：vLLM

vLLM 是当前最快的开源推理框架，PagedAttention 让吞吐量比 transformers 高 10 倍。

pip install vllm

vllm serve Qwen/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --port 8000

服务起来后兼容 OpenAI API：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-32B-Instruct","messages":[{"role":"user","content":"你好"}]}'

加 Web UI

LobeChat 或 OpenWebUI 是开源 ChatGPT 风格 UI：

# docker-compose.yml
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OPENAI_API_BASE_URL=http://vllm:8000/v1
      - OPENAI_API_KEY=dummy
    ports:
      - "3000:8080"

接入 OIDC 单点登录

OpenWebUI 支持 OIDC：

environment:
  - ENABLE_OAUTH_SIGNUP=true
  - OAUTH_CLIENT_ID=...
  - OAUTH_CLIENT_SECRET=...
  - OPENID_PROVIDER_URL=https://sso.company.com/.well-known/openid-configuration

接入公司 SSO 后员工免注册直接用。

接入 Claude Code / opencode / Cursor

所有兼容 OpenAI API 的客户端都可以接：

Claude Code 不行（专绑 Anthropic API），但 opencode 支持自定义 provider：

{
  "provider": {
    "internal-qwen": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://internal-llm.company:8000/v1",
        "apiKey": "dummy"
      },
      "models": {
        "qwen2.5-32b": { "name": "Qwen 2.5 32B" }
      }
    }
  }
}

监控

vLLM 自带 Prometheus metrics：

http://localhost:8000/metrics

关键指标：
- vllm:num_requests_running：当前在跑的请求
- vllm:num_requests_waiting：等待队列长度
- vllm:time_to_first_token_seconds：首 token 延迟
- vllm:e2e_request_latency_seconds：端到端延迟

队列长度持续 >10 说明 GPU 不够。

容量规划

50 人团队实测数据：

• 平均 QPS：2-3（峰值 8）
• 平均输入 token：2000
• 平均输出 token：500
• 单次延迟：2-5 秒

2 张 A100 80G + Qwen 32B 完全够用，每月电费 + 折旧 + 运维 ≈ ChatGPT Team 50 个 license 的成本。

几个坑

1. vLLM 不支持热更换模型：换模型要重启
2. batch size 调大有 OOM 风险：留 10% GPU 内存余量
3. 长上下文性能崩：32K 比 8K 慢 5 倍以上，业务能用 8K 就不要开 32K
4. 流式输出在某些客户端不工作：测试客户端兼容性

ROI 分析

ChatGPT Team / Claude Team license：~30 USD/人/月，50 人 = 1500 USD/月

私有化：
- 服务器 2×A100 80G：购置 30 万人民币（按 3 年折旧 = 8000 RMB/月）
- 电费 + 机房：~3000 RMB/月
- 运维（兼职 0.2 人）：~3000 RMB/月
- 合计：~14000 RMB/月

不算便宜，但数据不出公司这条对很多企业是硬要求。

教训：私有化 LLM 性价比的临界点是 50-100 人，再小就不如直接买 API。

Agent 跑偏是日常。本文是我反复调教 Agent 的提示词工程笔记。

反模式：让 Agent 自己"理解需求"

❌ "优化下这个文件的代码"

Agent 会按它认为的"优化"动手——可能改架构、可能换库、可能加注释。完全失控。

✅ "这个文件第 50-80 行是循环嵌套，重构成单次扫描。不要改函数签名，不要加注释。"

具体到行号、到约束、到禁止项。

反模式：奖励"努力"而非"结果"

❌ "详细分析一下这个 bug"

Agent 输出 500 字分析，然后说"建议进一步排查"，然后停了。

✅ "修复这个 bug，给我可运行的代码。如果定位不到根因，列出 3 个最可能的原因和验证方法。"

明确产出物：要么 fix，要么决策清单。

Pattern 1：用"角色 + 任务 + 约束 + 产出"四件套

你是 Linux 性能优化专家。
任务：分析下面的 perf 数据，找出 CPU 热点。
约束：
- 不要建议加机器
- 不要建议换语言
- 只看代码层面的优化
产出：
- 列 3 个最热的函数
- 每个函数给具体优化方法
- 预计性能提升幅度

Pattern 2：让 Agent 先回放需求

我要让你做 X。
**在动手前，用一句话总结你即将做的事，等我确认 OK 再执行。**

强制 Agent 把它理解的需求说出来，你能在它跑歪前抓住。

Pattern 3：给"反例"

只给正例 Agent 会过拟合。加反例：

任务：写一个 Bash 脚本备份 MySQL。

正例风格（参考）：
- 用 set -euo pipefail
- 每步都 echo 进度
- 失败要 exit 非 0

反例（不要这样）：
- 不要用 mysqldump > /backup/$(date)，因为 date 没引号会出空格
- 不要用 sleep 然后 polling，用 wait 或者 trap
- 不要 silent fail

Pattern 4：长任务用 checkpoint

这个任务有 5 步。
每完成一步，输出：
✓ Step N: <做了什么>，<关键产出>
然后等 30 秒（用 sleep 30）让我有机会打断。

让 Agent 在每个 checkpoint 停一下，你能控制进度。

Pattern 5：给"Agent 工作日志"模板

解决问题时，按这个格式输出：
- 假设：我认为问题是 ...
- 验证：跑这个命令 ...
- 观察：看到 ...
- 结论：所以 ...
- 行动：因此我会 ...

如果观察推翻假设，重新出一组。

把 Agent 的内部推理外化，方便你审查。

Pattern 6：禁止开放性结尾

❌ "任务完成。如有问题随时告诉我。"（Agent 默认这种结尾）

✅ 在提示词里加：

完成后不要写"如有问题告诉我"或"需要可以继续"。
只输出：
- 改了什么文件
- 验证命令
- 失败的边界场景

Pattern 7：用 example 引导

任务：写一个 K8s YAML 部署 redis。

参考这个 nginx 部署的格式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  ...

注意：
- labels 风格要一致
- replicas 默认 3
- 资源 requests/limits 必填

给一个完整 example 比写 10 条约束更有效。

最后

Prompt engineering 不是玄学，本质是让 Agent 的不确定性 → 你的确定性。每一句话都在缩小可能的输出空间。

教训：好提示词 = 角色明确 + 任务具体 + 约束清晰 + 产出可验证 + 反例兜底。

Claude Pro / Max 不支持第三方工具用 OAuth 登录（只 API Key），但 OpenAI 反而是 ChatGPT 订阅可以通过 Codex CLI 的 OAuth 拿到对 GPT-5.x 的访问权。这篇记录我用 opencode + Hermes-agent 把这条路串起来的过程。

工具栈是啥

• opencode：开源 AI Agent CLI，类似 Claude Code，模型层抽象做得不错
• oh-my-opencode：opencode 的配置增强（主题、插件、provider 模板）
• Hermes-agent：独立的 Python agent，封装了 Codex 的 OAuth 流程

三者关系：opencode 负责"做事"（编辑文件、跑命令），Hermes-agent 负责"出脑子"（通过 ChatGPT 订阅调 GPT-5.x）。

为什么这么折腾

• Claude API Key 按 token 算，重度用每月几百刀
• ChatGPT Pro/Plus 订阅 20 刀，包含 Codex CLI 用 GPT-5 的额度
• Anthropic 不允许 Pro/Max OAuth 给第三方工具用，所以同样的"白嫖订阅"路径在 Claude 这边走不通

如果你已经有 ChatGPT 订阅，这套方案能省不少钱。

安装步骤

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

# 2. oh-my-opencode（配置增强，可选但强烈推荐）
git clone https://github.com/oh-my-opencode/oh-my-opencode ~/.opencode/oh-my-opencode

# 3. Hermes-agent
git clone <hermes repo> ~/.hermes
cd ~/.hermes && pip install -e .

注意：opencode 和 oh-my-opencode 都安装到 ~/.opencode/，~/.config/opencode/ 是早期版本的目录，新版别用了。

配置 OAuth

Hermes-agent 启动一次会弹浏览器走 Codex OAuth：

hermes login
# 浏览器跳到 chatgpt.com 授权 → 回调拿 token → 存到 ~/.hermes/credentials.json

token 默认有效期一周，到期再 hermes login 续就行。

opencode 接 Hermes provider

在 ~/.opencode/opencode.json 配 provider：

{
  "provider": {
    "hermes-codex": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Hermes (GPT-5 via Codex OAuth)",
      "options": {
        "baseURL": "http://127.0.0.1:8765/v1",
        "apiKey": "dummy"
      },
      "models": {
        "gpt-5.4": { "name": "GPT-5.4" }
      }
    }
  }
}

Hermes-agent 启服务：

hermes serve --port 8765

之后 opencode 里选 model 就能看到 hermes-codex/gpt-5.4。

几个坑

1. OAuth token 短命：一周内必续，写个 cron 提醒自己
2. ChatGPT 订阅有 rate limit：用得猛会触发，别拿来跑批
3. Codex 的 GPT-5 不是公开 API 的 GPT-5：context window 和 capability 有差异，吃 tool use 不如直连 API 稳
4. Hermes-agent 不是 opencode 一部分：升级 opencode 不会动 Hermes，反之亦然，别混在一起调试

适用场景

• 个人项目、学习、做小工具：强推
• 公司生产、对 SLA 有要求：别，OAuth 随时可能被官方堵死
• 想要 Claude 的能力：这套方案接不到 Anthropic，老老实实买 API Key

教训一句话：opencode 是工具，Hermes 是省钱通道，两者解耦让你能随时切回正经 API Key，别把它们当一个东西。