把它记下来，交给GitHub Copilot，实现自动化。✅

一位营销人员将重复性的活动运营工作，变成了一个能自行运行的GitHub Issue表单。⬇️ https://t.co/BGhnlMGoAg

营运即代码：在GitHub上自动化从规划到跟进的营销活动

来源：https://github.blog/ai-and-ml/github-copilot/marketing-ops-as-code-automating-events-from-planning-to-follow-up-on-github/?utm_source=x-marketing-ops-as-code&utm_medium=social&utm_campaign=github-app-cli-Q1-push 我在GitHub负责日本和韩国的营销工作，而活动就是其中的命脉：针对企业开发者的定期网络研讨会、东京的社区聚会、首尔仅限受邀高管的会议。这个市场的开发者当下真正需要什么？哪些主题值得他们花一小时参与？谁应该参加？我愿意整天思考这些问题。

决定之后的事情则是另一回事。一旦活动获批，固定的流程就开始了：

• 在我们的活动平台上复制一个着陆页。
• 生成一组带UTM标记的链接：每个渠道一个，格式一致。
• 起草邀请邮件，并向负责发送的团队提交申请。
• 将活动添加到两个项目看板。
• 活动前的每一天：下载参会者名单，进行清理，为利益相关者发布状态更新。
• 活动后：导出参会者，为CRM上传调整名单格式，为相关记录打标签，并撰写报告。

虽然这些任务单独来看都不难，但它们都可能让你贴错链接、忘记某一天，或者拼错一个影响15个下游报告的活动名称。

