CLI AI

从一行到入仓的脚本：什么时候该「毕业」

2026-04-15

CliAI 在「我这次要用一下」这一类工作上闪亮。80% 的场景。但还有一个更安静的类别：你反复重新生成的同形命令。在某个时刻，这条命令该有名字、有 code review、有自己在 scripts/ 里的位置。

三个成熟信号

你一周里把同一形态跑了三次。 不是同一条命令——同一种形态。周一*「tail staging 日志，grep FAILED」，周三「……grep ERROR」，周五「……grep timeout」*。形态是要进脚本的东西。

同事问你要这条命令。 如果他要把你的一行流复制到 Slack，那省下这个来回，直接入仓。

命令跑在 CI 里。 CI 流水线里没经过审查的 shell 是慢动作中的事故。CliAI 生成的一行流一旦进 CI，就该好好写下来。

毕业流程

从 prompt 开始。跑一次。复制结果。

clai 
$ clai 对 staging 中每个不 Ready 的 pod，打印名字和最近 20 行日志→ kubectl -n staging get pods -o json \    | jq -r '.items[] | select(.status.containerStatuses[0].ready==false) | .metadata.name' \    | xargs -I{} sh -c 'echo "── {} ──"; kubectl -n staging logs {} --tail=20'

然后把它做成可 diff 的东西：

#!/usr/bin/env bash
# scripts/staging-unready-pods.sh
# 对 staging 中每个不 Ready 的 pod，打印名字 + 最近 20 行日志。
set -euo pipefail

NAMESPACE="${1:-staging}"

kubectl -n "$NAMESPACE" get pods -o json \
  | jq -r '.items[] | select(.status.containerStatuses[0].ready==false) | .metadata.name' \
  | while read -r pod; do
      echo "── $pod ──"
      kubectl -n "$NAMESPACE" logs "$pod" --tail=20
    done

差异不大但真实：set -euo pipefail、namespace 参数、一行注释、每个 pod 的分隔头。这些都不需要 LLM，入仓后每次执行可复现、不花请求。

留给 CliAI 的领地

别什么都往脚本搬。一次性任务——上手新仓库、调试事故、读别人的配置——就是 CliAI 为之设计的临时工作。如果过早脚本化，你只是给仓库添了垃圾，没增加杠杆。

另见