AI 改完代码后，怎样写清楚一份 PR

PR 是请求项目合并修改的入口。GitHub 的说明将它用于提出、讨论和审查变更；创建 PR 不意味着维护者已经接受修改。GitHub 官方说明

AI 完成修改后，PR 描述最该回答的是：为什么需要改，行为怎样变化，怎样检查过。维护者通常不需要阅读整段人机对话。

从触发条件写起

例如：“导入没有标题的记录时，页面直接结束操作且没有提示。现在保留输入并显示缺失字段。”这是虚构说明，用来展示问题与结果怎样放在同一段。

如果修改针对已有 Issue，按项目惯例关联它。若项目要求先讨论方案或披露 AI 使用方式，遵循当前贡献规则。

用实际差异核对描述

请 AI 先列出修改的行为，再检查文件差异是否支持这些说法。描述里不应出现未实现的功能，也不要把顺手改动藏在一句“其他优化”里。

范围过大时考虑拆分，但每一份修改仍应能够独立理解和验证。不要把紧密相关的修复拆成很多无法单独工作的 PR。

验证部分写检查事实

问题：什么条件下出现什么行为。
变化：修改后使用者会看到什么。
验证：运行或操作了什么，观察到什么结果。
限制：哪些环境未检查，哪些风险仍存在。

如果只检查了文档链接，就写文档链接检查；没有运行测试，就说明未运行及原因。不能因为代码由 AI 生成，就把“AI 认为正确”当作测试结果。

对不熟悉的代码，应获得具备相关能力的复核。尤其是权限、数据写入和共用逻辑，功能表面正常可能不足以判断影响范围。

随最终实现更新说明

审查中方案改变，标题和描述也要同步。删除已经放弃的功能描述，保留解释当前取舍所需的信息。

回复审查意见时，指明具体修改与检查结果。没有采纳的建议，说明原因并讨论。清楚的说明可以降低理解成本，但是否合并仍由维护者依据项目需求决定。