PR 审核

软著 PR 审核记录是什么？个人开发与团队评审材料说明

CCopyright 编辑团队内容核对：2026-10-16非官方指南

PR 是 Pull Request，GitLab 通常使用 Merge Request（MR）。它们可以承载一次变更的讨论、审核和合并过程。不是每个项目都采用这种协作方式，也不是每个 PR 都有人工审批。

存在提交、通过 CI、创建 PR、审核批准和完成合并，是不同的事实。没有提供审核资料时，应写“未提供”，不能自动填成“审核通过”。

PR 审核记录包含哪些信息

GitHub 官方说明，评审可以发表评论、批准变更或要求修改。评审结果和 PR 最终是否合并需要分别核对。

资料可以包括 PR 编号与链接、标题、提出人、创建时间、实际评审人、评审意见与状态、提交评审时间和合并时间。不要把评审人改为项目负责人，除非原始记录确实如此。

有仓库读取权限并已配置 GitHub CLI 的用户，可在对应仓库运行下面的只读查询。命令最多返回 100 条 PR；这不是“全部历史”的保证，大项目应按范围继续导出。

gh pr list --state all --limit 100 --json number,title,url,state,author,createdAt,mergedAt,reviewDecision,reviews > pull-requests.json

保留原平台的变更链接、讨论、评审状态和合并信息；截图应包含可识别的上下文，避免只截一个绿色状态标记。

当前工具自动解析的是上述 GitHub CLI 导出格式，Gitee/GitLab 原生接口结果不直接兼容。可按本指南字段人工整理，并附原平台记录，不必伪装成 GitHub 数据。

个人项目可能直接提交到主分支，事实如此就说明没有采用 PR 流程。可整理实际存在的版本、测试和交付资料，并就补正要求确认可接受的说明方式。

自己后来做的代码自查可以按实际日期记录，但不应冒充此前团队审核或第三方审核。若提供 AI 评审结果，也应如实说明来源。

Git log 能直接生成 PR 审核记录吗？

不能。Git 提交记录通常不包含平台上的审核人、评审意见和审批状态，需要单独取得实际 PR/MR 资料。

PR 已合并就等于审核通过吗？

不一定。某些项目允许未经评审直接合并，应分别记录合并事实与评审状态。

导出后发现 reviews 为空怎么办？

工具会标为“未提供审核记录”。先检查原平台是否确有评审及导出是否完整，不能自动补写审核人或意见。

软著独创性证明材料怎么准备？真实开发记录与补正清单

软著源程序文件目录怎么整理？附文件哈希清单示例

软著项目研发日志怎么写？字段、模板与记录整理方法

软著代码版本管理记录怎么导出？Git、GitHub、Gitee 整理指南

软著第三方测试报告需要吗？用途、机构与送测资料清单