分开说明你需要的功能和你建议的实现

先说明用户想要的结果及其验收条件，再指定技术设计。把实现想法放在单独一节，让智能体可以调查它们，而不会把猜测误当成需求。

“让我导出筛选后的工作列表”描述的是用户结果。“增加后台工作进程和一张新的下载表”提出的是实现手段。两者都可以出现在讨论中，但它们的确定性和约束力不同。分开记录，才能在拒绝不必要组件的同时，保留用户要求的功能。

下面给出一个完整虚构示例：一份混合了两者的初始请求、一份重写后的需求说明、两个实现方案，以及一份实施前调查请求。其中的产品、记录和业务限制都是虚构教学材料，不是客户研究，也不是 CueSpec 的现有能力。

从一份混合两者的请求开始

假设团队成员说：

加上 Redis 和后台工作进程，让 Export CSV 下载当前筛选条件匹配的
全部行，而不只是当前可见页。在数据库中加一张导出历史表，
下载文件保留一个月。必须即时完成，还应当安全。开始做吧。

这份请求中有一项可以识别的需求：当前筛选条件应跨页决定哪些记录进入导出。其余内容需要梳理。

后台工作进程、缓存产品、数据库表和文件保留时间，都是设计建议。“即时”缺少可检查条件。“安全”没有确定权限边界。即使用户可能只需要一次下载，保留文件一个月，也会改变功能在存储和访问方面的责任。

如果智能体把每句话都当成同样确定的决定，就可能在确认真实导出行为之前，先搭起请求中提到的基础设施。

将需求重写为独立说明

下面是这个虚构应用重写后的功能需求：

# 功能需求：导出当前筛选后的工作列表

## 用户与目标

已登录的工作区成员需要一份 CSV，包含与当前已应用的列表筛选条件
匹配的每一项工作记录。只导出可见页并不足够，
因为成员要用该文件离线审阅整个筛选结果集。

## 导出成员范围

成员点击 Export 时，为这次请求冻结已应用的筛选值。
服务器接受请求时，捕获匹配且该成员有权导出的记录及其值。
这个服务器捕获时点定义导出快照，而不是更早的浏览器点击瞬间。
之后编辑筛选条件，不得改变这次导出包含哪些记录。
本例中，交付的行值必须来自同一份已捕获数据集。

结果必须跨分页包含匹配且允许导出的行。
没有勾选或只输入了一部分、尚未应用的筛选条件不影响结果。
导出不会把访问范围扩大到该成员权限之外。

## 文件内容

按顺序包含 id、title、status 三列。以下方示例作为验收样例。
结果为空时，生成只包含表头、没有数据行的 CSV。

## 反馈与限制

界面必须展示请求正在处理，并提供明确的完成或失败状态。
下载可用之前，不得显示成功。如果交付前权限发生变化，
这次导出应失败，并请成员重新发起请求。

在这个虚构产品中，首版必须处理最多 5,000 条允许导出且匹配的记录。
超过这项选定限制时，显示解释，并请成员收窄筛选条件。
这是一项需要验证的需求，不是测得的容量结果。
目前没有设定完成时间承诺。

## 首版请求范围之外

不要求定期导出、保存导出历史、邮件交付或保留下载文件一个月。
现有保留与访问规则仍适用于任何实现产物。

## 尚未决定的问题

在哪里组装已捕获数据集；采用同步处理还是排队处理；
怎样表示进度；可以复用哪些现有组件。
选定设计之前，先调查这些问题。

这份说明让“当前筛选条件”变得具体。它也区分了示例中选定的限制与测得的性能声明。真实团队应根据实际用户和约束，选择数据集大小及可接受等待时间；这里的数字只用于定义练习。

权限变化规则是刻意写清楚的。如果缺少它，一个方案可能在访问权限变化后仍交付已捕获文件，另一个却可能悄悄省略部分行。两者都可以声称满足“安全导出”，但用户看到的结果不同。捕获时点也明确写出：在浏览器冻结筛选条件，和在服务器捕获记录，是两个不同事件。

给两个方案相同的验收示例

这位虚构成员可以导出以下四行。它们是本例中全部允许导出的数据集，不只是一个可见页：

