新工作的第一周是一连串琐碎、略显尴尬的问题。这个栈里怎么 tail 日志？连 staging 数据库的约定是什么？部署失败时去哪看？ 每个资深都记得自己问过这些问题，也记得五年后还在回答它们。两边都付代价：新人觉得自己慢，资深每天因上下文切换损失半小时。
CliAI 不替代师徒。它把能自助的问题压到几乎零。
真实的第一周场景
一位新工程师加入后端团队。生产是 Kubernetes，staging 是个小集群，可观测性走 Loki 和 Prometheus。到周三，需要调试一个仅在 staging 失败的不稳定测试。
问题 1：「日志在哪？」
clai
$ clai 流式查看 staging 中 api deployment 最近一小时的日志，只要错误→ kubectl -n staging logs -l app=api --tail=-1 --since=1h \ | grep -i error命令展示了结构：namespace 在哪、label-selector 约定、时间窗口标志。一周下来运行类似命令，新人不用谁讲解就吸收了团队对 kubectl 的口味。
问题 2：「怎么进 staging 数据库？」
clai
$ clai 把 staging 的 postgres 端口转发到本地 5432→ kubectl -n staging port-forward svc/postgres 5432:5432新人学到我们不 ssh 进 pod，而是对 service 做 port-forward。CliAI 自然带出团队规范。
问题 3：「上次部署为什么失败？」
clai
$ clai 显示 staging 中 api deployment 过去 30 分钟的事件→ kubectl -n staging get events --sort-by=.lastTimestamp \ | grep api | tail -20为什么比 runbook 强
runbook 是静态的。团队栈在漂移：有人从 Loki 迁到 OpenSearch，有人换 namespace 命名约定，有人加了个 Istio sidecar、要求不同的 exec 参数。runbook 永远滞后。CliAI 针对问题生成，而不是针对一张快照。
CliAI 不会做的是解释为什么。它能给出正确 kubectl；但不会告诉新人「staging 是唯一启用旧 auth 路径的环境，所以这个测试 flaky」。那段对话仍然属于资深。