用 40 个自动化流程重塑技术领导力
GitHub 员工分享 AI 自动化工作的实战案例,展示智能工具如何优化技术管理的日常流程。
GitHub 员工分享 AI 自动化工作的实战案例,展示智能工具如何优化技术管理的日常流程。
关于高层领导工作有一个事实,没人会提前告诉你:工作的难度不在于任何单一任务。而是因为你的工作散落在十五个不同的地方,你的大脑是唯一连接它们的系统。
会议接连不断。决策在你不知情的线程中做出。有人在规划会议中提到了你的名字,现在有个行动项出现在你从未看过的文档里。两周后,当某人随意问你进展如何时,你才会发现它。很有趣吧。
去年,我的团队差点错过绩效评估截止日期,因为它在一个没人在看的频道里宣布。一个人花了十分钟在 Slack 上搜索都没找到。另一个人在某个无关的频道里找到了日期。最后我只能发贴说"我得承认,我们在 Slack 跟进上掉链子了,这是我的错"。当你的大脑是唯一连接一切的系统时,这种事就不停发生。
我花了太多精力在上下文切换上,导致没精力去做思考、连接和创意工作——而那才是我的角色真正需要的,也是我真正喜欢做的事。但后来我开始在 GitHub Copilot 应用中使用自动化功能,它彻底改变了我的整个工作流。请听我解释。
GitHub Copilot 应用是一个独立的桌面应用,支持 macOS、Windows 和 Linux,专为与 agent 协作而构建,而不仅仅是与它们对话。你可以在多个仓库中运行并行会话,每个会话都有自己的分支和工作树。你可以通过 canvas 实时看到 agent 在做什么,canvas 是双向工作表面,你和 agent 在同一个计划、终端或浏览器会话上操作。进展是可见和可引导的,不会被埋在聊天历史里。
自动化是针对你真实工作上下文运行的定时提示:你的日历、邮件、消息、GitHub 仓库。它们通过 MCP 服务器和集成连接,能看到你的工作在所有地方发生了什么。它们告诉我什么真正需要我的关注,这让我能忽略其他的。
把它们想象成有固定任务的 agent。你告诉它们应该关心什么、怎样思考,以及什么时候运行。然后它们就……做了。每一天。你不用记得去要求。这很好,因为你反正不会记得。
我是 GitHub 的高级总监,领导开发者关系。我的职责范围很广,日历满满当当,我的大脑工作方式与大多数人的假设不同。我是 AuDHD,这意味着我擅长模式识别和深度专注,但对于记住三天前承诺跟进的那个线程真的很差。
我一开始并没有打算构建 40 个自动化。我只是对自动化标签感到好奇,问了应用它能做什么,它建议了一些我没想到的事情。第一次设置时,我打开聊天说了类似这样的话:"审视我所有的工作表面、我的日历、邮件、消息,找出我在哪里掉链子、哪里可能需要帮助,建议一些有用的自动化。"
它立即建议了大约六个。最初的草稿并不完美,但这没关系。你可以改进它们。你给它们赋予声音。你教它们你怎样思考。一旦我看到了可能性,我就继续了。一直继续。现在我有大约 40 个。(我知道。我知道。)
我不会一一讲过所有的。(你应该庆幸。)但这些是最重要的类别,以及每个类别的一些亮点。
每天在我打开任何东西之前,几个自动化已经运行了。Meeting Prep 提取我的日历,为每个会议构建上下文,对一对一会议、大型同步会议和外部电话有不同的格式。到我坐下的时候,我已经知道每个会议是关于什么的,我需要带什么。Pre-Meeting Access Check 验证我确实可以访问邀请中引用的文档和链接。不会再出现到场才意识到议程文档被锁定的情况了。如果你从未经历过那种特殊的恐慌,老实说,一定很幸福。Daily Triage Digest 扫描 GitHub、邮件和消息,找出任何需要我关注的事情。
累积效果是我的早晨从"疯狂打开十二个浏览器标签页,同时假装我读过议程"变成了"边喝咖啡边读几个总结"。这是完全不同的生活。
我不能被我们自己的发布所打蒙。那字面上就是这份工作。
Ship Decoder 找到 GitHub 过去 24 小时内发布的一切,并用通俗语言向我解释。这是我能在对话中使用的真实上下文。Launch Radar 每周运行,展示接下来的发布中会涉及我团队领域的,所以我永远不会被打蒙。仅这两个自动化就可能每天为我节省一小时的时间——原本我会在频道里滚屏,试图拼凑发生了什么。我曾经经常花那一小时。我一点都不喜欢那一小时。
这是让我最惊讶的类别。我构建了积极进行职业发展的自动化,如果这听起来很奇怪,请继续听我说。
Daily Wins Recap 每晚运行,总结我实际完成的工作。这个比听起来更重要。我的默认模式是勾掉某个事项,然后立即转到下一个。我不会停留在它上面。我不会肯定它。我就是继续前进。然后绩效评估季节到来。我必须阐明我的影响,我惊恐地盯着一个空白文档,试图记起八个月的工作。
这个自动化维护一个运行记录,所以我不必这样做。把它想象成由真实数据支持的感恩实践,而不是任务列表。它对抗"我今天到底做了什么?"的螺旋思维,这种思维在最忙碌的日子里最容易出现。在冒牌货综合症很严重的日子里,我需要用事实来回应它。机器人即使在我不相信自己时也相信我。这是……奇怪地感人?我不知道。但有效。
这是我想要特别诚实的地方,因为我知道你可能在想:她是在自动化工作中的人性部分吗?
不是。这个区别对我来说比这篇文章中的其他任何东西都更重要。
Commitments and Follow-Up Tracker 搜索我自己的消息,找出我说我会做的事情,并标记出我还没做的。这个很谦卑。也很必要。因为当我对某人说"我会看看这个",然后忘记了,那就是信任问题。这个自动化保护了信任。
我写的称赞仍然是我的。注意到的东西仍然是我的。自动化只是确保我的大脑不会把它从应该得到它的人那里夺走。
这些自动化不是为了取代连接。它们使连接成为可能。它们给我返还了心智空间来真正出现在人们面前。在这个系统之前,我走进对话时心不在焉或身心俱疲,因为我的大脑充满了运营噪音。现在当我在一对一会议上坐下时,我真的在场。当我为团队写表扬时,它是具体而真实的。
自动化处理脚手架。我做人的工作。这是协议。
这个类别涵盖那些如果你不加注意就会悄悄吃掉你一周的无聊的事情:Dependabot PR Triage 每天找到并合并我的仓库中的安全依赖更新。完成了。Stale Work Finder 展示我打开的、被我忘记的拉取请求、进展停滞的问题、堆积灰尘的分支。(我们都有这些。别撒谎。)Travel Logistics Tracker 监视与会议相关的线程,并将后勤信息整合为一个简洁的摘要。会议季节是混乱的。这有帮助。
这是我设置中的一个真实的自动化——Stale Work Finder,所以你可以看到这些提示在实际应用中是什么样的:
Find all my stale work across GitHub using the gh CLI. Things that are falling through the cracks.
Check for:
- PRs I opened that haven't received a review in 7+ days
- PRs I'm assigned to review that I haven't reviewed yet (older than 3 days)
- Issues assigned to me that have had no activity in 14+ days
- Draft PRs I own that have been drafts for 2+ weeks
- For each item show: repo, title, link, how long it's been stale, and who's involved.
Format as:
1. 🔴 Embarrassingly stale (3+ weeks)
2. 🟡 Getting dusty (1-3 weeks)
3. 🟢 Just needs a nudge (under a week)
就是这样。这就是整个自动化。你写一个提示,设置一个时间表,agent 就代表你运行它。你想要多详细或多宽松都可以。应用从你连接的工具中填入上下文。它为我每周一运行一次,结果总是……有点令人瞠目结舌。但最好知道。
我就直说了:对我来说,自动化是一个无障碍工具。
AuDHD 意味着我的执行功能和工作记忆极其不一致,这种不一致是最难向人们解释的部分。有些日子我能在脑子里保持十七个线程。其他日子我忘记了十分钟后有一个会议。没有中间状态。那些日子之间的差距曾经让我害怕,因为我的团队无论我的大脑在任何特定的周二做什么,都应该得到一致的领导。
这些自动化缩小了那个差距。它们让我保持一致。它们意味着无论我的执行功能今天是否出现,我的团队都能得到相同质量的关注。对我来说,这是兴盛和缓慢倦怠之间的区别。而我已经经历过倦怠。零星评价,不推荐。
如果你在考虑构建类似的东西,我想说的是:不要试图一次自动化所有的事情。从给你造成最大摩擦的那一件事开始。
对我来说,那是会议准备。我一直走进冷会议,因为准备需要访问四个不同的工具,并综合我没有带宽去综合的信息。一个自动化修复了这个。一旦我感受到了那种解脱,我就继续了。一直继续。一直继续。
我能合并其中一些吗?可能可以。我有大约 40 个,我确信其中一些可以合并。我更喜欢特定性,但如果那更适合你的风格,你可以轻松地将多个合并成一个大自动化。
对我来说有效的技巧是这样的:在 GitHub Copilot 应用中打开聊天,要求它审计你的工作表面。你在哪里掉链子?重复的模式在哪里?你一直想做但从未完成的东西是什么?从那里开始。
第一稿不会完美。这很好。你在对话中改进它。你教它你的声音、你的优先级、你如何思考"好"。然后你让它运行。
从一个开始。看看感觉如何。
然后构建另一个。再构建一个。在你意识到之前,你有 40 个,你正在写一篇关于它的博客文章。无论如何。
我认为我们正处于一个有趣的时刻,关于人们如何在工作中与 AI 相关联。关于工作中的 AI 的早期对话主要是关于生成的。为我制造一个东西。给我写代码。至少对我来说,现实更像是看不见的劳动的增强。那种会让你精疲力竭但从不显示在你的输出中的东西。没人在绩效评估中认可的元工作,但每个人都淹没在其中。
每个我认识的领导都被上下文压倒了。每个我认识的神经不同的专业人士都在花费大量精力来应对神经典型的人毫不费力就能驾驭的系统。自动化不会解决组织功能障碍或糟糕的管理或不合理的工作负荷。但它们可以给你返还足够的心智空间来真正做你来这里要做的工作。
而且诚实地说?这就够了。这已经是很多了。
而且,这是一个 GitHub 产品。它还将运行你的依赖更新、整理你的问题、对你的仓库进行安全扫描。开发者工作流恰恰如你所料。我只是碰巧把它用于我工作中没人谈论的部分。
在 GitHub Copilot 应用中创建你自己的自动化 >
Ashley Willis 是 GitHub 的开发者关系高级总监,她以对开源、社区和关怀的深刻承诺进行领导。作为开发者的长期倡导者,Ashley 建立了一个围绕让技术更人性化、支持贡献者、放大代表性不足的声音,以及构建有弹性的团队的职业生涯。她的工作位于领导力、倡导和无障碍的交叉点,重点是创建真正为使用它们的人服务的工具和空间。
The harness is all you need (mostly)
一个实际的 GitHub Copilot 工作流,用于原型设计、规划、实现和审查软件,而无需追逐每个新的 AI 工具。
GitHub Copilot app for Beginners: Getting started
刚接触 GitHub Copilot 应用?了解如何启动项目、与 AI agent 协作、探索 canvas,并简化你的开发工作流。
Copilot vs. raw API access: What are you actually paying for?
Copilot 现在按列出的 API 费率计费。比较直接模型访问与编码工作流、政策以及围绕它的工作。