已应用的筛选条件是 status=open 与 queue=support。分页每页显示一条匹配记录。因此，预期导出有两条数据行，而不是一条：

id,title,status
W101,Check labels,open
W104,Review inbox,open

这是人工编写的预期文件，没有由导出实现生成。它的作用是在实施之前，确定包含哪些记录及列顺序。更复杂的真实值，包括逗号和换行，仍需要合适的 CSV 序列化器及单独检查。

现在考虑四种验收情形：

无论组件听起来多熟悉，无法解释这些结果的架构，都还没有准备好被选定。

方案 A：在一次请求中构建文件

第一个候选方案由服务器捕获已授权且匹配的数据集，在发起导出的那次请求内构建 CSV。

## 候选 A：请求内导出

1. 复用已应用筛选条件的表示，而不是当前页的行。
2. 在服务器核对授权，并在选定的 5,000 行限制内
   捕获匹配数据集。
3. 使用 CSV 序列化器，将已捕获的值序列化。
4. 交付前立即重新检查导出权限。如果权限变化，
   让请求失败，不交付已捕获文件。
5. 返回下载或明确错误；界面保持等待状态，
   直到其中一种结果已知。

需要调查：现有查询/快照支持、请求时长限制、
选定数据集的内存使用、断连行为，
以及能否在交付时执行要求的权限复核。

考虑理由：如果现有请求路径可以满足需求，新增运维组件更少。
适用性尚未得到证明。

这个候选方案没有假定处理 5,000 行开销很小。仅凭行数无法确定：字段大小、查询成本、序列化和托管限制也都有影响。

方案 B：捕获数据集，再通过排队作业处理

第二个候选方案把数据集捕获与文件构建分开。这种拆分引入了状态模型与临时存储方面的决定。

## 候选 B：排队导出

1. 为初始请求冻结筛选条件，然后与候选 A 一样，
   在服务器接受请求时授权并捕获匹配数据集。
2. 创建一个引用该已捕获数据集的作业。
   工作进程不得稍后重新运行会变化的实时筛选，
   却把结果称为同一份快照。
3. 序列化已捕获的值，并记录完成或失败状态。
4. 交付前重新检查导出权限。若有变化，则失败并要求重新导出，
   与候选 A 遵循相同规则。
5. 采用这个设计之前，先定义临时快照和文件的访问、
   到期、删除、重试及清理规则。

需要调查：现有作业能力、临时数据策略、
进度获取、交付授权，以及被遗弃作业的处理。

考虑理由：文件构建可以拥有独立于初始请求的生命周期。
额外状态和存储需要明确归属；
它们不会自动让实现更快或更安全。

从纸面上看，两个候选方案都满足同一项预期用户结果。候选 B 必须额外解决持久化问题；候选 A 必须适配相关请求路径。这里没有构建或测量其中任何一个。检查实际应用之后，第三种设计可能更合适。

请求调查，并明确停止点

功能已清楚、实现尚不明确时，可以使用这份完整请求：

调查如何添加随附功能说明中的筛选结果 CSV 导出。
本轮只做调查与建议。

先检查应用如何表示已应用的筛选条件、执行导出权限、
跨页查询及捕获一致数据。
指出相关文件，以及任何现有导出或作业组件。

针对相同的四种验收情形，比较候选 A（请求内构建）
与候选 B（已捕获数据集加排队构建）。
把原始笔记中的 Redis、新表和保留一个月视为建议，而不是需求。
检查所得证据支持时，建议复用或采用另一种设计。

返回带文件链接的解释、最小可行实现方案、未决问题，
以及在声称方案满足 5,000 行要求之前需要做的检查。
如果托管限制未知，直接说明，不猜测受支持的持续时间。

本次调查不编辑文件、不安装依赖、不创建基础设施、
不运行生产导出、不创建拉取请求，也不部署。
给出建议后停止，以便我们选择实施范围。

GitHub 的任务指南建议明确问题范围和验收条件，并介绍了创建拉取请求之前的研究与规划。本文的导出需求说明与候选方案，是我们对这项建议的具体应用。

选定方案后，再将决定转成具有适当权限和交付边界的实施请求。始终保留最初的用户结果：只有在约定条件下产生正确导出，所选基础设施才有用。