市场运营即代码：GitHub 日本营销负责人用 Copilot 把活动全流程自动化成一条 Issue

星海拾光AI 前沿2026-09-17715 阅读💛 134 收藏

一句话结论

「如果你能把自己做事的方法写下来，你就能把它自动化。」GitHub 日本与韩国市场负责人 Tomoko Tanaka（前工程师）没写代码，而是把活动运营的 runbook 写下来交给 GitHub Copilot，用对话把自动化一点点养大。今天，一场过去要手工拼装两天的活动，现在从一个 GitHub Issue 自动完成搭建，每天早晨 AI 自动筛报名者，活动结束自动收拾残局。

活动运营里藏着的自动化机会

她的工作重心是面向企业开发者的系列网络研讨会、东京社区聚会、首尔高管闭门会。活动拍板之后是一串固定动作：在活动平台复制落地页；生成一整套 UTM 标记链接（每个渠道一条、格式严格统一）；起草邀请邮件并向发送团队提需求；把活动加进两个项目看板；活动前的每个早晨下载报名名单、清洗、发进度更新；活动后导出参会者、整理成 CRM 上传格式、打标签、写复盘报告。

单看没有一件难事，但每一件都是贴错链接、漏做一天、拼错活动名的机会——而 15 份下游报表指着这个名字。她说自己看到了一条「求着被自动化」的流水线。

一个活动就是一条 Issue

GitHub 市场团队本来就有「一个项目开一条 GitHub Issue」的习惯，计划、讨论、状态都住在一起。她做的事是让 Issue 自己干活。三个 GitHub 原语撑起整套系统：

Issue 表单是申请表。不是空白文本框，而是结构化字段：活动标题、日期、区域、活动名、目标人群。每种活动类型一张表单，喂给同一套机器。
标签是开关。event-setup 这类标签不是分类标记，是触发器——每条自动化工作流都以此标签存在为运行前提。
Actions 是机器。标签一落，工作流启动，从 Issue 正文解析表单字段，去干活。

仓库给开发者的一切，免费给了她的市场工作流：历史、可见性、审查、每个决策一条 URL。

一个前提跟活动无关但必不可少：活动管理平台有 API。CRM 甚至不需要 API——官方 CLI 覆盖全部操作，认证走浏览器登录，她从没配过 API key。API 或 CLI，要求是一样的：一个可编程的入口。如果你的重复工作经过的工具（活动平台、CRM、表单、数据分析服务）有其中之一，这套模式就适用。

为什么不用现成的营销自动化平台？亚太不是一个市场，是一组差异很大的市场：同一场研讨会这个月东京用日语、下个月首尔用韩语，细分人群不同、CRM 字段不同、「优质线索」的定义也不同。让打包工具吃下所有变体意味着定制预算、咨询工时和等别人的路线图。用现成工具自己搭，工作流变更就是一个拉取请求：描述清楚要什么、审查者把关、按开发者改软件的同一套流程合入主分支。

策划活动是一场对话

流水线的起点在 Issue 创建之前。她打开 GitHub Copilot 说：「我想在 11 月办一场关于 AI 辅助开发的网络研讨会。」

接下来的走向由仓库根目录的 AGENTS.md 决定——团队的 runbook，纯 Markdown 写成，定义活动命名规则、财季怎么映射日期、各区域用什么时区、一封合格邀请邮件长什么样。Copilot 读完，找出一场相似的往期活动，按命名规则提议活动名，起草两版邀请邮件，再把 runbook 里该问的问题问一遍。

把对话放在流水线最前端本身就是个设计决策，一次解决两个问题。全自动会失去弹性——哪天你想让这场活动稍微不同，僵硬的流水线没有开口的余地；全人工又难免出错。对话恰好卡在中间：Copilot 按模板走，落进 Issue 的数据格式正确；因为是对话，这一场的细节可以掰弯而不弄断下游机器。

早期这场对话在 Copilot CLI 的终端里进行，但「打开终端」对很多想拉进这个工作流的人是道坎。Copilot 桌面应用出现后，同样的对话在普通桌面窗口里进行，门槛从「习惯命令行」降到「会打字」。

分工要说精确，因为这是全部要点：Copilot 起草，我做决定。每个活动名、每封邮件标题、每个日期都要她签字才动。对话结束时 Copilot 带着正确的标签建好 GitHub Issue，机器从这里接手。

一个标签，一场活动，全套就位

