---

从 Docker Compose 到 K3s：单节点全栈迁移实战指南

本文记录了将一个包含 20+ 微服务的 AI 研发平台从 Docker Compose 迁移到 K3s 的完整过程，涵盖网络、存储、配置管理、推理服务对接等实际踩坑经验。

特别说明：整个迁移过程在纯内网环境下完成——服务器没有公网 IP，不能直接访问 Docker Hub、GitHub、Google。所有镜像拉取依赖阿里云内网镜像仓库，Docker 构建经常因为网络问题失败。但即便如此，2 天内完成了全部迁移。

背景

我们的 AI 研发平台（内部代号 AILab Platform）包含以下服务栈：

• 前端：两个 React 应用（代称 Portal Web 和 Insight Web）
• 后端：Go 微服务集群（用户中心、业务服务、文档处理、Agent 智能体）
• 基础设施：爬虫系统、知识库引擎（WeKnora）、OCR 服务、物体检测
• AI 服务：LLM 代理、Token 计算、Embedding 向量化、PaddleOCR

原来全部跑在单台 ARM64 服务器上的 Docker Compose 里。随着服务增多，配置散落、重启混乱、没有统一管理面板，决定迁移到 K3s。

环境约束：服务器在纯内网机房，没有公网。Docker Hub 被墙，GitHub 访问不稳定。镜像全部存在阿里云容器仓库（通过内网拉取），Docker 构建时基础镜像也需要走镜像源。这给构建部署带来了不少额外工作量——但 AI 帮我生成了所有镜像源切换、代理配置、跨架构构建的方案，我在服务器上执行。

第一步：从零搭建 K3s 环境

安装 K3s 和 Headlamp

全程和 AI 协作完成。第一步是安装 K3s 本体——一行命令搞定：

curl -sfL https://get.k3s.io | sh -

然后部署 Headlamp（K8s 的 Web 管理 UI）。最初尝试用 Helm 安装：

helm install headlamp headlamp/headlamp

结果报了一个奇怪的错误：proto: cannot parse invalid wire-format data。AI 分析后发现是 Helm 3.21 和 K3s 1.36 的 OpenAPI 校验不兼容，加了 --disable-openapi-validation 就过了——但 Helm chart 生成的配置不合适（端口、ServiceAccount 都有问题）。

最终改用官方 YAML 直接部署，然后逐步修复。

生成 K3s 配置文件目录

AI 读取了我们的 docker-compose.yml 和所有服务的配置文件，自动生成了 k3s/ 目录下的 19 个 YAML 文件，每个服务一个文件：

k3s/
├── 00-namespace.yaml          # 命名空间
├── 01-ailab-web.yaml          # 前端
├── 02-core-server.yaml        # 用户中心
├── 03-biz-server.yaml         # 业务服务
├── 04-aidoc-server.yaml       # 文档处理
├── 05-agent.yaml            # Agent 智能体
├── 06-crawlab-master.yaml     # 爬虫主节点
├── 07-crawlab-worker.yaml     # 爬虫工作节点
├── 08-namespace-yiai.yaml     # 第二个命名空间
├── 09-portal-server.yaml      # Portal 后端
├── 10-portal-web.yaml         # Portal 前端
├── 11-pandoc.yaml             # 文档转换
├── 12-token-server.yaml       # Token 计算
├── 13-ingress-portal.yaml     # Portal 路由
├── 14-traefik-add-port.yaml   # Traefik 端口扩展
├── 15-ingress-insight.yaml    # Insight 路由
├── 16-detection.yaml     #    物体检测
├── 17-weknora-app.yaml        # 知识库后端
├── 18-weknora-docreader.yaml  # 知识库文档解析
└── 19-markitdown.yaml         # MarkItDown 转换

每个文件包含 Deployment + Service，配置统一用 ConfigMap，数据用 hostPath。整个目录的结构是 AI 设计的——编号排序、按 namespace 分组、命名规范一致。

尝试 kompose 自动转换

最初尝试用 kompose convert 自动把 docker-compose.yml 转成 K8s YAML。结果发现：

• 配置文件挂载丢了：kompose 把 ./config.yml:/app/config.yml 这种 host 挂载忽略了
• PVC 是空的：数据卷变成了空 PVC，原有数据全丢
• 多文件配置丢失：mcp.json 等多文件配置被直接跳过

最终决定全部手写。AI 读取了 compose 文件 + 每个服务的配置文件 + 端口映射，逐个生成干净的 YAML，人工 review 后部署。

批量部署

# 一键部署所有服务
kubectl apply -f k3s/

然后逐个排查启动问题。AI 帮我建立了标准化的排查流程：

# 查 pod 状态
kubectl -n ailab get pods

# 看报错日志
kubectl -n ailab logs <pod-name>

# 进入容器调试
kubectl -n ailab exec -it <pod-name> -- sh

每个报错都是：贴日志给 AI → AI 分析原因 → 给出修复命令 → 我在服务器上执行 → 贴新日志。循环直到全部 Running。

Docker 镜像处理

大部分镜像在阿里云容器仓库，K3s 自动拉取。少数本地构建的镜像需要手动导入：

# 本地构建的镜像导入 K3s containerd
docker save <image> | k3s ctr image import -

有一个镜像名称写错了（少了 registry 前缀），K3s 默认去 Docker Hub 拉，报 403。AI 一眼看出是镜像名缺了完整路径。

内网构建挑战：Docker 构建时拉取基础镜像（如 python:3.11-slim）需要访问 Docker Hub，内网环境直接超时。AI 生成了 DaoCloud 镜像源和阿里云 PyPI 源的配置方案，还分析了 torch 427MB 大包下载哈希不匹配的问题（最终建议去掉 torch——token 计算不需要 GPU 库，镜像从 2GB 降到几百 MB）。我在开发机上构建推送，服务器上拉取部署。

第二步：Headlamp 踩坑之旅

Headlamp 的部署花了不少时间，踩了好几个坑：

坑 1：Token 缺失

Headlamp 安装后没有 ServiceAccount，登录需要 Token。AI 生成了完整的 SA + ClusterRoleBinding + Token 创建命令。

坑 2：端口不对

Headlamp 默认监听 4466 端口（不是文档暗示的 80）。Service targetPort 配的是 80，导致后端连不上，一直返回 503。

坑 3：NodePort 不通

改了 NodePort 后 curl 还是 Connection refused。ss -tlnp 看不到端口——因为 K3s 的 kube-router 用 iptables 模式，不创建监听 socket。但实际还是不通。

AI 深入排查了 iptables 规则，发现 kube-router 注入了 REJECT 规则拦截宿主机到 pod 的流量。解决方案：禁用网络策略。

坑 4：hostNetwork 端口冲突

尝试用 hostNetwork: true 绕过网络问题，结果 headlamp 监听的端口和 Pod 声明的 containerPort 不匹配，K8s 拒绝。最终改了 containerPort 为 4466 并配合 hostNetwork 解决。

第三步：Traefik 替代 Caddy

原来用 Caddy 做反向代理，两组路由：

• :80 → Portal 前端 + API
• :8084 → Insight 前端 + 4 个后端

K3s 自带 Traefik，功能完全重叠。但 Traefik 默认只有 :80 和 :443 两个入口，需要额外加 :8084。

迭代过程

第 1 轮：HelmChartConfig 配置 ports → 不生效
第 2 轮：改用 additionalArguments → 生效了
第 3 轮：patch Service 加端口 → 成功

每一轮都是 AI 分析 → 给出方案 → 我执行 → 贴结果。整个过程 30 分钟搞定。

停 Caddy

Traefik 和 Caddy 都监听 :80，必须先停一个。分两步：

1. 先部署好 Traefik Ingress 规则
2. 验证通过后停 Caddy

docker stop caddy && docker rm caddy

修改路由零成本

Caddy 时代改路由要 SSH 改 Caddyfile → 重启 Caddy → 有短暂中断。Traefik 时代在 Headlamp 里改 Ingress → Apply → 1-2 秒生效，零中断。

第四步：配置文件迁移

从 hostPath 到 ConfigMap

最初所有配置文件用 hostPath 挂载（和 Docker 时代一样，直接挂宿主机文件）。后来 AI 建议迁移到 ConfigMap：

	hostPath（最初）	ConfigMap（最终）
改配置	SSH 改文件 → 重启	Headlamp 里改 → Apply → 重启
迁移服务器	要带着整个目录	跟着 K8s 走
版本管理	没有	可导出存 Git

AI 把 5 个配置文件打包到一个 ConfigMap app-configs 里，通过 subPath 分别挂载。改完后所有配置统一在 Headlamp 管理。

localhost → Service DNS

迁移到 K3s 后，每个 pod 有自己的 localhost。所有配置中的 localhost 必须改为 Service DNS 名。AI 读取了所有配置文件，列出了全部需要改的地方：

