把「反复手撸」的活，交给脚本
生产级的标志之一是自动化：把重复的流程写成脚本，一次编排、长期复用。CLI（命令行）是自动化的基石——它简单、可组合、可脚本化。
这一节讲 CLI 命令与脚本编排：怎么把多个命令串成「一步到位」的任务。
为什么自动化
你可能有这样的活：每次发布前，都要跑一串命令——测、打包、检查、部署。手撸又慢又容易漏。脚本化后，一条命令搞定。
手撸：5 条命令，手动敲 5 遍，易漏
脚本：1 条命令，自动跑完，一致
自动化 = 把「怎么做的」写下来，让机器每次都按对的方式做。
对 deploy-bot 尤其如此：它每次部署要执行的动作（拉代码 → 测试 → 构建 → 部署），如果靠人临时敲，一定不一致。写成脚本，deploy-bot 每次调用的都是同一套、正确的那套。
CLI 命令：自动化的砖块
脚本由 CLI 命令组成。常见的组合思路：
&&：前一条成功才跑下一条
cd project && npm test && npm run build
|：管道，把前一条输出给下一条
ps aux | grep node
理解「命令的组合」，你就能把多步串成一步。
配合 deploy-bot 的实际动作，你会看到这样的组合：
# 部署前的关键命令链
git pull origin main && npm ci && npm test && npm run build
&& 保证任一环节失败就停下来，绝不在坏代码上继续部署——这正是 deploy-bot 要的安全感。
脚本编排：把流程固化成脚本
把一串命令写进一个脚本文件，就是「编排」：
#!/bin/bash
# 发布前检查脚本
echo "== 1/4 跑测试 =="
npm test || exit 1 # 失败就停
echo "== 2/4 检查 TODO =="
grep -r "TODO" src/ && echo "有 TODO，请检查" || echo "无 TODO"
echo "== 3/4 构建 =="
npm run build || exit 1
echo "== 4/4 完成 =="
以后执行 ./prepublish.sh，这 4 步自动跑完，还有进度提示、失败就停。
下面这份，就是 deploy-bot 的部署动作脚本（示意）：
#!/bin/bash
# deploy-bot 部署动作：拉代码 → 测 → 构建 → 部署 staging
set -e # 任一步失败立即退出
echo "== 1/4 拉取最新代码 =="
git pull origin main
echo "== 2/4 跑测试 =="
npm test
echo "== 3/4 构建 =="
npm run build
echo "== 4/4 部署 staging =="
./deploy.sh --env staging
deploy-bot 每次要部署，就调用这份脚本——动作标准、失败即停、步骤可见。
编排的核心要素
一个可用的脚本，通常包含：
| 要素 | 作用 |
|---|---|
| 步骤 | 每一步做什么 |
| 失败处理 | 某步失败怎么停（exit 1 / set -e） |
| 进度提示 | 打印当前到哪一步（echo） |
| 可配置 | 用变量/参数，别写死 |
有这四点，脚本才可靠、好用、可维护。
deploy-bot 的脚本更要守这四点：部署是高权限动作，失败必须停、步骤必须可见、环境必须可配置（staging/production 用参数区分，别写死）。set -e 和 --env 参数就是这两点的体现。
让 AI 帮你写脚本
你不用从零写，可以让 Codex 帮你：
帮我写一个「发布前检查」的 shell 脚本：
1. 跑测试，失败就停
2. 检查有没有 TODO，列出位置
3. 构建产物
4. 每步打印进度
用变量定义项目路径，别写死。
AI 起草 + 你审查 + 真实验证，脚本又快又对。
给 deploy-bot 写部署脚本，也可以这样让它起草：
给 deploy-bot 写一个部署动作脚本：
1. 拉取 main 最新代码
2. 跑测试，失败即停
3. 构建产物
4. 用 --env 参数区分部署 staging / production
5. 每步打印进度，结尾输出成功/失败标记
环境用变量，别写死。
记得：AI 写出来的脚本，你务必审查 + 在测试环境真跑一遍，尤其涉及部署的，绝不明文信任。
常见坑：脚本写死环境，一套脚本两种环境互串
部署脚本最常见、最危险的坑，是把环境「写死」在脚本里，或者环境判断混乱。
真实场景：你给 deploy-bot 写脚本时，把部署目标直接写成了 --env production。某次本想在 staging 试跑，结果脚本一执行，直接动的是生产。或者脚本里 staging/production 判断逻辑写错，串了环境。
为什么：部署脚本默认是高权限、高风险动作。一旦「去哪」不明确或用错了环境，后果直接放大到生产。
怎么破：环境一律用参数或变量传入（--env staging），脚本里做「白名单校验」——不是明确列出的环境就拒绝执行，绝不默认生产。必要的话，production 部署再加一道「必须人工确认」的开关。
小结
- 自动化 = 把重复流程写成脚本，一次编排长期复用
- CLI 是砖块：
&&串行、|管道 - 编排要点：步骤、失败处理、进度提示、可配置
- 让 Codex 帮你写，你审查验证
下一节，讲自动化任务与定时触发。