> For the complete documentation index, see [llms.txt](https://docs.mojo.trade/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mojo.trade/zh/feng-bi-ce-shi-zhi-nan/fan-kui-yu-zhi-chi.md).

# 反馈与支持

封闭测试的目的，是让我们向你学习。把一切都告诉我们——哪些好用，哪些让人困惑，哪些有问题，哪些还缺失。

***

### 联系渠道

**Telegram 群组** — <https://t.me/mojoaihq>

这是封闭测试期间的主要沟通渠道。整个团队都在里面，会阅读每一条消息。Bug 报告、问题、功能请求、"等等，Mojo 还能做这个吗？"——这些都发到这里。

***

### 一份出色的 Bug 报告要包含什么

如果你能包含以下任意内容，我们会更快定位并修复：

1. **你当时想做什么** —— 用你自己的话描述你的意图
2. **你原本预期会发生什么**
3. **实际发生了什么**
4. **它发生在什么时候** —— 大致时间 + 所在平台（Hyperliquid / 链上现货 / Polymarket）
5. **截图或屏幕录制** —— 哪怕是一张手机屏幕的快速拍照也有帮助

别让“完美”成为“已发送”的敌人。哪怕只发两行，写着 *“我的多步骤 ETH 策略在 UTC 14:30 左右停止响应了，这是截图”* 也远比一份我们从未收到的精美报告更有用。

***

### 我们最希望看到什么

Bug 报告很重要。但测试阶段最有价值的反馈，往往是那些你根本不会特意写下来的东西：

* **你想构建却不知道该如何表述的策略**
* **你尝试某件事时，突然冒出的那一刻&#x20;*****“等等，它真的这么做了？”***
* **你以为 Mojo 会做、但它没做成的事**
* **Mojo 本可以解决、但尚未解决的工作流摩擦**

都发给我们。半成型的想法也没关系。你的“如果 Mojo 能……”想法越大胆越好。

***

### 我们会如何处理你的反馈

* **Bug** 会每天分流处理。严重问题会立即处理。
* **产品反馈** 会由团队每周审阅。信号最强的条目会直接影响路线图。
* **功能请求** 会被跟踪并归类。我们不会做出所有功能，但我们一定会告诉你我们在做什么，以及为什么。

第一批封闭测试用户将对 Mojo 的最终形态产生远超常人的影响。我们特意把群组保持得很小，就是为了让每一种声音都能被听见。

如果你告诉我们某件事很重要，它就会被讨论。如果你发现某处有问题，它就会被修复。 **感谢你在一开始就来到这里。**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mojo.trade/zh/feng-bi-ce-shi-zhi-nan/fan-kui-yu-zhi-chi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.