实时多人、自动化,与你——Idan Gazit(GitHub)

• 讲者 Idan Gazit 带的是 GitHub Next——GitHub 的实验室团队，他自己管它叫"瞎折腾看看会出什么事部"。Copilot 就是这个团队做出来的，之后还开拓了基于 spec 的编程、用自然语言直接生成应用等一堆方向。→ 详细
• 团队目标不是"明天的 GitHub"，而是一年后、两年后我们用来做软件的那套工具；产出不见得都变成正式产品。他强调这不算研究——"想知道什么东西会成，唯一的办法就是把它做出来"。工作基本公开，网站 githubnext.com。→ 详细

• 一个没有既定方向的研究团队，最难的永远是"什么才值得我们花时间"。他的原话："就算你是个 token 亿万富翁，就算你开着 10 个终端让 Fable 日夜不停地跑，机会成本依然在那儿——而且它就是一切。"（Fable 是他随口提的一个模型名，转写里听感一般，别当准确专名用。）→ 详细
• 在代码的边际成本趋近于零、市场噪音大、技术每周都变的环境里，他给的方法是找"持久的主题"——不管明天出什么技术都依然成立的东西。而且他明说："这已经不只是 Next 团队的问题了……我们每个人都成了实验室团队。"→ 详细

*▲ 图注：他这一季的主题就印在这一页上：multiply us, not me（放大「我们」，不是复制「我」）——agent 该做的不是给你造一堆分身，而是让一群人一起做成更多事。*

• 他的分期：AI 的第一波是个人生产力的暴涨——大模型帮你补全打的字，agent（能自己动手跑任务的 AI 助手）帮你去把东西取回来，现在一堆 agent 帮你把自己并行化。→ 详细
• 但他认为价值天花板不在这儿："最大的价值并不来自把'我'复制成更多个'我'，而是来自让一群人能做成更多事。" 两个抓手：自动化 + 协作，正好对应他后面演示的两个原型。→ 详细

• 每一次工业革命都是靠自动化发生的。他说把庞大的软件行业叫"前工业时代"听着好笑，但某种程度上是真的——在此之前我们拥有的自动化只有死规则，比如"检查每行末尾有没有分号"。现在 AI 能自动化那些需要一点基本判断力的事，这是质变。→ 详细
• 由此推出他的时间账：做好软件没有魔法，就是要花时间；自动化是"把时间买回来"的手段。"要么你多招人，要么你把手下人现在正在做的一部分事情自动化掉。"→ 详细

• 他接住了 Geoffrey Litt 前一天演讲的观点"理解才是瓶颈"，但补了一刀：这话在"我"的层面对，"我个人的理解，从来都不足以让代码在一个团队里发布出去。""我们"层面的理解不能只发生在流程最后一步。→ 详细
• 为什么现在更要紧：流程跑得快了，一个小小的错位会滚雪球滚成一大堆白费的工作，而这些工作要烧 token，token 现在是真金白银——这还没算上浪费掉的时间。→ 详细

• 演示从他的个人网站开始（他自己说这是"契诃夫的枪"，后面还会用到）。网站用 Astro 这个 Web 框架搭的，而 Astro"最棒的一点是每个月能发布大概 50 个东西，这意味着我永远在升级的跑步机上跑"。→ 详细
• GitHub 有个产品叫 Dependabot（依赖机器人，专门盯着你项目引用的第三方库有没有出新版本、有没有安全漏洞，然后给你提个 PR 提醒）。问题在于它只管通知，升级时往往还得改代码，尤其遇到破坏性变更（新版本故意改掉了旧写法，不改代码就跑不起来）。→ 详细
• 所以他要的是"一个一直待在后台的超级 Dependabot，自动盯着我的依赖，自己琢磨怎么帮我升上去，包括那些代码改动、破坏性变更"。动机他说得很直白："因为我懒，我喜欢不干活。"→ 详细