# ❌ Docker 时代
agent_url: "http://localhost:18084"
crawlab_url: "http://localhost:8091/api"
chip_detection_url: "http://localhost:8800"

# ✅ K3s 时代
agent_url: "http://agent.8001:18084"
crawlab_url: "http://crawlab-master:8091/api"
chip_detection_url: "http://chip-detection:8800"

跨命名空间加后缀：http://token-server.yiai:8000。

停 Docker 容器

必须先停 Docker 容器再启动 K3s pod（端口冲突）。AI 设计了部署顺序：

# 1. 停 Docker Compose（释放端口）
docker compose down

# 2. 部署 K3s 服务（接管端口）
kubectl apply -f k3s/

# 3. 逐个验证
kubectl -n ailab get pods

架构总览

用户浏览器
  ├─ :80   → Traefik → Portal Ingress（Portal 前端 + API）
  ├─ :8084 → Traefik → Insight Ingress（Insight 前端 + 4 个后端）
  └─ :30080 → Headlamp（K8s 管理 UI）

内部服务（ClusterIP）:
  - Token 计算服务（跨命名空间调用）
  - Pandoc 文档转换
  - 物体检测服务
  - 知识库引擎（WeKnora App + DocReader）
  - MarkItDown 文档转换
  - 爬虫（Master + Worker）

外部依赖:
  - PostgreSQL / Redis / MongoDB（宿主机）
  - LLM 推理代理（one-api，局域网另一台服务器）
  - Embedding + PaddleOCR（NVIDIA GPU 服务器）

一、K3s 安装与关键配置

1.1 安装

curl -sfL https://get.k3s.io | sh -

1.2 禁用网络策略（重要！）

K3s 的 kube-router 默认注入 REJECT 规则，导致从宿主机访问 NodePort/ClusterIP 全部被拒：

# /etc/rancher/k3s/config.yaml
disable-network-policy: true

现象：curl 访问任何 NodePort 都返回 Connection refused，但 pod 之间互通。排查了很久才发现是 kube-router 的问题。

1.3 Traefik 替代 Caddy

K3s 自带 Traefik 作为 Ingress Controller，替代了原来的 Caddy 反向代理。

需要为不同应用组添加额外端口入口（如 :8084）。Traefik HelmChartConfig 的 ports 配置不生效（chart 版本兼容问题），最终通过 additionalArguments + 手动 patch Service 解决：

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    additionalArguments:
      - "--entryPoints.app8084.address=:8084/tcp"

kubectl -n kube-system patch svc traefik --type='json' \
  -p='[{"op":"add","path":"/spec/ports/-","value":{"name":"app8084","port":8084,"targetPort":8084,"protocol":"TCP"}}]'

二、Headlamp — K8s 管理 UI

部署 Headlamp 作为 Web 管理面板，替代命令行操作。

踩坑：默认端口不是 80

Headlamp 容器监听的是 4466 端口（不是文档里说的 80），Service targetPort 必须改成 4466，否则 503。

另外 K3s 1.36 的 kube-router 会拦截宿主机到 pod 的流量，用 hostNetwork: true 绕过。

Token 管理

使用 1 年有效期的 ServiceAccount Token（kubectl create token --duration=8760h）。也支持永久 Token（通过 Secret 关联 ServiceAccount），但内网环境 1 年够用。

三、服务迁移策略

3.1 服务分类

类型	示例	策略
无状态 API	业务服务、Agent	优先迁移，ConfigMap 管理配置
有状态数据	PostgreSQL、Redis、MongoDB	保留宿主机运行，k3s 通过 IP 访问
特殊硬件	GPU 推理、Ascend NPU	保留独立服务器，k3s 通过网络调用
前端静态	React 应用	迁移到 k3s，走 Ingress

3.2 Deployment 关键设计

hostPort vs ClusterIP：

• 需要外部直接访问的服务用 hostPort（保持和 Docker 时代相同的端口号）
• 内部服务用 ClusterIP（pod 间通过 Service DNS 调用）

strategy: Recreate：

所有使用 hostPort 的 Deployment 必须设 strategy: Recreate，否则滚动更新时新旧 pod 抢端口导致 FailedScheduling。

spec:
  strategy:
    type: Recreate   # hostPort 必须用 Recreate

3.3 配置管理：ConfigMap 统一管理

将所有配置文件放入一个 ConfigMap，通过 subPath 分别挂载到不同服务：

# 一个 ConfigMap 管理所有配置
volumes:
- name: config
  configMap:
    name: app-configs
