用途：为新项目从零搭建 CI，替换与实际技术栈不符的复制流水线，在 GitHub Actions 与 GitLab CI 间迁移，检查流水线阶段是否匹配项目工具链，优化缓慢构建（缓存、并行、条件步骤），并在做专门加固前先建立稳定的 CI 基础。
主要能力：先检测再生成。通过锁文件（package-lock.json、yarn.lock、poetry.lock、go.sum、Cargo.lock）、语言清单（package.json、pyproject.toml、go.mod）和脚本定义（test、lint、build）识别技术栈与包管理器，不假设 Node 项目。随后按阶段生成配置：基础基线为 checkout、运行时安装、带缓存的依赖安装，再顺序执行 lint、test、build。提供各生态缓存策略（Node 用 ~/.npm 或 node_modules，Python 用 ~/.cache/pip，Go 用 ~/go/pkg/mod，Rust 用 ~/.cargo/registry 与 target/，Ruby 用 vendor/bundle，键基于对应锁文件哈希）。密钥部分列出所需项及添加方式，建议平台托管密钥存储与 OIDC，禁止在 YAML 中硬编码凭据。部署按环境推进：先仅 CI，再加无审批的 staging，再加需人工审批的 production。输出包含检测结果、Mermaid 流程图、完整 YAML、密钥表、激活步骤与验证清单。
最佳实践：lint 优先以尽早失败；激进缓存可减少 30% 至 60% 构建时间；用 SHA 固定 action 版本；设置 timeout-minutes 与并发取消；一次只加一项增强。常见陷阱包括误用 Node 流水线、测试未稳定就启用部署、忽略缓存、频繁跑全矩阵、缺少分支保护、凭据写入 YAML。
限制：具体项目所需的 secrets 名称、部署目标与分支保护规则需由用户环境确定，资料未提供固定默认值；价格与平台细节暂未提供。