把一个私有生产仓库里的 AI workflow 开源，最容易犯的错误是：直接把脚本、prompt、label 和目录结构搬出来。

这看起来快，但通常不是好的开源。

私有生产 workflow 里混合了两类东西：一类是可复用的方法论，另一类是只属于这个组织、这个产品、这个基础设施的上下文。开源要提炼前者，而不是暴露后者。

先开源 contract，不要先开源 daemon

一个 issue-driven agent workbench 的第一版，不应该急着做生产 daemon。

更好的第一版是：

  • issue template；
  • label state machine；
  • branch claim 规范；
  • worker prompt skeleton；
  • evidence manifest；
  • PR checklist；
  • release boundary 文档；
  • toy example。

这些东西足以让其他团队手动复现方法论。

如果一开始就开源 daemon，用户会被迫理解你的调度假设、权限模型、GitHub access model、并发策略、失败恢复、部署环境和本地工作区结构。这个门槛太高，也容易把私有实现误认为通用标准。

私有内容必须被替换成 synthetic examples

开源仓库不应该包含：

  • 私有 issue 原文；
  • 内部截图或日志；
  • 真实用户数据；
  • 服务拓扑；
  • 生产环境名称；
  • 业务风险规则；
  • 组织特定 label；
  • 发布脚本或凭证假设。

这些内容即使看起来“没什么秘密”，也会暴露团队如何运行生产系统。

正确做法是用 synthetic example 替代。

例如，不要用真实支付、交易、权限、客户或生产事故做示例。可以用一个 toy app 的“更新用户名后 greeting 没刷新”来说明 issue contract、branch claim 和 evidence gate。

示例的目标不是还原真实业务，而是验证方法论结构。

开源仓库应该是发布节点，不是真相源

如果你同时有中央知识库、私有生产仓库、个人网站和开源仓库，需要明确数据流向。

中央知识库沉淀概念和 publication source。

私有生产仓库提供经验，但不直接暴露。

个人网站负责解释、传播和形成公开文章。

开源仓库承载 public-safe 的模板、规范和示例。

也就是说，开源仓库不是私有 workflow 的真相源，也不是中央知识库的替代品。它是公开资产的发布节点。

这个边界能避免两个问题：开源仓库不会被私有生产上下文污染，中央知识库也不会被开源模板反向绑架。

什么时候再做 runner

当 contract、state machine 和 evidence gate 已经被手动使用过，才适合考虑 runner。

runner 的第一版也应该保守：

  • 默认 dry-run；
  • 手动触发优先；
  • 不自动发布；
  • 不默认关闭 issue；
  • adapter 可替换；
  • 所有状态写回 GitHub；
  • 所有风险升级给 human。

这时 runner 才是在放大一个稳定流程，而不是把混乱自动化。

一个好的开源目标

一个可持续的 Issue-Driven Agent Workbench，不应该承诺“让 AI 自动修完所有 issue”。

它应该承诺更朴素但更有价值的事情：

  • 让 issue 变成可执行合同；
  • 让 AI worker 有明确边界；
  • 让任务状态可审计；
  • 让 PR evidence 可复核；
  • 让 release boundary 不被 AI 模糊；
  • 让私有生产经验被安全地抽象成公共方法。

这类开源项目的价值，不在于炫耀自动化有多强，而在于给 AI coding 建立一套可以被人信任的工程控制面。