# 各服务通过 subPath 取自己的配置
volumeMounts:
- {name: config, mountPath: /app/config.yml, subPath: biz-config}

修改配置 → Headlamp 编辑 ConfigMap → Apply → 重启 pod。全程不用 SSH。

3.4 数据卷：hostPath

单节点 K3s 用 hostPath 最简单，数据在宿主机磁盘上，pod 重建不丢：

volumes:
- name: data
  hostPath:
    path: /data/app/service-data
    type: DirectoryOrCreate

四、跨命名空间服务调用

K8s 内部 DNS 自动解析 Service 名。同命名空间直接用名字，跨命名空间加后缀：

# 同命名空间
http://biz-server:3001

# 跨命名空间
http://token-server.yiai:8000

所有配置中的 localhost 必须改为 Service DNS 名，否则 pod 内的 localhost 指向 pod 自己，不是宿主机。

五、推理服务对接

5.1 LLM 代理（one-api）

业务服务通过局域网的 one-api 代理调用 LLM 模型。Eino 框架的 OpenAI adapter 要求 baseURL 必须包含 /v1：

# ❌ 不行
baseurl: "http://192.168.x.x:30888/one-api"

# ✅ 正确
baseurl: "http://192.168.x.x:30888/one-api/v1"

5.2 推理模型的 system 消息问题

最隐蔽的坑：Eino 框架可能发送多个 role: "system" 消息。官方 API（OpenAI、DeepSeek）的网关层会自动合并，但本地部署的模型服务器（vLLM/one-api）直通到 chat template，不支持多 system 消息 → 返回 400。

解决方案：在 HTTP 传输层自动合并多个 system 消息为一个（模拟官方 API 网关行为）。

5.3 maxTokens 硬编码问题

推理模型（如 Qwen3.6）需要大量 token 用于思考（reasoning），硬编码的 max_tokens: 4096 不够用，模型服务器直接返回 400。改为从配置读取 max_output_tokens。

5.4 Embedding 模型（vLLM）

Qwen3-Embedding-4B 部署在独立的 NVIDIA GPU 服务器上，通过 Docker Compose 运行 vLLM：

services:
  embedding:
    image: vllm/vllm-openai:latest
    command: >
      serve /model
      --served-model-name qwen3-embedding-4b
      --gpu-memory-utilization 0.35
      --max-model-len 4096
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

GPU 显存分配（32GB GPU）：

• Embedding 模型：0.35（~11GB）
• PaddleOCR：0.55（~17.6GB）

5.5 Token 计算服务别名

模型部署名和 HuggingFace 模型名不一致（如 internal-qwen-35b vs Qwen/Qwen3.6-35B-A3B），通过 MODEL_ALIASES 环境变量映射解决。

六、知识库（WeKnora）部署

WeKnora 需要独立的 PostgreSQL 数据库（不是主业务库），部署前手动创建：

CREATE DATABASE weknora;

API Key 采用自动注册机制：配置 api_key 留空 → 服务启动时自动注册管理员账号 → 获取 key → 缓存使用。

七、爬虫文件路径适配

爬虫系统（CrawLab）的 PDF 输出目录和文档处理服务的查找目录不一致，通过配置化的路径搜索解决：

"crawlConsumeJob": {
    "workspaceDir": "/data/pdfs",
    "extraSearchPaths": [
        "/data/workspace/{spider_id}/output/{file_name}"
    ]
}

{spider_id} 和 {file_name} 运行时自动替换。以后路径变了只改配置，不用改代码。

八、数据库迁移注意事项

Ent（Go ORM）

设 initdb=true 环境变量触发 Schema.Create()：

• 新增表/字段：✅ 自动
• 删除字段：❌ 不删（安全）
• 改字段类型：⚠️ 需手动 SQL

GORM

GORM 的 AutoMigrate 无法添加 NOT NULL 列到已有数据的表（PostgreSQL 拒绝），需手动加 DEFAULT：

ALTER TABLE ocr_files ADD COLUMN source VARCHAR(20) NOT NULL DEFAULT '';

另外 GORM v1 对 Updates(map) 中的 nil 值有参数编号 bug，改用 gorm.Expr("NULL")。

九、日常运维

常用命令

# 查看服务状态
kubectl -n <namespace> get pods

# 重启服务（改了 ConfigMap 后）
kubectl -n <namespace> rollout restart deployment <name>

# 查看日志
kubectl -n <namespace> logs -f deployment/<name>

