我自动化了自己的工作,并因此成为更好的领导者
GitHub Blog 文章中,一位 GitHub senior director 讲述她如何在 GitHub Copilot app 中使用 automations,将分散在日历、邮件、消息和 GitHub repos 中的工作上下文转化为定时运行的 agent 工作流。

正文
关于高级管理这件事,有一点没人会提前提醒你:这份工作之所以难,不是因为任何一项任务本身有多难,而是因为你的工作散落在十五个不同的地方,而你的大脑是唯一把它们连接起来的系统。
会议一个接一个,毫无间隙。决策在你不在场的线程里被做出。有人在一次规划会议上提到了你的名字,于是现在有一项行动项,正躺在一份你从未见过的文档里。两周后,你才会在别人若无其事地问你进展时发现这件事。真有意思。
去年,我们团队差点错过一次绩效评审截止日期,因为通知发在了一个没人看的频道里。一个人花了十分钟在 Slack 里搜索,也没找到;另一个人在某个完全无关的频道里才找到日期。最后我不得不发帖说:“我承认,我们在 Slack 里的跟进做得不好,这件事我负责。”当你的大脑是唯一把一切串起来的系统时,这种事就会不断发生。
我把太多精力都耗在上下文切换上,以至于没有力气再去做这个岗位真正需要的思考、连接和创造——而这恰恰也是我真正喜欢做的工作。后来我开始在 GitHub Copilot app 里使用 automations,它彻底改变了我的工作流。先听我说完。
GitHub Copilot app 是一款独立的桌面应用,支持 macOS、Windows 和 Linux,专为与智能体协作而设计,而不只是和它们对话。你可以在多个代码仓库之间并行运行会话,每个会话都有自己独立的分支和 worktree。通过 canvas,你可以实时看到智能体在做什么;canvas 是一种双向工作区,你和智能体会在同一个计划、终端或浏览器会话里协同操作。进度是可见、可调整的,而不是被埋在聊天记录里。
Automations 是按计划执行的提示词,会在你的真实工作上下文中运行:你的日历、电子邮件、消息,还有 GitHub 仓库。它们通过 MCP servers 和集成进行连接,因此能够看到你工作所处的所有位置正在发生什么。它们会告诉我真正需要我关注的内容,这样我就可以忽略其他事情。
可以把它们看作有常驻简报的智能体。你告诉它们该关注什么、该如何思考、以及何时运行。然后它们就会……照做。每天都这样。你甚至不需要记得去提醒它们。这样很好,因为你本来也记不住。
我是 GitHub 的 senior director,负责 developer relations。我的职责范围很广,日程排得很满,而且我的大脑运作方式和大多数人的预期并不一样。我是 AuDHD,这意味着我很擅长模式识别和深度专注,但对三天前承诺要跟进的是哪条线索,真的很容易忘记。
我并不是一开始就打算做出 40 个自动化流程的。我只是对 automations 标签页很好奇,就问了这个应用它能做什么,它于是给我推荐了一些我自己都没想到的东西。第一次设置时,我打开聊天窗口,大概是这样说的:“请查看我所有的工作场景、日历、邮件和消息,帮我找出我在哪些地方会顾此失彼、哪些地方可能需要帮助,并建议一些会有用的自动化流程。”
它立刻给我推荐了大约 6 个。第一版并不完美,但这没关系。你可以继续打磨它们,赋予它们你的表达方式,教它们理解你的思维方式。一旦我看到了它能做到什么,我就一直往下做。现在我大概有 40 个。(我知道,我知道。)
我不会把它们全部讲一遍。(不用谢。)但下面是最重要的几个类别,以及每个类别里的亮点。
每天在我打开任何东西之前,已经有好几个自动化流程跑完了。Meeting Prep 会拉取我的日历,为每一场会议建立上下文,并针对一对一、多人同步会议和对外通话采用不同格式。等我坐下来时,我已经知道每场会议是关于什么的,以及我需要带上什么。Pre-Meeting Access Check 会验证我是否真的能访问邀请里提到的文档和链接。再也不用到了现场才发现议程文档被锁了。要是你从没经历过那种瞬间的恐慌,老实说,真让人羡慕。Daily Triage Digest 会扫描 GitHub、邮件和消息,找出任何需要我关注的内容。
累积起来的效果就是,我的早晨从“疯狂打开十二个标签页,同时假装我已经读过议程”变成了“端着咖啡看几份摘要”。这完全是另一种生活。
我不能对我们自己的发布感到意外。这本来就是这份工作的内容。
Ship Decoder 会找出 GitHub 在过去 24 小时内发布的所有内容,并用通俗语言解释给我听。这是真正能让我在对话中用得上的上下文。Launch Radar 每周运行一次,筛出那些会影响我团队领域的即将发布内容,这样我就不会措手不及。光是这两个工具,可能就帮我省下了每天一小时去刷各个频道、拼凑到底发生了什么的时间。我以前就花这一个小时,而且我并不喜欢那一个小时。
这一类最让我意外。我做了些会主动帮助职业发展的自动化,如果这听起来有点奇怪,请先听我说完。
Daily Wins Recap 每天傍晚运行,汇总我实际完成了什么。这个自动化比听起来更重要。我的默认状态是把一件事勾掉,然后立刻转向下一件。我不会停下来感受它,也不会意识到它,就只是继续往前。然后绩效评估季就来了。我必须说明自己的影响力,却只能盯着一个空白文档发慌,努力回忆起过去八个月都做了什么。
这个自动化会持续记录,所以我不用自己记。你可以把它看作一种由真实数据支撑的感恩练习,而不是任务清单。它能对抗那种“我今天到底做了什么?”的情绪漩涡,尤其是在最忙的时候。那些 imposter syndrome 特别强烈的日子里,我需要有东西用事实回击它。即使我不相信自己,这个机器人也相信我。这感觉有点动人?我也不知道。反正它管用。
这里我想非常坦诚,因为我知道你可能会在想:她是在把自己工作中的人性部分都自动化掉吗?
不是。而且这一点对我来说,比这篇文章里的任何其他内容都重要。
“承诺与跟进追踪器”会搜索我自己的消息,找出那些我说过要做的事,并标记出我还没完成的部分。这一项让我很难堪。但它必不可少。因为当我对别人说“我去查一下”,结果却忘了,这就是信任问题。自动化是在保护这份信任。
我写的致谢仍然是我自己写的。我的留意仍然是我自己的。自动化只是确保我的大脑不会把这些本该属于别人的东西偷走。
这些自动化并不是为了取代连接,而是为了让连接成为可能。它们把我的脑力空间还给我,让我能真正腾出时间和精力去陪伴别人。在这个系统出现之前,我走进对话时总是心不在焉,或者已经快被耗干了,因为我的大脑里塞满了运营层面的噪音。现在,当我坐下来做一对一交流时,我是真正专注在场的。给团队写认可时,也会更具体、更真实。
自动化负责搭起脚手架。我负责做人该做的事。就是这么回事。
这个类别涵盖那些看起来不起眼、却会悄悄吞掉你一整周时间的琐事:Dependabot PR Triage 会每天在我的各个仓库里筛选并合并安全的依赖更新。处理完了。Stale Work Finder 会找出我开了却忘记处理的 pull request、安静下来的 issue,以及那些落了灰的分支。(我们都有这些,别否认。)Travel Logistics Tracker 会盯着会议相关线程,把行程安排整合成一份简明摘要。会议季就是一团乱,这个工具能帮上忙。
这是我配置里的一个真实例子,Stale Work Finder,这样你就能看到这些提示词在实际中是什么样子:
就这样。整个自动化就是这么回事。你写一段提示词,设定一个计划,agent 就会代表你运行它。你可以把它写得很详细,也可以写得很宽泛。应用会从你连接的工具里补充上下文。对我来说,它每周一都会运行,结果总是……多少会让人有点惊讶。但知道总比不知道好。
我直接说:对我来说,automations 是一种无障碍工具。
AuDHD 的意思是,我的执行功能和工作记忆极不稳定,而且这种不稳定最难向别人解释。有些日子,我能在脑子里同时处理十七条线索;有些日子,我会忘了自己 10 分钟后还有个会议。这中间没有过渡。过去,我会因为这种日与日之间的巨大差异而感到害怕,因为无论我那天的大脑状态如何,我的团队都值得得到始终如一的领导。
这些自动化缩小了这种差距。它们让我保持一致。它们意味着,无论我今天的执行功能有没有“上线”,我的团队都能得到同样质量的关注。对我来说,这就是蓬勃发展和慢慢燃尽之间的区别。而我已经经历过燃尽的那部分了。零星,不推荐。
如果你在考虑构建类似的东西,我想说的是:不要试图一次把一切都自动化。先从那个给你带来最大阻力的点开始。
对我来说,那是会议准备。我总是冷着头脑就走进会议,因为准备工作需要访问四个不同的工具,再把我没有余力去整合的信息综合起来。一个自动化流程就解决了这个问题。等我感受到那种轻松之后,我就继续做下去。一直做,一直做,一直做。
我能不能把其中一些整合一下?大概可以。我现在大约有 40 个,我相信其中一些完全可以合并。我更偏好细分,但如果你更喜欢,也完全可以把几个并成一个更大的自动化。
对我来说,真正奏效的技巧是:在 GitHub Copilot app 里打开一个聊天,然后让它审计你的工作界面。你总在哪些地方掉链子?哪些是重复出现的模式?你一直想做却总没做成的事是什么?就从这里开始。
第一版不会完美。没关系。你可以在对话中继续打磨它。教它理解你的表达方式、你的优先级,以及你对“好”的判断。然后让它开始运行。
先从一个开始。看看感觉如何。
然后再建一个。再建一个。没过多久,你就有了 40 个,然后开始写一篇关于这件事的博客。总之。
我认为,我们正处在一个很有意思的时刻:人们在工作中如何与 AI 建立关系。最早关于 AI 在工作中的讨论,主要集中在生成上。给我做个东西。给我写代码。至少对我来说,现实更像是对那些不可见劳动的增益。这些事会把你耗尽精力,却从不会出现在你的产出里。它们是没人会在绩效评估里提起、但每个人都深陷其中的元工作。
我认识的每一位领导都被上下文淹没。我认识的每一位神经典型之外的专业人士,都在为那些神经典型的人几乎不假思索就能处理的系统付出巨大精力。自动化无法修复组织失能、糟糕的管理,或者不合理的工作量。但它们可以把足够多的脑力空间还给你,让你真正去做你来到这里要做的工作。
说到底?这就够了。其实已经很多了。
而且,说到底,这还是 GitHub 的产品。它同样可以帮你更新依赖、整理 issue、对整个仓库做安全扫描。开发者工作流就是你预期中的那些功能。只是我碰巧把它用在了我工作里那些没人会谈起的部分。
在 GitHub Copilot 应用中创建你自己的自动化 >
Ashley Willis 是 GitHub 的开发者关系高级总监,负责以对开源、社区和关怀的深度投入来推动工作。Ashley 长期倡导开发者,职业生涯一直围绕让技术更有人情味、支持贡献者、放大代表性不足群体的声音,以及打造更具韧性的团队展开。她的工作位于领导力、倡导和可访问性的交汇点,重点是创建真正服务于使用这些工具和空间的人们。
Qubot 是我们内部由 Copilot 驱动的分析智能体,允许任何 GitHub 员工用自然语言向我们的数据提问。以下是我们在构建它时学到的东西。
GitHub Copilot 如何让每个 session 中更多时间都用于真正有用的工作,从而让你的 credits 用得更值。
Git worktree 早在 2015 年就已经出现,但直到最近才开始流行。了解它是什么、如何使用,以及你为什么可能会需要它。
在我们每两周一期、专为开发者准备的 newsletter 中,发现技巧、技术指南和最佳实践。
AI解读
值得关注的是,这篇文章把 AI agent 的价值放在“跨工作界面持续追踪上下文”上,而不是一次性问答或代码生成,展示了知识工作和管理工作的自动化切入点。
对 AI builder 和开发者而言,这提示了一个产品方向:围绕真实工作上下文、定时任务、MCP 连接和可审计摘要构建 agent 工作流。对创业者而言,团队协作、领导力运营和个人工作记忆可能是可产品化场景。
建议观察 GitHub Copilot app 的 automations、MCP 集成和 agent 工作面能力如何演进;若在团队内试用,应先从会议准备、待办跟进、发布摘要等低风险场景开始,并明确哪些内容只能辅助、不能替代人工判断。