Ant Design Issue 回复技能（issue-reply）详解：面向维护者与 AI Agent 的 Issue 处理规范及仓库自动化佐证

本篇基于 Ant Design 仓库中 .agents/skills/issue-reply/SKILL.md 及其配套参考文档 labels-and-resources.md 展开，完整解读该项目为「回复 GitHub Issue」这一维护动作制定的 Skill 规范：首次回复的准入条件、语言判断策略、Bug 与功能请求的分类方法、dosubot 等 AI 助手的协作方式、关闭 Issue 的红线与两阶段确认流程。读完本文，你可以既按规范手动处理 Issue，也能理解这些规则在仓库 GitHub Actions 工作流中的自动化落地方式，并了解如何以同样的两阶段流程驱动 AI Agent 代你完成 Issue 巡检与回复。

一、技能定位：issue-reply Skill 在仓库中的位置

该规范以 Agent Skill 的形式存放在 .agents/skills/issue-reply/ 目录下，采用「一个主文件 + 一个 references 子目录」的结构：

• SKILL.md：技能主体，包含全部处理规则、判断流程与交互约定；
• references/labels-and-resources.md：标签速查表、FAQ 资源、重现模板与 Issue 创建规范，供处理过程中按需查阅。

SKILL.md 的 YAML frontmatter 定义了技能名与触发描述：

name: antd-issue-reply
description: Help maintainers reply to Ant Design GitHub issues following official guidelines. ...

其中 description 明确列举了触发场景：当用户要求处理、回复、检查或管理 ant-design 仓库的 issues，或在 antd 语境下提及 "issue" 时启用该技能。它还提供了一组能力边界：对 Issue 分类（Bug vs Feature Request）、处理 dosubot 回复、使用正确标签、撰写礼貌回复、判断何时关闭 Issue。

从源码结构看，该技能并非孤立存在。.agents/skills/ 目录下并列存放了 changelog-collect、commit-msg、create-pr、test-review、version-release 等多个技能，与 AGENTS.md、CLAUDE.md 中为 AI 编程助手编写的项目上下文（组件目录结构、PR 规范、Changelog 规范等）共同构成了一套「AI 协作者工作手册」。issue-reply 正是这套体系中负责维护者侧社区沟通的模块。

二、目标与核心原则

规范开篇给出两个明确目标：

1. 保持社区活跃——让用户反馈被及时响应，提升用户参与感和满意度；
2. 提高处理效率——减少 open issues 和重复 issues，保持 issues 区整洁有序。

并强调一条贯穿全文的核心原则：

开源项目的用户和维护者之间并不是甲方和乙方的关系，issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。

这条原则直接约束了后文的语气要求、引导式提问策略，以及「确认已有能力后不直接否定用户」这类具体话术。

三、基本规则：何时回复、何时跟进

首次回复的准入条件

对满足以下所有条件的 issue 进行首次回复：

1. Issue 状态为 open；
2. 没有人类维护者（MEMBER/OWNER/CONTRIBUTOR）回复过。

检查已回复的 Issues

对于已有 MEMBER/CONTRIBUTOR 回复的 issue，也要检查是否处理妥当。需要关注的三种情况：

1. 维护者已提出问题或解决方案，但用户**长时间（7 天以上）**未回复；
2. 问题已明确被解决（用户确认或版本已修复）；
3. 维护者已说明这不是 bug，但 issue 仍然 open。

对应处理方式：

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

一个重要的注意点：Inactive 标签只表示近期无活动，不代表已解决，带该标签的 issue 仍可回复。这一点与仓库的自动化行为一致——后文会看到 Inactive 标签由定时任务按 30 天无活动自动打上，它只是「冷却」信号，不是「结案」信号。

四、语言政策：必须严格执行

回复语言是规范中要求最严格的环节，判断规则只有一条：只看 issue body 原始内容，忽略后续评论中使用的语言。

规范给出的判断流程：

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

文档同时列出了常见误区与示例，避免执行者被模板和机器人语言干扰：

• ❌ 不要因为 issue-helper 模板是中文就用中文回复（Issue 助手生成的模板本身是中英双语骨架，不代表作者语言）；
• ❌ 不要因为后续评论使用了某种语言就跟随；
• ❌ 不要因为 dosubot 使用了某种语言就跟随；
• ✅ 只看 issue 作者在 body 中描述问题时使用的语言。

示例：

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

正确做法 → 用英文回复

最后附一条态度要求：即使面对语气不太好的用户，也要保持友善和耐心。

五、Issue 类型与替代渠道

Issue 列表主要用于跟踪 Bug 报告 和 功能请求 两类问题。对于「使用问题」，规范建议优先引导至以下渠道（参考文档中给出的链接为官网 FAQ、StackOverflow 的 antd 标签与 SegmentFault 的 antd 话题，此处仅列渠道名称以避免外链）：

• Ant Design 官网「常见问题」文档；
• StackOverflow（英文）；
• SegmentFault（中文）。

这一分流策略的目的是把 issues 区聚焦在真正需要维护者介入的 Bug 与新能力上。

六、Issue 分类处理