• 他怎么写的：最上面一行是"神奇的一行"——塞给 Copilot 一个 skill（一份告诉模型"这类东西该长什么样"的说明文档），内容大意是"帮我创建一个 agentic workflow，这份文档里写了你需要知道的一切"。注意这一层是元规格，讲的是格式和规矩，不是这次的具体任务。→ 详细
• 再往下的正文，用他自己的话说，"就很像我发给团队里某个初级开发的一条 Slack 消息：每天帮我看看有没有新版本发布，去读 changelog，去看文档，想一个升级方案出来，然后开一个 PR 把东西提上来，这儿是文档的链接。"——就这么长，没有参数、没有步骤编号、没有伪代码。→ 详细
• 展开结果：Copilot 生成的 playbook 里写着「升级检查器」和一串任务——第一步检查有没有新版本发布，因为它能看到代码库，自己推断出该去查哪些依赖，而且真的找到了那几个具体的依赖；然后是查 changelog 和升级指南、执行升级、最后创建 pull request。他强调："这些我一条都没有明说，但事实证明，Copilot 挺擅长把我那三行小消息挖出意思、扩写成一整份 playbook。"→ 详细
• 这里有个值得单独记住的分工："该干什么"用大白话说，"该查哪些具体东西"让模型自己从环境里读出来，只有"这类文档该长什么样"是他事先写死的。→ 详细

• 他给的定义比任何架构图都好记："agentic workflow 大致就长这样：它们看起来就是 Markdown 文档。就像 GitHub Actions 和 Copilot 生了个孩子，而这孩子跑在 Markdown 上。"（GitHub Actions 是 GitHub 自带的自动化流水线，平时用 YAML 配置文件描述"什么时候跑什么命令"。）→ 详细
• 由此带来的迭代方式非常轻："你不喜欢这个自动化的行为方式，改英文就行。" 它会被重新编译成一个 Actions workflow。他把关系挑明了——"Markdown 才是源代码，YAML 只是编译产物，你根本不用去看它。"→ 详细
• 这条的分量在于它改的是"谁是权威文本"：过去人写的说明是给机器配置作注解，现在人读的那份自然语言文档才是真源码，机器格式退化成中间产物。→ 详细

▲ 图注：护栏那页只有四行，但每行都是硬规则：纵深防御 / 别把密钥交给 agent / 所有写操作都要先暂存再审 / 记录一切。他的原话是：靠提示词约束 agent 等于把狐狸放进鸡窝。

• 文档顶部的 YAML front matter（Markdown 文件开头用 --- 围起来的一小段配置区，写元信息用的）是放护栏的地方。理由是：如果你不打算全程盯着 agent 干活，就必须给"能做什么、能读什么、能写什么"加上强得多的限制。→ 详细
• 为什么不能靠提示词：他举的例子是你对 agent 说"兄弟听着，你永远不许拿我的钱去买比特币"——这不够，因为别人可以通过 prompt injection（提示词注入：把恶意指令藏在 agent 会读到的网页、issue、邮件里，骗它当成你的命令执行）把 agent 带到你意想不到的方向去。 结论一句话："如果你的护栏是靠提示词喂给 agent 的，那基本上等于把狐狸放进鸡窝，它根本算不上护栏。"→ 详细
• 他实际写死的东西：权限只读；允许用哪些工具；允许发哪些网络请求——不是想去哪就去哪，而是一组指定的白名单：NPM 生态（查有什么新版本用）、GitHub，以及他在原始提示里点名的 Astro 文档。→ 详细
• 还有一块叫 safe outputs（安全输出）的配置：这是 agent 唯一被允许写入的东西。这个例子里只允许"创建 pull request"，而且是单数——"因为我不希望 agent 被 prompt injection 之后一口气开 500 个 PR，那就成拒绝服务攻击了"。→ 详细
• 最容易被忽略的一条：他明确写了"你也可以什么都不做"。他自己都说这听着有点傻，但很重要——"在一个我有一大堆自动化的世界里，我最不想要的就是噪音。我可不想被这些 agent 反过来拒绝服务了。"→ 详细

