如何为已有开发者社区设计可执行的健康度量框架（活动、响应…

当有人问“我们的开发者社区/ Discord/Slack/论坛是否健康、是否在衰退、该追踪哪些社区指标”时，用一套可采集、有基线、能触发行动的指标表来回答。

适用场景

解决思路

1. 先路由：确认用户真正需要的是启动社区、制定行为准则、设计 issue/PR 分诊、搭建首次贡献路径、招募超级用户、衡量整个 DevRel 项目，还是搭建底层追踪计划；若不是衡量已存在社区的健康度，就指向对应技能并停止。
2. 访谈直到能填满指标表，一次只问一个问题，选项已知时用多选题：社区形态（聊天/论坛、开源贡献者、或两者）及具体场所；B2B 还是个人采用/开源；社区存在的唯一目标（支持分流、激活、产品反馈、贡献、留存或口碑）；当前规模与典型周活动量；今天无需预算或权限即可获取的数据（forge API、git 历史、场所自带分析、导出、社区数据平台）；谁拥有数字、谁读结果；投入上限（每月小时数、人数、能否申请新工具预算或权限）；首次读数截止日期；要一次性回答还是可累积的趋势表；已在追踪什么、该数字曾导致过什么改变；背后是否有具体担忧（下滑、冷清频道、维护者倦怠、董事会要理由）；导出成员数据是否有隐私、法律或场所条款限制。
3. 务必分别问清三件事：团队“能”采集什么（数据访问）、已经“在”采集什么（现有追踪）、以及“可以”采集什么（隐私/法律/条款约束）；漏掉任何一个，框架都会在埋点或合规处失败。
4. 根据投入上限、截止日期和是否要累积趋势来重新排序指标菜单：硬截止日期优先提升历史可读指标（响应性、活动），降级需要三个周期才有意义的指标；要求累积趋势则优先从第一天起快照到自有存储，并提升漏斗支柱；低投入上限直接删除社区数据平台这一层，而不是把它留在表底。
5. 若用户带着症状（如“没人发帖了”）而非明确任务而来，按诊断顺序执行：先测症状指向的支柱，再补全其余部分。
6. 用 SPACES 词汇命名唯一主要目标（支持、产品反馈、获取/倡导、内容/贡献、参与、成功），使它是公认类别而非临时说法；表中每个指标都必须在该目标变动时合理变动。
7. 最多选 8 个指标（本技能自设上限），每个支柱至少一个；越少越好，5 个能持续刷新的表胜过 20 个会腐烂的表。
8. 在承诺任何指标前先做埋点现实检查：按每小时采集投入的回报排序候选指标，删除回报不足以支撑每月固定一小时的指标（自设门槛，非标准）。
9. 在指标表中把每个指标的公式写在名称旁边。
10. 采集基线：至少拉取三个历史周期；没有历史就标记该指标为“baselining”，并在下次评审时设阈值。
11. 从基线设定阈值，并标注每个数字的来源（已发布可归因、自设基线、民间传说）。
12. 为每个阈值突破附上具名行动和负责人；没有行动附着的指标是装饰，删掉它。
13. 设定评审节奏（默认每月，仅高流量时每周，均为自设），并撰写报告。
14. 逐节呈现报告，每节先与用户确认再继续。
15. 覆盖全部四个支柱后再发布指标表：响应性（首次人工响应中位时间、零回复问题占比、变更请求关闭率）、贡献者漏斗（贡献者缺席因子、每周期首次参与者、90 天内二次贡献率、按加入队列的活跃成员留存）、活动（非员工活动占比、每周期活跃贡献者/发帖者、突发性 vs 稳定趋势、频道集中度）、情绪（维护者倦怠信号、推荐度 NPS 式调查项、新人欢迎项）。
16. 按每小时采集带来的决策数排序支柱：效率上响应性 > 贡献者漏斗 > 活动 > 情绪；投入上响应性 == 活动（近乎零，各一个脚本查询）> 贡献者漏斗（身份映射加三个周期历史）> 情绪（需编写、投放和解读调查，一个季度才有读数）；价值上响应性 == 情绪（各自在量变前捕捉问题：没得到回答的新人、即将退出的维护者）> 贡献者漏斗（告诉你改动是否有效）> 活动（只说明有事发生，从不说明健康）；合规成本上活动 == 响应性 == 贡献者漏斗（对场所已公开数据的聚合计数，无需审查）> 情绪（个人级回复、同意、匿名阈值、无法撤回的答案）。
17. 当请求背后的担忧关乎人而非量（维护者倦怠信号、新人抱怨、活动数字看似正常的冷清房间）时，即使效率比会饿死情绪支柱，也要把它提升到第一位。
18. 根据访谈结果重新排序默认支柱顺序：纯聊天社区没有廉价的响应性拉取，提升活动；已有社区数据平台的团队漏斗支柱近乎零成本，可领先；主要目标是贡献的社区无论比率如何都以漏斗为头条。
19. 只保留能通过“那又怎样”测试的指标：如果下个月数字变动 20%，会有人做不同的事吗？不会就不是该社区的健康指标。
20. 用一套词汇命名漏斗阶段并保持一致（如 Orbit 的 explorer → participant → contributor → advocate，或 core/regular/casual 划分）；一张表里两套词汇会让每个队列定义含糊。
21. 标注每个数字的来源：已发布可归因（如 Nielsen 2006 的 90-9-1、VMware 两个工作日人工响应指南、CHAOSS 贡献者缺席因子定义）要注明来源及其范围；自设基线（本社区三个周期滚动中位数、8 指标上限、约 30 事件小样本下限、90 天二次贡献窗口、每月评审、每月一小时埋点门槛）要说明是工作惯例及何种证据会改变它；民间传说（24 小时响应、20% 月活比、40% 七日新成员留存、30% 员工消息占比）只能作为未标注来源的假设引用，三个周期后用本社区滚动中位数替换。
22. 阈值随历史成熟：无历史时标记“baselining”读原始数字，低于约 30 事件/周期时报告带日期的列表而非比率；三个及以上周期时用滚动中位数设阈值，只与自身过去比较，绝不与其他社区比较；六个及以上周期时用偏离带（明确百分比带或滚动均值周围标准差散布，二选一并写入表中）替代固定截断值。
23. 应用两条读数规则：区分突发与趋势（发布、会议、黑客松和事故都会造成尖峰，发布月对比安静月是最常见的假趋势）；把参与不平等当作基线状态而非发现（约 90% 潜水、9% 偶尔贡献、1% 产生大部分活动），目标是活跃人数绝对增长而非消除潜水者。
24. 埋点现实检查按数据源每小时回报排序：forge 与 git 历史 > 场所分析面板 > 社区数据平台；效率上 forge/git 领先（有代码时精确、可脚本化、不受场所保留限制），纯聊天社区除外；场所分析面板是聊天/论坛活动支柱的唯一来源；社区数据平台价值最高但投入最大，仅当多个场所、有具名管道负责人、且上层已两次无法回答同一问题时才提升。
25. 默认层级：1，社区非代码中心时加 2；只有当真正需要的指标在更低层无法计算时才上移一层，绝不因为更高层看起来更严谨。
26. 删除访谈已排除的层级，而不是留作未来工作；没有预算和管道负责人的团队没有第 3 层，纯聊天社区没有第 1 层。
27. 避开四个静默腐蚀数字的陷阱：机器人（从所有响应性指标中排除，维护显式机器人列表并在查询时过滤）；身份（同一人出现在 forge 句柄、聊天句柄、提交邮箱和论坛账号，低量时手工维护映射文件即可）；保留窗口（租用场所低档位限制历史，从第一天起每月快照到自有存储，回填往往不可能）；员工归属（标记员工和维护者账号，“非员工回答占比”和“版主消息占比”需要该标记）。
28. 把隐私当作硬门槛：聚合任何个人级数据；未经同意避免公开的每成员排行榜；批量导出消息内容前检查场所条款。
29. 可选辅助：有 shell 和 git 时运行 `bash scripts/contributor-absence-factor.sh --help` 从本地 git 仓库计算贡献者缺席因子；无法运行脚本时从任何贡献者排名手工计算。
30. B2B 社区以客户账户为单位，统计至少有一个活跃成员的客户账户数及关注账户是否被代表；低量正常，依赖原始列表和具名账户对话而非比率，六份回复的情绪调查不如三次访谈；分流和扩展信号比原始增长更重要。
31. 个人采用和开源社区中量使漏斗和潜水比可读，队列留存、二次贡献率和集中度指标真正有用；情绪来自调查并诚实标注回复率；高一次性贡献率在开源中正常，只有在你做出改动后变动才成为发现。
32. 两类社区共同点：排除机器人、基线派生阈值、每个指标附行动、隐私门槛。
33. 诊断模式：从症状到支柱而非先建全表——‘变冷清’先测按月活动趋势、员工 vs 成员占比、突发性；‘有人问没人答’先测首次响应时间、零回复问题占比；‘新人不再回来’先测加入队列留存、二次贡献率、新人调查项；‘一个人扛所有事’先测贡献者缺席因子、维护者倦怠信号；‘领导要价值证明’先测主要目标指标加一个漏斗指标。
34. 当诚实答案是社区应收缩回更小范围时，明确说出来；让死房间开着，每次新人发帖无人回应都在消耗信任。
35. 按顺序产出：主要目标；指标表（指标、支柱、公式、来源、基线、阈值、负责人、行动）；本期相对基线的读数；两到三条带证据和置信度的发现；带负责人和日期的行动；观察清单；下次评审日期。
36. 节奏跟随受众：给运营社区的人每月工作读数，给资助方每季度汇总；不要为每月才看一次数字的社区建实时仪表盘。
37. 通过阈值检查：每个指标都有通俗定义、团队今天可访问的数据源、基线值或明确的“baselining”标记、触发关注的阈值、突破时的具名行动和负责人；加上最多 8 个指标、每支柱至少一个、没有通不过“那又怎样”测试的指标。
38. 避免失败模式：把成员总数当头条（只增不减，不说明健康）；把机器人当人；与其他社区对标；用文本分类器推断情绪（开发者对话充满直白 bug 报告和冷幽默，会被读成愤怒，应直接问人）；指标变成目标（奖励消息数产生闲聊，奖励关闭 issue 产生过早关闭，为任何激励指标配质量反向指标）；仪表盘无负责人（第三个月就停止刷新，解法是更少指标而非更多自动化）；只调查仍在场的人（离开的成员才掌握原因，尽量加入轻量退出或流失成员问题）；发布个人级数据；队列切得太细（按天而非按月分组导致每队列三人，留存曲线平坦或剧烈波动，加宽窗口并说明所用窗口）；同一指标两种算法（把公式发布在数字旁，而非在会上争论）；无人重访的阈值（每次评审从滚动基线重新推导）。
39. 若运行环境有持久记忆，在用户验证后存储主要目标、最终指标表、基线和阈值，下次评审从记录基线开始，阈值变化成为可见决策而非静默编辑。

适用边界 · 注意事项

• 不要用于启动新社区（应使用 developer-community-launch）。
• 不要用于制定行为准则、执行阶梯或事件响应手册（应使用 developer-community-moderation）。
• 不要用于设计 issue/PR 分诊工作流、首次贡献路径、招募超级用户，或衡量整个 DevRel 项目与搭建底层追踪计划（应使用对应技能）。