Bug 报告

处理顺序是「先查版本，再查重现」：

首先检查版本：

• 用户停留在老版本，且 changelog 中显示该问题已修复 → 引导用户升级验证；
• 修复 PR 已合并但新版本尚未发布 → 告知用户等待新版本发布。

检查重现链接：

• 缺少或链接与问题无关 → 添加 🤔 Need Reproduce 标签，请求提供；
• 有可运行重现且确认是 bug → 添加 🐛 Bug 标签。

功能请求

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

规范进一步要求：处理功能请求时，先排查现有能力再讨论新增，并给出四条可操作的原则：

1. 先查现有 API——用户提需求时常因「找不到」而误以为「没有」。收到 feature request 时，第一反应应是「我们是不是已经有这个了」，而非「怎么实现它」。应搜索相关组件的 props、文档与已有 issue，确认未被现有功能覆盖。
2. 关注命名可发现性——如果功能已存在但用户找不到，问题本质不是缺功能，而是 API 可发现性差。此时应向用户指出已有 API 并附代码示例；同时反思文档是否需要补充搜索关键词或交叉引用（例如用户搜 mapping 但 API 叫 fieldNames，文档中应把这两个词关联起来）。
3. 检查跨组件一致性——用户会从一个组件的 API 类推另一个组件。同一概念在不同组件使用不同命名（如 Table 的 rowKey 与 Select 的 fieldNames）会制造认知负担。发现用户因跨组件命名不一致而困惑时，应记录下来作为后续 API 一致性优化的参考。
4. 用提问引导而非否定——确认已有功能后，不要直接说「我们已经有这个了」然后关闭 issue。用提问式引导让用户自己确认：「看描述这个需求好像可以用 fieldNames 实现，是我理解的不对吗？」——既帮用户解决问题，又保护了用户面子；用户确认后再关闭。

使用问题

规范明确：你可以尝试直接解决和回复使用问题——

• 查阅文档，提供解决方案和代码示例；
• 如果能解决，直接回复帮助用户；
• 如果用户描述的问题其实是现有 API 已覆盖的场景，用提问式引导：「这个需求看起来可以用 xxx prop 实现，是我理解的不对吗？」——比直接甩文档链接更友好。

同时可以引入 AI 帮助解答，规范列出了两个 GitHub 上的助手：@docu（GitHub Copilot 文档助手）与 @Copilot（GitHub Copilot）。回复示例模板：

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

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

参考文档：官网对应组件文档页

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

若无法解决，则按第五节所述引导用户到常见问题、StackOverflow 或 SegmentFault 等其他渠道。

FAQ 问题

查找资源遵循固定顺序：

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

Bug vs Feature Request 分类判定

类型	特征
Bug	使用现有功能，行为不符合预期；之前正常现在坏了
Feature Request	需要目前不存在的新能力

规范给出的示例：

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

兜底规则：不确定时归类为 Bug。这符合「谨慎关闭、宁可多排查」的整体基调。

七、处理 dosubot 回复

当仓库的 dosubot 机器人已经回复过某 issue 时，规范给出了三步审核流程：

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

一个细节要求：mention 机器人时使用 @dosu，而非 @dosubot。

八、处理重复 Issues

三步固定动作：

1. 找到原始 issue；
2. 回复「Duplicate of #xxxx」；
3. 关闭 issue。

九、关闭 Issues：可关与不可关的边界

关闭是风险最高的操作，规范单独成章并要求谨慎。

关闭前必须检查：

1. ⚠️ 确认使用正确的语言（参照第四节语言政策）。

可以关闭的情况：

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

不要关闭的情况：

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

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

十、禁止承诺

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

这条规则与仓库中另一技能 changelog-collect 的发布纪律一致：changelog 由 release owner 在发布流程中统一整理，任何人在 issue 中的口头承诺都不构成版本计划的一部分。

十一、何时不回复

三种情况应保持沉默：

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

十二、检查已回复 Issues 的判定流程

规范以决策树形式给出了对「已有维护者回复的 issue」的完整检查流程：

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

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

该流程与第九节的关闭规则、第四节语言政策形成闭环：任何「可关闭」分支都必须先过语言检查。

十三、语气和风格

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

十四、交互流程：先草拟、后确认的两阶段模式

当用户（维护者）要求 AI 处理 issues 时，规范强制采用两阶段流程，核心原则是：先草拟完整方案，等用户讨论确认后再执行，不要未经确认就回复或关闭 issue。

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

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

第二阶段：讨论和确认

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

这一设计本质上把 AI Agent 的副作用操作（评论、打标签、关闭）全部收敛到「人类确认」之后，与仓库中 AGENTS.md「编码行为准则」里「先思考再编码」「精准改动」的谨慎基调一脉相承。

十五、标签与资源体系（references 配套文档）

labels-and-resources.md 为上述规则提供了配套速查表，核心是常用标签表：

标签	用途
🐛 Bug	已确认的 bug
🤔 Need Reproduce	缺少重现链接或无法复现
💡 Feature Request	功能请求
❓FAQ	常见问题
help wanted	欢迎社区贡献
good first issue	适合首次贡献者
unconfirmed	需要更多信息或验证
improvement	改进建议
Inactive	近期无活动（不代表已解决）

