设计 AI 可操作的发布工作流

Source: Dev.to

我的发布流程现在是这样

当我发布新版本时，我只会说：

“发布版本 1.2.0。”

仅此而已。

我不再：

• 构建包
• 手动运行测试
• 检查 CI 日志
• 验证标签
• 推送制品
• 协调发布顺序

AI 会完成所有这些工作——不是盲目执行脚本，而是推理出接下来应该发生的事情。

这不是自动化

区别很重要。

AI 验证 README 的一致性，检查语义化版本，验证分支状态，创建标签，触发 GitHub Actions，发布到 NuGet —— 并在每一步解释 原因。

我称这种模式为 Decision/CD：管道不仅仅是执行，它还 决定。

我设计的工作流

以下是我在 OSS 项目中实际使用的发布流程：

Local → RC → Verify → GO/NO‑GO → Tag → Stable → Publish

flowchart TD
    A["Local prep\nbuild/test + docs"] --> B["Publish RC\n(GitHub Packages)"]
    B --> C["Download RC & verify\n(restore + smoke test)"]
    C --> D["GO decision\n(coordinator)"]
    D --> E["Lock commit hash"]
    E --> F["Publish stable\n(nuget.org)"]
    F --> G["Aftercare\ndocs + announcements"]

每个阶段都有 条件、证据要求 和 明确的所有权。

角色：谁负责什么

在我的工作流中，这些角色分配给 AI 代理。人类（我）只负责 协调员 角色——即 GO/NO‑GO 决策。

Decision Gates: Where Human Judgment Lives

The GO/NO‑GO decision requires all of the following to be true:

• ✅ 单元测试通过
• ✅ 物理测试通过（附有证据）
• ✅ 已记录差异日志（如果有更改）
• ✅ README 可作为用户文档使用

If the conditions are met I say “GO.” The AI then handles everything else.

让它运行的 CI/CD

两个简单的 GitHub Actions 工作流驱动它：

RC 发布（在 release/** 分支推送时触发）

on:
  push:
    branches:
      - "release/**"

此工作流会构建、测试、使用 -rcN 后缀打包，并将制品推送到 GitHub Packages。

稳定发布（在 v*.*.* 标签推送时触发）

on:
  push:
    tags:
      - "v*.*.*"

此工作流验证 SemVer，运行测试，打包稳定版本，并将其推送到 nuget.org。

就这样。AI 创建分支，验证条件，创建标签——其余工作由流水线完成。

实际交互

以下是一段实际发布会话的精简记录。

Human: 检查 README。

AI:

Conclusion: The English in README.md is clear and accurate.
Reasoning:
- Meaning is clear and concise
- Technically accurate
- Consistent with other documentation
Suggestion: Let me know if you need consistency checks on other READMEs.

Human: 提交并推送。

AI:

Conclusion: Commit and push completed.
Reasoning:
Commit: docs: translate src README
- Changed: README.md (English translation)
release/1.2.0 pushed to remote
Suggestion: Let me know if other READMEs need English consistency checks.

Human: 合并到 main 并发布到 NuGet。

AI:

Conclusion: Merged release/1.2.0 to main. NuGet release requires a tag.
Reasoning:
- main now includes latest from release/1.2.0
- Release is triggered by v*.*.* tag push (per nuget-publish.yml)
- VersionPrefix in Directory.Build.props is 1.2.0
Suggestion: Ready to create and push v1.2.0 tag? (If OK, I'll run `git tag v1.2.0` → `git push origin v1.2.0`. Please confirm NUGET_API_KEY is set in GitHub Secrets.)

Human: 创建并推送 v1.2.0 标签。

AI:

Conclusion: Created and pushed v1.2.0 tag.
Reasoning:
- git tag v1.2.0 executed
- git push origin v1.2.0 executed
- Matches NuGet publish workflow trigger conditions
Suggestion: GitHub Actions workflow "Publish stable to nuget.org" should now be running. Let me know if you need completion confirmation.

模式概述

决策门后没有人工验证。整个发布——从验证到 NuGet 发布——仅用了 四条人类消息。

为什么大多数 AI 工作流会失败

典型的 AI 在开发中的使用方式如下：

• ❌ “帮我写代码”
• ❌ “修复这个 bug”
• ❌ “优化这个函数”

这属于 外包，而不是工作流。它没有结构、没有决策门、没有证据要求，也没有所有权模型。结果是不可预测的。

劳动分工

人类决定 什么 和 是否；AI 负责 如何 和 何时。这种分离使工作流可操作。

什么使工作流“AI 可操作”

1. 阶段是明确的 – AI 完全知道自己所在的位置以及下一步是什么。
2. 输入/输出定义明确 – 每个阶段消耗并生成具体的产物（例如标签、包、日志）。
3. 证据需求已编码 – AI 可以在继续之前验证条件（测试结果、差异日志、README 检查）。
4. 决策门槛被隔离 – 只有人类可以做出通过/不通过的决定；其余全部自动化并有据可依。
5. 已分配所有权 – 每个阶段都有负责的“代理”（人类或 AI），以确保责任明确。

当满足这些标准时，AI 可以自主行动，同时在需要判断的环节保持人为参与。

Source:

TL;DR

我不再手动构建、测试或发布。我只需 声明 “Release vX.Y.Z”。AI 会验证所有内容，创建分支，给提交打标签，并让 CI 流水线完成繁重的工作——同时解释它的推理过程。

# It Is in the Process

**Conditions are verifiable** — The AI can check them programmatically.  
**Evidence is defined** — The AI knows what proves success.  
**Decision points are marked** — The AI knows when to stop and ask.  
**Failure modes are specified** — The AI knows what to do when things break.

If your workflow has these properties, an AI can operate it. If not, you're just hoping for the best.

Final Thought

CI/CD 自动化流水线。它 不 自动化决策。

我没有让我的工作流更智能。我让它 可被 AI 操作。

这改变了一切。

这是我“Beyond Prompt Engineering”系列的一部分，在该系列中我探索超越优化提示的人‑AI 协作模式。本文展示的工作流来自 Kafka.Context，这是一个我完全通过人‑AI 协作开发的开源项目。