引言：为什么LLM项目需要CI/CD/CT？

在LLM应用的开发中，除了常规的代码变更，数据分布变化、模型性能衰减、RAG系统更新等都会触发重新训练和部署。如果仍依赖手动操作，不仅效率低、易出错，还难以保证生产环境的一致性和可追溯性。MLOps的核心目标正是自动化数据采集、训练、测试和部署流程，让团队专注于模型效果决策。对于LLM项目，CI/CD（持续集成/持续部署）确保代码变更被自动验证并交付；而CT（持续训练）则让模型能根据新数据或反馈自动迭代。

CI/CD流程设计：分支策略与触发条件

生产级CI/CD基于明确的环境划分：

• dev分支：开发人员日常提交，触发CI流水线（代码检查、单元测试）。
• staging分支：合并开发分支后，触发完整CI+CD，部署到预生产环境供QA验收。
• production分支：通过staging验证后，合并到production，触发CD将镜像发布到生产。

典型触发条件：

• 对main或release/*分支的push事件触发部署；
• 对所有分支的pull_request事件触发CI检查；
• 通过标签（tag）或手动工作流调度（workflow_dispatch）控制特殊部署。

GitHub Actions基础：工作流、作业、步骤与触发事件

GitHub Actions是GitHub原生的CI/CD引擎。一个工作流（workflow）由一个或多个作业（job）组成，作业内包含多个步骤（step）。触发事件（on）可配置为push、pull_request、workflow_dispatch等。

典型工作流文件（.github/workflows/ci.yml）结构如下：

name:CI Pipelineon:push: