每年盘点一次工具栈。本文是 2026 年的版本。

终端 / Shell

• 终端：iTerm2 / Wezterm（Wezterm 新晋黑马，GPU 加速）
• Shell：zsh + oh-my-zsh / fish
• Prompt：starship（跨 shell，rust 写的快）
• 复用：tmux（不可替代）+ tmux-resurrect 持久化
• 历史：atuin（云同步 + 全文搜索）

文件操作

• ls 替代：eza（带颜色、图标、git 状态）
• cat 替代：bat（语法高亮 + 行号）
• find 替代：fd（更快、更直观）
• grep 替代：ripgrep (rg)（10x 快）
• du 替代：dust（树状可视化）
• diff 替代：delta（git diff 颜值飞升）

进程 / 系统

• top 替代：btop（颜值 + 鼠标交互）
• 进程查看：procs
• 网络监控：bandwhich（按进程看带宽）
• 磁盘 IO：iostat / iotop（经典款没替代）
• systemd-cgtop：按 cgroup 看资源

K8s

• k9s：TUI K8s 客户端，必装
• kubectx + kubens：上下文切换
• stern：多 Pod 日志聚合
• kustomize：YAML 管理
• velero：备份恢复
• lens / k8sLens：图形化（CTO 演示用）

容器

• docker：还是 docker
• lazydocker：TUI Docker 管理
• dive：分析镜像层

监控

• Prometheus + Grafana：经典组合
• VictoriaMetrics：Prometheus 替代，更省内存
• Grafana Loki：日志聚合（轻量替代 ELK）
• Tempo：分布式追踪
• Pyroscope：持续 profiling

IaC

• OpenTofu：Terraform 的开源 fork（HashiCorp 改 license 后大家跑路）
• Pulumi：用编程语言写 IaC
• Ansible：仍然在用，但 K8s 时代占比降低
• Crossplane：用 K8s CRD 管基础设施

CI/CD

• GitHub Actions：默认选项
• Argo CD：GitOps 标杆
• Tekton：K8s 原生 CI/CD
• Drone：轻量替代

AI Agent / Copilot

• Claude Code：CLI Agent 首选
• Cursor：IDE 集成最好
• opencode：开源 + 可换模型
• GitHub Copilot：写代码补全够用
• Codeium：免费 Copilot 替代

数据库工具

• DBeaver：万能客户端
• TablePlus：颜值党
• dbmate：迁移管理
• pg_repack：PostgreSQL 在线 vacuum

网络 / 安全

• Wireshark：抓包祖宗
• mtr：traceroute 替代
• httpie / xh：curl 替代
• bruno：Postman 开源替代
• Tailscale：内网穿透神器

文档 / 知识

• Obsidian：本地 markdown 笔记
• Logseq：知识管理替代
• HackMD：协作 markdown
• Excalidraw：手绘风架构图

我的实际栈（每天必用）

iTerm2 + zsh + starship + tmux + atuin + eza + bat + rg + fd + delta + k9s + kubectx + stern + Claude Code + Cursor + Obsidian + Excalidraw + DBeaver + httpie + Tailscale

反潮流：还在用的"老古董"

• vim（neovim 也用，但 vim 肌肉记忆）
• screen（偶尔——比 tmux 老但有时更稳）
• ssh（永不替代）
• mysql client（CLI 比 GUI 快）

教训：工具栈不要追新——一年换一次，每次升级花一周适应。能用 5 年的工具才是真好工具。

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，别把它们当一个东西。