参考文档还整理了三类资源：

• FAQ 资源：带 ❓FAQ 标签的 Issue 列表、官网常见问题汇总、更新日志，以及组件级 FAQ（如 Form FAQ、Table 虚拟滚动、国际化、主题定制）；
• 重现模板：CodeSandbox 与 StackBlitz 上的 antd 重现模板（用于请求用户 fork 后提交最小重现）；
• Issue 规范：所有 issue 应通过官网的 new-issue 助手页面创建；Bug 报告必须包含重现链接；功能请求需要描述使用场景和期望的 API。如果用户没有通过规范渠道创建 issue，但内容完整有效，无需强制关闭，可以正常处理。

十六、仓库侧的自动化佐证：规则背后的 GitHub Actions

issue-reply 规范中反复出现的「3 天」「7 天」「30 天」等时限并非凭空约定，仓库的 .github/workflows/ 目录下存在一组 issue 治理工作流，为这些规则提供了自动执行与兜底，可以逐条对照印证：

工作流	触发时机	行为	对应规范条款
issue-open-check.yml	issue 被创建	先给新 issue 添加 unconfirmed 标签；若 body 不含 issue-helper 标记且用户无 write 权限，则打上 Invalid 标签、留言并以「不符合格式要求」为由自动关闭；对官网访问类标题做镜像站点指引；对 IE9/IE10 报告直接说明 v4 支持范围并关闭	「unconfirmed 需要更多信息或验证」；Issue 规范中「必须通过 issue 助手创建」
issue-labeled.yml	打标签事件	打 🤔 Need Reproduce 时自动留言，要求 fork 在线重现模板或按脚手架指南建最小仓库，并告知「3 天内未跟进将被自动关闭」；打 help wanted 时引导提交 PR；打 Usage/Question 时引导至问答渠道并关闭	第六节「缺少重现链接 → 加 🤔 Need Reproduce」
issue-close-require.yml	每天定时	对 🤔 Need Reproduce 与 needs-more-info 标签的 issue，3 天无活动自动关闭并中英双语留言	第九节「用户长时间未回复（7 天以上）→ 关闭」的更严格自动版（重现类问题 3 天即关）
issue-inactivity-reminder.yml	每天定时	对超过 14 天无活动、且未关联 PR 的 issue 发送提醒（通过 timeline 判断是否有 linked PR）	「等待用户反馈」状态的自动化催办
issue-check-inactive.yml	每 15 天定时	30 天无活动的 issue 打上 Inactive 标签	「Inactive 标签只表示近期无活动，不代表已解决」
issue-schedule.yml	每天定时 + 手动触发	检索超过 7 天仍未确认（unconfirmed 标签）的 issue，汇总推送到维护者群（钉钉机器人）	「用户长时间（7 天以上）未回复」的人工跟进时限

此外，.github/ISSUE_TEMPLATE/config.yml 声明了 blank_issues_enabled: true 并只提供指向 issue 助手的 contact link，明确告知「未通过助手创建的 issue 将被机器人自动关闭」——这正是 issue-open-check 工作流执行 Invalid 关闭的判断依据。

对照后可得出结论：Skill 规范中的判断时限（7 天回复窗口、3 天重现窗口、30 天 Inactive 窗口）与自动化流水线形成「人工按规范判断 + 机器按时限兜底」的双层结构。维护者（或受其驱动的 AI Agent）在人工层面可以提前介入，但不必焦虑于漏处理——超时问题最终会被定时任务收敛，这也解释了为什么规范敢放心地让「其他情况 → 跳过」。

十七、适用前提与限制

• 本规范适用于 Ant Design 主仓库的 GitHub issue 维护场景，且假定操作者具备 issue 的评论、打标签、关闭权限（工作流中均以 issues: write 权限运行）；
• 语言判断、分类与关闭等规则依赖 issue body 的结构化程度，issue 助手模板产出的 issue（含 "What is expected?" / "What is actually happening?" 小节）是语言判断的最佳输入；非模板 issue 应退化为看作者 body 的实际书写语言；
• 两阶段交互流程预设了 gh CLI 可用（gh issue list 拉取列表）以及操作者与仓库的认证关系；
• 规范中的渠道名称（官网 FAQ、StackOverflow、SegmentFault、new-issue 助手）与参考文档中的具体 URL 以 labels-and-resources.md 原文为准，本文按规范不重复罗列外链。

十八、小结

issue-reply Skill 的价值在于把「如何回复一个社区 Issue」这件依赖个人经验的维护工作，拆成了可检查的决策点：准入条件（第三节）、语言判断（第四节）、分类（第六节）、AI 协作审核（第七节）、关闭边界（第九节）、判定流程（第十二节）与两阶段执行（第十四节），并通过配套的标签表和仓库自动化工作流（第十六节）让每一条规则都有落点。对于其他开源项目，这套「Skill 文档 + references 速查表 + Actions 兜底」的组合方式本身就是一个可直接借鉴的 issue 治理模板。