火种&起源：一个运营从0到1搭建CI自动化流水线的实战记录

推荐语

高德运营同学半年内从零搭建自动化日报系统，用AI解放人力，实现数据到阅读仅需10分钟。

核心内容：
1. 运营日报的痛点与AI化契机
2. 从静态站点开始的CI初体验与踩坑历程
3. 自动化流水线的完整搭建与实战效果

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

作为一名高德打车的区域运营同学，和常规运营同学一样，日常工作中需要大量时间和精力在盯数据、写日报、做分析上。半年前，我对"CI/CD"这个词一无所知，甚至不理解代码库、git存在的意义——认为那些都是开发同学才需要懂的东西。

但现在，我独立搭建了一套完整的日报自动化流水线：每天定时从ODPS取数、用Qwen大模型生成日报解读、自动推送钉钉群、自动部署到在线站点。整个流程无需人工干预，从数据到阅读只需要10分钟。

这篇文章不是技术科普，而是一个运营视角的真实实战记录——我是怎么从零开始，一步步踩坑、一步步用AI解决技术问题，最终把整套系统跑起来的。

运营团队应该都需要有这样一份日报，要覆盖前一天的目标达成、大盘数据、商户异动、城市峰值、分时应答情况等诸多模块。以前这份日报的制作流程是这样的：

1. 打开ODPS进行SQL取数

2. 把数据复制到Excel里整理

3. 手动写分析解读

4. 排版成文档，发到钉钉群

5. 如果要留档，还得手动上传到某个地方

每天至少花1小时，而且依赖人工读数和业务经验，分析质量高度依赖处理人的经验和细心程度。

2026年初，我们团队开始全面推进AI工具落地。Qwen Code、提示词工程、自动化流程……大家都在探索怎么用AI把重复性工作自动化。

我的leader提出了一个想法：日报能不能自动化？ 每天的数据结构是固定的，分析框架是固定的，唯一变化的是数字本身——这不就是最适合自动化的场景吗？

说实话，一开始我根本不知道用什么工具。我尝试过几个方案：

最终选Aone CI的原因很简单：我们的代码仓库就在Aone上，CI是现成的能力，不用额外搭环境。 而且团队里已经有同学在用CI做静态站点托管，有现成的经验可以参考。

我的CI之旅不是从日报开始的，而是从一个更简单的需求开始——把HTML文件放到在线站点上。

在Aone代码库里有一个静态站点（Aone Pages），可以把HTML文件托管成在线页面。团队里其他同学已经搭好了这个站点，我需要做的是：把我生成的HTML文件推送到仓库的public/目录下，它就能自动部署到在线地址。

听起来很简单对吧？但实际操作起来，坑一个接一个。

我在master分支的public/文件夹里放了一个HTML文件，然后发现——我自己的分支能看到这个文件夹，但其他同学的分支看不到。

我当时很困惑：明明在master里建了文件夹，为什么别人的分支没有？

后来问了AI才知道，这是Git分支隔离的正常现象。每个分支是独立的，public/文件夹只存在于创建或合并了它的那些分支上。要让别人的分支也有，需要每个人自己执行一次git pull origin master。

更头疼的问题来了。我们仓库的master分支是受保护分支，不能直接push。每次往public/目录合入新的HTML文件，都需要提MR（Merge Request）审核。

这意味着：

• 每次上传HTML → 提MR → 等审核 → 合入master → 手动更新README（生成新的访问链接）

• 流程繁琐，效率很低

如果能配置一条流水线，在每次push HTML文件后自动生成README索引并推送回去，不就不用手动更新了吗？

这是我第一次真正动手配置CI流水线。 整个过程是在AI的辅助下一步步完成的，大致分为以下几步：

第一步：申请PAT（个人访问令牌）

CI容器里要往仓库push代码，需要一个"通行证"——PAT（Personal Access Token）。CI自带的Token是只读的，不能push。

操作路径：打开 code.alibaba-inc.com → 右上角头像 → 设置 → Private Token → 重置并复制。

第二步：配置Secrets

PAT不能明文写在YAML里（会泄露到日志中），需要通过仓库的变量管理配置为Secrets类型。

千万别混用——用secrets语法引用Variables类型的变量，值会是空字符串。

第三步：写YAML流水线

这是我写的第一条YAML流水线（.aoneci/update-readme.yaml），核心逻辑是：