event-setup 标签落到 Issue 上的那一刻，GitHub Actions 工作流几分钟内干完过去大半天的活：复制往期活动生成新落地页；生成全套 UTM 标记链接（每渠道一条、格式每次一致）；把邀请邮件生成 Word 文档提交进仓库；给发邮件和跟进区域市场的团队开请求 Issue；把活动加进项目看板并填字段；回帖一条汇总评论，下一个打开 Issue 的人一眼看全。

报名筛选按计划任务跑而不是按标签。每天早晨，定时工作流拉取每场进行中活动的最新报名者，分享清洗后的名单；闭门活动还会按条件筛等候名单——报名者是企业客户的开发者、学生，还是特别想参加高管简报的竞对——然后才放行批准。

她最得意的设计决策是一个叫 DRY_RUN 的总开关，存成仓库变量，每条工作流运行前都查它。打开它，所有工作流走完全部动作但不碰任何外部系统：不建落地页、不在别的仓库开 Issue、不分享名单。一个自动化自己工作的市场团队需要排练手段，DRY_RUN 就是排练开关——这是她从不怕做实验的原因。

活动结束，两条命令

活动后的活以前最熬人：导出参会者、按 CRM 上传格式重排列、按客户名匹配账号、写报告。现在用两条 AI 命令直接生成交付物。/lead-upload 拉取参会者名单、整成市场运营团队要的精确格式、提交上传请求 Issue、关掉跟踪 Issue。/event-report 拉出参会指标和问卷结果，把复盘报告作为评论发回活动 Issue——一切都回到那一个 URL。

这些是 GitHub Copilot 智能体技能（agent skills），而关键在这里：一个技能就是一个 Markdown 文件。每个技能是一份 SKILL.md：用散文写成的操作流程，告诉 AI 智能体做什么、按什么顺序、注意什么。她写的技能读起来就像她以前记在脑子里的 runbook，因为本来就是。

能写 runbook，就能写技能。技能也是系统保持弹性的原因：亚太没有两个市场的后续动作完全一样，受众不同、分层不同、本地惯例不同，硬编码的工作流会把所有市场塞进一个模子。Markdown 写的流程可以各自适配市场现实而不动底层机器——这就是后续步骤放在 Copilot 技能而不是固定流水线里的原因。技能在一点上被当代码对待：新技能靠拉取请求进来、审查后才合入，CODEOWNERS 文件把审查路由给维护者。市场自动化自带审批流程，治理随平台免费送。

自带的护栏让人敢做实验

她自动化的是一条碰客户数据和 API 凭证的工作流，放在全团队可见的仓库里，而且几乎没写代码。半年前她会说这个组合是莽。改变判断的是看清了有多少护栏早就位。

自己建的护栏：DRY_RUN 开关、每个拉取请求都跑的测试套件、每次变更的代码审查——标准开发者习惯，保护市场工作和保护软件一样好。平台自带的护栏更关键：

密钥扫描与推送保护。她这个位置最怕的就是手滑提交 API token。GitHub 的推送保护在密钥落库之前就挡下这次 push，GitHub 自家 token 即使漏网也会被自动吊销。
Copilot 的数据策略。报名名单是业务数据，固定脚本用固定方式处理；但真实工作总有脚本没预料到的一次性分析。因为 Copilot 商业版不保留提示词、不用提示词训练模型，她可以直接要那次性分析，而不是像全行业很多人悄悄干的那样——把业务数据贴进旁边标签页开着的消费级聊天机器人。可用哪些模型也由组织策略定死，不由个人判断，一次性实验也跑在公司已划定边界内。安全的路和省事的路，头一回是同一条。

技能还带来一个副产品：每个流程现在是命名固定的作业单元，可以按活给 AI 模型分工——快而便宜的模型管每日名单清洗，更强的模型起草活动文案。

一个诚实教训：每天早晨的筛选工作流曾静默失败五天才有人发现名单不新鲜了。不监控的自动化是延迟引爆的定时炸弹——给每条定时工作流一个大声抱怨的渠道，别漏掉。

从一个任务开始

给同病相怜的手工劳动者们的建议：挑出一周里最重复的那一个任务，查一下它经过的工具有没有 API 或 CLI——你会惊讶有多少都有。然后做最小可行版本：一张捕获输入的 Issue 表单、一个意为「开跑」的标签、一条只干一步的 Action。或者直接把 runbook 写成 SKILL.md 让 Copilot 执行。带着 dry-run 开关跑到你信任它为止，再往外长。她没写代码，只是把自己已经知道的东西（这活儿怎么干）写下来，平台干了剩下的一切。你的那份「早晨报名名单」，离自己跑起来大概就差一份写下来的 runbook。