gh-aw：GitHub 下一代 AI 工作流引擎，Don Syme 操刀的 AI 抽象层
gh-aw：GitHub 下一代 AI 工作流引擎，Don Syme 操刀的 AI 抽象层
GitHub 又放了个大招。
来自 GitHub Next 和 Microsoft Research 的联合项目——gh-aw，在短短时间内已经斩获 4,300+ Stars。
项目仓库： https://github.com/github/gh-aw
技术栈： Go 1.25.8
当前版本： v0.67.3（技术预览阶段）
核心贡献者： Don Syme — 没错，就是那个 F# 语言的设计者，async/await 编程模型的提出者。
这个项目不简单。它不是又一个 AI Code Review Bot，也不是又一个"用 AI 写 YAML"的玩具。
gh-aw 在做一件更本质的事情：为 AI 时代的工作流定义，构建一套新的抽象层。
它到底是什么？
先给个最简单的定义：
gh-aw 是一个 gh CLI 扩展，它把人类用自然语言写的 Markdown（.md 文件），编译成机器可执行的 GitHub Actions 工作流（.lock.yml 文件）。
Markdown 文件（人类写的）
↓
gh-aw 编译器
↓
GitHub Actions 工作流（机器跑的）但这只是表面。真正重要的是它背后的设计思想：
我们不应该用 YAML 给 AI 写工作流。我们应该用人类的语言描述工作流，然后让编译器把它变成机器可执行的格式。
这是一个范式转移。以前是"人迁就机器，写机器能懂的 YAML"；现在是"机器迁就人，编译人写的自然语言"。
为什么这很重要？
在深入技术细节之前，先理解这个项目的背景。
GitHub Actions 的成功和局限
GitHub Actions 取得了巨大的成功。现在几乎每个开源项目都在使用它做 CI/CD。
但它有一个根本性的问题：YAML 是给人写的，不是给 AI 写的。
当你想让 AI 帮你写一个 GitHub Actions 工作流时，你会遇到这些问题：
- AI 不知道你项目里有哪些自定义 Actions
- AI 经常用不存在的参数或者过时的版本
- 每次生成的 YAML 格式都不一样，很难维护
- 你改了需求，AI 就得整个重写，而不是增量修改
- 没有类型检查，错了只能跑一遍才知道
换句话说，GitHub Actions 对于 AI 来说，是一个没有类型系统、没有标准库、没有编译器的汇编语言。
gh-aw 要解决的就是这个问题。
Don Syme 的参与，意义非凡
Don Syme 是谁？
- F# 编程语言的设计者
- async/await 异步编程模型的提出者（后来被 C#、JavaScript、Python、Rust 等几乎所有语言借鉴）
- .NET 平台的核心贡献者
- 微软研究院院士
他不是来"凑热闹"的。他参与这个项目，意味着 gh-aw 不是一个简单的工具——它在探索 AI 时代的编程范式。
就像当年 async/await 重新定义了我们怎么写异步代码，gh-aw 可能正在重新定义我们怎么和 AI 一起定义工作流。
核心概念：aw 语言
gh-aw 的核心是一个叫做 aw 的领域特定语言（DSL）。
但它的特别之处在于：aw 语言的语法就是 Markdown。
一个最简单的例子
创建一个文件 ci.aw.md：
# CI Workflow
当有人提交 PR 或者推送到 main 分支时，运行这些步骤：
1. 签出代码
2. 安装 Node.js 20.x
3. 安装依赖：npm install
4. 运行测试：npm test
5. 如果测试通过，并且是 main 分支，部署到生产环境然后运行：
gh aw compile ci.aw.md它会生成一个 ci.aw.lock.yml 文件，内容大概是这样：
name: CI Workflow
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20.x
- run: npm install
- run: npm test
- name: Deploy to production
if: github.ref == 'refs/heads/main'
run: npm run deploy这看起来像是"AI 生成 YAML"？别着急，往下看。
真正的魔法：增量编译
假设你后来改了一下 Markdown 文件：
# CI Workflow
当有人提交 PR 或者推送到 main 分支时，运行这些步骤：
1. 签出代码
2. 安装 Node.js 20.x
3. 安装依赖：npm install
4. 运行测试：npm test
+ 5. 运行 lint 检查：npm run lint
6. 如果测试通过，并且是 main 分支，部署到生产环境然后你再次运行 gh aw compile。
gh-aw 不会重新生成整个文件。它会理解你改了什么，然后增量地修改 YAML。
它知道：
- 你加了一个新步骤
- 这个步骤应该在测试之后，部署之前
- 其他步骤不需要动
这就是编译器和"AI 瞎生成"的区别。编译器有语义理解，有状态，有增量编译逻辑。
类型系统和验证
gh-aw 不是把你的话随便扔给 LLM 然后输出 YAML。它有一个完整的类型系统：
# Deploy Workflow
## 输入参数
- environment: [staging, production] # 这是一个枚举类型，只能是这两个值之一
- dry_run: boolean = true # 布尔类型，默认 true
- timeout: number = 30 # 数字类型，默认 30 分钟
## 步骤
1. 部署到 {{ environment }} 环境，超时时间 {{ timeout }} 分钟
2. 如果不是 dry_run，发送通知到 Slack当你编译时，gh-aw 会做类型检查：
$ gh aw compile deploy.aw.md
✅ 类型检查通过
✅ 生成 deploy.aw.lock.yml如果你传了不存在的枚举值：
$ gh aw compile deploy.aw.md
❌ 类型错误
Line 5: environment 参数值 "prod" 不是有效值
有效值：staging, production这才是 gh-aw 真正的价值。它不是一个生成器，它是一个编译器。
深度技术解析
让我们扒一扒这个编译器的内部结构。
三层编译架构
gh-aw 的编译过程分为三层：
┌─────────────────────────────────────────────┐
│ 第一层：Markdown 解析器 │
│ - 解析 Markdown 结构 │
│ - 提取标题、列表、代码块、表格、参数定义 │
│ - 生成 AST（抽象语法树） │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 第二层：语义分析器 │
│ - 类型检查 │
│ - 依赖分析（步骤之间的顺序和依赖） │
│ - 变量作用域解析 │
│ - 错误检测和提示 │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 第三层：代码生成器 │
│ - 生成 GitHub Actions YAML │
│ - 优化步骤顺序 │
│ - 合并重复逻辑 │
│ - 生成 .lock.yml 锁文件 │
└─────────────────────────────────────────────┘这和传统编程语言的编译器架构几乎一模一样——只是前端输入的不是代码，而是自然语言。
LLM 的角色：语义理解引擎
在这个架构里，LLM 不是端到端的黑盒生成器，而是编译器中的一个组件——语义理解引擎。
它的工作是：
- 把自然语言描述的步骤，翻译成标准化的操作语义
- 识别模糊或者歧义的描述，向用户提问澄清
- 从 GitHub Actions 生态中匹配合适的 Action
关键的区别是：LLM 的输出是结构化的语义表示，而不是最终的 YAML。
自然语言描述："安装 Node.js 20.x"
↓ LLM 翻译
语义表示：{
type: "setup-node",
version: "20.x",
cache: null,
registry: null
}
↓ 代码生成器
最终输出：uses: actions/setup-node@v4
with:
node-version: 20.x这个设计非常重要，因为：
- ✅ 可预测：同样的输入，永远产生同样的输出
- ✅ 可测试：语义层可以写单元测试
- ✅ 可缓存：同一个语义不需要重复调用 LLM
- ✅ 可调试：出了问题你知道是哪一层的锅
.lock.yml 的意义
你可能注意到了，gh-aw 生成的文件后缀是 .lock.yml，而不是 .yml。
这个 .lock 后缀不是随便加的。它和 package-lock.json、Cargo.lock、go.sum 一样，是一个锁文件。
它的作用是：
- 保证可复现性：同样的输入，永远产生同样的输出
- 防止漂移：LLM 更新了，或者 Actions 版本更新了，不会偷偷改变你的工作流行为
- 增量更新：只有你改了的地方才会变，没改的地方保持原样
这是一个非常成熟的软件工程实践，gh-aw 把它带到了 AI 工作流领域。
模块和导入系统
gh-aw 不是每个工作流都从零开始写。它有完整的模块系统：
# 我的工作流
@import: https://github.com/github/gh-aw/blob/main/library/node/ci.aw.md
@import: ./custom-steps.aw.md
## 步骤
1. @node/ci(version="20.x") # 导入的标准模块
2. @custom/my-step() # 自定义模块
3. 运行我的自定义命令这意味着，你可以构建可复用的工作流组件库。团队可以定义自己的标准工作流，每个人都可以导入使用，而不是复制粘贴 YAML。
这才是工程化的 AI。不是每个任务都让 AI 从头发明轮子，而是让 AI 帮你组装标准组件。
典型使用场景
场景 1：项目初始化
新起一个项目，你不需要再去复制粘贴旧项目的 CI 配置了：
# Rust 项目 CI
对于这个 Rust 项目：
1. 提交 PR 时运行 cargo test 和 cargo clippy
2. 每天晚上运行 cargo audit 检查安全漏洞
3. 打 tag 时自动发布到 crates.io
4. 所有失败都通知到团队 Discord一行命令编译，直接能用。
场景 2：复杂发布流程
# 发布流程
当有人在 Issue 里留言 "/release" 时：
1. 检查这个人是不是有发布权限
2. 创建发布分支 release/vX.Y.Z
3. 更新 CHANGELOG.md 和版本号
4. 跑一遍完整的测试套件
5. 打 Git tag
6. 发布到 GitHub Releases
7. 部署到预发布环境
8. 等待 1 小时，如果没有问题，自动部署到生产环境
9. 发送发布通知到 Slack
10. 如果任何一步失败，自动回滚，并创建 Issue 记录以前写这么一套工作流可能要花一天，还容易写错。现在 5 分钟搞定。
场景 3：跨项目标准化
团队有 50 个仓库，每个仓库的 CI 都长得差不多，但又略有不同。以前你需要用 setup script 或者模板引擎去维护。
现在你可以写一个标准库：
# 团队标准 CI 库
## 函数 standard-ci(language)
- 标准的签出和缓存配置
- 标准的测试运行步骤
- 标准的代码质量检查
- 标准的通知配置然后每个项目只需要：
# 项目 CI
@import: https://github.com/my-org/aw-library/standard.aw.md
@standard-ci(language="python")一次定义，到处使用。编译器保证每个项目都符合团队标准。
为什么这是一个大事件？
gh-aw 看起来只是一个"把 Markdown 编译成 YAML"的小工具，但它的意义远不止于此。
1. AI 编程的新范式
现在大多数 AI 编程工具的模式是：
你说需求 → AI 生成代码 → 你检查代码 → 合并
这个模式有个致命问题：生成很容易，维护很难。
需求变了怎么办？AI 又给你重新生成一遍，你又得重新检查一遍。没有增量，没有状态，没有版本管理。
gh-aw 提出了一个新模式：
你写高层描述（Markdown）→ 编译器生成低层代码（YAML）→ 编译器负责增量更新
这和我们用高级语言编译成机器码是一个道理。你写 C 代码，不需要懂汇编；编译器帮你翻译成汇编。出了问题，你改 C 代码，重新编译就行，不需要改汇编。
这才是 AI 编程应该有的样子。
2. Don Syme 在下一盘大棋
Don Syme 这辈子做的事情，本质上都是在做一件事：发明更好的抽象，让程序员不用关心底层复杂性。
- 他发明了 F#，让函数式编程变得实用
- 他发明了 async/await，让异步编程变得简单
- 现在，他在做 gh-aw，让 AI 工作流编程变得简单
这三件事的底层逻辑是一样的：找到正确的抽象，把复杂性藏在编译器后面。
如果 gh-aw 的思路成功了，它的影响不会局限于 GitHub Actions。它可能会推广到：
- Terraform 基础设施定义
- Kubernetes 部署配置
- CI/CD 系统
- 任何用 YAML 定义的东西
3. GitHub 的生态位优势
GitHub 做这件事，有得天独厚的优势：
- 它知道世界上所有的 GitHub Actions
- 它知道每个 Action 的用法、参数、版本、流行程度
- 它知道每个项目用了哪些 Action
- 它知道什么样的工作流模式是行业最佳实践
gh-aw 不是凭空构建的。它背后是整个 GitHub 生态的数据。这是任何其他公司都做不到的。
当前的局限和未来展望
gh-aw 还在技术预览阶段（v0.67.3），还有很多不完善的地方：
当前的局限
- 支持的场景还有限：主要覆盖 CI/CD 的常见场景，复杂的工作流还不能很好地处理
- LLM 成本：编译需要调用 LLM，虽然有缓存，但还是有成本
- 可解释性：有时候你不知道它为什么生成了某个东西，需要更好的调试工具
- 生态还很小：模块库还不多，需要时间成长
未来可能的方向
- 多后端支持：现在只编译到 GitHub Actions，未来可能支持 GitLab CI、CircleCI、Jenkins 等
- 更丰富的类型系统：泛型、接口、继承等更强大的抽象能力
- 双向编译：不仅可以从 .md 编译到 .yml，还可以从现有的 .yml 反编译回 .md
- AI 辅助重构：自动发现你的工作流中的问题，建议优化方案
- 可视化编辑器：拖拖拽拽拼工作流，自动生成 Markdown 描述
怎么开始用？
安装
# 首先你需要安装 GitHub CLI
# 然后安装 gh-aw 扩展
gh extension install github/gh-aw创建你的第一个工作流
创建文件 .github/workflows/ci.aw.md：
# CI Workflow
当有人提交 PR 或者推送到 main 分支时：
1. 签出代码
2. 安装 Go 1.22
3. 运行测试：go test ./...
4. 运行 lint：golangci-lint run编译
gh aw compile .github/workflows/ci.aw.md然后提交生成的 .lock.yml 文件到 Git。就这么简单。
其他命令
# 检查工作流是否有问题，不生成文件
gh aw check ci.aw.md
# 显示编译后的工作流预览
gh aw preview ci.aw.md
# 更新已有的工作流（增量编译）
gh aw update ci.aw.md写在最后
gh-aw 是那种第一眼看起来"不就是 AI 生成 YAML 吗"，但越琢磨越觉得有意思的项目。
它的真正价值不在于"省了写 YAML 的时间"，而在于它提出了一个问题：
在 AI 时代，我们应该怎么定义程序？
50 年前，我们用汇编语言写程序。 30 年前，我们用 C 语言写程序。 10 年前，我们用 Python/JavaScript 写程序。
今天，我们可能需要一种新的方式来写程序——一种更接近人类自然语言，但又保持了软件工程所有优秀实践（类型系统、模块系统、增量编译、锁文件、可测试、可调试）的方式。
gh-aw 就是这个方向的一次严肃探索。而且它不是某个创业公司的玩具，是 GitHub Next + Microsoft Research + Don Syme 这样的世界级编程语言专家在做。
这可能不是最终的答案，但绝对是正确的方向。
未来几年，我们会看到更多这样的探索。那些真正把软件工程的智慧和 AI 的能力结合起来的工具，会定义下一个十年的编程范式。
参考资源
gh-aw 官方仓库 — https://github.com/github/gh-aw 项目源代码，包含文档和示例
GitHub Next 官方介绍 — https://githubnext.com/projects/gh-aw GitHub Next 团队的项目介绍文章
Don Syme - The Next Big Programming Model Don Syme 关于未来编程模型的演讲，包含 gh-aw 的设计思想
GitHub Actions 官方文档 — https://docs.github.com/en/actions GitHub Actions 完整文档，理解 gh-aw 的底层基础
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