• 先看小版本：自动化产出的 PR 里写着"从你现在这个版本升到目标版本，你能拿到的亮点是这些"——它把中间所有的 release notes 都读了一遍，他补了一句"正常情况下这活儿得我这个人类来干"；写了份量身定制的说明，判断出没有破坏性变更，而且真的跑了一遍构建来验证。→ 详细
• 验证闭环也很实在：网站部署在 Cloudflare（他强调任何支持预览部署的平台都行——就是每个 PR 自动生成一个临时可访问的站点副本），点开链接看到页面没有任何变化，"升级做完了，站还跟原来一模一样"。→ 详细
• 真正的硬活是大版本：他运气好，Astro 刚发布了 Astro 7，所以这次是从 5 一口气跳两个大版本到 7。PR 里列出 Astro 7 带来了什么、Astro 6 本来会带来什么——他坦白："我一直没升级，就是为了给大家留一个够酷的 demo。"→ 详细
• 结果三件套：把所有被改坏的代码找出来并更新掉、验证构建能跑通、把那些需要他事后自己动手的手工步骤单独标出来。最后一条尤其关键——它没有假装全能，而是划清了机器与人的边界。→ 详细

• 他们提供了一整个 agentic workflows 的库当起点，可以拿来自己改。issue 分诊器——GitHub 内部就是拿它当基础，快速搭出了自己的 issue 分诊器，还有去他们那个大单体代码库里揪 N+1 查询（一种常见性能问题：本该一次查完的数据被拆成上百次数据库查询）。→ 详细
• repo assist 是"一群 agentic workflow 协同工作"帮你维护项目：找出容易摘的低垂果实并修掉、找出哪些工单需要推一把、哪些提了 issue 的人那边还需要拿到反馈。→ 详细
• CI doctor 配了全场最有共鸣的一句："有多少次，你面对一个跑挂的 CI，处理方式就是再跑一遍？我们所有人都这样。没举手的都在撒谎。"另外还有目标追踪、每日团队状态、仓库状态，也能让它上网做功课。→ 详细
• 他专门点了非工程角色："这不只是给工程师用的，也是给产品经理用的——他们的工作就是看这边的信息、把那边的工单总结出来。我们可以开始让所有人都参与到自动化里来，这才是真正做到工业级规模的方式。"→ 详细

• 他说这四条"所有人都该刻进脑子里"：① 纵深防御，一层永远不够；② 永远别让 agent 碰密钥；③ 所有写操作先暂存、再审核，为了可审计；④ 把所有事情都记录下来，同样为了可审计。→ 详细
• 第二条他展开得最狠："如果一个 agent 能知道某个密钥，你就得当这个密钥已经泄露了来处理"——因为你不知道有没有人注入了它、让它把密钥透露到别处。他们的做法是把密钥全放在 agent 的"牢房"外面，agent 想用密钥调服务时得先问看守："报告，我能去跟那个服务说句话吗？"→ 详细
• 外部案例：他们把这套东西给了 Home Assistant（一个巨大的开源智能家居项目），对方做的第一个 agentic workflow 是——看每个提交上来的 issue，顺着 Python 的调用栈判断这个 bug 到底出在第一方代码还是第三方代码里，不是他们的问题就直接关掉。 他的评语："这件事在 AI 出现之前是做不到的，用死规则也做不到，但现在可以了。"→ 详细
• 状态与赌注：Agentic Workflows 当天已开放 public preview（公开预览，谁都能试）。他给了一个明确的品类判断："我们其实相信，这会是一个比交互式 AI 更大的品类——因为真正决定胜负的，是那些趁你睡觉时在后台自己跑的自动化。"→ 详细

▲ 图注：全场的转场页：Automation → Collaboration。前半场讲自动化（一个人怎么把活交出去），后半场讲协作（一群人和一群 agent 怎么在同一份东西上干活）。

