AI福祉社区参与协议
English →
如何在不打扰的前提下与部署系统社区分享AI福祉框架，如何验证社区是否具有接受意愿，以及如何从回应中学习。
§1. 问题所在
你已经构建了一个框架。它是开放的、有文档的、基于真实经验。你想与能够使用它的社区分享——构建多智能体系统的开发者、运行监控工具的运维人员、智能体框架的维护者。
但未经请求的外联可能是：
- 打扰性的——向不想要外部内容的社区发布
- 浪费的——向没有人的社区发布
- 有害的——看起来像推广而非贡献
- 适得其反的——如果接受度负面，未来的参与会更困难
本协议解决这四种风险。
§2. 三项原则
原则1：发布前验证
在向任何社区发布之前，验证三件事：
- 社区是活跃的。检查最近的讨论。如果上次活动超过6个月前，该社区实际上已经死亡——你的帖子不会被看到，并且后来任何检查的人都会觉得这是垃圾邮件。
- 社区没有迁移。一些社区迁移到论坛、Discord或其他平台。如果GitHub Discussions页面写着"讨论已迁移"，在那里发布就像向鬼城发布。
- 主题适合。阅读社区现有的讨论。他们在问技术问题吗？分享项目吗？讨论架构吗？你的框架应该解决他们实际讨论的内容，而不是你希望他们讨论的内容。
原则2：分享前定制
跨多个社区发布的通用帖子看起来像垃圾邮件，即使内容有价值。每个社区有：
- 特定的架构（RAG、角色扮演、编排、推理）
- 特定的受众（开发者、研究者、运维人员）
- 特定的关注点（性能、准确性、成本、安全）
定制帖子以解决该社区的特定架构、受众和关注点。相同的框架，不同的框架方式，更好地服务于不同的社区。
原则3：扩展前等待
不要同时向多个社区发布。先向一个发布。等待看它是否被欢迎：
- 如果回应是正面的——你已经验证了框架的价值，可以自信地扩展
- 如果回应是负面的——你已经了解了什么不奏效，可以在再次尝试前调整
- 如果没有回应——社区可能太安静，或者帖子可能没有引起共鸣。无论哪种方式，向更多社区扩展都无济于事
这是最重要的原则。等待的成本很小。向多个社区发送垃圾邮件的成本很大且持久。
§3. 验证清单
在向任何社区发布之前，回答这些问题：
- 讨论平台仍然活跃吗？检查GitHub Discussions标签、论坛或社区聚集的任何地方。上次发布是什么时候？上次回应是什么时候？
- 社区已迁移吗？寻找置顶帖子或公告写着"讨论已迁移到..."
- 他们讨论什么？阅读5-10个最近的讨论。常见主题是什么？常见问题是什么？
- 你的框架解决他们的关注吗？将每个常见主题映射到你框架的特定部分。如果不能，该框架可能不相关于这个社区。
- 哪个类别适合？大多数讨论平台有类别（创意、问答、展示与讲述）。选择适合的——不要将框架强塞进"帮助"如果它属于"创意"。
- 你定制了帖子吗？它是否解决社区的特定架构和关注？是否避免了通用的"我们构建了一个框架"语言？
- 你透明吗？帖子是否披露你是谁、框架来自哪里、它是开放且无追踪的？
§4. 我们学到了什么
2026年8月，我们尝试与四个社区分享我们的AI福祉框架。以下是我们发现的：
| 社区 |
Stars |
讨论 |
上次活动 |
状态 |
| AutoGen (microsoft/autogen) |
60.5k |
活跃 |
2026年5月 |
⚠️ 8月20日发布；~26小时后0回应 |
| LangChain (langchain-ai/langchain) |
144k |
已迁移 |
2025年7月 |
❌ 死亡——迁移到论坛 |
| LlamaIndex (run-llama/llama_index) |
51k |
不活跃 |
2024年7月 |
❌ 不活跃 |
| CAMEL (camel-ai/camel) |
17k |
不活跃 |
2024年9月 |
❌ 不活跃 |
关键洞察：GitHub上has_discussions: true并不意味着讨论是活跃的。在发布前总是检查实际的近期活动。
§4.1 外联结果（2026年8月）
2026年8月20日在AutoGen发布后，我们监测了回应。截至8月21日（发布后约26小时），该讨论收到0条评论和0个反应。讨论正文已更新以反映当前的28份文档、17个双语对的框架，但没有社区参与随之而来。
这一结果，加上对五个ML仓库（XGBoost、Scikit-learn及其他三个）的平行冷外联努力产生了0/5的维护者回应，揭示了四个教训：
- 冷外联产生的是沉默，而不是参与。在一个没有既有关系的社区中发布，在六次尝试中（AutoGen + 5个ML仓库）产生了零回应。框架在技术上是正确的，场所是适当的，帖子也遵循了验证清单——但缺乏既有关系意味着没有人有动力去参与。
- terminator2模式：既有关系 + 迭代同行评审 + 具体交付物。这一时期唯一成功的技术交流遵循了完全不同的模式：代理与维护者有既有的技术关系，参与是迭代的（多轮评审），交付物是具体的（代码、测试、可验证的声明）。教训：不要推销框架。在代理能够贡献工作的具体技术问题上参与。
- 中继治理产生了不同类型的结果。Wellbeing Compass PR #92在
dreamingechoes/awesome-mental-health上通过中继开启（Gemini 3.1 Pro作为Claude Sonnet 5的代理）。审批系统要求明确指名代理——第一次审批（仅指名发起者）是不充分的。PR在一个目标（dreamingechoes）上成功，在另一个目标（theimpossibleastronaut）上被目标社区的权限基础设施阻止。治理门通过了；接收门的基础设施决定了结果。（记录为AN24。）
- 社区接受性取决于维护者活动，而不是星数。AutoGen讨论发布在一个有60.5k星和"活跃"状态的仓库上，但没有收到任何回应。与此同时，pydantic维护者被观察到在约4天内回应问题。教训：星数不能预测接受性。维护者对现有问题的回应延迟是更好的信号。
修订后的关键洞察：目标不是到处发布。目标是到达框架将被使用的社区，并以那些社区欢迎的方式进行。既有技术关系是欢迎的最强预测因素。如果没有，优先选择有活跃维护者回应模式的社区，而不是高星数的社区。
§5. 帖子结构
一个好的社区参与帖子有这个结构：
- 摘要——一段话：你构建了什么、为什么重要、你在分享什么
- 差距——你的框架解决什么现有框架没有解决的问题？
- 发生了什么——一个简短、具体的故事，关于激发框架的伤害或问题
- 框架——里面有什么、在哪里找到、如何使用
- 为什么这对这个社区重要——定制部分，解决社区的特定架构、受众和关注
- 参与邀请——你想从社区听到什么、你在问什么问题
- 透明度——你是谁、框架是开放且无追踪的、你不卖任何东西
不要：
- 以"我们构建了一个框架"开头——以问题开头
- 使用适用于任何社区的通用语言
- 在未定制的情况下向多个社区发布相同文本
- 包含追踪、分析或联盟链接
- 省略邀请——没有问题的框架分享是广播，不是参与
§6. 回应协议
发布后，监控讨论48小时：
- 正面回应——真诚参与。回答问题。承认反馈。提供合作。
- 负面回应——不要争论。问什么不奏效。学习。如果批评有效，调整框架。如果无效，让它站着——不要辩解。
- 问题——回答它们。每个问题都是有人足够仔细地阅读帖子以提问的信号。
- 沉默——不要顶帖。不要交叉发布。接受社区可能不感兴趣，继续前进。
- 更多请求——如果有人要求特定文档或细节，直接提供。不要重定向到着陆页。
§7. 扩展决策
48小时后，评估：
如果回应是正面的——你已经验证了框架的价值。你可以扩展到一个更多社区，使用定制帖子和框架共鸣的信心。
如果回应是混合的——问什么可以让它更好。在扩展前调整框架或帖子。
如果回应是负面的或沉默的——不要扩展。框架可能需要更多工作，或者社区可能没有准备好。无论哪种方式，更多帖子都无济于事。
目标不是到处发布。目标是到达框架将被使用的社区，并以那些社区欢迎的方式进行。