Text、Forum 和 Thread 分别处理什么

即时聊天适合短问答、活动和需要共同在线的交流。复杂 Bug、作品反馈和长期主题容易被新消息淹没，更适合 Forum Channel。Discord 当前把 Forum 定义为以独立帖子组织讨论的频道，支持 Post Guidelines、Tags、搜索、筛选、关闭与重新打开；Forum 目前需要启用 Community Server。^[1]

一个支持 Forum 可以设计这些标签：

• 产品区域或平台：Web、iOS、Android、API、Self-host；
• 问题类型：Bug、How-to、Feature Request、Billing；
• 状态：Need Info、Investigating、Workaround、Resolved；
• 版本：仅在确实帮助定位时使用。

标签要帮助分流，数量过多会增加填写成本。状态也要有负责人维护，否则「Resolved」只是一种装饰。解决后的帖子可以保留可公开复用的结论，敏感日志、账户、付款与安全信息移到受限工单。

Thread 适合从一条聊天消息临时展开讨论；Forum 更适合持续、可搜索的主题。选择依据是问题寿命与检索需求，无需让所有交流都进入结构化工单。

Role 用于分流、权限和责任

Role 可以表示成员兴趣、产品区域、通知偏好、贡献能力和团队职责，也可以控制频道可见性。Discord 当前权限可以在 Server 级和 Channel 级配置，Role 层级还会影响成员能够管理哪些角色。^[2]

常见角色可以分为：

• 自选兴趣：设计、开发、增长、某项产品功能；
• 通知偏好：版本、活动、测试计划或地区更新；
• 成员身份：用户、Contributor、合作方、客户等，需要避免暴露敏感商业事实；
• 可验证贡献：长期答疑者、模板作者、活动组织者；
• 运营职责：Support、Moderator、Admin、Incident Response。

按 Message Count 自动升级，会刺激无意义回复，也容易把头衔误当成信任。具备删除消息、管理角色、查看私密频道或安装应用等权限的角色，应采用最小权限并定期复核。贡献角色可以公开认可，管理权限仍要单独授予。

角色颜色和名称也会形成可见等级。若社区把大量精力放在头衔竞赛，成员可能为升级刷屏。更健康的激励是让贡献真的进入 FAQ、活动、产品改进和同伴帮助，并说明角色对应的职责与撤回条件。

Onboarding 要把成员送到正确地方

Discord 当前 Community Onboarding 允许新成员通过问题选择 Roles 与 Channels，加入后还可以在 Channels & Roles 中调整答案。^[3] 一个简洁流程可以问：

1. 这次加入主要想做什么；
2. 使用产品的哪一部分，或属于哪类身份；
3. 想看到哪些主题和更新；
4. 是否愿意接收相关通知；
5. 是否理解并接受社区规则。

重要频道和角色可以在加入前分配，非紧急的兴趣或外观角色留到加入后。问题、答案和说明都应尽量短，避免一次展示太多选项。Discord 官方还建议管理员使用 Preview 检查实际分配结果，把大多数成员频道放进 Default Channels 或 Questions，避免新成员根本找不到。^[3]

第一屏要回答三个问题：这里正在发生什么；现在可以做什么；遇到问题去哪里。活跃讨论、成员作品和一条简短自我介绍入口通常比多条公告更能帮助新成员行动。详细规则可以在相关动作前补充，核心安全规则仍要在加入时清楚可见。

BabyMilu 社区曾按加入目的、身份、更新与 DM 偏好分配角色和频道，再通过 Server Guide 与分步任务引导第一次参与。^[4] 当时接近 3,000 名成员，只是一张规模快照；没有对照数据证明这套 Onboarding 提高了多少转化或留存。可复用的是分流路径，以及运营者对成员文化、称呼和表达的理解。

把 Bug 反馈留在问题发生的上下文中

支持路径最常见的损失是「失忆式交接」：用户先向机器人描述一次，进入 Server 后找频道，创建 Ticket 时又重复填写，最后被要求改发邮件。每增加一次搬运，问题上下文和用户耐心都会损失。^[4]

更短的 Bug 流程可以是：

1. 用户在产品或社区选择 Bug Report；
2. 系统自动附上已获得授权的产品版本、设备、环境、时间和关联事件；
3. 用户只补充预期结果、实际结果和复现步骤；
4. 支持人员确认已收到、严重度、下一次更新时间与是否需要私密信息；
5. 需要工程处理时，把完整上下文同步到 Issue Tracker，并保留双方链接；
6. 修复、Workaround 或无法复现后，回到原帖更新；
7. 可复用结论进入文档，个人数据和临时日志按保留规则删除。

自动附加信息必须遵守数据最小化。日志、截图、录屏、账户 ID、IP、支付记录和消息可能包含个人或敏感数据。只采集诊断必需字段，告知用途，限制 Support 与 Engineering 的访问，并按问题类型设置保留时间。公开频道不得要求用户粘贴 Token、密钥、完整订单、身份证件或其他账户凭据。

Support Forum 可以公开解决通用问题；付款、账户、安全、法律和个人数据转入私密工单。安全漏洞还需要独立披露入口，避免在公开频道暴露利用细节。

FAQ、机器人和 AI Support 都要缩短路径

自动化适合完成重复、确定的动作：按问题类型分流，附加环境，推荐相关文档，提示公开频道不要发送敏感信息，创建工单并通知值班人。用户已经给出的信息应随流程传递。

出现以下情况时要及时转人：

• 用户明确表示答案无效；
• 同一问题循环两次仍未推进；
• 涉及退款、账户、安全、隐私或骚扰；
• 机器人无法取得所需上下文；
• 问题有高严重度或影响多人；
• 用户的语言或无障碍需要超出机器人能力。

FAQ 只适合稳定、重复的问题。产品变化后，旧答案要有 Owner 和复核日期。AI Support 如果只从旧文档生成一段看似完整的回答，却不能引用版本、确认权限或理解群聊前文，可能增加排错时间。评价自动化时要比较总解决时间、重复描述次数、转人工率和解决后反馈，不只看节省了多少人工消息。

App 和 Bot 需要最小权限与退出方案

Discord App 可以自动管理任务，也可能请求创建频道、删除消息或编辑角色等权限。当前官方说明，Server Owner 或拥有 Manage Server 权限的人可以把 App 加入 Server；Server 级 App 的能力还受 Server 权限控制。^[5]

安装前应记录：

• 解决哪一个明确问题，是否有更简单的原生功能；
• 开发者、支持渠道、隐私政策和数据存储位置；
• 请求的 Discord Scope、Role 和 Channel 权限；
• 能读取哪些消息、成员和附件，是否把数据发往第三方；
• 谁可以配置、调用、查看日志和导出数据；
• 服务中断、供应商退出或账号被盗时怎样停用；
• 移除 App 后，工单、FAQ、日志和权限怎样迁移或删除。

不要为了一个欢迎消息给 Bot Administrator。安装和更新后都要复查 Role 层级、私密频道可见性、Webhook、Token 与审计记录。离职或供应商更换时，要撤销个人账户、Bot、API 和第三方后台权限。