1. 检测本次push是否涉及public/*.html文件变更

2. 如果有，执行scripts/update-readme.sh脚本重新生成README

3. 用PAT把更新后的README推回当前分支

写YAML的过程充满了挫折感——语法错误不会报错，只是流水线不触发。比如trigger要写成triggers（复数），run: |要写成数组格式，checkout要写成- uses: checkout而不是- checkout。这些调试过程全部依赖AI读取运行日志，一步一步和AI共创问题的解决方案。在这个过程中，我深刻体会到网上那个梗——"我和AI对话的时候，就像绝望的李鸿章，不管他端上来什么，只能无能地点【接受并运行】"......

由此我总结出一个经验：不要从零写YAML，先复制仓库里已经跑通的流水线，再改。

当我第一次看到流水线执行成功、README被自动推回分支的时候，那种成就感是真实的。

[INFO] 当前分支: qioyue_370902[INFO] Token 长度: 20[INFO] 检测到 HTML 变更: public/test_ci.html[INFO] 推送到 origin/qioyue_370902（用户: judy.qy）[OK] README 已自动推回 qioyue_370902

虽然只是一个简单的README自动更新，但它让我理解了CI的基本工作原理：触发条件 → 执行步骤 → 产出结果。这为后面搭建日报流水线打下了基础。

有了CI的基础认知后，我开始设计日报自动化流水线。整体思路是：

定时触发 → 取数 → 生成日报 → 转HTML → 推钉钉 → 推仓库 → 自动部署

具体来说，分为7个步骤：

日报流水线需要很多配置：ODPS的AccessKey、Qwen的API Key、钉钉Webhook地址等等。

好消息是：代码库的变量配置是仓库级别共享的。只要在Aone CI的变量管理中配置一次，同仓库的所有YAML流水线都可以通过相同语法调用。

我配置的变量包括：

这里有一个值得分享的经验：ODPS权限建议用团队公共账号。申请一个公共AccessKey，授权所需的数据表，然后统一配置到仓库Secrets中。这样：

• 避免个人AK泄露风险

• 人员变动无需更换凭证

• 新人上手零配置

最终我搭建了两条独立的流水线：

流水线一：daily-report-auto（日报生成）

• 镜像：python:3.11

• 触发：工作日10:30定时 + 个人分支push

• 职责：取数 → 生成日报 → 推钉钉 → 推HTML到public/

流水线二：deploy-pages（站点部署）

• 镜像：alios-8u（自带jq + git）

• 触发：push到public/时实时触发 + 每天17:00定时兜底

• 职责：合并所有分支的public/内容 → 部署到生产站点

为什么要拆成两条？因为Aone CI的uses:组件运行在隔离容器中，python:3.11镜像缺少deploy-pages需要的jq工具，而且无法在流水线中补装。所以把"生成"和"发布"拆开，各用各的镜像，互不干扰。

日报流水线跑通后，我以为大功告成了。但很快遇到了一个更棘手的问题——多人协作时HTML互相覆盖。

我们团队只有一个Aone Pages静态站点，deploy-pages每次部署是全量替换（不是增量追加）。

场景还原：

1. 我在个人分支生成了日报HTML → 推到public/daily-report/ → 触发部署 → 站点上有了日报 ✅

2. 其他同学往master分支合入了一个活动页面 → 触发master的deploy-pages → 用master的public/全量替换站点

3. 我的日报消失了 ❌（因为master的public/里没有我的daily-report/）

核心矛盾：所有人都在各自分支生成HTML，但站点只有一份，每次部署都是全量替换。

思路很明确：每次部署前，先把所有远程分支的**public/**内容合并到一起，再部署完整集合。

具体实现是在deploy-pages.yaml的部署步骤前加一个"合并"环节：

# 动态发现所有远程分支git fetch origin --depth=1ALL_BRANCHES=$(git branch -r | grep -v 'HEAD' | sed 's|origin/||' | tr -d ' ')
# 逐一拉取每个分支的public/内容for branch in$ALL_BRANCHES; do  git fetch origin $branch --depth=12>/dev/null || true  git checkout origin/$branch -- public/ 2>/dev/null || truedone
# 当前触发分支的内容最后覆盖（保证最新变更优先）git checkout HEAD -- public/ 2>/dev/null || true

这样无论谁触发部署，所有人的HTML都会先合并进来，再一起部署。

Aone CI读取的是被推送分支上的YAML。如果你的分支上没有deploy-pages.yaml，你推public/时不会触发任何部署。

好消息是：所有分支的YAML内容完全一样，不用各自定制。 如果你是从master新建的分支，这个文件已经自动继承了。

我设计了几层防护，确保系统健壮：

17:00的定时任务是一个兜底机制，应对极端情况。正常情况下，每次push触发的实时部署就已经包含了所有分支的内容。

最初我想用[skip ci]标记来防止部署流水线重复触发，但后来发现[skip ci]会杀死所有流水线（包括日报生成流水线）。

更好的方案是用paths过滤：只在public/**有变更时才触发deploy-pages。这样不该跑的流水线不会被误杀。

以下是搭建CI流水线过程中真实踩过的坑，涵盖语法陷阱、环境隔离和平台机制差异，按配置流程顺序排列：

总结心法： 遇到CI问题别自己死磕。把完整的报错日志复制给AI，让它帮你分析定位。配置CI的效率不取决于你记住了多少语法，而是你能不能快速定位问题。

善用调试三板斧：查官方手册 → 对比已跑通的YAML → 加诊断输出。

遇到报错不要慌，把完整的日志信息复制给AI，让它帮你分析。 这是我整个CI搭建过程中最高效的调试方式。

如果你也想搭建类似的日报自动化流水线，以下是你需要关注的文件：

回头看这半年的经历，从一个连YAML是什么都不知道的运营，到能独立搭建和维护CI自动化流水线，最大的感触是：

AI不会替代运营，但会用AI的运营会替代不会用的。

搭建CI的过程中，我遇到的每一个技术问题——YAML语法、Git认证、ODPS权限、多分支并发——都是在AI的辅助下解决的。我不需要记住每一个技术细节，我只需要知道我要实现什么效果，然后把报错信息告诉AI，让它帮我找到解决方案。

当然，有些东西是需要自己理解的：

• 业务逻辑：哪些数据重要、怎么分析、怎么呈现——这是运营的核心能力

• 系统设计：为什么要拆两条流水线、为什么要合并分支——这些决策需要理解业务场景

• 质量把控：AI生成的内容需要人工校验，数据准确性需要机制保障

技术工具在变，但运营的核心价值没变：用数据驱动决策，用效率创造价值。 CI只是帮我把重复性工作自动化了，让我有更多时间去做真正需要人判断的事情。

如果你也是一个想用技术提效的运营同学，我的建议是：不要怕，从最简单的开始，一步步来，遇到问题就问AI，与AI协同找到解决方案。 你会发现，那些看起来很"技术"的东西，其实并没有那么难。

本文是「火种&起源」系列的一部分，记录一线运营同学在AI工具实践中的真实故事。

千问云-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问云体验

点击阅读原文即可体验！