问题是：我曾经是工程师。我的第一份工作是在Linux服务器上为企业客户维护数据库。虽然我的编程技能可能有些生疏，但我依然能看出一条亟待自动化的流水线。这就是我使用GitHub Copilot (https://github.com/features/copilot) 的地方，也是你可以在自己的工作中效仿的地方。

所以我没有写代码。我写下我的操作手册，将它们交给GitHub Copilot，并在对话中逐步构建自动化流程。今天，一个我过去需要花几天时间手动搭建的活动，现在只需一个GitHub Issue就能自动设置自身，每天早上自动筛选注册者，并在结束后自行清理。

本文将介绍这是如何运作的，以及为什么我认为任何在工作中需要跨工具进行重复性操作（这些工具提供任何可脚本化的方式，比如API或CLI）的人，都能做到同样的事。

一个活动就是一个Issue

我不能将这个核心思想据为己有。GitHub的营销团队早已养成为每个项目开启一个GitHub Issue的习惯。这成为计划、讨论和状态并存的地方。Issue本来就是我们的工作单元。我所做的，是让这个Issue去“工作”。

三个GitHub基础构件支撑了整个系统：

• Issue表单是申请表。 与其提供一个空白文本框，Issue表单 (https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms) 提供了结构化字段：活动标题、日期、地区、活动名称、目标受众。我们为每种活动类型（如网络研讨会和线下活动）都有一个表单，它们驱动着同一套机制。
• 标签是开关。 像event-setup这样的标签不是标记，而是触发器。每个自动化工作流都始于一个条件判断，实质上就是“只有在存在此标签时才运行”。
• Actions是机械装置。 GitHub Actions (https://docs.github.com/en/actions) 工作流在标签贴上时触发，解析Issue主体中的表单字段，然后开始执行任务。

代码仓库为开发者提供的一切，也免费提供给了我的营销工作流：历史记录、可见性、审查，以及每个决策的URL。

有一件事让这成为可能，与活动本身无关：我们的活动管理平台提供了API。我们的CRM甚至不需要API；其官方CLI涵盖了我们所有操作，我从未为它配置过API密钥，因为CLI通过浏览器登录并处理认证。无论是API还是CLI，要求都是一样的：可脚本化的接口。如果你的重复性工作通过一个提供API或CLI的工具来完成——无论是活动平台、CRM、表单构建器还是分析服务——本文介绍的模式都适用你。

开发者读到这里，可能已经在构思明显的异议：这难道不是在重新发明轮子吗？营销自动化平台是存在的，一个优秀的平台可能已经开箱即用地覆盖了部分需求。但亚太地区与其说是一个市场，不如说是一系列迥异市场的集合，即使在我的团队内部，工作流也会随着每个子区域和细分市场而变化。同一个网络研讨会，可能这个月在东京用日语举办，下个月在首尔用韩语举办，面对不同的细分市场，CRM中的字段不同，对优质线索的定义也不同。要让一个打包的工具吸收所有这些差异，意味着定制预算、咨询时间，并等待别人的路线图。我们自己动手，利用手头已有的工具，意味着工作流的更改就是一个拉取请求：我描述我的需求，审查者检查它，然后通过与开发者更改软件完全相同的流程合并到主分支。

筹划一次活动就是一场对话

流水线在Issue存在之前就开始了。我打开GitHub Copilot，大致说：“我想在11月举办一个关于AI辅助开发的网络研讨会。”

接下来发生什么取决于我们仓库根目录下一个名为AGENTS.md的文件。这是我们团队的操作手册，用纯Markdown编写，定义了我们如何命名活动、财年季度如何映射到日期、每个区域使用哪个时区，以及一封好的邀请邮件是什么样子。GitHub Copilot读取它，然后找到一个类似的过往活动，提出一个符合我们命名规则的活动名称，起草两版邀请邮件，并按照操作手册的要求向我提问。

将对话置于流水线前端本身就是一个设计决策，它一举解决了两个问题。自动化一切会失去灵活性；当你希望某个特定活动略有不同时，僵化的流水线没有地方让你表达。但如果让人填写所有内容，又会出现错误。对话恰好介于两者之间。GitHub Copilot遵循模板，因此进入Issue的数据是正确格式下的正确数据。并且因为是对话，我可以为这一个活动调整细节，而不会破坏下游的机制。

刚开始时，这个对话发生在GitHub Copilot CLI (https://github.com/features/copilot/cli) 中，在一个终端里。这对我来说没问题，但“打开一个终端”对许多我希望引入这个工作流的人来说是个障碍。现在，借助GitHub Copilot应用 (https://github.com/features/ai/github-app)，同样的对话可以在一个普通的桌面窗口中进行。入门门槛从“熟悉shell”降低到了“会打字”。

我想精确说明分工，因为这正是要点：GitHub Copilot起草；我决定。每个活动名称、每个邮件主题行、每个日期都要经过我的批准才能继续。对话结束时，GitHub Copilot会提交带有正确标签的GitHub Issue，这时机器才接管。

一个标签，一个活动，全面部署

event-setup标签一贴上Issue，一个GitHub Actions工作流就会接手，在几分钟内完成过去需要我大半天时间的工作：

• 在我们的活动平台上复制一个过往活动，以创建新的着陆页
• 生成全套带UTM标记的URL：每个渠道一个，格式始终一致
• 生成邀请邮件的Word文档并提交到仓库
• 向负责发送邮件和跟踪区域营销的团队提交申请Issue
• 将活动添加到我们的项目看板并填写字段
• 在Issue上发布摘要评论，这样下一个打开它的人就能在一个地方看到所有内容

注册者筛选按计划而非标签运行。每天早上，一个由cron触发的工作流会获取所有开放活动的最新注册者，并分享清理后的名单。对于仅限受邀的活动，它还会根据我们的标准筛选候补名单（该注册者是企业账户的开发者、学生，还是非常想参加我们高管简报的竞争对手？），然后才批准任何人。

我最自豪的设计决策是一个名为DRY_RUN的开关，它存储为一个设置（在GitHub术语中是仓库变量），每个工作流在运行前都会检查它。打开它，所有工作流就会走个过场，而不接触任何外部系统：不创建着陆页，不在其他仓库提交Issue，不共享名单。当你是一个自动化的营销人员时，你需要一种排练的方式。DRY_RUN就是排练开关，这也是我从不害怕尝试的原因。

活动后，一个斜杠命令

活动后的工作曾是最糟糕的部分：导出参会者、为CRM上传重新格式化列、将公司名称与账户记录匹配，以及撰写报告。现在只需要两个命令。

/lead-upload获取参会者名单，将其塑造成我们的营销运营团队进行CRM上传所需的精确格式，提交申请Issue，并关闭相关跟踪Issue。

/event-report拉取参会指标和调查结果，并将报告作为评论发布到活动的Issue上，回到那个汇集了关于此活动所有信息的唯一URL。

这些是GitHub Copilot智能体技能 (https://docs.github.com/copilot)，我最想让你听清楚的部分是：技能就是一个Markdown文件。每个技能都是一个SKILL.md：一个用散文写成的流程，告诉GitHub Copilot该做什么、按什么顺序、以及要注意什么。我的技能读起来就像我过去记在脑子里的操作手册，因为它们就是那样的东西。

如果你能写操作手册，你就能写技能。

技能也使系统保持灵活性。亚太地区（APAC）的两个市场在后续跟进工作上不可能完全一样。受众不同，细分市场不同，本地惯例不同，而硬编码的工作流会迫使每个市场遵循同一模式。用Markdown写成的流程是灵活的：每个市场都可以在不触及底层机制的情况下，根据自身实际情况调整操作手册。这正是活动后步骤存放在GitHub Copilot技能中而非固定流水线中的原因。

我们在一个方面像对待代码一样对待技能：新技能通过拉取请求到来，并在合并前经过审查，CODEOWNERS文件将审查路由给维护者。带有审批流程的营销自动化。治理也是平台免费附带的。

内置的防护栏让我敢于尝试

我自动化了一个涉及客户数据和API凭证的工作流，在一个整个团队都能看到的仓库中，而我自己几乎没有写代码。六个月前，我会说这种组合很鲁莽。改变我想法的是，我意识到在我介入之前，已经有这么多防护措施就位了。

一些是我构建的防护栏：DRY_RUN开关、在每个拉取请求上运行的测试套件，以及每个更改的代码审查。标准的开发者习惯。事实证明，它们保护营销工作就像保护软件一样有效。

但最重要的防护措施来自平台：

• 带推送保护的密钥扫描。 对我这样的人来说，噩梦般的场景是意外提交了API令牌。GitHub的推送保护 (https://docs.github.com/code-security/secret-scanning/introduction/about-push-protection) 在密钥进入仓库之前就阻止了推送，而对于GitHub自己的令牌，即使有漏网之鱼也会被自动撤销。
• GitHub Copilot的数据策略。 注册者名单是业务数据，固定脚本以固定方式处理它们。但实际工作从未完全固定；有时我需要对数据进行一次性分析，这是任何脚本都无法预料的。因为GitHub Copilot的商业版不会保留提示词或用其训练模型，所以我可以直接请求这种一次性分析，而不是像业内许多人悄悄做的那样：将业务数据粘贴到浏览器下一个标签页中打开的消费级聊天机器人里。模型本身也是如此：我能够使用哪些模型由组织策略决定，而非留给我的个人判断，因此即使是一次性实验也在公司已确定的边界内运行。安全路径和便捷路径，这一次，是同一条路。

技能还使另一件事成为可能，几乎是一个附带的好处：因为每个流程现在都是一个命名固定的工作单元，我可以根据任务选择模型，从我们组织批准的阵容中挑选。一个快速、低成本的模型处理日常名单清理；一个更强的模型起草活动文案。

还有一个诚实的失败教训，希望你不要重蹈覆辙：每天早上的筛选工作流曾静默失败了五天，才有人注意到名单已经过时了。你不监控的自动化更像是一个带延迟的定时炸弹。给每个计划运行的工作流提供一种大声报错的方式，这样你就不会错过它。

从一个任务开始

以下是我的建议，来自一个曾经的体力劳动者给另一个。

选择你每周最重复的任务。然后检查它所涉及的工具是否有API或CLI。你可能会惊讶地发现有很多都有。

然后构建尽可能小的版本：一个捕获输入的Issue表单、一个表示“开始”的标签，以及一个完成工作其中一步的Action。或者直接跳到将你所知写成一个SKILL.md，让GitHub Copilot执行它。用干运行开关运行它，直到你信任它。然后从那里扩展。

我没有写代码。我写下我已经知道的东西（工作如何完成），平台完成了其余部分。无论你的“每日注册者名单”是什么，它可能只需要一份写下来的操作手册，就能实现自动化。

开始使用：

• Issue表单语法 (https://docs.github.com/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms)
• GitHub Actions 文档 (https://docs.github.com/actions)
• GitHub Copilot 文档 (https://github.com/copilot)
• 以及说服我这行得通的博客文章：我自动化了我的工作（它让我成为了更好的领导者）(https://github.blog/developer-skills/github/i-automated-my-job-and-it-made-me-a-better-leader/)

作者

田中智子（Tomoko Tanaka） 智子是GitHub在日本和韩国的区域营销负责人，致力于AI驱动下开发者构建方式和企业增长方式的转变的前沿。作为前工程师，她用GitHub Copilot和GitHub Actions重建了自己的营销工作流。