写一份把改动与证据对应起来的 PR 描述

有用的 Pull Request（PR）描述，应把具体问题与补丁联系起来，再说明实际检查了什么。审阅者应能分清已实现的改动、预期行为与观察结果，而不必从长对话中重建这些区别。

先整理一个小型事实包，依据它写描述，再删掉任何信心超过证据的句子。计划中的检查放在计划里，已经记录的结果放在验证里。本地提交、合并完成和功能部署，各自需要相应的状态依据。

本教程使用一个虚构的 TypeScript 导出补丁。所有文件、需求、描述和审阅请求都是原创示例。代码没有执行，没有声称测试、CI、合并或部署已经完成。

写摘要之前，先整理事实包

虚构应用导出的行，已经由上游完成授权。新增选项的目的是让调用方可以保留这批已授权输入中的 closed 行；此前，选择函数总会将它们排除。

以下是补丁前 src/export/selectRows.ts 的完整小型源代码，代码与英文源保持一致：

export type Row = {
  id: string;
  status: "open" | "closed";
};

export function selectRows(rows: readonly Row[]): Row[] {
  return rows.filter((row) => row.status !== "closed");
}

替代后的选择函数：

export type Row = {
  id: string;
  status: "open" | "closed";
};

export function selectRows(
  rows: readonly Row[],
  includeClosed = false,
): Row[] {
  return rows.filter((row) => includeClosed || row.status !== "closed");
}

示例中，原调用方 src/export/buildExport.ts 选择行时，没有传递这个选项：

import { type Row, selectRows } from "./selectRows";

export function buildExport(
  authorizedRows: readonly Row[],
  options: { includeClosed?: boolean },
): Row[] {
  return selectRows(authorizedRows);
}

替代后的调用方会传递这个有类型声明的选项：

import { type Row, selectRows } from "./selectRows";

export function buildExport(
  authorizedRows: readonly Row[],
  options: { includeClosed?: boolean },
): Row[] {
  return selectRows(authorizedRows, options.includeClosed);
}

最后，这个虚构补丁在 docs/export.md 中增加下面的完整英文段落，保留其源文本：

The export builder accepts an optional includeClosed boolean. When omitted
or false, selection excludes closed rows. When true, selection retains
closed rows from the already-authorized input set. The selector does not
fetch additional rows or perform authorization.

这段文档的意思是：导出构建函数接受可选的 includeClosed 布尔值；省略或为 false 时，排除 closed 行；为 true 时，保留已授权输入集合中的 closed 行。选择函数不额外获取行，也不执行授权。

以上就是这个教学补丁的全部内容。它没有增加导出按钮、请求解析器、文件下载或授权实现。描述结果时能说多大范围，取决于这些没有包含的部分。

在证据与预期混在一起之前，先记录它们：

上游授权边界是场景假设。这些片段不证明真实应用已经执行了该边界。同样，TypeScript 类型声明本身也不会验证来自网络的任意运行时输入。

看看旧描述错在哪里

一份过度自信的初稿可能这样写：

修复所有缺失的导出记录。

现在导出包含全部内容，完全向后兼容，权限也完全安全。
所有浏览器中的测试均已通过。修复已经上线，可供客户使用。

每句话都让补丁更难判断。“所有缺失的导出记录”掩盖了具体的 closed 行条件；“全部内容”忽略了选项默认值和已授权输入边界；“完全向后兼容”超过这几段代码所能证明的范围；浏览器测试和发布状态则根本没有相应记录。

修复方法是收窄描述对象，并明确验证状态。堆上更多技术细节，不能修复一个没有依据的结论。

使用一份完整的替代 PR 描述

下面的描述依据事实包编写。真实 PR 应将文件引用连到相关 diff，并在有实际检查记录时附上证据。这里的路径指向本文展示的虚构文件。

## 问题与改动

导出构建函数接受 includeClosed 选项，但原调用方没有传递它，
选择函数因此始终排除 closed 行。本补丁传递这个选项，
并给选择函数增加参数，目的是在 includeClosed 为 true 时保留 closed 行。

选择函数默认值为 false，让省略该选项的调用继续采用原先的排除规则。
它只处理自己收到的行。

## 相关文件

- src/export/selectRows.ts：增加 includeClosed，并更新过滤条件。
- src/export/buildExport.ts：传递 options.includeClosed。
- docs/export.md：说明默认行为和输入边界。

## 验证

这个示例补丁尚未运行编译、自动化测试、浏览器检查或端到端导出检查。
上面描述的行为由已展示源码推断，不是执行记录。

计划检查：
- 混合 open/closed 输入，分别省略选项和设为 false。
- 对同一输入，把选项设为 true。
- 空输入，以及调用方传递每种受支持值的情况。
- 真实应用中现有的上游授权边界。

## 范围与剩余工作

本补丁不增加 UI、不解析不可信请求值、不改变授权，
也不获取超出输入集合的记录。它不证明完整的可下载导出已经可用。
本例没有进行合并或部署。

请先审阅默认值和选项传递行为，再决定是否扩展到独立的请求解析
或界面工作。

即使验证部分没有一次成功运行，这仍是一份完整描述。它告诉审阅者已经有什么、应去哪里检查，以及还缺少哪些依据。

把最终声明对应回证据

逐句核对描述，尤其要留意智能体为了行文流畅而改写之后的版本。

这份映射可以留在审阅笔记中，不必塞进对外 PR 描述。它帮助作者在缩短文字时，避免把假设变成事实。

后来运行了检查，再更新对应句子

验证更新应写明修订版本、环境、命令或操作步骤、结果，以及证据位置。只跑了选择函数检查，就只描述选择函数检查。在有相应证据之前，端到端导出状态继续留为未决。

例如，只针对现在已有记录的那项检查，将“未运行”替换为实际结果。不能因为一个测试套件通过，就写成“经过全面测试”。如果后续代码又改变了选项语义，旧结果也未必继续支持当前修订版本。

英文来源所引的 GitHub PR 生命周期指南讨论了草稿阶段的早期审阅，以及较大改动后的重新审阅。本教程的描述格式是编辑建议，用来让改动在这个过程中保持清楚，不是 GitHub 强制要求的模板。

为自己的补丁复用这个简短模板

## 问题与改动后的行为
[具体触发条件与原有行为；本补丁改变什么。]

## 补丁中的证据
[相关文件或 diff 区域，以及各自支持的声明。]

## 验证
[实际执行的检查、修订版本／环境、结果与证据链接。]
[未运行的检查，以及实际限制。]

## 剩余范围
[本补丁留待单独处理的重要行为。]
[相关时注明当前合并／部署状态。]

## 审阅重点
[最需要审阅者作出判断的决定或风险。]

为没有看过智能体对话的人写这份描述。审阅者应当只凭 PR 本身，就能理解问题，并判断现有证据。