GitHub 把营销工作塞进 Issue，Copilot 负责起草，人仍要签字

GitHub 日本和韩国地区的营销负责人 Tomoko Tanaka 9 月 11 日发表文章，介绍她怎样把活动运营搬进 GitHub。她列出的工作很具体：复制活动落地页、生成各渠道链接、写邀请邮件、更新两个项目看板、每天清理报名名单，活动结束后再整理 CRM 上传文件。

Tanaka 说，自己没有从头写一套应用，而是把已有 runbook 交给 GitHub Copilot，在对话中逐步长出自动化。现在，一个 GitHub Issue 可以触发活动页面、链接、邮件文档和项目更新；定时任务每天拉取报名名单，活动结束后再用命令生成上传文件和报告。

文章称，过去手工准备一场活动要花上几天，现在从一个 Issue 开始即可完成。这个说法来自作者所在团队的内部实践，文中没有给出活动数量、人工小时、错误率或持续几个月的对照数据，不能据此计算普遍的效率提升。

文章里最清楚的一句分工是：Copilot 起草，负责人决定。对话会提出活动名称、邮件版本和需要确认的问题；日期、受众、活动名称和邮件主题仍由人签字，确认后才把 Issue 和标签交给后面的工作流。

实现这一分工靠的是几个很朴素的部件。Issue form 负责收集固定字段，label 充当触发条件，GitHub Actions 读取字段后调用活动平台 API 或 CRM 的官方 CLI。模型处理的是语言和选择，脚本处理的是复制页面、改字段和上传文件。

这和‘让模型替你做完营销’是两回事。可重复的动作有明确输入和输出，才适合交给脚本；活动主题、目标受众和邮件语气会随市场变化，仍要留在人的审阅范围内。

Tanaka 给每条工作流加了一个 DRY_RUN 开关。打开后，流程会完整走一遍，却不会创建落地页、向其他仓库发 Issue 或分享名单。改动通过 pull request 审阅后再合并，团队可以先看结果，再决定何时允许真实写入。

报名筛选则由每天运行的定时任务完成，活动结束后的整理通过 /lead-upload 和 /event-report 两个命令触发。每一步都有一个 Issue 可以回看，流程变更也留下版本记录。对需要多人协作的营销团队来说，记录放在哪里，往往和模型选哪家同样影响执行。

这套安排仍然出过问题。文章承认，报名筛选任务曾经静默失败五天，直到有人发现名单已经过期。作者后来补上了提醒。自动化少写几行重复代码，并不会自动知道自己已经坏了。

文中没有公布接入活动平台和 CRM 的维护时间，也没有拆出 Copilot、Actions、人工复核各自占用多少成本。‘从几天缩到几分钟’描述的是一个准备动作，不等于整场活动的运营时间按同样比例下降。

这套做法还依赖现有工具能提供 API 或 CLI。GitHub 自己的营销团队可以直接使用内部权限和企业方案，其他公司可能面对审批、数据隔离、供应商限制或没有 CLI 的旧系统。把同一套文件复制过去，未必能得到同样结果。

文章提到企业方案的提示词和报名数据政策，也提到组织可以限制可用模型。这些承诺属于 GitHub 的产品与合同范围，采购时仍需逐条核对数据保留、权限和审计条款。

一个流程是否适合这样改，先看三件事：输入能否写成固定字段，外部工具有没有稳定入口，失败后能否找到哪一步出了问题。缺一个，模型写得再顺也只是在聊天框里多了一份草稿。

试做时可以从一条最重复、影响范围有限的任务开始，先用 DRY_RUN 记录每个动作，再拿原来的人工流程对照报名名单、链接错误和复核时间。成功案例要把失败批次也算进去，沉默的五天不能从统计里消失。

GitHub 这篇文章的价值在于把分工写明白：模型负责起草和提问，规则、脚本和审批负责落地。它展示的是一套可检查的工作方法，还不是营销团队普遍省时的证据。