用 AI 整理 GitHub Issue：让维护者能够复现问题

一个有帮助的 Issue，让维护者看得懂问题，也能用合理的成本检查问题。AI 可以整理文字和提取步骤，但观察事实仍要来自实际发生的行为。

GitHub 支持创建 Issue，项目也可能提供专用模板。提交前先读项目规则并搜索已有讨论，避免重复报告。GitHub 官方说明

先保存事实，再整理表达

记录使用的版本、必要环境、操作顺序、预期结果和实际结果。日志只提供与问题有关的部分，删去令牌、个人资料和不必要的内部地址。

不确定的信息直接写不确定。没有测过其他版本，就不要让 AI 补成“所有版本都会发生”。

一份可填写的报告结构

标题：在哪个条件下，哪个行为与预期不符。
版本和环境：只列影响复现的必要信息。
复现步骤：从明确起点开始编号。
预期结果：依据文档或正常工作流程应发生什么。
实际结果：观察到了什么。
最小样例：不含隐私、能触发问题的输入。
补充证据：必要日志或截图。
未确认事项：还没有排除哪些原因。

例如，“导入含空标题的记录时页面没有提示”比“导入坏了”更容易定位。它仍需要实际步骤和样例，标题本身不能替代证据。

给 AI 的整理要求

请它按项目模板重排现有信息，保留事实与推测的区别，列出缺失字段。不要让它为了完整而编造环境、错误码或复现结果。

整理完成后，照着步骤再做一次。若必须依靠没有写出的操作才能复现，就补全它。维护者没有你的聊天背景，报告需要独立成立。

提交后继续维护同一条记录

收到问题时补充实际检查结果；原因查明后更正先前推测。除非项目另有要求，避免为了吸引注意重复开多条相同 Issue。

Issue 也可以用于需求讨论，但应清楚说明使用场景和限制，而不把个人偏好写成软件故障。完整贡献流程见用 AI 参与 GitHub 开源。