Boyce

有了 AI 以后写代码速度快了非常多，但是校验的速度其实还是不快的，特别是在 GitHub 上跑 Actions CI 的速度，下午花了一些时间对 Mole、Kaku、Pake 的 CI 全部彻底优化了一下，效果很不错，分享给大伙。 你可以这样直接 Copy 下面给到你的 Agent，我们来看看可以帮你节约多少时间。 帮我把这个仓库的 GitHub Actions 提速，在不减少必要的测试项以及功能校验下，最大幅度减少耗时。 1. 先使用 gh 拉最近 50 次的运行情况，把每一个 job 拆成排队、准备、真正跑测试的 3 个时间段，去看规律，可能很多时候慢的是准备的阶段，不是测试本身。 2. 同一个 PR 连着推好几次时，只跑最新的那次，旧的直接取消掉，用 cancel-in-progress 去实现。不过 main 分支不要这么做，需要确保发版 main 上的每一个提交都完整跑过一遍。 3. 只改 README 和文档的这种提交不要触发跑 CI，可以用 paths 过滤掉，另外被跳过的必需检查会一直卡住 PR 合不进去，这个要提前注意一下。 4. 优先用 setup 类 action 自带的缓存，setup-node 打开 cache，setup-go 默认就开，Rust 用 Swatinem/rust-cache，注意每个仓库缓存只有 10 GB，用不上的就不要放到这里面去。 5. 本地连着构建两次，第二次应该几乎不花时间，假如有多余的花时间的地方，一定是哪些写得有问题，比如 Dockerfile 装依赖前先 COPY 了整个仓库，或者构建脚本盯着一个不存在的文件，类似的问题记得检查。 6. 工具直接下载预编译好的，不要用 go install、cargo install 现场安装编译，这里会很费时间。 7. 不互相依赖的 job 并行跑，删掉不传数据的 needs，最长的那套测试拆到多台机器上去跑。 8. 免费账号的 macOS 最多同时跑 5 个，所有 workflow 共用，格式化、lint、依赖审计这些不挑系统的都移到 Ubuntu 去跑更好。 9. 做过的事情就不要做重复了，以及不要多此一举做事情，比如别的 job 跑过的检查就不要套重复再跑，比如只构建前端的 job 就不要多此一举去拉整个 Rust 缓存。 10. 改完去 push 那个上面测试运行效果，看运行的时间，发现规律，再次查漏补缺来优化一遍，做到最好，最后给到我优化前后的对比。