活动运营总漏一环，GitHub Copilot 这套骨架能直接借

一场线上活动从点头到收尾，最容易把人磨没的往往不是选题，也不是海报。

是后面那串看着很小、漏掉一项就要返工的活。复制落地页，给每个渠道拼 UTM 链接，找人发邀请，盯报名表，活动结束后把名单整理成 CRM 能吃的格式，再补一份复盘。每一步都不难，凑在一起就很像一个没有写进任何文档的小型系统。

GitHub 日韩营销负责人 Tomoko Tanaka 最近公开了一套做法。她把一场活动放进一张 GitHub Issue，让 Copilot 负责把运行手册变成可执行的流程，GitHub Actions 负责在合适的时候干活。官方案例里，一天里原本靠人工拼起来的大部分准备工作，变成了几分钟的工作流。好家伙，活动运营也开始有自己的编译期了。

这篇不打算把它写成一篇 Copilot 功能介绍。更值得借的，是那套把重复劳动变成一条可审查流水线的骨架。它不只适合做活动。你每周要做的客户跟进、内容协作、资料归档、数据清洗，只要能写出步骤，大多都可以从这里起步。

先把边界说清。这是 GitHub 的公开案例，不是小岛 AI 对这套流程的亲自实测。下面讲的细节来自原始案例和 GitHub 文档，适合拿去画自己的流程，不适合直接当成无脑复制粘贴的答案。

一张 Issue 不再只是待办

Tanaka 的第一步挺朴素。她没有先去搭一个花哨的自动化平台，而是把一场活动定义成一张 Issue。

Issue Form 负责收集结构化输入，比如活动标题、日期、地区、活动名称和目标人群。标签负责当开关。event-setup 这个标签一挂上，GitHub Actions 就读取表单字段，开始执行后面的准备工作。

这看起来像是把待办事项换了个地方放。其实不是。

当活动从聊天记录和散落的表格里搬进一张 Issue，它就有了唯一入口、修改历史、负责人、评论和链接。以后有人问这场活动什么时候改了受众，哪封邮件是谁确认的，不需要翻半天群记录，直接回到这张 Issue 就行。

一张结构化入口把准备工作分到可追踪的分支，图为概念示意。

很多团队做自动化，第一反应是把机器人接到飞书、Slack 或聊天框里。聊天当然方便，但它特别擅长把上下文冲散。今天一句改日期，明天一句换渠道，后天才发现链接命名没跟着改。系统没有一个能稳定读到的事实源，自动化就只能在碎纸屑里找答案。

Issue Form 的价值不在 GitHub 这两个字，而在于把输入钉住。你用表单、数据库记录，甚至一份严格约定字段的 Markdown，都可以。关键是别让机器从一段自然语言里猜活动日期和客户分组。模型再聪明，也不该替你猜这种会影响外部动作的值。

Tanaka 还把 Copilot 放在流程的前面，而不是留到末端打杂。她让 Copilot 先读取仓库里的 AGENTS.md，知道活动命名规则、区域时区、邀请邮件的基本要求，再找类似的历史活动，提出名称和邮件草案。人确认以后，Copilot 才创建带好标签的 Issue。

这个分工很舒服。Copilot 负责把脑子里那些零散规则找出来并补齐，人负责签字。厉害了，模型终于没有被安排成一个一边猜一边直接改生产数据的莽夫。

标签落下之前，先准备一个不伤人的开关

官方案例里，event-setup 触发后会复制活动页面，生成各渠道的 UTM 链接，产出邀请邮件，创建协作请求，更新项目板，并把结果回写到 Issue。报名筛查则由定时任务每天拉取一次进行中的活动名单。

这里最该抄作业的，不是自动做了多少事，而是那个叫 DRY_RUN 的仓库变量。

每个工作流执行前都看它。如果开关打开，流程照常解析输入、生成计划、打印结果，却不创建外部资源，不修改客户数据，不给其他团队发请求。它像彩排。

先看计划和日志，再允许流程碰外部系统，图为概念示意。

没有这一步，所谓自动化经常只是把手工失误放大。把一个错误的 UTM 模板批量生成到十个渠道，速度确实很快，快到你开始怀疑人生。把名单字段映射错了再同步到 CRM，也会让后面修数据的人记住你的名字。

很多人把干跑理解成开发阶段的临时功能。我更愿意把它当成长期安全带。新同学改了工作流，营销规则换了，接口字段变了，或者你只是想确认本周新增的一条条件会不会误伤旧活动，都该先走一次干跑。工作流不怕慢半拍，最怕安静地做错。

GitHub 的案例还写了一个很诚实的失败。每天早上的报名筛查曾经静默失败了五天，直到有人发现名单一直没更新。这个故事不浪漫，但特别有用。自动化没有告警，只是把遗忘交给了更准时的机器。

所以一条能上线的流程，至少要让三件事说得明白。

它什么时候该跑，跑了之后改了什么，没跑成时谁会知道。

前两件事靠触发器和回写记录解决，还有一件得靠告警。哪怕只是失败时往群里丢一条消息，也比第二周才发现数据过期强。棒棒的，别让你的 Agent 只会沉默地努力。

先拿下周最烦的一件事开刀

如果你现在也想试这套，不必从活动全流程开始。那样很容易把自己写进一张巨大流程图，然后再也没有然后。

挑一个本周一定会发生、步骤又最固定的动作。比如每周把报名表导出后按公司规模分组，给销售团队生成跟进清单。先把它写成一份运行手册，写清输入在哪，输出要长什么样，哪些条件必须由人确认，失败后要通知谁。

然后给这份手册配一个结构化入口。可以是一张 Issue Form，也可以是团队已有的表单。再加一个只做预览的 DRY_RUN 模式，先让流程把计划和结果回写到原来的记录里。别急着连 CRM，也别一上来就给客户发信。

等连续几次预览都对，再接一个外部动作。每接一步，就给它留下可回看日志和失败通知。这个节奏听起来不够酷，甚至有点像把一个表格逐步搬进仓库。但工程里最靠谱的魔法，往往就是能回滚、能复盘、能让下一个人接手。

Tanaka 把会后动作做成了两个斜杠命令，/lead-upload 用来整理并提交线索名单，/event-report 用来汇总出席和问卷数据。它们背后是 Copilot 的技能文件，也就是一份写清步骤和注意点的 Markdown 运行手册。这个点我很喜欢。

能自动化的东西，不一定要先长成一段代码。它可以先是一份人人看得懂、能被评审的说明。等说明稳定下来，才值得交给模型和工作流。

你下周最想摆脱的那件重复活是什么？如果只能先给它加一个东西，你会选结构化表单、干跑开关，还是失败告警？