Hedy 护送每周发布：催办合并截止时间、确认检查清单、起草对外通告——每个对外步骤都等待人工批准。定时任务必须显式声明投递目标。
Hedy 以一名私有 AI 员工的身份承担发布管理，而不是又一个 Slack 席位。它跟踪截版时限与检查清单项，把所有对外发布说明和客户通告置于 L0/L1/L2 审批之后，并把每次发布结果写入台账。定时提醒必须声明显式目标频道——绝不使用“上一个频道”。自部署在您自己的 Docker/K8s 或气隙/离线基础设施上，配备只增不改审计与默认拒绝的写操作。
最后更新：2026 年 7 月 20 日
熟知班车时刻与合并截止时间；在截止之前提醒负责人，而不是之后。
逐项走查发布检查清单，向发布负责人报告缺口。
发往公开频道的发布通告以审批卡片排队。一键批准或驳回。
按期发布还是延期，结果连同原因都记入活动台账。
发布管理是横跨截止时间、检查清单、审批与记录留存的协调工作。住在 Slack 里的云端 AI 助手可以提醒您临近截版，但它不对发布负责。Hedy 负责。它是运行在您自己基础设施上的一名 AI 员工：盯着冻结窗口、逐项走查发布清单，并在构建发出之前清楚哪些步骤还未关闭。hedy.one 的要点就在于：一名 Hedy 扛起整个发布闭环，而不是往频道里再加一个席位。
发布出问题往往出在对外沟通上，因此 Hedy 把它当作受治理的写操作。起草对外发布说明、状态页更新或客户通告都是写操作，而写操作按白名单默认拒绝。任何面向客户的内容在发出前都要经过分级审批——L0 自动、L1 单人复核、L2 双人签署。Hedy 可以准备并暂存通告，但放行的是人。这条限制落在配置与代码层，而不是提示词里，即便模型信心十足也依然生效。
每次发布都会落入台账。版本、清单状态、通告由谁批准、何时发出以及关联证据，全部写入只增不改审计日志，没有更新与删除路径。当 Hedy 回答关于历史发布的问题时，证据门要求它逐字引用来源，而不是凭记忆转述；检索范围以提问者的 ACL 为界——报告只反映此人有权限看到的内容。
cron 是自动化悄悄出错的地方，所以 Hedy 把目标写成显式的。定时的截版提醒或清单催办必须在任务定义中写明目的频道；不存在可能把提醒漏发给错误受众的隐式“上一个频道”回退。Hedy 把飞书/Lark 与 Slack 同作为一级支持渠道，使用您自己的模型 key（包括本地 vLLM 或 Ollama），通过 Compose 约 30 分钟完成部署，且不带任何数据次级处理方（sub-processors）——发布历史保存在您的基础设施上。