# 进入容器调试
kubectl -n <namespace> exec -it deployment/<name> -- sh

修改 Ingress 路由

在 Headlamp 中 Network → Ingresses → Edit → Apply，Traefik 1-2 秒内实时生效，不用重启任何 pod。

添加新服务

1. 内部服务：Deployment + ClusterIP Service
2. 外部前端：加到现有 Ingress 的路径中
3. 配置：加到统一 ConfigMap
4. 数据：hostPath 挂载

十、踩坑总结

#	问题	根因	解决
1	helm install proto 错误	helm 和 k3s OpenAPI 不兼容	--disable-openapi-validation
2	NodePort 全部不通	kube-router REJECT 规则	disable-network-policy: true
3	Headlamp 503	默认端口 4466 不是 80	Service targetPort 改 4466
4	Traefik 自定义端口不生效	chart 版本不支持 ports 配置	additionalArguments + patch
5	推理模型 400 错误	多 system 消息 + maxTokens 太小 + 缺 /v1	三重修复
6	hostPort 滚动更新失败	新旧 pod 抢端口	strategy: Recreate
7	GORM 无法加 NOT NULL 列	PostgreSQL 拒绝无 DEFAULT	手动 ALTER TABLE 加 DEFAULT
8	GORM nil 参数 SQL 错误	GORM v1 参数编号 bug	gorm.Expr("NULL")
9	爬虫文件找不到	路径不匹配	配置化 extraSearchPaths
10	Token 别名不匹配	部署名 ≠ HuggingFace 名	MODEL_ALIASES 映射

总结

从 Docker Compose 迁移到 K3s 的核心收益：

1. 统一管理：Headlamp 可视化管理所有服务，不用 SSH
2. 配置集中：ConfigMap 统一管理，修改 → Apply → 重启
3. 自动恢复：Pod 崩溃自动重启，服务器重启自动恢复
4. 服务发现：DNS 自动解析，不用维护 IP 列表
5. 路由灵活：Ingress 改路径即时生效，不用改反向代理配置

迁移过程中最大的挑战不是 K8s 本身，而是各种框架（Eino、GORM、Ent）与本地推理服务器的兼容性问题。官方云服务（OpenAI、阿里云）的 API 网关会做大量容错处理，本地部署需要自己补上这些适配层。

---

附：我是如何与 AI 协作，2 天完成全栈迁移的

这部分不是技术文档，而是方法论分享。我从零接触 K8s，到 20+ 服务全部迁移上线，只用了 2 天。这不是因为我厉害，而是因为和 AI 协作的方式彻底改变了开发节奏。

传统开发 vs AI 协作开发

维度	传统方式	AI 协作方式
学习新技术	看文档 2 天 → 动手试 1 天	边做边学，AI 即时教学
写配置文件	查文档 + 复制粘贴 + 改	描述需求，AI 生成完整 YAML
排查问题	Google + Stack Overflow + 猜	AI 并行读代码 + 分析日志 + 定位根因
构建部署	手动操作，容易出错	AI 生成命令，我复制执行
写文档	最后补，经常忘	边做边记，AI 实时整理

核心技巧一：让 AI 读代码，而不是你读

整个迁移过程中最关键的提效点。当遇到报错时：

传统方式：你打开文件，一行行找问题，可能看半天。

AI 协作：直接告诉 AI “看下 provider.go 第 120 行附近的 Build 函数”，AI 秒读秒分析。更强大的是，AI 可以同时跨多个文件追踪调用链：

我：agent 调 LLM 返回 400
AI：（同时读了 6 个文件）
    → agent_factory_service.go: maxTokens 硬编码 4096
    → provider.go: HTTP 请求构造逻辑
    → chat_model.go (Eino 库): 自动加 stream_options
    → tool.go: 工具定义序列化格式
    → crawl_consume_job.go: 消息构造逻辑
    → 定位到多个 system 消息问题

这种跨文件调用链追踪是 AI 的强项。一个人同时看 6 个文件还要理解它们的关系，至少要 1 小时。AI 几秒就完成了。

核心技巧二：分层排查，快速排除

遇到复杂问题（比如推理模型返回 400），不是乱猜，而是系统性地分层排除：

第 1 轮：curl 直接测试 LLM API → 通 ✅（排除 LLM 服务本身）
第 2 轮：从 pod 内部 curl → 通 ✅（排除网络问题）
第 3 轮：加 HTTP 日志拦截，dump 完整请求体 → 发现多个 system 消息
第 4 轮：curl 模拟多 system 消息 → 400 ❌（定位根因）
第 5 轮：加合并逻辑，重新构建部署 → 成功 ✅

