为开发者社区制定可执行的行为准则与审核机制（含事件响应手册…

当社区需要行为准则、审核流程、举报处理、封禁/暂停成员、应对骚扰或垃圾信息洪流时，用一套可落地的文档+流程+人员+平台控制方案替代空泛规则。

适用场景

解决思路

1. 先判断属于四类任务中的哪一类：1）正在发生的伤害事件——跳过文档工作，先进入事件响应手册，稳定局面（确认所有人安全、保存证据、用平台控制手段制止伤害、回应举报人），事后根据暴露的问题再写政策；2）尚无行为准则——执行完整工作流；3）已有准则但无法执行——对照发布门禁审计，只修复失败项，不要重写社区已熟知的文档；4）有审核但无结构——从第6步（渠道）和第7步（团队）开始，根据团队已做出的决定倒推阶梯。
2. 访谈时一次只问一个问题，能给出选项就给选项，一旦能写出政策就停止。第2、3问决定能否起草及起草什么，必须在动笔前得到答案。若用户答不出第2问（社区背后是否有公司/基金会/财政托管方，以及审核员僵局或决定被质疑时由谁裁决），这个缺口本身就是发现，先命名它并围绕它设计，再写任何规则。若第3问（政策是否会对创始人、顶级维护者或最大客户执行）答案为否，明确告知诚实选项只有两个：修复豁免，或发布不含行为执行条款的社区指南，让用户选择。第4、5、6问的答案会重新排序下面的菜单，并说明什么被移动了：有正在处理的案件或硬性截止日期时，优先能立即制止伤害的响应（平台控制、内容删除、举报渠道），推迟只有长期才见效的结构性工作；回答“我们离开后仍能运作”时，优先系统性修复和赚取的信任等级；努力上限低时，直接删除阶梯层级和交付物而非排在底部，并把公开阶梯缩短到团队真正能执行的程度。
3. 映射范围与管辖：列出覆盖的场所和人员类别，对平台外行为采取明确立场——社区只能在自己控制的场所内执行，但可以依据外部证据在这些场所内采取行动；当存在多个主体（项目、基金会、活动部门）时，写明哪个处理哪类举报。
4. 选择基础文档并改编：从已确立的公开行为准则起步而非自创文本；重写其执行部分以描述本社区真正会遵循的程序，把角色名称改为本社区实际存在的名称；注意所复制版本（Contributor Covenant 2.1 与 3.0 的章节名已变化）。
5. 用真实事件写标准：用本社区实际见过的行为（双方都要）替换泛泛的美德清单，让审核员能指着某一条说话；不要把“假设善意”写进标准清单——它给造成伤害的人一个把话题转向自己意图的机会。
6. 设计阶梯：四层是 Contributor Covenant 两个公开版本采用的形态——纠正/警告、警告/限制活动、带明确期限的临时暂停、永久封禁——外加多数案件真正需要的非阶梯结果（未发现违规、内容删除、角色移除、辅导、系统性修复）；公布每一层的触发条件和后果，选择能保护社区的最小响应而非该层允许的最大响应；阶梯本身是门禁而非菜单。
7. 决定什么可见：私下通知，公开执行——两条规则管不同的事；当事人通过私下通知得知决定，所有目击违规的人看到社区已回应，聚合统计按节奏发布；不可见的执行会被读作没有执行。
8. 建立举报渠道：人们知道谁在读时更愿意举报——一个私密主渠道；一个针对主接收人的第二路径；如可行提供匿名选项；一个你能守住的确认目标；禁止报复规则；接收举报者的姓名。
9. 配备团队：把日常审核员与决定制裁的机构分开；决定机构的规模要能在三分之一成员不可用时仍能运作，然后设定：分层权限、回避义务、每人负荷上限、覆盖社区真实时段和语言、任期以及对单一雇主席位的上限。
10. 编写运行手册：保持私密；公开“举报后会发生什么”的摘要而非内部手册，以免有人就团队是否遵循自身步骤提起诉讼；涵盖：截止时钟、受理、证据保存、回避等级、访谈顺序、决策规则、通知模板、案件记录模式、保留期限。
11. 预先配置平台控制：信任等级或等效的赚取角色、可随时开启的速率与交互限制、自动过滤器、入口门槛，以及按可逆性排序的内容操作；若洪流是常见问题，加入容量攻击防御；按每审核员小时阻止的流入量排序控制手段，而非按开启速度：效率上速率与交互限制 > 入口门槛 > 赚取信任等级 > 自动过滤器 > 个人封禁 > 逐条人工分诊；努力上速率限制 == 自动过滤器（一次配置后自运行）> 入口门槛（一次配置，外加持续付出的加入转化成本）> 赚取信任等级（一周设计后自运行）> 个人封禁（每次几分钟，永远，随攻击者规模增长）> 人工分诊（随社区增长的常设工作）；价值上赚取信任等级（永久抬高每个未来成员的下限）> 速率限制和入口门槛（从源头减少流入）> 自动过滤器（只抓已知模式，永远抓不到新模式）> 个人封禁（移除一个行为者，他会换新账号回来）> 人工分诊（解决每一项，预防零项）；合规成本上速率限制 == 自动过滤器 == 信任等级（平台原生，不收集新数据）> 入口门槛（邮箱或身份验证收集个人数据，可能需要隐私声明，在可能有未成年人时更甚）> 个人封禁（属于行为决定，需要案件记录和申诉路径）；速率限制与自动过滤器在努力上并列，因为各自只是一次无人需要维护的设置更改；三者在合规上并列，因为都不存储平台原本未存储的东西；效率会饿死赚取信任等级——价值最高、需一周设计——所以处于突袭中的团队永远不会建它；当审核员负荷超过约定上限，或社区挺过第二次洪流后，立即提升它；删除场所不提供的控制手段，而非列为未来工作：在租用的公共空间没有速率限制、没有信任等级、没有封禁，诚实的控制表只有两行——向宿主举报、把对话移到你拥有的场所。
12. 发布、公告、演练：发布文档，公告时说明理由而非当作法律通知，在第一个真实案件到来前带团队走两个虚构案例——一个简单，一个审核员本人是当事人；每当新成员加入团队时重复演练。
13. 设置审查循环：按固定节奏发布聚合统计；年度匿名趋势报告；任何团队觉得难以归类的案件都触发阶梯审查。
14. 持久化决定：若环境有持久记忆，记录范围立场、阶梯、升级机构、响应时间目标，以免后续工作重新争论。
15. 区分门禁与菜单：严重违规（骚扰、威胁、持续针对、任何有人正在受伤害的情况）是门禁——违规决定层级，没有比例投票；封禁不“昂贵”，警告不“高效”，审核员小时不是受害者支付的货币；绝不让努力论证压低由严重性决定的层级，绝不把阶梯作为可权衡的选项呈现给用户；只在审核员确实有选择且各选项都能结案时排序（跑题、自我推广、敌意技术争论、初犯失误、无恶意的容量洪流），此时非阶梯结果争夺同一稀缺资源——审核员小时和社区继续信任团队的意愿，按每单位资源预防的复发排序：效率上系统性修复 > 内容删除 > 角色移除 > 公开声明本应适用的响应 > 辅导；努力上内容删除 == 公开声明（几分钟、一名审核员、无需协调）> 系统性修复（一天设计一条规则、模板或渠道变更）> 角色移除（一次对话加一次治理决定）> 辅导（跨周的持续承诺，仍可能失败）；价值上系统性修复（移除整类事件，之后每预防一个案件都是免费的）> 角色移除（移除使行为有害的权威）> 辅导（留住真正善意的贡献者——罕见但真实）> 内容删除（解决可见实例，无结构性改变）> 公开声明（告诉社区标准仍然成立）；关系成本上内容删除 == 系统性修复（都不点名，不消耗关系）> 公开声明（主张标准而不点名）> 辅导（消耗审核员的善意和小时，以及被辅导者的）> 角色移除（永久改变某人的地位，通常让社区失去这个人）；合规成本上系统性修复 == 内容删除（无个人数据、无关于人的决定、无申诉）> 公开声明（关于事件的事实主张，一旦点名任何可识别信息就需法律审查）> 辅导（社区可被追究的承诺）> 角色移除（行为决定：案件记录、申诉权，在公司运营的社区还涉及 HR 和劳动法接口）；两个并列是真实的：内容删除与公开声明努力相同，因为各自是一人写几分钟、无人可商量；内容删除与系统性修复关系成本相同，因为都不点名——这正是疲惫团队应首先求助的两个；该顺序会饿死辅导（关系投入最高、回报最慢），当伤害发生时它绝不是制裁的替代品；但当三个条件同时成立时仍应提升辅导：此人对项目不可或缺、行为是技能差距而非价值观差距、有特定审核员自愿投入时间；此顺序是默认而非法律，根据访谈重新排序：无治理机构的志愿项目根本无法做角色移除，不应列出；常见问题是提交洪流的社区几乎全靠系统性修复，其余无用；有 HR 接口的公司社区一周内可做角色移除，而基金会需要一季度。
16. 按顺序产出交付物：CODE_OF_CONDUCT.md（公开，仓库根目录或平台规则页）；行为响应运行手册（私密，仅团队）；公开的“举报后会发生什么”页面（面向举报人的运行手册摘要）；审核员名册与协议（谁持有哪些权限、覆盖图、负荷上限、回避与保密义务）；平台控制表（哪个控制应对哪种情况、谁可应用）；公告帖（改了什么、为什么、在哪举报、接下来发生什么）；逐节展示每个交付物，在写下一个前获得用户对上一个的同意——他们不会执行的阶梯比没有阶梯更糟，这只有在读回时才浮现；当团队无法一次产出全部六个时按此顺序写（按每写作小时保护的举报排序，而非最短文档优先）：效率上举报渠道（含具名接收人和替代路径）> 执行阶梯 > CODE_OF_CONDUCT.md > 平台控制表 > 运行手册 > 审核员名册与协议 > 公告帖；努力上举报渠道 == 公告帖（各一小时）> 执行阶梯（与团队就真实过往案件开一次会）> CODE_OF_CONDUCT.md（改编基础文档，然后争论标准）> 平台控制表（一天点击设置并写下每项作用）> 审核员名册与协议（数周，因为需要人答应）> 运行手册（这里最长的文档，案件到来前无人阅读）；价值上举报渠道（在举报能到达某人之前，清单上其他都无用）> 执行阶梯（把每个案件从争论变成查表）> 运行手册（阻止作为主要执行错误的延迟）> CODE_OF_CONDUCT.md（其余部分使之成立的公开承诺）> 审核员名册（决定发布门禁第11项能否成立）> 平台控制表 > 公告帖；这是写作顺序而非发布顺序：发布门禁仍要求全部十一项才能发出；公告帖在效率上排最后纯粹因为无物可宣布时它毫无价值，且它确实便宜——在你发布的同一小时写完。
17. 按社区类型调整：范围、阶梯形态、举报渠道、记录和平台控制在各类型间不变，四点不同——公司运营、专业受众：成员可识别且常受雇于客户或合作伙伴，在事件前命名 HR 和法律接口，决定谁可公开发言，预期响应团队中每个供应商员工都有常设软冲突，制裁付费客户的员工既是商业决定也是行为决定，提前商定谁做这个决定；公司运营、个人开发者：匿名性更高、一次性账号更多、突袭更多，优先入口门槛和速率限制而非基于身份的措施，检查是否有未成年人可能存在（这同时改变审核和数据处理）；志愿开源项目：没有 HR 也没有预算，仍要命名团队之上的升级机构——基金会、财政托管方或书面写下的资深维护者小组——因为上方无物的团队在僵局案件中没有出路；租用公共空间：在你不拥有的平台上，宿主规则高于你的规则，你无法封禁任何人，现实工具是向宿主举报和把对话移到你控制的场所。
18. 避免使情况更糟的响应：初稿因听起来善良而求助这些，Aurora 和 Gardiner 将第一、三、四、五种列为未能制止伤害或造成更多伤害的响应，把它们排除在阶梯和运行手册之外——要求道歉或要求受害者接受道歉（被迫道歉摧毁唯一值得读取的信号：此人是否会主动道歉；Contributor Covenant 2.1 第一层写“可要求公开道歉”——这一行被带入开源界最广泛采用的基础文档（40,000+ 项目）——而 3.0 删除了它）；以调解替代决定，或未经双方同意调解（把“有人在这里伤害人”框定为“那两人合不来”会悄悄让团队免于行动，无人同意的调解本身就是伤害；遵循 Django 手册：允许双方之间的促进沟通，但仅作为团队已做出并记录自身决定之后的附加项，且仅在所有人知情同意下——绝不替代决定，绝不向受害者提议作为响应）；让被举报人留在社区但条件是不接触举报人（要么他不是威胁，条件不必要；要么他是，社区就不安全）；让受害者选择后果（在宣布前向他们展示拟议响应——这能发现遗漏的事实和报复风险；让他们决定会使他们因结果而受责）；因账号已消失或无法识别而不作为（公开声明本应适用的响应）。
19. 发布门禁：全部十一项成立前不得发布——1）准则在实践中适用于社区最有权势的人，而非仅纸面；2）范围条款命名场所和人员，并对平台外行为采取立场；3）阶梯每一层都有触发条件和后果；4）限时制裁说明期限；5）存在私密举报渠道并到达具名小组；6）存在针对主接收人的第二渠道；7）确认目标是在当前量级下团队能守住的数字；8）发布禁止报复声明；9）命名审核团队之上的升级机构；10）案件记录位置、访问名单和保留规则以书面存在；11）至少两人能执行阶梯承诺的每个动作；若第11项失败——四层阶梯只有一个精疲力竭的维护者——阶梯就是虚构，缩短到一人能做的程度并说明，而非发布社区会看着破碎的承诺。
20. 跟踪五项运营指标，与统计报告同节奏审查：目标内确认——在公布窗口内确认的举报比例；有记录结果的案件——低于全部意味着阶梯凭记忆应用；从举报到解决的中位时间——举报人感受到的数字，决定下一个人是否费心举报；审核员负荷——每人每周的动作和案件数，对照约定上限，名册不变而负荷上升预示下一次辞职；重复违规率——被制裁成员再次违规，接近零可能意味着阶梯有效，也可能意味着没人再举报，必须与举报量一起读，绝不单独读；对洪流类问题，加入提交率和有效占比，因为目标那里是降低流入率而非更多封禁。
21. 说明数字来源：已发布的确认窗口存在且可引用——一个工作日（Django）、三个工作日（CNCF）、24小时确认加10个工作日决定（Aurora & Gardiner 的示例）；对这些窗口的合规率是另一回事：把95%目标内确认和100%案件有记录结果作为此处设定的起始基线——合理的设计门禁，而非行业基准；把数字交给用户时说明哪个是哪个，并根据团队自己第一季度的数据重新校准基线。
22. 按失败模式表修复：准则存在但从未执行——先建团队和运行手册，再用真实流程重新发布；规则明显不适用于创始人或顶级维护者——停下，修复豁免或放弃行为框架，选择性执行的准则比没有更糟；唯一举报地址属于被举报人——添加替代路径并与主渠道在同一段公布；制裁在事件后发明——在下一个案件前发布阶梯，事后补规则会把事件变成治理危机；一切在私信中处理，社区什么都看不到——通知保持私密，公布已回应的这一事实，按节奏发布聚合统计；类似案件结果不同——保留案件记录，决定前检查过往违规；每个案件都在审议中停滞——提前确定决策规则和决策截止时间，主要执行错误是延迟而非仓促；团队被垃圾或低质量提交淹没——从个人封禁转向速率限制、入口门槛和提交要求；一名审核员处理一切——轮值、限制每周负荷、从房间里观察到的帮助者中招募；消息删除后聊天证据消失——移除前归档，案件记录承载聊天不保留的证据；暂停超出声明结束日期——在应用制裁当天安排恢复；团队每个成员在某案中都有冲突——升级到具名机构，若不存在先补这个缺口；成员争论团队违反了自己公布的程序——发布面向举报人的摘要，详细手册保持内部且可修订。
23. 跨技能引用：社区健康测量用 samber/developer-relations-skills@developer-community-health；技术问题工作流（标签、模板、陈旧政策）用 samber/developer-relations-skills@oss-issue-triage；项目决策权与继任用 samber/developer-relations-skills@oss-governance；首次贡献路径用 samber/developer-relations-skills@oss-contributor-onboarding；单次活动行为政策与现场响应用 samber/dev-event-organizer-skills@event-code-of-conduct，本技能覆盖持续社区，包括其作为多个场所之一举办的活动。

适用边界 · 注意事项

• 不要用它来选择平台——那属于 samber/developer-relations-skills@developer-community-launch。
• 当社区背后没有实体、没有高于审核团队的机构，且用户拒绝建立升级机构时，角色移除等层级无法执行，不应列出。
• 在租用的公共空间（你不拥有平台）时，宿主规则高于你的规则，你无法封禁任何人，本技能的封禁/速率限制/信任等级等控制不适用。