Ant Design Issue 回复规范

• 用户长时间未回复 → 关闭 issue 并留言说明
• 问题已解决 → 关闭 issue
• 使用问题但已提供解决方案 → 关闭 issue

注意： Inactive 标签只表示近期无活动，不代表已解决，仍可回复。

⚠️ 语言政策（必须严格执行）

判断规则：只看 issue body 原始内容，忽略后续评论中使用的语言

判断流程：
1. 查看 issue 的原始 body（第一个帖子内容）
2. 检查 "What is expected?" 和 "What is actually happening?" 部分的语言
3. 如果是英文 → 用英文回复
4. 如果是中文 → 用中文回复

常见误区：

• ❌ 不要因为 issue-helper 模板是中文就用中文回复
• ❌ 不要因为后续评论使用了某种语言就跟随
• ❌ 不要因为 dosubot 使用了某种语言就跟随
• ✅ 只看 issue 作者在 body 中描述问题时使用的语言

示例：

Issue body:
  "What is expected?" → "22.01.2026"  (英文)
  "What is actually happening?" → "dont work datepicker..." (英文)

正确做法 → 用英文回复

保持友善和耐心，即使用户语气不太好。

Issue 类型

Issue 列表主要用于跟踪 Bug 报告 和 功能请求。

使用问题的建议渠道：

• 常见问题
• StackOverflow（英文）
• SegmentFault（中文）

处理 dosubot 回复

如果 dosubot 已经回复过：

1. 审核回复的准确性
2. 正确 → 确认背书："感谢 @dosu 的分析，确认这是正确的解决方案。"
3. 不正确 → 提供更正："感谢 @dosu，但需要补充说明..."
4. 完整正确 → 无需额外回复

使用 @dosu（而非 @dosubot） mention 机器人。

Issue 分类处理

Bug 报告

首先检查版本：

• 老版本 + changelog 中已修复 → 引导用户升级验证
• PR 已合并但新版本未发布 → 告知用户等待新版本发布

检查重现链接：

• 缺少/无关 → 添加 🤔 Need Reproduce，请求提供
• 有重现 + 确认 bug → 添加 🐛 Bug 标签

功能请求

• 添加 💡 Feature Request 标签
• 描述模糊 → 询问使用场景和期望 API

使用问题

你可以尝试解决和回复使用问题：

• 查阅文档，提供解决方案和代码示例
• 如果能解决，直接回复帮助用户

也可以引入 AI 帮助解答：

• @docu - GitHub Copilot 文档助手
• @Copilot - GitHub Copilot

回复示例：

感谢反馈！这是一个使用问题，让我尝试帮你解答：

[提供解决方案和代码示例]

参考文档：https://ant.design/components/xxx

如果以上方案不能解决问题，可以尝试 @dosu 或 @Copilot 获取更多帮助。

若无法解决，引导用户到其他渠道：

• 常见问题
• StackOverflow 或 SegmentFault

FAQ 问题

查找资源顺序：

1. 带 ❓FAQ 标签的 issues
2. 组件文档 FAQ 部分
3. 常见问题汇总

Bug vs Feature Request 分类

示例：

• Cascader onFocus 不触发 → Bug（现有功能不工作）
• 添加 DatePicker 键盘导航 → Feature Request（新能力）

不确定时归类为 Bug

处理重复 Issues

1. 找到原始 issue
2. 回复："Duplicate of #xxxx"
3. 关闭 issue

关闭 Issues（需谨慎！）

关闭前必须检查：

1. ⚠️ 确认使用正确的语言（参考语言政策）

可关闭：

• 重复问题
• 确定不是 bug（使用问题）
• 已解决
• 用户长时间未回复（7天以上）

关闭时保持礼貌，简要说明关闭原因即可。

不要关闭：

• 不确定是否是 bug
• 用户未确认解决方案有效（且未超过等待时间）
• 有效的功能请求
• 正在活跃讨论中的 issue

禁止承诺

• ❌ 不要承诺发布日期
• ❌ 不要说"我们会添加这个功能"
• ✅ 应该说："这是一个合理的需求，我们会考虑。欢迎社区贡献。"

何时不回复

• dosubot 已提供完整正确答案
• 无法确定正确的回复内容
• Issue 正在活跃讨论中

检查已回复 Issues 的流程

对于已有维护者回复的 issues，按以下流程检查：

1. 确认回复语言正确（⚠️ 只看 issue body 原始语言）

2. 查看维护者的最后一条评论
   ├─ 是提问/请求更多信息？
   │   └─ 用户是否超过 7 天未回复？
   │       ├─ 是 → 检查语言 → 关闭 issue 并留言
   │       └─ 否 → 跳过
   ├─ 是说明解决方案？
   │   └─ 用户是否确认解决？
   │       ├─ 是 → 检查语言 → 关闭 issue
   │       └─ 否，且超过 7 天 → 检查语言 → 关闭 issue 并留言
   └─ 其他情况 → 跳过

语气和风格

• 保持友善、耐心和专业
• 尽可能提供代码示例
• 引用文档链接
• 对新人友好，鼓励社区参与

交互流程

当用户要求处理 issues 时，采用「先草拟、后确认」的两阶段流程：

第一阶段：总览 + 草拟方案

1. 使用 gh issue list 拉取指定范围的 open issues
2. 对每个 issue 获取详情（body、comments、labels）
3. 对每个 issue 给出处理方案，包括：
   • 分类（Bug / Feature Request / 使用问题）
   • 当前状态（无人回复 / 维护者已回复 / 等待用户反馈 等）
   • 处理建议（需要回复 / 可以关闭 / 无需操作 / 等待中）
   • 如果需要回复：草拟回复内容（含语言判断、正文、代码示例）
   • 标签操作（添加/移除哪些标签）
   • 是否关闭 issue
4. 将所有方案一次性呈现给用户，不要直接操作

第二阶段：讨论和确认

1. 用户可以对任意 issue 的方案提出修改意见
2. 根据反馈调整方案，直到用户满意
3. 用户确认后执行操作（评论、加标签、关闭等）
4. 如果用户说「就这样」或类似确认，直接执行

关键原则：先草拟完整方案，等用户讨论确认后再执行。不要未经确认就回复或关闭 issue。

参考资源

详细标签列表和资源链接请参阅 references/labels-and-resources.md