开源维护者自动回复：机器人要帮忙，不要赶客

一、自动回复容易伤人

开源项目 issue 多了以后，维护者会想用机器人自动回复：缺复现、缺版本、重复问题、环境不完整。自动化能节省时间，但如果语气生硬、判断错误，就会让贡献者觉得被拒之门外。

机器人要帮忙，不要赶客。

二、先分类再回复

flowchart TD
  A[新 Issue] --> B[分类]
  B --> C[缺复现]
  B --> D[疑似重复]
  B --> E[功能请求]
  B --> F[安全问题]

不同类型需要不同回复。安全问题不能公开追问细节，功能请求不能用缺复现模板。

issue_triage:
  bug_report: require_reproduction
  feature_request: ask_use_case
  security: private_channel

分类错了，回复就会冒犯。

三、回复要给下一步

“请补充信息”太泛。更好的回复是列出需要的版本、复现步骤、最小代码、日志片段，并说明为什么需要。

为了复现这个问题，请补充：
- 工具版本
- 操作系统
- 最小复现命令
- 完整错误日志

这样贡献者知道怎么推进。

四、机器人要低置信静默

AI 判断不确定时，不要自动回复。可以打标签、进入人工队列。错回复比不回复更伤社区体验。

auto_reply_policy:
  confidence_required: 0.85
  low_confidence: label_only
  maintainer_override: true

还要避免频繁追问。用户已经补充信息后，机器人不应该继续重复同一模板。

最后，自动回复要可被维护者编辑。社区沟通需要温度，机器人只负责减轻负担，不应该替代维护者。

自动回复还要识别贡献者状态。第一次提交 issue 的用户，需要更温和、更详细的引导；长期贡献者可能只需要一个简短提示。社区体验不是统一模板能解决的。

reply_tone:
  first_time_contributor: friendly_detailed
  regular_contributor: concise
  security_reporter: private_and_careful

还要避免公开暴露敏感信息。用户贴了 token、内部 URL 或安全漏洞细节时，机器人应该提醒删除或转到私有渠道，而不是引用原文继续回复。

机器人动作要可撤销。误关 issue、误打标签、误判重复时，维护者可以一键恢复，并把反馈用于改进规则。

最后，自动化效果也要看数据。首次响应时间下降了多少，误回复率是多少，新贡献者留存有没有改善，这些比“机器人回了多少条”更重要。

自动回复还要支持项目阶段差异。早期项目更需要鼓励反馈，不适合过度要求模板完整；成熟项目 issue 量大，可以更严格要求复现信息。规则要跟项目状态一起演进。

project_stage_policy:
  early: friendly_collect_context
  growing: balanced_triage
  mature: strict_template_required

还要保留人工欢迎。机器人可以补信息，但重要贡献、首次 PR、复杂问题，维护者最好亲自回复一句。社区不是客服系统，关系感很重要。

最后，机器人回复模板也要版本化。社区语气、项目规则变化后，历史模板和新模板要能追踪，避免误用过期规则。

五、总结

开源维护者自动回复要先分类 issue，再给出明确下一步，并在低置信时保持克制。

机器人要帮忙，不要赶客。好的自动化应该降低贡献门槛，而不是提高心理压力。