每一轮都是：提出假设 → 设计实验 → 执行验证 → 缩小范围。AI 帮你设计实验和生成验证命令，你在服务器上执行并贴回结果。分工明确，效率极高。

核心技巧三：让 AI 生成方案，我来执行

AI 不直接操作服务器，但它生成所有需要执行的命令和代码：

我：帮我生成构建推送命令
AI：docker build → docker push → kubectl set image（完整命令）
我：复制到开发机/服务器执行

这次迁移中，AI 生成了至少 10 个 Docker 镜像的构建脚本和部署命令。在内网环境下尤其有价值——Docker Hub 访问不了，每次构建都要处理镜像源、代理、网络超时。AI 分析问题并给出镜像源切换、依赖裁剪的方案，我在服务器上执行验证。

核心技巧四：边做边记

传统开发最后补文档，经常遗漏。AI 协作时：

做完一个功能 → "更新文档" → AI 实时追加到 markdown
踩了一个坑 → "记录踩坑" → AI 自动归档到踩坑清单

最终交付时，文档已经写完了。这篇 500+ 行的部署指南和博客，没有额外花时间写，都是开发过程中自然积累的。

核心技巧五：精准描述问题

AI 的回答质量取决于你给的上下文。最佳实践：

❌ 模糊提问：

“我的服务不工作了”

✅ 精准提问：

“ailab-biz-server 日志报 crawlab mongo 未配置，ConfigMap 里 crawlab_mongo 配在 Extend 下，附上完整配置内容”

附上报错日志、配置内容、相关代码路径，AI 能直接定位问题。不附上下文，AI 只能猜，来回沟通浪费时间。

一天的工作流示例

以第二天（解决问题日）为例：

09:00  贴 agent 400 报错日志 → AI 分析可能原因
09:15  AI 建议测 baseURL → 发现缺 /v1
09:30  加了 /v1 还是 400 → AI 深入读 Eino 源码
09:45  AI 发现 stream_options → 测试 → 排除
10:00  AI 建议加 HTTP 日志 → 构建 debug 镜像 → 推送
10:30  dump 出完整请求体 → 发现多个 system 消息
10:45  AI 验证假设 → 确认根因 → 写修复代码 → 构建 → 部署
11:00  内部模型聊天成功 ✅
11:15  处理 biz crawlab_mongo 缺失 → 改 ConfigMap
11:30  处理 aidoc PDF 路径问题 → 加 extraSearchPaths
12:00  处理数据库字段缺失 → ALTER TABLE
       ...下午继续处理 Embedding 部署、知识库初始化...

一天解决了 10+ 个问题，每个问题从发现到解决平均 15-30 分钟。传统方式一个都可能卡半天。

什么 AI 能做，什么你得自己做

AI 做	我做
读代码、分析逻辑	在服务器执行命令
写 YAML / Go / Python 代码	贴日志和报错给 AI
生成构建/部署命令	在开发机执行构建推送
写文档、整理踩坑记录	在浏览器测试功能
跨文件追踪调用链	做架构决策（选什么方案）
搜索网络查文档	确认改动符合业务需求
设计排查实验	最终验证（上线确认）

本质：AI 是你的分析师 + 代码生成器 + 文档员，你是决策者 + 执行者 + 测试者。AI 生成方案和代码，你在服务器上执行验证。

总结：为什么能 2 天完成

1. 零学习成本启动：不用先学 K8s，边做边学，AI 实时教学
2. 并行工作：AI 读代码、生成方案的同时，我在服务器上执行和测试
3. 快速迭代：从假设到验证只需几分钟（构建 + 推送 + 部署全自动化）
4. 跨领域：AI 同时处理 Go 代码、YAML 配置、PostgreSQL、MongoDB、Docker、网络
5. 文档同步：开发完成 = 文档完成，没有额外工作量

这不是"AI 替代开发者"，而是"AI 放大开发者能力"。我还是需要理解每一步在做什么、做架构决策、在服务器上执行和验证。但 AI 把分析和编码速度提升了 10 倍——读代码、写代码、生成命令、查文档，这些原来占 80% 时间的工作，现在几乎零成本。

如果你还在"AI 写一段代码我 review 一段"的模式，试试让 AI 全程参与：从架构设计到部署上线，给它终端访问权限，让它读你的代码库，让它动手构建和推送。你会发现自己变成了一个指挥官，而不是苦力。