• 旧模式是被"写代码成本高"逼出来的：一起做规划、一起做 review，但真正动手建的那段是一个人干的——"就我一个人，对着显示器的光闷头写"。→ 详细
• 现在没有哪一步是一个人干的了："规划不再是'之前'的事，review 也不再是'之后'的事。我们一起把方向捋一遍，AI 往前走一步，然后我们再一起把方向往前推一点。" 问题随之而来：什么样的界面配得上这种开发方式？→ 详细

*▲ 图注：他为界面选型给的理由只有一句：realtime multiplayer wins every time（实时多人协作，每次都赢）——所以 Ace 长得像聊天，不是偷懒，是因为要把「不在代码里的那些事实」浮到台面上。*

• 他先自嘲这话"只是稍微有点找茬"：Slack 当年的设计目标是"对普通办公室白领来说比邮件更好用"，它从来就不是为做软件设计的。→ 详细
• 但聊天这种形态有个不可替代的长处：代码里有的事实，agent 自己读代码就能搞明白；剩下的就是代码里没有的东西。 他给的例子全是"政治与偏好"类：那边那位 VP 会认这个方向、应该做成紫色因为那是人家最喜欢的颜色、从 Azure 拿到的基础设施价格特别香所以该建在 Azure 而不是 GCP 或 AWS。→ 详细
• 更大的那层收益他用一个类比说完："我现在不会再把 Word 文档用邮件来回传了，我在同一个界面里创作，也在同一个地方协作。这件事一定会发生在代码上，一万个百分点地确定。"→ 详细

• Ace 的界面"长得特别像 Slack"，左边是 sessions（会话）列表，可以随手新建。他承认到这儿为止跟市面上 Conductor 之类的产品差不多。→ 详细
• 区别在于没有任何东西跑在他本机上，全是云上的 micro VM（微型虚拟机，一个轻量、启动极快的独立小机器）——每个 session 就是这个 repo 的一个分支，被 check out 到云端某个地方，可以在里面装依赖、跑 dev server、开浏览器预览，同时跟队友聊天。→ 详细
• （现场小插曲：他把一句聊天当成终端命令发了出去，自嘲"干得漂亮啊我"；Wi-Fi 也不给力，他只能说"这块你们得信我一次"。演示真实度还行。）→ 详细

• 演示的痒点很具体：他和队友 Russ 在频道里讨论了一整轮配色（"你确定吗？也许绿色更让人平静一点"），"我不想转过头来把那些指令再重新说一遍。我只想说一句：'Ace，照做。'" 因为它能看到他跟同事、跟团队之间完整的聊天记录，就能基于这段历史直接行动。→ 详细
• 他还点出 AI 在这件事上的一个隐藏优势：擅长从对话里把最终结论捞出来。工程师讨论的典型形态是"嘿我们试试这么干"→"等下，我想到一个边界情况，其实应该那么干"→"算了，还是回到第一个方案吧"。"与其让我自己从这么长一段对话里把最终状态一点点抠出来，不如让 AI 去干……所以我不用反过来伺候机器人。"→ 详细

*▲ 图注：他用一条进度条表示工作状态：plan（规划）→ build（构建）→ review（评审）——计划不是一次性动作，而是这条带子上可以来回滑的位置。*

• 复杂需求走另一条路：他想给应用加"可切换的时间范围"，于是先让 Ace 出一份计划，计划以一个 Markdown 文档的形式给出。→ 详细
• 关键差别在所有权："这个 Markdown 文档不只是给我一个人看、一个人改的，它是给我们一起看、一起改的。" 演示里 Russ 就在文档里加了"全部时间"选项，他自己顺手删掉"今天"，然后一句"计划我们已经更新过了，照做"——Ace 就照着两人共同改出来的这份计划执行。→ 详细
• 他从中推出一个更大的判断："我们跟 AI 一起干的活儿，越来越多地会沉淀成文档，比如 docs 目录里的 Markdown 文档，那里承载的才是'事实'。也许再往后，我们做开发的方式就是去编辑这些文档：要改我这个应用里的某个东西，我就去改一份文档，然后跟 AI 说'把这份文档变成真的'。"→ 详细
• 落点一句："所以这种共享文档编辑不只是'有了更好'的锦上添花，它可能真的就是我们愿意待着干活的那个界面。"→ 详细

