私有工作区不是公开仓库#

本地工作区是给我自己用的，里面可以放真实环境规则、本机脚本、日志、临时包和只在这台机器上成立的配置。公开仓库不一样，它面对的是第一次看到项目的人，只应该留下能复用的脚本、安全示例、安装说明、验证命令和 release 记录。两边有交集，但不能混成一个目录。

白名单比黑名单稳#

如果用黑名单发布，很容易漏掉东西。

今天排除了日志，明天可能又新增了一个本地缓存目录；今天排除了凭据文件，明天某个脚本里又写了机器路径。私有工作区越活跃，黑名单越容易失效。

更稳的是白名单：

1
只发布 scripts/
2
只发布 plugins/
3
只发布通用 schema
4
只发布 example config
5
只发布公开文档

所有不在白名单里的东西，默认不进入公开仓库。这样新增私有文件时，不会因为忘记写 exclude 规则而被带出去。

文档也要重写#

发布代码时，很多人会记得过滤文件，却忘了文档也是泄漏面。

部署文档里可能有真实服务器地址、本地路径、运行账号、群名、内部项目名、服务配置路径。即使没有凭据内容，这些信息也不一定适合公开。

所以公开 README 不能直接复用私有 README。它需要换成面向外部读者的版本：

• 解释项目是什么。
• 说明适合哪些场景。
• 给出安全的安装方式。
• 用占位符替代真实部署信息。
• 明确哪些能力需要用户自己配置。
• 说明 release 包不包含运行时私密文件。

这一步应当作为重新写一份对外说明，而不是在原 README 上改几句话。

验证检查门要在发布前#

OpenClaw 这类项目有很多脚本和命令层，不能把“文件同步完成”当成发布完成。

更合适的做法是把发布流程拆成几个检查门：

1
敏感信息扫描
2
command isolation tests
3
plugin tests
4
index security tests
5
file health
6
memory health
7
manifest health
8
help health

把这些检查分开，是因为它们抓的问题不同。

敏感信息扫描防止泄漏；命令隔离测试防止公开命令误读私有工作区；插件测试防止 capability manifest 坏掉；索引安全测试防止检索层暴露不该暴露的内容；health 类测试确认发布包能被读者理解和运行。

release 成果也要分层#

私有运行包和公开 release 不能混成一个成果。

私有运行包可以服务云端部署，需要知道目标系统、服务管理、运行时依赖和本地恢复步骤。

公开 release 更像一个可复用产品包。它应该告诉读者：

• 当前公开版本有哪些能力。
• 怎么安装。
• 怎么验证。
• 哪些配置需要自己提供。
• 哪些内容不会随包发布。
• 出问题时先看哪些 health 命令。

如果把私有运行包直接当公开 release，读者会看到太多和个人环境绑定的内容；如果把公开 release 直接当生产部署包，又可能缺少真实运行所需的本地配置。

两者应该分开。

发布流程也是产品的一部分#

做完以后，真正需要留下来的不是那一次 push，而是这套发布前流程。以后再发 OpenClaw，至少知道哪些文件能进公开仓库、哪些文档要重写、哪些检查必须先跑一遍。

1
private workspace -> whitelist sync -> privacy filter -> public docs -> validation gates -> release

这条路跑通以后，下次发布至少有步骤可查，不用临到推送前再靠记忆补漏。