拉取请求是什么？从代码差异到审阅、检查与合并
用新增导出字段解释拉取请求，区分提交与分支，也比较 PR 和上线，说明基准分支、检查与评论处理，帮助核对 AI 创建的 PR 是否真的可交付。
先理解这个概念
拉取请求Pull Request是把一个分支的改动合入另一个分支的提议，提供讨论、审阅和自动检查的位置。它与Git提交不是同一个对象，也不表示代码已经合并或部署。AI创建PR以后，仍要核对实际差异和测试证据，满足项目规则再处理合并；最终用户能否使用功能，还取决于后续发布与线上验证。
分支与基准决定提议包含哪些改动
例如新增导出字段，应确认PR基准是预期目标分支，差异只包含相关修改。若分支混入旧工作，PR可能带上无关文件。标题写得正确不能弥补实际差异超范围，审阅应从文件和提交内容核对，而不是只读生成摘要。
GitHub资料把PR描述为提议并集中展示提交和检查。草稿状态用于未准备好的工作，不能与待合并状态混淆。本文解释流程，没有创建实际PR，也没有对某个仓库作合并或权限变更。
检查通过与审阅批准各自提供不同证据
自动测试可以确认覆盖的行为，审阅则可以指出实现和需求偏差，两者都可能有遗漏。评论、批准和请求修改也有不同含义。不能把一条普通评论解释为批准，更不能在必需检查失败时只凭AI总结说可以合并。
新提交推送以后，旧测试结果可能不对应当前代码，应核对运行版本。审阅发现的问题需要修改或明确说明处理结论，避免只标记对话已解决而未修复。所需规则由仓库配置决定，不应通过跳过保护来完成任务。
合并完成以后仍要核对部署和用户路径
合并只把代码纳入目标分支，发布可能由流水线自动触发，也可能需要其他步骤。应确认构建部署状态，再检查新增字段在真实导出文件中是否出现。一个合并按钮的成功提示，不能替代用户路径验收。
如果尚未合并或上线，报告应准确说明当前阶段与阻塞项。这里没有报告任何真实PR的结果。AI可以帮助准备描述和检查差异，但可交付性最终取决于实际产物、规则满足和验证范围，不由PR数量或标题决定。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。