• 他重提 GitHub logo 底下当年那句 slogan（"social coding"，社交化编程），说光有实时多人协作不够——"我还想在不经意间就知道大家都在忙活什么。"→ 详细
• 演示里有个团队 dashboard，显示队友各自在做什么（其中一位在做工具链方向的活儿——这块的具体词转写不清晰，别当准确专名；另一位写了这个 dashboard 还把自己的名字写死在里面，所以看板上只有她的名字）。这些都是他们开发 Ace 时的真实工作，目的是帮他跟团队保持在一条线上。→ 详细
• 他留了个开放问题：自动化要怎么在这种界面里"露面"？ 比如当一个 agent 想拍拍你肩膀、问你一个问题的时候。→ 详细

*▲ 图注：全场最扎人的一页：humans are the tool calls now（现在人类才是那个被调用的工具）——关系反转了，你越会把目标讲清楚，agent 需要打断你的次数越少。*

• 他称之为"很奇怪的一次反转"："我们越是能把自己的目标讲清楚，它们就越不需要我们。" 而随着模型变强，它们越来越擅长发现哪些地方没说明白、回头让人澄清；等它们需要一双手的时候，再叫我们去当那双手。→ 详细
• 界面层面的含义：现在的界面已经有能力支撑"agent 听着所有的动静，需要的时候把我们叫过来"这种模式。他还打趣说，他们从这一头往里走、另一个方向的团队从另一头往里走，最后落到差不多的位置（那个团队/产品名在转写里听感一般，此处不做认定）。→ 详细

▲ 图注：收尾那张条形图：开发者的时间绝大部分花在理解代码、在代码里导航和其他杂事上，真正「编辑」（打字）只占很小一条。他的结论是：工具一直在优化那 5%，而 AI 该去管剩下的 95%。

• 全场最硬的一个数："过去这几年，AI 帮我的是'打字'。但你要是看研究数据，打字只占这份工作的大概 5%。有一项纵向研究，跟踪了大约 100 名开发者、上千小时，结果发现真正手放在键盘上敲代码的时间只占 5%。"（纵向研究＝长时间持续跟踪同一批人，而不是问一次卷。）→ 详细
• 那剩下的 95% 是什么？他直接把问题列了出来：我想动的那个系统在哪儿？它今天是怎么跑起来的？别人怎么看这个系统能怎么改、该不该改？ 当 AI 能把代码库里的任何东西都翻出来时，"我们该怎么把这些'其他的事'一起放大？而不是只盯着那 5%——到目前为止，所有工具帮我们做的都只是这 5%。"→ 详细

（本期无闪电问答）——这是 AI Engineer 大会上的单人演讲，没有问答环节。演讲的收尾观点已并入上面第十九、二十节。

产品状态（演讲当天口径，会过期）：

• Agentic Workflows：已开放 public preview，"大家可以去随便折腾，尽管撒欢"。→ 详细
• Ace：争取"这个月晚些时候"进 technical preview（技术预览，比公开预览更早、更小范围的试用阶段）。→ 详细

• 讲者：Idan Gazit，GitHub Next 负责人（GitHub 的实验室团队，Copilot 的出处）。
• 团队网站：githubnext.com（团队工作大部分公开，社交账号"我们偶尔会想起来在上面发点东西"）。→ 详细
• 现场：会场里在微软展台设有位置（GitHub 是微软旗下公司）。他明确邀请反馈："我们非常想听到你们的反馈，以及你们打算拿它来干什么。"→ 详细