Community Desk
把问题分流、协作入口和更新追踪放到同一个工作台里。
社区页不该只是入口合集。这里优先回答三件事：你现在该去哪里、怎样提问更容易被处理、以及在 FAQ、搜索、路径和专题都不够时该怎样继续往下走。
资料优先问题还不清先查 FAQ、路径和文档
问题公开化可复现 bug 优先进入 GitHub
持续更新新闻页与 RSS 承接长期追踪
Priority Routes
先选正确入口，再开始沟通。
Triage Flow
遇到问题时，按这个顺序判断。
先判断问题属于哪一层
产品能力、使用方法、站点内容、还是代码级 bug。先分层，才能走对入口。
再决定是否需要公开追踪
需要复现、协作、补日志和后续回溯的，放到 GitHub；只涉及中文站内容时走站内反馈。
最后补齐上下文
带上版本、页面路径、错误信息、复现步骤或预期行为，能显著减少来回沟通。
Quick Map
常见场景对应入口
先建立背景，再决定是否继续提问。
适合错别字、结构建议、缺图、链接错误。
适合公开跟踪和补充复现信息。
适合版本变化、能力更新、里程碑追踪。
Contribution
如果你想参与建设，优先做这些事。
内容修订
纠正表达、补充案例、优化阅读路径，让中文资料更稳定。
从反馈或文档页开始问题归档
把零散的使用问题整理成 FAQ、最佳实践或更清晰的 Issue。
优先形成可复用的问题描述能力验证
围绕安装、渠道接入、运维、安全等主题补充真实使用反馈。
用实践案例提升文档可信度Status
中文社区当前状态
交叉访问
社区页负责分流，真正处理问题还要回到对应承接页。
FAQ
把最容易重复的问题先说清楚。
我第一次接触 OpenClaw，应该从哪里开始？
先看文档首页和快速开始，再进入安装、功能手册或 FAQ。这样提问时上下文会更完整。
我发现的是中文站问题，不是 OpenClaw 本身的问题，发哪里更合适？
直接走站内反馈。这样能更快区分是内容修订、结构优化还是页面 bug。
什么情况下应该直接去 GitHub Issues？
当问题需要复现、公开讨论、附日志或长期跟踪时，GitHub Issues 比私下反馈更合适。
现在有独立的中文社区群吗？
当前仍以 GitHub 和站内反馈为主。中文社区入口会随着内容与协作机制成熟逐步补充。