?
提问：把卡住的地方说清楚
遇到问题时先检索，如果已有帖子没有覆盖你的情况，就把问题整理成可以复现的样子。 描述清楚系统与版本、配置片段、期望结果与实际结果——这三样齐了，回复质量会明显不同。
3种参与方式：提问 / 分享 / 整理
定期精华内容沉淀归档，可长期查阅
官方维护人员同步动态、回应关切
友善理性讨论，不嘲讽、不贬低
Three Spaces
社区里有三种典型的参与方式
不必一开始就想清楚「我能贡献什么」。从提问开始，慢慢就过渡到分享， 再到帮别人整理——这是大多数人的路径。
✎
分享：把自己跑通的方案放上来
你为特定场景写过的规则、调试过的策略组结构、整理过的域名清单， 很可能正好是别人需要的。不必追求大而全，把一个具体问题解决好，就值得分享。
◎
整理：把散落的讨论沉淀下来
社区里的优质内容会被定期归档成精华合集。整理者做的不是原创， 而是把散落的讨论收拢成可查阅的文档——这份工作同样重要。
i
三种参与方式没有高下之分。提问也是在为社区做贡献—— 一个好问题往往能暴露出文档或规则里没有覆盖的地方，让后面的人受益。不必因为「只是来问问题」而感到不好意思。
Before Asking
提问前，先做好这三步
这不是为了设置门槛，而是为了让你的问题更容易被准确回应。 大多数「没人回复」的情况，原因是信息不够，而不是社区不友好。
02
把问题整理成可以复现的样子
说明系统与客户端版本、附上出问题相关的配置片段、 写清楚期望结果与实际结果。如果有日志，贴出相关的那几行——不必贴全部。
03
用一句话说清楚你想解决什么
标题尽量具体，比如「某站点在规则模式下超时，其他站点正常」， 比「不生效」更容易被人一眼看懂。正文里再展开细节。
Template
一份提问模板，可以照抄
下面这份模板覆盖了排查所需的基本信息。复制过去填上自己的内容， 比从零组织语言要快得多。
# 提问模板
系统：Windows 11 / macOS 14 / Android 14
客户端：v0.20.6
模式：rule
问题：
访问 example.com 时超时，其他站点正常。
期望结果：
example.com 走 PROXY 策略组，正常打开。
实际结果：
连接记录显示命中 REJECT，请求被拦截。
相关配置：
rules:
- DOMAIN-KEYWORD,ads,REJECT
- DOMAIN-SUFFIX,example.com,PROXY
# 已尝试：把 example 规则上移一位，问题依旧
!
记得隐去敏感信息。订阅地址、节点密码、私有域名这些内容在公开之前先做替换或删减。 保留复现所需的部分即可，不必把完整配置贴出来。
Good vs Bad
什么样的提问更容易得到回应
下面的对照并不是要批评谁，而是把「有效信息」和「无效信息」分开来看。 两边的差距通常只在几句话上。
✓
更容易得到回应的写法
- 标题具体：「某站点在规则模式下超时，其他站点正常」
- 附上版本、系统、模式这三项基本信息
- 贴出相关规则片段，而不是整份配置
- 说明已经尝试过什么，避免重复建议
- 区分期望结果与实际结果
- 有人回复后及时反馈结果是否解决
✕
容易被跳过的情况
- 标题只有一句「不生效」「怎么办」
- 不说明版本与系统，只描述模糊现象
- 贴出整份配置，让人自己找问题在哪
- 反复追问「有人吗」，却不补充信息
- 描述成「就是不行」，没有具体现象
- 得到回复后不再回应，讨论无法闭环
问问题不是示弱，
把问题问清楚才是本事
把问题问清楚才是本事
社区里没人会因为你不懂某个概念而轻视你。真正被尊重的是把问题整理清楚的努力—— 那是对回答者时间的尊重，也是对自己的尊重。
Community Rules
社区倡导的几条基本规范
规则不多，核心只有一条：把讨论引向解决问题，而不是证明谁更懂。
1
Be Kind
友善理性
不嘲讽、不贬低、不使用侮辱性表达。即使对方的理解有明显偏差， 也可以指出问题所在，而不是评价对方的能力。
2
Search First
先查后问
提问前先检索精华帖与文档。这不是强制要求，但能显著提升你得到有效回复的概率—— 也避免同一个问题被反复回答。
3
Answer Clearly
回答清晰易懂
回答时尽量把「为什么这样做」讲清楚，而不只是给一个结论。 如果涉及多种方案，说明各自的适用场景与限制。
4
Respect Choices
尊重不同选择
每个人使用的系统、场景、配置习惯都不同。适合你的方案不一定适合别人， 讨论时说明适用条件比断言「哪个更好」更有帮助。
5
Verify First
不传播未经验证的内容
分享配置或规则前先自己跑通。把「我听说的」当成「已验证的」分享， 可能会给别人带来额外排查成本。
6
Protect Privacy
隐私优先
分享配置、日志或截图时，隐去订阅地址、节点信息、私有域名等敏感内容。 这是对自己的保护，也是对他人的尊重。
Official Role
官方维护人员在社区里做什么
日常问答主要由社区成员互助完成，官方侧重处理影响面较大、反复出现的问题。 两者分工明确，避免让官方回应成为解决问题的唯一路径。
◎
定期同步与集中回应
官方维护人员会定期在社区同步项目动态、回应集中关切、收集共性需求。 下面的几件事是他们的主要职责。
- 同步版本动态：新版本发布时说明变更内容与影响范围，更新日志同步维护
- 回应集中关切：当某个问题在社区里被反复提及时，官方会给出统一说明，避免重复解释
- 收集共性需求：把社区里反复出现的功能建议整理成需求清单，纳入版本规划参考
- 维护归档索引：协助整理精华帖，让优质内容更容易被后续使用者找到
- 处理影响面较大的问题：涉及全平台、安全性或结构性变更的问题，官方优先跟进
i
官方不代替社区回答问题。大多数具体配置问题由社区成员互助解决， 官方角色更像是动态同步与需求收集的窗口。遇到问题时，先和社区里的其他使用者交流，往往更快。
Archive
优质内容会被沉淀下来
社区讨论的价值不应随着帖子沉下去而消失。定期整理归档，让后来的人还能找到。
Step 01
讨论在社区里自然发生
一个具体问题被提出来，几位有经验的成员从不同角度给出看法。 讨论过程中可能产生多种方案，各有适用条件。
Step 02
定期整理，把结论收拢
整理者把讨论中的有效信息提炼出来：问题描述、排查过程、最终方案、已知限制。 去掉中间的试错和重复，留下可复用的部分。
Step 03
归档成精华，保留署名与出处
归档内容会标注原作者与讨论链接。如果参与者不希望被归档，可以在分享时说明， 整理者会相应处理。
Step 04
后续更新时回溯修订
当版本变化导致原方案不再适用时，归档内容会被标注或更新。 这样沉淀下来的内容不会变成误导后人的过时信息。
常见问题聚合
基础疑惑集中解答
把新手反复遇到的基础问题收拢成一篇，减少重复回答，也方便新人自查。
方案对照
同类问题的多种解法
把同一类场景下不同成员提出的方案并列展示，说明各自的适用条件与取舍。
规则模板库
可直接取用的配置片段
按用途分类整理规则片段，注明适用范围与更新方式，取用后自行替换关键字段。
沉淀的意义在于让经验可以继承。
一个人踩过的坑，被整理成可查阅的内容之后，后面的人就不必再踩一遍。
社区真正的价值，不在于讨论了多热烈，而在于留下的东西能不能被反复用上。
Boundaries
关于社区，几点需要说清楚的
把边界讲明白，比笼统地承诺「热心互助」更有用。
◐
回复不一定及时
社区成员都是自发参与，没有人有义务在固定时间内回复你。 把问题描述清楚、保持耐心，比反复催促更有效。
◑
答案需要自己验证
社区里给出的方案基于他人经验，不一定完全适用于你的场景。 采纳前先在自己的设备上验证，特别是涉及规则和策略调整的部分。
◒
不处理节点相关问题
项目不提供节点，社区也无法帮你判断某个订阅是否可靠。 节点质量、订阅更新失败这类问题，建议联系对应服务方。
!
社区是公共空间，不是客服通道。在这里提问，得到的是其他使用者的经验分享。 如果你需要的是有保障的响应时间与处理流程，那么社区并不是最合适的渠道。
Q & A
关于社区参与，常被问到的几件事
提问之前应该先做哪些准备？
先查阅精华帖与官方文档，确认问题不在已有内容里；再整理清楚三件事：系统与客户端版本、出问题的配置片段、期望结果与实际结果。把这三样准备好，得到有效回复的概率会显著提高。
什么样的分享更容易被采纳？
有具体场景、有可复现的配置片段、有清晰说明的分享更容易被采纳。与其只贴一段配置，不如说明「这个方案解决了什么问题、适用什么场景、有哪些已知限制」。
社区会保存我分享的内容吗？
优质内容会定期整理归档，形成可查阅的精华合集。归档时会保留原作者的署名与出处，若你希望内容不被归档，可以在分享时说明。
官方人员会回应社区的问题吗？
会。官方维护人员定期同步项目动态、回应集中关切、收集共性需求。但日常问答主要由社区成员互助完成，官方侧重处理反复出现、影响面较大的问题。
社区对提问和回答有什么基本要求？
提问前先检索，描述时尽量具体；回答时清晰易懂、尊重他人，避免嘲讽或贬低。讨论以解决问题为目标，而不是证明谁更懂。
可以分享自己的规则或配置吗？
可以。整理成独立文件、写明适用范围与更新方式即可分享。涉及个人环境、内部域名或私有地址的内容，在公开之前请确认其中不包含不希望对外披露的信息。
Next
想先自己看看，从这几页入手
如果暂时不想在社区里发帖，站内也有几处可以自查的地方。
◫
先看基础问答
去「常见问答」页。是什么、怎么装、快速上手、常见误区， 入门阶段的问题基本都在那里。
✎
想自己写规则
去「分流规则」页。YAML 的三段式写法、常见匹配类型、注释与分组维护的思路， 参照模板就能改出第一条属于自己的规则。
⇅
想找现成的资源
去「社区生态」页。规则集、订阅模板、插件脚本、界面面板， 以及怎么判断一份资源是否还在维护，都整理好了。
◎
想了解项目本身
去「项目介绍」页。那里说明了项目坚持什么、拒绝什么， 以及为什么强调透明与可控。
社区不是文档的替代品，而是文档的补充。
文档解决共性问题的「标准答案」，社区处理具体场景里的「实际情况」。
两者互相补位，遇到问题时先看文档、再问社区，是效率最高的路径。