GitHub日本韩国市场负责人用Copilot把活动运营写成代码
Tomoko Tanaka在GitHub官方博客披露：把活动立项、报名筛选、会后上传CRM全流程交给GitHub Issue表单、标签触发的Actions和Copilot，过去手工花一两天搭建的活动现在从单个Issue自动跑起来。
AI解读：这条新闻的实用价值在于，它展示了一条具体的自动化路径：把重复性运营工作写成Markdown版runbook，再让GitHub Copilot按流程执行。作者原本是工程师，现在负责GitHub日本和韩国的市场营销，活动策划与执行是她的核心工作。
受影响的首先是经常跨工具做重复操作的人，比如市场、运营和社区管理者。她强调门槛不高：只要工具提供API或CLI这种可脚本化的入口，就能套用同一模式，不必等打包好的营销自动化平台排期。
一个值得注意的取舍是，她没有选择现成的营销自动化工具，原因是亚太区各子市场和细分受众差异太大，定制成本和等待别人路线图的代价更高。自己搭的代价是活动上线变成一次pull request，需要走代码审查。
风险也在文中写明：一个每天早上运行的报名筛选工作流曾连续五天静默失败，没人发现名单已经过期。自动化不配监控，等于装了个延迟引信。想在团队里推广这模式，这一点比省下的时间更该先想清楚。
GitHub日本和韩国区域市场负责人Tomoko Tanaka在GitHub官方博客发文，讲述她如何用GitHub Issue表单、标签、GitHub Actions和GitHub Copilot，把活动从策划、报名筛选到会后CRM上传的整条流程自动化。她称，过去手工搭建一场活动要花一两天，如今从单个GitHub Issue自动完成。
整条系统依赖三个GitHub原语：Issue表单作为申请入口，收集活动标题、日期、地区、campaign名称和目标受众等结构化字段，每种活动类型一个表单；标签作为开关，例如event-setup不是普通标记而是触发器，每个自动化工作流只在标签存在时运行；Actions作为执行机构，在标签落地后解析表单字段并执行任务。
她承认这不是在造轮子：营销自动化平台确实存在，一个好的平台可能已覆盖其中部分功能。但她表示亚太区并非一个市场而是多个差异很大的市场，同一场网络研讨会可能这个月在东京用日语、下个月在首尔用韩语，受众细分、CRM字段和优质线索的定义都不同；让打包工具吸收这些差异意味着定制预算、顾问工时和等待别人的路线图。
活动从对话开始，Copilot起草、人签字
流程在Issue创建之前就已经开始。作者打开GitHub Copilot，说一句“我想在 11 月办一场关于AI辅助开发的网络研讨会”。仓库根目录的AGENTS.md文件会约束后续行为：这份纯Markdown团队runbook定义了campaign命名规则、财季与日期的对应、各地区时区，以及一封好的邀请邮件长什么样。Copilot读取后，找到类似的历史活动，按命名规则提出campaign名称，起草两版邀请邮件，并按照runbook的要求向作者提问。
作者把对话放在流程前端当作一个设计决策，同时解决两个问题：全自动化会失去灵活性，某一场活动想稍有不同时，刚性流水线无处表达；全人工填写则会出错。她强调分工：Copilot起草，她决定。每个campaign名称、每封邮件主题、每个日期都要她签字后才会推进。
对话最初发生在GitHub Copilot CLI的终端里。作者说这对她没问题，但“打开终端”对很多人是门槛。换用GitHub Copilot应用后，同样的对话发生在普通桌面窗口，门槛从“熟悉shell”降到“会打字”。对话结束时，Copilot带着正确标签创建GitHub Issue，机器随即接手。
- AGENTS.md是团队runbook，用纯Markdown写，规定campaign命名、财季日期映射、各地区时区和邀请邮件样式。
- 对话式的入口让数据以正确格式进入Issue，同时保留为单场活动调整细节的余地。
- 作者明确：campaign名称、邮件主题、日期均由她本人签字确认。
一个event-setup标签，几分钟完成原需近一天的工作
event-setup标签落到Issue上的瞬间，一个GitHub Actions工作流接手，几分钟内完成过去要花作者大半天的工作：在活动平台上复制历史活动来创建新的落地页；生成全套带UTM参数的链接，每个渠道一条、格式始终一致；把邀请邮件生成为Word文档并提交到仓库；向负责发邮件和追踪区域营销的团队创建请求Issue；把活动加入项目面板并填好字段；最后在Issue上回帖汇总，下一个人打开就能看到全部信息。
报名筛选不由标签触发，而是按计划运行。每天早上，一个cron触发的工作流抓取所有开放活动的最新报名者，分享清洗后的名单。对于仅限邀请的活动，它还会在批准前按标准筛选等候名单，例如判断报名者是某企业账号的开发者、学生，还是非常想参加高管简报会的竞争对手。
作者最满意的设计是一个名为DRY_RUN的开关，存为仓库变量，每个工作流运行前都会检查它。打开后，所有工作流只是走一遍流程而不触碰外部系统：不创建落地页、不在其他仓库创建Issue、不分享名单。她称这是一个排练开关，也是她敢于实验的原因。
- event-setup标签触发的工作：复制落地页、生成全套UTM链接、生成邀请邮件Word文档、创建跨团队请求Issue、加入项目面板、回帖汇总。
- 报名名单清洗和仅限邀请活动的等候名单筛选由每日cron工作流完成，按标准判断报名者类型后再批准。
- DRY_RUN仓库变量让工作流在不触碰外部系统的前提下完整彩排。
会后两个斜杠命令，技能写成Markdown文件
会后工作过去被认为是最糟糕的部分：导出参会者、为CRM上传重新格式化列、把公司名与账户记录匹配、写报告。现在只剩两条命令。/lead-upload抓取参会名单，整形为营销运营团队进行CRM上传所需的确切格式，创建请求Issue并关闭追踪Issue。/event-report拉取出席指标和问卷结果，把报告作为评论发在活动Issue上，回到这个活动所有信息的唯一URL。
这两条命令是GitHub Copilot agent skills，每个技能都是一个SKILL.md文件：用散文写成的流程，告诉Copilot做什么、按什么顺序、注意什么。作者称它们读起来就像她过去记在脑子里的runbook。会写runbook就会写skill。
技能也是系统保持灵活的原因。亚太区没有两个市场的会后流程完全一致，受众、细分和本地惯例都不同，硬编码的工作流会把每个市场压成同一种形状，而Markdown写成的流程允许各市场适配自己的现实，无需改动底层机制。技能以pull request形式进入、经过审查才合并，CODEOWNERS文件把审查路由给维护者。
- /lead-upload：抓取参会名单、整形为CRM上传格式、创建请求Issue、关闭追踪Issue。
- /event-report：拉取出席指标和问卷结果，把报告作为评论发在活动Issue上。
- 技能是SKILL.md Markdown文件，新技能经pull request和CODEOWNERS路由的审查后合并。
平台自带护栏与一次静默失败
作者说，她在一个全团队可见、触及客户数据和API凭证的仓库里做自动化，自己却几乎没写代码，六个月前她会认为这种组合很鲁莽。改变她想法的是意识到已经有很多护栏存在。她自建的包括DRY_RUN开关、每次pull request都运行的测试套件，以及每次变更的代码审查。
她认为最重要的护栏来自平台。Secret scanning配合推送保护：对做她这个岗位的人来说，最可怕的场景是误提交API token，GitHub的推送保护会在密钥进入仓库前阻止推送，GitHub自己的token即使漏过也会被自动吊销。Copilot的数据政策：报名名单是业务数据，固定脚本按固定方式处理，但真实工作不会完全固定，有些日子她需要对数据做一次性切分；因为GitHub Copilot商业版不保留提示也不用于训练模型，她可以直接提出这种一次性分析，而不是把业务数据粘到旁边的消费者聊天机器人里。可用的模型本身也由组织策略决定，而不是交给她个人判断。
- 自建护栏：DRY_RUN、每次pull request运行的测试套件、每次变更的代码审查。
- 平台护栏：Secret scanning与推送保护会在密钥进入仓库前阻止推送，GitHub自有token漏过后会被自动吊销。
- Copilot商业版不保留提示、不用于训练；可用模型由组织策略限定。