跳到正文
Decision guide

CLI 还是 GitHub Action：看部署由谁触发。

CLI 适合个人、本地诊断和手动发布。GitHub Action 适合团队自动化、push/PR 触发、secret 管理和可审计执行记录。两者应该调用同一条 Appaloft 部署语义，而不是各自发明一套脚本。

CLI 部署GitHub ActionPR preview

检查项

Trigger

部署由本地人触发，还是由仓库事件触发？

Secrets

凭据应放在本地 profile，还是 GitHub Secrets？

Review

是否需要 PR preview、审批或执行记录？

Debug

失败时谁看日志和状态，本地还是 CI？

Cleanup

PR preview 或临时环境是否有 close cleanup workflow？

CLI 的优势

CLI 适合把项目接入 Appaloft、验证服务器、查看状态、读取日志和做手动恢复。它让个人和 AI agent 可以在本地上下文里完成部署操作。

GitHub Action 的优势

Action 把部署放进仓库事件和审计记录里，适合团队协作、PR preview 和标准发布。凭据应该引用 GitHub Secrets，不在日志里打印值。

不要让脚本分叉

本地 CLI 和 GitHub Action 应该走同一条部署配置和恢复语义，避免 CI 成功但本地无法复现，或本地能部署但团队无法审计。

落地步骤

1

先用 CLI 接通路径

验证配置、服务器、日志和回滚。

2

再写 GitHub Action

把稳定路径放进 push/PR workflow，并配置 secrets。

3

保留诊断入口

CI 失败后仍能用 CLI 或 Web 读取状态、日志和恢复命令。

常见问题

个人项目需要 GitHub Action 吗？

不一定。个人项目可以先用 CLI；当需要自动发布或 PR preview 时再加 Action。

团队可以只用 CLI 吗？

可以，但标准发布通常更适合放进 GitHub Action，减少口头流程和本地环境差异。

AI agent 应该用哪一个？

agent 可以先用 CLI 做诊断和部署，也可以生成或触发显式 GitHub workflow。关键是保留日志和恢复路径。

相关主题

继续沿着同一条部署路径看。

Appaloft 的 SEO 页面按真实部署任务组织。每个主题页都应该把用户带到下一步，而不是停在孤立介绍。