太长不看
- 自动化就是描述一次、反复执行的任务：触发器有 Manual（手动）、Hourly、Daily、Weekly 和 Issue created（新建 issue 时）五种。
- 把定时设在工作日开始之前（演示用上午 9:00），再决定跑在云端还是本机。
- 用自然语言写 prompt、选好项目，然后点 Create and run 立刻试跑，不用干等定时。
- 每次运行产出一份报告：PR 按风险分组、标出可直接合并的，并给出最佳下一步，一键就能转成新会话。
手把手创建你的第一个自动化
配置自动化
- 1
新建自动化并命名
在 Copilot app 里打开 Automations 区，点 New automation。起一个以后能在列表里认出来的名字——演示用的是“Daily Dependabot triage”。名字是给你自己看的，Copilot 真正执行的是下面的 prompt。
按任务内容命名，别按工具命名。在 1:28 观看 - 2
选一个匹配节奏的触发器
菜单里有五种触发器：Manual 自己手动点火，适合试想法；Hourly、Daily、Weekly 按时间表跑；Issue created 则在有新 issue 出现时自动触发。演示把 Daily 留在上午 9:00——正好赶在工作日开始之前。
试验阶段用 Manual，跑顺了再上定时。在 1:00 观看 - 3
用自然语言把任务描述一次
这里的 prompt 和普通会话写法一致。演示让 Copilot 审查 Dependabot 的开放 PR、按风险分组、标出可以安全合并的、区分 minor 与 major 版本升级、确认各自的 CI 通过，最后给一段最佳下一步的简短总结。
能粘进会话里的需求，就能当自动化跑。在 2:00 观看 - 4
把自动化指向正确的项目
在 prompt 下方选择自动化要作用的仓库——演示选了 tailspin-toys，Dependabot 的 PR 都在那里。这里也能像交互会话一样调整模型和 agent 控制项。
一个自动化盯一个项目，报告才聚焦。在 2:08 观看
启动并观察第一次运行
- 5
保存并立刻试跑第一次
点 Create 保存，等上午 9:00 的定时；或者点 Create 旁边的小箭头选 Create and run，保存的同时立刻手动跑一次，不用干等就能看到效果。
Create and run 是验证 prompt 最快的办法。在 2:20 观看 - 6
在 Your automations 里看它上线
保存后的自动化会以卡片形式出现在 Automations 屏上，带着触发器徽章和实时状态。以后随时可以手动触发，也可以边用边改 prompt。
触发器、仓库、最近一次运行，卡片上一目了然。在 2:26 观看 - 7
读报告，而不是翻 PR 列表
原来要耗掉一早上的活儿，回来时变成一份整理好的报告。演示里的这次运行把 Dependabot PR 按风险等级分组、把安全项标成 Passing，头部还有“Last run 1m ago”的时间戳。
风险分组加 CI 状态，取代一收件箱的升级 PR。在 3:00 观看
拿着结果干活
- 8
分清能直接合并的和要单独评估的
Low、Medium 行——打包的 dev 依赖 bump 和 minor 更新——快速过一眼就能合并。High 行写着 Do not merge：major 框架或集成升级，值得单独走一遍评审。
报告的价值就是把“能合/别动”划清楚。在 3:08 观看 - 9
照着最佳下一步执行
表格之外 Copilot 还给了行动顺序：先合安全的；孤立的 major bump 可以后置；相关的几个 Astro 升级因为已经在打崩 CI，要当成一次整体迁移来处理。
总结告诉你先做什么、再做什么、为什么。在 3:20 观看 - 10
把发现变成后续会话
当报告里出现真正的活儿——比如 Astro 6 升级——不用重新解释背景。直接在报告下方的输入框里下单，Copilot 会带着已有上下文开一个新会话，而自动化条目继续留作审计记录。
报告就是修复工作的起点。在 3:28 观看
云端还是本机：自动化跑在哪
Run in the cloud 开关决定 agent 在哪里执行，而且影响的远不止进程位置。官方演示保持关闭、在本机跑；两种模式在实际使用中的差别如下。
- 1本机运行在你的机器上执行，电脑关机就不会跑。prompt 还在试验期时它是自然的默认选择；另外按文档说法，只有本机自动化支持自定义 CRON 表达式。
- 2云端运行“电脑关着也照跑”——这是开关自己的描述。云端运行依赖仓库开启 Copilot cloud agent，动作直接发生在仓库里而不是你的工作区。
- 3云端模式下，Tools 下拉可以限制 Copilot 能做什么——推送代码、改标签、开 PR。文档建议只勾选任务需要的工具，给无人值守的任务拴上短绳。
- 4成本和权限也不一样：云端自动化要求仓库是 private 或 internal，每次运行的 Actions 分钟数和 AI credits 记在创建者账上；有写权限的人都可以创建自动化。
一个务实的默认姿势：先用 Create and run 在本机迭代到报告像样，再打开开关交给定时。一个触发器不够用的话，app 还支持添加多个——任一触发器命中，自动化就会执行。
先自动化什么（以及怎么排查一次运行）
GitHub 官方建议：从一个你已经“肌肉记忆”的无聊任务开始。缺灵感的话，Automations 屏自带模板——Issue triage、Changelog draft、Repo audit——都是不错的起点。
- 1日常杂活是最佳场景：给 Dependabot PR 分类、把新 issue 分桶、检查整个仓库的 CI 是否全绿。视频里的经验法则：有明确判断标准的活儿，都能无人值守地跑。
- 2从模板起步，然后按会话的写法重写 prompt——动词具体、分组明确、输出有定义。演示 prompt 要的是分组、标签加总结，而不是一句“看看 PR”。
- 3自动化不是黑盒：每次运行都会落在 Automations 区，跑了什么、什么时候跑的、干了什么一清二楚。结果不对劲时，先打开运行记录读会话，再动 prompt。
- 4报告指向真正的开发工作时，直接从结果续一个会话——演示里的 Astro 6 升级就是这么起的头，自动化攒下的上下文全都在。
- 5prompt 产出不满意？编辑自动化、把要求写紧，然后用 Create and run 立刻验证，别傻等下一个定时。
把自动化当成带脑子的 cron job：小而清晰、跑得勤的任务，胜过又大又空、一月一跑的巨无霸。一套节奏跑出信任之后，复制到下一个仓库就行。