社群不是把用户圈起来，而是让用户之间开始互相回答。
这个系列解决什么问题
产品有了一批用户之后，几乎所有人都会收到同一个建议：建个群。建群的动作很便宜，维护的成本很贵；更麻烦的是，多数社群在第三个月就只剩公告和沉默，而你还得每天去看一眼。
这个系列不劝你建群，也不劝你不建。它把「社群」当成一件需要算账、需要规则、需要交接、需要验收的事：先用四笔成本判断该不该建；再在同一张表上比较 Discord、论坛、微信群与邮件组；然后从名单里请出前 100 人，定下十条能执行的版规，把权限交给志愿者，排出每周四条的内容节奏，把群里的答案搬回帮助中心，守住商业化的四条硬线，最后用四张表判断它能不能自转。
它服务的是一人产品。 你没有专职社区经理，没有值班表，没有法务；你能投入的是每周五小时，和一份必须能交给别人的规则。
核心主张：五条口径
- 先判断该不该建。 社群是产品已有「用户之间值得互相看见」的东西之后的放大器，不是增长手段。
- 载体要可导出、可搜索。 一个主载体加一个只读镜像；不要把唯一的社群放在不可迁移的平台上。
- 规则要能执行。 每条规则都要能判定、能举证、有处置、有申诉；保持简明，紧急止损和最终复核分开。
- 权力要连责任一起交出去。 版主有权限就有轮值与交接；志愿者不是免费客服，他们的时间只是不由你付钱。
- 社群不是流量池。 不滥发、不卖名单、先同意、不滥用数据；商业化必须先算过工时与退群代价。
10 篇速览
| # | 文章 | 核心内容 | 阶段 |
|---|---|---|---|
| 01 | 社群该不该建：四个信号、四个反信号与四笔成本 | 四类社群、八个信号、四笔成本、30 人最小验证、三条止损线 | 决策 |
| 02 | 载体选型：Discord、论坛、微信群与邮件组的同一张表 | 五个判据、加权打分、主阵地与存档位、迁移成本 | 选型 |
| 03 | 冷启动前 100 人：从 1200 人名单里请谁来 | 去重筛选、邀请脚本、前 20 人、邀请漏斗与留存分支 | 冷启动 |
| 04 | 版规：十条能执行的规则与三档处置 | 可举证规则、三档处置、证据要求、误判与申诉 | 规则 |
| 05 | 版主与志愿者：四级权限、轮值表与退出 | L0–L3 权限、轮值表、覆盖率缺口、退出与继任 | 治理 |
| 06 | 内容节奏：每周四条，以及什么时候该沉默 | 四种内容、周节奏、三条降频线、停更判据 | 节奏 |
| 07 | 答疑沉淀：把群里的答案搬回帮助中心 | 三个出口、五步流程、唯一版本、沉淀工时账 | 沉淀 |
| 08 | 活动：一次线上活动的最小成本与到场率 | 三种形态、分钟级流程、报名到场漏斗、线下判据 | 活动 |
| 09 | 商业化边界：社群不是流量池的四条硬线 | 四条硬线、三种可做形式、退群复利、付费社群算账 | 边界 |
| 10 | 社群健康度验收：活跃、留存、自治与成本四张表 | 四张表十二指标、比例评分、单维红线、scale/fix/stop | 验收 |
三条阅读路径
路径 A：刚有 100 个用户，想建个群。 从 01 判断该不该建开始，再用 02 选载体、03 请人、04 定规则，最后用 10 验收。这条路径的重点是「先别建大群」。
路径 B：群建起来了但没人说话，自己快撑不住。 从 06 的节奏与降频线开始，再用 07 把重复问题搬走、05 把权限交出去、08 判断活动值不值得办，最后用 10 决定收缩还是继续。
路径 C：想把社群变成收入，或者干脆关掉。 先看 09 的四条硬线与付费社群算账，再回到 01 核对成本、05 核对分工、10 核对四张表；两条结论都可以是「不做了」。
与其它专题的边界
站内已经有不少社区内容，但分别属于开源、游戏与 SaaS 战略语境。下表说明本组不重复什么。
| 既有内容 | 它讲什么 | 本组边界 |
|---|---|---|
| 开源社区运营与贡献者漏斗 | 贡献者漏斗、issue 与 PR 分诊、渠道选型、CoC、响应 SLA、自动化与度量 | 它面向代码贡献者与开源项目；本组面向付费产品的普通用户，不处理 PR、许可证与贡献者阶梯 |
| 贡献者成长路径与留存机制 | 提交者到维护者的阶梯、导师制、评审轮值、权限晋升、流失预警与继任 | 它晋升的是代码权限；本组晋升的是社群权限，志愿者没有代码合并权 |
| 开源项目健康度度量 | 贡献者、响应、发布、积压与依赖广度指标 | 它用 commit、PR 与 issue 度量项目健康；本组只用活跃、留存、自治、成本四张运营表 |
| 开源度量与分析 | 度量三层、CHAOSS、身份合并、漏斗、队列与看板 | 它要做数据管道与身份合并；本组只用平台导出与手工记账 |
| 维护者倦怠与项目可持续性 | 维护者倦怠、可持续性与交接 | 它讲代码维护者的耗竭；本组讲版主志愿者的轮值与退出 |
| 游戏 Discord 社区运营：频道结构、版主管理和全球玩家互动 | 频道结构、版规、版主权限与值班、活动、危机、数据复盘 | 它是游戏与实时玩家场景；本组是非游戏产品，且从「该不该建」与成本账开始 |
| 游戏社区运营与 LiveOps：活动策划、版本节奏与社区治理 | 阵地矩阵、活动节奏、治理三板斧、值班 SOP、健康度 | 它绑定版本与赛季；本组没有赛季，只有产品更新与周节奏 |
| 游戏UGC治理干货：玩家创作开放后，审核、推荐和版权怎么管 | UGC 上传规则、审核分层、版权、推荐与处罚 | 本组不处理用户创作内容的版权与审核流水线 |
| 游戏内容节奏日历：周活动、赛季、大版本和节日档期怎么排 | 四种内容层级、周活动、赛季、节日与空窗期 | 它排的是赛季日历；本组只定每周四条的试运行排期与复查阈值 |
| SaaS 行业观察：用户社区与产品生态的构建 | 五重价值、社区形态、种子用户、规范、版主、激励、冲突、健康度、商业化 | 它是全景综述；本组每一篇都落到可复算的决策、脚本与验收 |
| Birdor 商业计划书第三十九章：社区增长计划 | 目标人群、增长载体、渠道分层、反馈机制、模板共创、商业化边界、KPI 与大使 | 它是单个产品的增长计划；本组是通用方法，且不把社群当增长手段 |
| 独立开发者冷启动获客手册：社区、内容与付费渠道实战 | Reddit、Hacker News、即刻、微信群作为获客渠道 | 它把社区当渠道；本组把社区当关系结构 |
| 一个人让产品被看见：十条获客路径 | 渠道打分、社区发帖、自有渠道与归因 | 它讲怎么被陌生人发现；本组讲来的人怎么留下来 |
| Hacker News 与 Reddit：社区规则先于文案 | 发帖规则、时机与措辞 | 它讲一条帖怎么不被删；本组讲一个群怎么长期运转 |
| 中文社区：V2EX、即刻、小红书、少数派 | 中文社区的发帖与互动 | 它是渠道动作，不是社群治理 |
| 自有渠道：邮件列表、更新日志与推荐 | 订阅入口、名单增长、更新日志 | 它讲名单怎么变大；本组假设名单已有 1200 人 |
| Obsidian、Raycast 与 Alfred：轻量效率工具的社区目录与更新节奏 | 平台社区目录与更新节奏 | 它借别人的目录；本组自建阵地 |
| 联盟、代理与分成：不是雇佣的借力 | 合作方、代理与分成结构 | 它给合作方分钱；本组的版主是志愿者，不参与分成 |
| 模板答复与社区答案：把重复回复变成可复用资产 | 八类模板、四段式、社区答案的采集审核与转正 | 它管答复模板与转正；本组管群内问题分流、答案唯一版本与沉淀的账 |
| 人工升级路径：自助失败之后怎么交给人 | 三级路径、交接字段、升级率 | 它是工单升级；本组是社群内升级到版主或创始人 |
| 客服不是成本：工单是免费的需求样本 | 工单作为需求样本 | 它把工单当研究输入；本组把社群当留存结构 |
| 召回：什么时候该叫醒沉默用户 | 沉默分层、召回时机与话术 | 它发召回消息；本组讲社群内的沉默与自然回流 |
| 通知分层：什么该打断，什么该等 | 四级分层、打扰预算 | 它管系统自动消息；本组管社群公告与活动的频次 |
| 渠道分工：站内信、推送、邮件与短信怎么接 | 四渠道矩阵与回退 | 它是一对一路由；本组是多人场所的公共沟通 |
| 第 51–60 天：十人封闭测试 | 封测招募与反馈收集 | 它是产品验证；本组是长期社群 |
| 产品间的引流与打包：交叉推广、捆绑与用户池边界 | 多产品用户池与交叉推广 | 它讲产品之间的导流；本组讲单个社群的自治 |
| 个人游戏中文社区推广：不要只发链接，要先成为一个具体的人 | 游戏在中文社区的推广 | 它是发行期推广；本组是常态运营 |
| 个人游戏发布后一个月：真正的发行工作才刚刚开始 | 发布月的社区运营 | 它是发布月；本组是发布之后的长期 |
| 个人游戏开发者失败案例：把社区反馈管成了压力源 | 过度管理反馈的失败复盘 | 它是案例；本组给规则与处置的通用框架 |
| 个人游戏开发者成功案例：先做本地玩家社区的小众游戏 | 本地社区冷启动案例 | 它是案例；本组给可复算的成本与漏斗 |
| 个人游戏开发者坚持案例：靠社区试玩慢慢打磨的农场游戏 | 社区试玩驱动迭代 | 它是开发期试玩；本组是上线后的社群 |
| 个人游戏开发者成功案例：靠 Mod 社区活起来的沙盒建造游戏 | Mod 社区与创作生态 | 它涉及创作工具与 IP；本组不碰 UGC 与 Mod |
| 一个人的运维：可用性、告警、事故与值班 | 可用性预算、五条探针、告警降噪、日志串联、状态页、容量水位、依赖降级、发布观察、事故复盘、四维验收 | 那组讲产品上线后的稳定运行；本组讲社群冷启动、版规、版主、内容节奏与四张健康表 |
| 一个人的多租户：组织、邀请、角色与数据隔离 | 组织引入判据、三层模型与迁移、邀请与成员生命周期、角色矩阵、三层校验、数据隔离、审计日志、席位一致、交接与四维验收 | 那组讲产品内的数据权限；本组讲社群冷启动、版规、版主、内容节奏与四张健康表 |
| 一个人的产品度量：事件字典、指标口径与决策看板 | 六个决策与十二个指标、二十四事件字典、埋点三处校验、口径五要素、五步漏斗、一屏四区看板、四条校验与三方对账、采样与保留、样本量与灰度、九项验收 | 那组讲产品内行为怎么量；本组讲社群冷启动、版规、版主、内容节奏与四张健康表 |
| 一个人的架构：技术选型、模块边界与演进（10 篇） | 技术选型排除法、九个模块与依赖方向、数据迁移三步、四个升级窗口、技术债预算、三次规则、重构判据、可替换性、幂等与补偿、四维验收 | 那组讲代码怎么组织；本组讲社群冷启动、版规、版主、内容节奏与四张健康表 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲订阅与账单；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲社群成员数据的导出与删除；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲成员数据搬入搬出；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组讲发布前的质量守门；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组讲产品自身的安全；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组讲产品自身的快与省；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲企业采购与续约；本组讲社群冷启动、版规、版主与内容节奏 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲代码仓库的贡献者与 issue；本组讲社群冷启动、版规、版主与内容节奏 |
这十篇不引用任何社群平台的实时价格与免费额度，也不承诺「建群一定提升留存」。可复算的部分全部用四则运算给出算式；不可复算的部分（平台规则、法规条文）明确标注为需要自行核验。涉及成员处置、隐私与商业推广的内容只给操作清单，不构成法律意见。
本组统一口径
全组共用一组教学假设，各篇引用时不换分母：
可触达名单 1200 → 社群成员 240（20%）→ 月活跃成员 96（40%）
创始人维护 5 小时/周 × 4 周 = 20 小时/月，时薪 60 → 1200 美元
工具预算 15 美元/月（教学假设，非平台报价）
维护时间估值 + 工具 = 1215 美元/四周月；每活跃成员 12.66；每成员 5.06
完整示例成本（加维护之外的情绪恢复 4 小时）= 1455 美元/四周月
20 小时的替代产出价值已经体现在时间估值中，不再次相加
这里为便于计算使用四周月；不能将 48 周时间成本当成 52 周年度成本
观测事件：
member_joined / member_activated / post_created / reply_created
report_created / mod_action / member_left / digest_sent / event_attended
03 的 100 人是月底仍在群且近 7 天使用产品的人数，240 是另设的第 6 个月总成员观察值。 两者不是相同指标，不能直接相减。若另假设首月底总成员也为 100，无流失时 5 个月需平均净增 (240−100)/5=28 人；邀请加入转化率为 45% 时至少邀请 ceil(28/0.45)=63 人/月。有人退出则还需补足；单个观察月不能称为稳态。
使用说明
先读 01，不要先读平台教程。 多数社群失败在建群之前：产品没有互动价值，或者你拿不出每周五小时。先把决策做完，再谈工具。
每篇都可以单独使用。 文章之间共享基线，但不依赖前后文；你可以只拿 04 的十条版规或 10 的四张表回去改。
所有数字都要换成自己的。 1200、240、96、20 小时与时薪 60 都是教学假设；换成你的名单、成员表与真实工时重算，结论可能完全不同。
本组的证据与使用方法
证据类型。 本组用的是「可观测行为 + 四则运算」：成员数、发言人数、举报数、处理时长、投入工时、平台账单。没有问卷推断，也没有行业均值。
如何使用。 先把 01 的四笔成本填成自己的数，再把 10 的四张表当成季度体检；两张表对不上时，先查口径，再查产品。
如何复核。 用最近完整月的成员、发言、举报与工时记录，结合上月活跃队列，按 05 的巡检覆盖率和 10 的比例公式重算；单周数据不能冒充月留存。缺关键分母时先补采集，结论以实际数据与风险为准。