提供以帖子为单位留下反馈并确认进展上下文的公告板

用有标题和正文的帖子形式代替简短询问表单留下反馈，可以在列表和详情页面重新确认内容。

产品改进请求很多时候仅靠一句话难以理解原因和期待结果。为了能同时留下使用环境、重现过程和期待的动作，将/feedback以公告板形式提供。

好的反馈不是简短收集不满，而是留下可以重新确认问题发生上下文的记录。

本次更新的变化

• 可以编写反馈标题和详细正文。
• 可以在列表中重新找到编写的反馈并确认详细内容。
• 可以具体留下错误报告、功能请求和使用体验，不混在一句话中。
• 介绍了运营者需要确认的信息和不应公开的信息。
• 为今后更明确地提供回复和处理状态奠定了基础。

用户确认的方法

1. 在/feedback搜索已有帖子确认是否有相同问题。
2. 编写能了解问题类型的标题。
3. 在正文中区分编写发生环境、重现顺序、实际结果和期待结果。
4. 去除个人信息、令牌和非公开对话原文后注册。

实际使用流程中的示例

例如用户确认当前改进状态时，在/feedback搜索已有帖子确认是否有相同问题。编写能了解问题类型的标题。之后去除个人信息、令牌和非公开对话原文后注册。在此过程中不应将以下范围与当前完成状态混淆。公告板注册不保证立即修复或实现。这样确认就能将已提供的功能和仍在稳定化中的部分分离理解。

区分变更前后

改进前当前提供的范围和仍在稳定化中的部分可能在一句话中混合显示。本次整理中用有标题和正文的帖子形式代替简短询问表单留下反馈，可以在列表和详情页面重新确认内容。已提供的功能原样保留，仅单独说明改进对象，让用户不带夸张地理解当前状态。

适用范围和注意事项

• 公告板注册不保证立即修复或实现。
• 不应在公开帖子中包含账户密码、认证令牌和个人对话原文。
• 反馈数量不自动决定优先级，危险度和契约影响同时审查。
• 支付·认证·数据问题比一般功能请求需要单独的验证程序。

在5BY.AI整体结构中本次变更重要的原因

反馈公告板不是将用户意见分数化的功能，而是防止产品失去实际使用上下文的记录渠道。积累可以重现问题的信息后，可以基于证据而非推测找到最初不一致的边界。

确认本次更新的标准

• 不应将改进中的范围和已稳定提供的范围在同一句话中混合。
• UI和Provider兼容性改进不改变记忆Core的存储单位和用户选择契约。
• 未完成的项目不应表述为当前提供功能，应在后续更新中更新状态。

相关页面

• 反馈公告板
• 社区
• 问题解决指南