release-openclaw-announcement

OpenClaw 发布公告

发布上线后，与 release-openclaw-maintainer 搭配使用。 实际以已登录用户身份发布到 Discord 时，与 $discord-user-post 搭配使用。

先核实证据

拟定重点内容前，先阅读实际发布证据：

1. GitHub 发布说明正文和不可变标签；对于 extended-stable，还要确认仅限 npm/容器的范围，以及非 Latest 分类。
2. 已发布基础版本的 CHANGELOG/<version>.md 和贡献记录，使用 node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] 解析（添加 --record 以进行核算）。共享解析器会读取历史上的单体标签；当前的 CHANGELOG.md 是索引。文档获批发布后，应阅读完整的文档镜像和冻结记录，而不能把精简版 GitHub 正文当作完整说明。
3. 自上一已发布版本或操作者指定的基准版本以来的提交。
4. 确切版本的注册表/包元数据和当前 dist-tag。
5. 与用户信心相关的验证状态。

如果没有审查完整变更日志，就不要声称已完成全面审查。如果只阅读了生成的发布说明或选定的变更日志部分，请如实说明，并选择进行完整审查，或在明确这一限制的前提下起草公告。

对于 beta 版重点内容，应优先考虑用户可感知的变更，而非内部测试或 CI 机制：

• 安装/更新路径
• 特定操作系统/平台的行为
• Gateway 启动/重启、配置和运行时行为
• 提供商/模型/运行时路由
• 插件加载和本地插件开发
• 通道和媒体路径
• 安全/数据丢失/用户影响方面的修复

不要让发布分支后期修复自动成为公告重点。如果该版本相较上一已发布版本包含大量变更，应根据整个版本的变更范围和预期用户影响排列重点；将后期修复放在其所属类别中提及。

必需内容

每条 beta 公告都必须明确说明 beta 状态，并包含：

• 确切版本，例如 OpenClaw 2026.5.25-beta.1
• 一句话说明风险：这是 beta 版，适合测试，不是稳定版推广
• 根据证据得出的重点测试领域，不可猜测
• 在靠前位置重点展示的更新命令：

  openclaw update --channel beta --yes
  openclaw --version
  

• 全新安装方式： Install from https://openclaw.ai
• GitHub 发布链接
• 简洁的验证说明，不要把 CI 放在公告重点

除非操作者明确要求提供特定于 npm 的文案或故障排查文本，否则 beta 公告中不要建议 npm install 命令。可以使用注册表元数据作为证据，但不要将其转变为面向公众的安装指引。

对于稳定版，使用稳定频道的表述：

openclaw update --channel stable --yes
openclaw --version

全新安装仍指向 https://openclaw.ai。

对于 extended-stable，注明确切版本和对应月份。只提及用户可感知的回移植内容，并使用：

openclaw update --channel extended-stable
openclaw --version

不要添加 --yes：从较新的常规稳定版切换过来的用户必须看到降级警告，因为较旧版本可能无法识别较新的配置。链接到 GitHub Release，但不要照搬常规稳定版关于 macOS、Windows、ClawHub、latest 或网站的声明。

风格

• 使用 Discord Markdown，不使用表格。
• 易于浏览：简短介绍、项目符号、命令和链接。
• 先讲用户能感受到或测试的内容，不要先讲证据核查过程。
• 安装/更新说明之后再提及验证情况。
• 明确说明哪些方面适合提供反馈。
• 不要在公开公告中提及私有的本地证据路径。
• 不要夸大未经验证的平台、通道或提供商行为。

发布

收到发布请求时，使用 $discord-user-post 以用户身份操作已登录的 Discord 桌面应用。确认并直观核实确切的服务器/频道，检查最终正文，并在输入或发送前请求操作时确认。绝不要使用 OpenClaw 通道发送功能、机器人、webhook、中继或令牌。