OpenClaw 发布公告
与 release-openclaw-maintainer 配合使用，在发布上线后执行。
与 $discord-user-post 配合使用，以当前登录用户身份实际发布到 Discord。
证据优先
在起草关注领域之前，先阅读真实的发布证据：
- GitHub 发布正文和不可变标签；对于扩展稳定版，还需确认仅限 npm/容器范围且未标记为 Latest。
- 已发布基础版本的
CHANGELOG/<version>.md及贡献记录，通过node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>]解析（添加--record用于统计）。共享解析器读取历史整体标签；当前的CHANGELOG.md是索引。在批准文档发布后，阅读完整的文档镜像和冻结记录，而不是将精简的 GitHub 正文视为完整笔记。 - 自上一个已发布版本或操作员指定的基准以来的提交。
- 精确版本和当前 dist-tag 的注册表/包元数据。
- 与用户信心相关的验证状态。
除非你确实做了完整的更新日志审计，否则不要声称做过。如果你只阅读了生成的发布说明或选定的更新日志部分，请说明这一点，然后要么正确审计，要么在限制条件下起草。
对于测试版关注领域，优先考虑用户可观察到的变化，而不是内部测试或 CI 机制：
- 安装/更新路径
- 操作系统/特定平台行为
- 网关启动/重启、配置和运行时行为
- 提供者/模型/运行时路由
- 插件加载和本地插件开发
- 通道和媒体路径
- 安全/数据丢失/用户影响修复
不要让后期发布分支的修复自动主导公告。如果版本包含与上一个已发布版本的较大差异，请按整个发布差异和预期用户影响对关注领域进行排序；在相应的类别中提及后期修复。
必备文案
每个测试版公告必须明确说明测试版状态，并包括：
- 精确版本，例如
OpenClaw 2026.5.25-beta.1 - 一句话风险说明：测试版，适用于测试，不适用于稳定版推广
- 基于证据（而非猜测）的测试关注领域
- 顶部附近突出显示更新命令：
openclaw update --channel beta --yes openclaw --version - 全新安装路径：
从 https://openclaw.ai 安装 - GitHub 发布链接
- 简洁的验证说明，不要让 CI 成为头条
除非操作员明确要求 npm 特定的文案或故障排除文本，否则不要在测试版公告中建议 npm 安装命令。使用注册表元数据作为证据是可以的，但不要将其转化为公开的安装指南。
对于稳定版公告，使用稳定版通道措辞：
openclaw update --channel stable --yes
openclaw --version
全新安装仍指向 https://openclaw.ai。
对于扩展稳定版，指定精确版本和末尾月份。仅提及可观察到的向后移植，并使用：
openclaw update --channel extended-stable
openclaw --version
不要添加 --yes：从较新的常规稳定版迁移的用户必须看到降级警告，因为较旧版本可能无法理解较新的配置。链接 GitHub Release，但不要继承常规稳定版的 macOS、Windows、ClawHub、latest 或网站声明。
风格
- Discord Markdown，无表格。
- 保持可速读性：简短介绍、要点、命令、链接。
- 以用户能感受到或测试的内容开头，而不是证明管道。
- 仅在安装/更新说明之后提及验证。
- 具体说明在哪些地方提供反馈最有帮助。
- 不要在公开公告中提及私有的本地证明路径。
- 不要夸大未经验证的平台、通道或提供者行为。
发布
当被要求发布时，使用 $discord-user-post 以用户身份操作已登录的 Discord 桌面应用程序。解析并可见验证确切的服务器/频道，检查最终正文，并在输入或发送之前请求操作时确认。切勿使用 OpenClaw 频道发送、机器人、webhook、中继或令牌。