Tomoko 是 GitHub 在日本和韩国的区域营销主管，在人工智能驱动的开发人员构建和公司发展方式转变的边缘工作。作为一名前工程师，她使用 GitHub Copilot 和 GitHub Actions 重建了自己的营销工作流程。

我在日本和韩国负责 GitHub 的营销工作，活动是它的核心：针对企业开发者的定期网络研讨会系列、东京的社区聚会、首尔的仅限受邀者参加的高管会议。这个市场上的开发商现在真正需要什么？哪些主题值得他们花一个小时的时间，谁应该在房间里？我很乐意花一整天的时间来思考这些问题。

决定之后的事情是另一回事。一旦事件被批准，固定的序列就会开始：

在我们的活动平台上复制登陆页面。生成一组 UTM 标记的链接：每个频道一个，每个格式都如此。起草邀请电子邮件并向发送该电子邮件的团队提出请求。将事件添加到两个项目板。每天早上直到活动开始：下载注册者列表，进行清理，为利益相关者发布状态更新。活动结束后：导出与会者、重新调整 CRM 上传列表、标记正确的记录并编写报告。

虽然这些任务本身并不困难，但它们却是粘贴错误链接、跳过一天或拼错 15 个下游报告所依赖的活动名称的机会。

事情是这样的：我曾经是一名工程师。我的第一份职业是为企业客户维护 Linux 服务器上的数据库。虽然我的编码可能已经生疏，但我仍然可以看到一条需要自动化的管道。这是我使用 GitHub Copilot 的地方，您也可以在自己的工作中使用。

所以我没有写代码。我写下了我的操作手册，将它们交给 GitHub Copilot，并在对话中提高了自动化程度。今天，我过去花了几天时间手工组装的一个活动从一个 GitHub Issue 开始，每天早上都会筛选自己的注册者，并在结束后自行清理。

这篇文章将介绍它的工作原理，以及为什么我认为任何需要跨工具（API，甚至只是 CLI）提供任何可编写脚本的方式进行重复性工作的人都可以做同样的事情。

我不能声称这个基本想法是我自己的。 GitHub 的营销团队已经养成了为每个项目打开一个 GitHub Issue 的习惯。这里成为计划、讨论和状态共存的地方。这个问题已经是我们的工作单元了。我所做的就是让问题发挥作用。

三个 GitHub 原语承载了整个系统：

发行表格是申请表格。问题表单不是空白文本框，而是呈现结构化字段：活动标题、日期、地区、活动名称、目标受众。我们为每种活动类型（例如网络研讨会和现场活动）提供一种形式，并且它们提供相同的机制。标签就是开关。像 event-setup 这样的标签不是标签，而是触发器。每个自动化工作流程都以一个条件开始，该条件实际上表示“仅在存在此标签时运行”。行动是机器。当标签登陆时，GitHub Actions 工作流程就会触发，从问题正文中解析表单字段，然后开始工作。

存储库为开发人员提供的一切，都免费提供给我的营销工作流程：历史记录、可见性、审查以及每个决策的 URL。

有一件事使这成为可能，而且它与具体的事件无关：我们的事件管理平台公开了一个 API。我们的 CRM 甚至不需要它；它的官方 CLI 涵盖了我们所做的一切，而且我从未为其配置过 API 密钥，因为 CLI 通过浏览器登录并从那里处理身份验证。 API 或 CLI 的要求是相同的：可编写脚本的方式。如果您的重复性工作通过提供事件平台、CRM、表单构建器、分析服务的工具运行，那么本文中的模式适用于您。