Ant Design Issue 回复技能issue-reply详解面向维护者与 AI Agent 的 Issue 处理规范及仓库自动化佐证【免费下载链接】ant-designAn enterprise-class UI design language and React UI library项目地址: https://gitcode.com/GitHub_Trending/an/ant-design本篇基于 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 正是这套体系中负责维护者侧社区沟通的模块。二、目标与核心原则规范开篇给出两个明确目标保持社区活跃——让用户反馈被及时响应提升用户参与感和满意度提高处理效率——减少 open issues 和重复 issues保持 issues 区整洁有序。并强调一条贯穿全文的核心原则开源项目的用户和维护者之间并不是甲方和乙方的关系issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。这条原则直接约束了后文的语气要求、引导式提问策略以及「确认已有能力后不直接否定用户」这类具体话术。三、基本规则何时回复、何时跟进首次回复的准入条件对满足以下所有条件的 issue 进行首次回复Issue 状态为open没有人类维护者MEMBER/OWNER/CONTRIBUTOR回复过。检查已回复的 Issues对于已有 MEMBER/CONTRIBUTOR 回复的 issue也要检查是否处理妥当。需要关注的三种情况维护者已提出问题或解决方案但用户**长时间7 天以上**未回复问题已明确被解决用户确认或版本已修复维护者已说明这不是 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。规范进一步要求处理功能请求时先排查现有能力再讨论新增并给出四条可操作的原则先查现有 API——用户提需求时常因「找不到」而误以为「没有」。收到 feature request 时第一反应应是「我们是不是已经有这个了」而非「怎么实现它」。应搜索相关组件的 props、文档与已有 issue确认未被现有功能覆盖。关注命名可发现性——如果功能已存在但用户找不到问题本质不是缺功能而是 API 可发现性差。此时应向用户指出已有 API 并附代码示例同时反思文档是否需要补充搜索关键词或交叉引用例如用户搜mapping但 API 叫fieldNames文档中应把这两个词关联起来。检查跨组件一致性——用户会从一个组件的 API 类推另一个组件。同一概念在不同组件使用不同命名如 Table 的rowKey与 Select 的fieldNames会制造认知负担。发现用户因跨组件命名不一致而困惑时应记录下来作为后续 API 一致性优化的参考。用提问引导而非否定——确认已有功能后不要直接说「我们已经有这个了」然后关闭 issue。用提问式引导让用户自己确认「看描述这个需求好像可以用fieldNames实现是我理解的不对吗」——既帮用户解决问题又保护了用户面子用户确认后再关闭。使用问题规范明确你可以尝试直接解决和回复使用问题——查阅文档提供解决方案和代码示例如果能解决直接回复帮助用户如果用户描述的问题其实是现有 API 已覆盖的场景用提问式引导「这个需求看起来可以用xxxprop 实现是我理解的不对吗」——比直接甩文档链接更友好。同时可以引入 AI 帮助解答规范列出了两个 GitHub 上的助手docuGitHub Copilot 文档助手与CopilotGitHub Copilot。回复示例模板感谢反馈这是一个使用问题让我尝试帮你解答 [提供解决方案和代码示例] 参考文档官网对应组件文档页 如果以上方案不能解决问题可以尝试 dosu 或 Copilot 获取更多帮助。若无法解决则按第五节所述引导用户到常见问题、StackOverflow 或 SegmentFault 等其他渠道。FAQ 问题查找资源遵循固定顺序带❓FAQ标签的 issues组件文档的 FAQ 部分官网常见问题汇总。Bug vs Feature Request 分类判定类型特征Bug使用现有功能行为不符合预期之前正常现在坏了Feature Request需要目前不存在的新能力规范给出的示例CascaderonFocus不触发 →Bug现有功能不工作为 DatePicker 添加键盘导航 →Feature Request新能力。兜底规则不确定时归类为 Bug。这符合「谨慎关闭、宁可多排查」的整体基调。七、处理 dosubot 回复当仓库的 dosubot 机器人已经回复过某 issue 时规范给出了三步审核流程审核回复的准确性正确 → 确认背书例如「感谢 dosu 的分析确认这是正确的解决方案。」不正确 → 提供更正例如「感谢 dosu但需要补充说明...」完整正确 → 无需额外回复。一个细节要求mention 机器人时使用dosu而非dosubot。八、处理重复 Issues三步固定动作找到原始 issue回复「Duplicate of #xxxx」关闭 issue。九、关闭 Issues可关与不可关的边界关闭是风险最高的操作规范单独成章并要求谨慎。关闭前必须检查⚠️ 确认使用正确的语言参照第四节语言政策。可以关闭的情况重复问题确定不是 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。第一阶段总览 草拟方案使用gh issue list拉取指定范围的 open issues对每个 issue 获取详情body、comments、labels对每个 issue 给出处理方案包括分类Bug / Feature Request / 使用问题当前状态无人回复 / 维护者已回复 / 等待用户反馈 等处理建议需要回复 / 可以关闭 / 无需操作 / 等待中如果需要回复草拟回复内容含语言判断、正文、代码示例标签操作添加/移除哪些标签是否关闭 issue将所有方案一次性呈现给用户不要直接操作。第二阶段讨论和确认用户可以对任意 issue 的方案提出修改意见根据反馈调整方案直到用户满意用户确认后执行操作评论、加标签、关闭等如果用户说「就这样」或类似确认直接执行。这一设计本质上把 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 Actionsissue-reply 规范中反复出现的「3 天」「7 天」「30 天」等时限并非凭空约定仓库的.github/workflows/目录下存在一组 issue 治理工作流为这些规则提供了自动执行与兜底可以逐条对照印证工作流触发时机行为对应规范条款issue-open-check.ymlissue 被创建先给新 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标签的 issue3 天无活动自动关闭并中英双语留言第九节「用户长时间未回复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 的实际书写语言两阶段交互流程预设了ghCLI 可用gh issue list拉取列表以及操作者与仓库的认证关系规范中的渠道名称官网 FAQ、StackOverflow、SegmentFault、new-issue 助手与参考文档中的具体 URL 以 labels-and-resources.md 原文为准本文按规范不重复罗列外链。十八、小结issue-reply Skill 的价值在于把「如何回复一个社区 Issue」这件依赖个人经验的维护工作拆成了可检查的决策点准入条件第三节、语言判断第四节、分类第六节、AI 协作审核第七节、关闭边界第九节、判定流程第十二节与两阶段执行第十四节并通过配套的标签表和仓库自动化工作流第十六节让每一条规则都有落点。对于其他开源项目这套「Skill 文档 references 速查表 Actions 兜底」的组合方式本身就是一个可直接借鉴的 issue 治理模板。【免费下载链接】ant-designAn enterprise-class UI design language and React UI library项目地址: https://gitcode.com/GitHub_Trending/an/ant-design创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ant Design Issue 回复技能（issue-reply）详解：面向维护者与 AI Agent 的 Issue 处理规范及仓库自动化佐证
Ant Design Issue 回复技能issue-reply详解面向维护者与 AI Agent 的 Issue 处理规范及仓库自动化佐证【免费下载链接】ant-designAn enterprise-class UI design language and React UI library项目地址: https://gitcode.com/GitHub_Trending/an/ant-design本篇基于 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 正是这套体系中负责维护者侧社区沟通的模块。二、目标与核心原则规范开篇给出两个明确目标保持社区活跃——让用户反馈被及时响应提升用户参与感和满意度提高处理效率——减少 open issues 和重复 issues保持 issues 区整洁有序。并强调一条贯穿全文的核心原则开源项目的用户和维护者之间并不是甲方和乙方的关系issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。这条原则直接约束了后文的语气要求、引导式提问策略以及「确认已有能力后不直接否定用户」这类具体话术。三、基本规则何时回复、何时跟进首次回复的准入条件对满足以下所有条件的 issue 进行首次回复Issue 状态为open没有人类维护者MEMBER/OWNER/CONTRIBUTOR回复过。检查已回复的 Issues对于已有 MEMBER/CONTRIBUTOR 回复的 issue也要检查是否处理妥当。需要关注的三种情况维护者已提出问题或解决方案但用户**长时间7 天以上**未回复问题已明确被解决用户确认或版本已修复维护者已说明这不是 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。规范进一步要求处理功能请求时先排查现有能力再讨论新增并给出四条可操作的原则先查现有 API——用户提需求时常因「找不到」而误以为「没有」。收到 feature request 时第一反应应是「我们是不是已经有这个了」而非「怎么实现它」。应搜索相关组件的 props、文档与已有 issue确认未被现有功能覆盖。关注命名可发现性——如果功能已存在但用户找不到问题本质不是缺功能而是 API 可发现性差。此时应向用户指出已有 API 并附代码示例同时反思文档是否需要补充搜索关键词或交叉引用例如用户搜mapping但 API 叫fieldNames文档中应把这两个词关联起来。检查跨组件一致性——用户会从一个组件的 API 类推另一个组件。同一概念在不同组件使用不同命名如 Table 的rowKey与 Select 的fieldNames会制造认知负担。发现用户因跨组件命名不一致而困惑时应记录下来作为后续 API 一致性优化的参考。用提问引导而非否定——确认已有功能后不要直接说「我们已经有这个了」然后关闭 issue。用提问式引导让用户自己确认「看描述这个需求好像可以用fieldNames实现是我理解的不对吗」——既帮用户解决问题又保护了用户面子用户确认后再关闭。使用问题规范明确你可以尝试直接解决和回复使用问题——查阅文档提供解决方案和代码示例如果能解决直接回复帮助用户如果用户描述的问题其实是现有 API 已覆盖的场景用提问式引导「这个需求看起来可以用xxxprop 实现是我理解的不对吗」——比直接甩文档链接更友好。同时可以引入 AI 帮助解答规范列出了两个 GitHub 上的助手docuGitHub Copilot 文档助手与CopilotGitHub Copilot。回复示例模板感谢反馈这是一个使用问题让我尝试帮你解答 [提供解决方案和代码示例] 参考文档官网对应组件文档页 如果以上方案不能解决问题可以尝试 dosu 或 Copilot 获取更多帮助。若无法解决则按第五节所述引导用户到常见问题、StackOverflow 或 SegmentFault 等其他渠道。FAQ 问题查找资源遵循固定顺序带❓FAQ标签的 issues组件文档的 FAQ 部分官网常见问题汇总。Bug vs Feature Request 分类判定类型特征Bug使用现有功能行为不符合预期之前正常现在坏了Feature Request需要目前不存在的新能力规范给出的示例CascaderonFocus不触发 →Bug现有功能不工作为 DatePicker 添加键盘导航 →Feature Request新能力。兜底规则不确定时归类为 Bug。这符合「谨慎关闭、宁可多排查」的整体基调。七、处理 dosubot 回复当仓库的 dosubot 机器人已经回复过某 issue 时规范给出了三步审核流程审核回复的准确性正确 → 确认背书例如「感谢 dosu 的分析确认这是正确的解决方案。」不正确 → 提供更正例如「感谢 dosu但需要补充说明...」完整正确 → 无需额外回复。一个细节要求mention 机器人时使用dosu而非dosubot。八、处理重复 Issues三步固定动作找到原始 issue回复「Duplicate of #xxxx」关闭 issue。九、关闭 Issues可关与不可关的边界关闭是风险最高的操作规范单独成章并要求谨慎。关闭前必须检查⚠️ 确认使用正确的语言参照第四节语言政策。可以关闭的情况重复问题确定不是 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。第一阶段总览 草拟方案使用gh issue list拉取指定范围的 open issues对每个 issue 获取详情body、comments、labels对每个 issue 给出处理方案包括分类Bug / Feature Request / 使用问题当前状态无人回复 / 维护者已回复 / 等待用户反馈 等处理建议需要回复 / 可以关闭 / 无需操作 / 等待中如果需要回复草拟回复内容含语言判断、正文、代码示例标签操作添加/移除哪些标签是否关闭 issue将所有方案一次性呈现给用户不要直接操作。第二阶段讨论和确认用户可以对任意 issue 的方案提出修改意见根据反馈调整方案直到用户满意用户确认后执行操作评论、加标签、关闭等如果用户说「就这样」或类似确认直接执行。这一设计本质上把 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 Actionsissue-reply 规范中反复出现的「3 天」「7 天」「30 天」等时限并非凭空约定仓库的.github/workflows/目录下存在一组 issue 治理工作流为这些规则提供了自动执行与兜底可以逐条对照印证工作流触发时机行为对应规范条款issue-open-check.ymlissue 被创建先给新 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标签的 issue3 天无活动自动关闭并中英双语留言第九节「用户长时间未回复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 的实际书写语言两阶段交互流程预设了ghCLI 可用gh issue list拉取列表以及操作者与仓库的认证关系规范中的渠道名称官网 FAQ、StackOverflow、SegmentFault、new-issue 助手与参考文档中的具体 URL 以 labels-and-resources.md 原文为准本文按规范不重复罗列外链。十八、小结issue-reply Skill 的价值在于把「如何回复一个社区 Issue」这件依赖个人经验的维护工作拆成了可检查的决策点准入条件第三节、语言判断第四节、分类第六节、AI 协作审核第七节、关闭边界第九节、判定流程第十二节与两阶段执行第十四节并通过配套的标签表和仓库自动化工作流第十六节让每一条规则都有落点。对于其他开源项目这套「Skill 文档 references 速查表 Actions 兜底」的组合方式本身就是一个可直接借鉴的 issue 治理模板。【免费下载链接】ant-designAn enterprise-class UI design language and React UI library项目地址: https://gitcode.com/GitHub_Trending/an/ant-design创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考