聊天机器人天然贴近私有现场#

普通工具项目通常只需要担心配置文件和运行日志。聊天机器人复杂得多。

它会接触：

• 平台登录状态。
• 本地桥接配置。
• 群空间目录。
• 导入文件。
• 成员笔记。
• 运行记录。
• 插件本地设置。

这些内容有些是工程资产，有些是运行现场。问题在于，它们常常长得很像：同样是 Markdown、JSON、TOML、图片、归档文件，很容易被一次粗心的同步带出去。

所以这个仓库发布前光靠人工扫一遍不够。明显问题可以人工发现，但长期维护还是要靠规则；能写进脚本的风险，就别留给临场判断。

公开内容和本地现场要分开#

我更喜欢把扫描语义分成两种：

1
Publish: 准备进入公开仓库的内容
2
Live:    本地真实运行现场

Publish 扫描应该严格。运行态目录、个人空间、本地配置、数据库、日志和上传文件都应该默认排除或阻断。

Live 扫描不一定要阻断。它更适合提醒本机有哪些运行态材料存在，帮助维护者知道风险位置。

这两类扫描不能混在一起。混在一起会产生两个坏结果：要么为了让本地能跑而放松公开规则，要么为了让公开仓库干净而误伤本地运行文件。

规则文件不是摆设#

chatbot-qq 里有一份私有数据审计规则。里面不只是几个关键词，还写清了几类判断：

• 哪些目录在公开发布时不应进入扫描结果。
• 哪些文件名属于本地运行配置。
• 哪些扩展名更像运行成果。
• 哪些路径模式属于群空间里的运行态材料。
• 哪些命中可以在极小预算内被允许。

最后一条很容易被忽略。规则文件本身有时必须出现一些字面量，否则测试无法说明它在保护什么。我的做法是给“允许命中”设置路径和数量预算，避免全局放行。

预算一旦超了，扫描仍然失败。

这比“把这类词都忽略”可靠很多。

路径解释比黑盒扫描更适合维护#

安全扫描如果只输出“失败”，维护起来会很痛苦。你需要知道某个路径为什么被扫、为什么被排除、为什么在 Publish 下阻断、为什么在 Live 下只是提醒。

所以我更看重 explain path 这类能力。

例如一个群工作区里的 README.md 可以是公开骨架的一部分；同一个群工作区里的运行记录、成员材料、上传文件就不该进入公开仓库。

这类差异靠文件后缀判断不出来，必须靠路径规则解释。

当扫描器能回答“这个路径为什么会被处理成这样”，后续重构目录时才不会靠猜。

插件平台也要配合审计#

聊天机器人越做越大后，所有功能都塞在代理脚本里会很难管。插件平台把功能拆到 plugins/<id>/ 下面，用 manifest 描述能力、配置、权限和测试。

这对安全审计也有帮助。

插件应该声明自己需要什么能力，而不是默认拿到整个宿主环境。能发消息是一种能力，能读工作区文件是另一种能力，能写本地文件又是另一种能力。

当功能用插件隔离后，审计对象也更清晰：

• 插件 manifest 是否完整。
• 插件本地配置是否可公开。
• 插件测试是否覆盖关键行为。
• 插件是否绕过宿主权限模型。

这比在一个巨大脚本里找风险点容易得多。

公开仓库应该展示骨架，不展示现场#

我觉得这类项目最适合公开的部分是：

• 架构说明。
• 安装脚本。
• example 配置。
• 安全策略。
• 插件平台文档。
• 发布审计规则。
• 自动化测试。
• 故障排查流程。

不适合公开的是具体运行现场。

我不想把项目删到只剩空壳再公开。更好的做法是把可复用的工程骨架和不可复用的个人现场分开。别人能参考的也是这些骨架：路由怎么拆、权限怎么收、插件怎么管、发布前怎么拦。

现在我的判断#

聊天机器人项目越接近真实群聊，越不能把“能跑”当成唯一目标。

如果一个仓库要长期公开，发布检查门要比功能按钮更早稳定下来。尤其是这类跨平台、跨配置、跨工作区的机器人项目，私有数据审计不该拖到发布前补救，最好一开始就进开发流程。

先把公开规则写清楚，再让脚本和测试每天检查它。这样项目从本地自用走向公开时，心里会踏实很多。