先确认反馈入口和查看职能
准备交接 TestFlight 截屏或崩溃反馈时，团队可以先打开 Apple 的“查看测试员反馈”帮助页，再核对自己能否进入目标 App 的反馈页。本文整理的是查找、记录和交接方法；页面看不到的字段、尚未下载的材料，都应留空待查，不要在交接表里补猜。
Apple 说明，使用 TestFlight 2.3 或更新版本提交的反馈会显示在 App Store Connect，反馈内容包括截屏、有关崩溃的评论和总体评论。
Apple 将查看测试员反馈所需职能列为账户持有人、管理、App 管理、开发者或营销。
团队可自建一条查找记录，填入目标 App、待查构建、反馈类型、记录人和核对日期；这些是交接用的工作字段。若接手人打不开原反馈，请有相应职能的同事重新核对并更新记录，把“尚未亲自查看”标清楚。转发的截图只能作为待核线索，不能替代原页面；交接时另列出仍缺的访问或材料。
- 先核对 App、构建与反馈类型，再开始摘录。
- 缺少页面访问权限时交由有相应职能的成员复核。
- 记录核对日期，避免把旧截图当作当前页面。
按构建、系统和设备缩小反馈范围
Apple 在截屏和崩溃反馈入口均提供按 App 平台、App 版本、构建版本群组、构建版本、操作系统版本和设备筛选的选项。
团队可以先确定这次需要排查的构建，再把页面实际选中的平台、App 版本、构建版本群组、构建、系统版本和设备写在同一条工作记录中。筛选顺序只是方便复查的团队习惯；若某项未显示，明确写“未显示”，不要从另一条反馈借用值。复查人应能按这些条件重新找到目标反馈。
比较两个构建时，分别保留筛选组合与记录日期，给每条反馈分配团队自建编号，再列出相同现象和差异。筛选命中只说明找到了待看的记录，不能单凭列表确认故障原因；是否为同一个问题，还要核对评论、实际材料和后续复现结果。更改筛选后同步更新记录，免得接手人按旧条件寻找。
- 一组筛选条件对应一个待查构建范围。
- 没有显示的字段写“未显示”。
- 相似反馈先保留为两条记录，再核实关联。
团队整理截屏反馈时，区分画面、评论和推测
Apple 说明，截屏反馈 ZIP 包含截屏和相关评论，崩溃反馈 ZIP 包含崩溃报告和相关评论。
团队可自建三栏来整理一条截屏反馈：测试员写下的评论、画面中直接可见的内容、团队尚待验证的解释。记录时先保留评论原意，再写可从画面核对的提示；例如“可能与网络有关”只能进入待验证栏，并附上后续要检查的条件。这套分栏是团队交接方法；界面字段请以当前页面为准，并在记录中注明自建栏目。
若团队下载了 ZIP，先确认文件能打开、内容属于当前反馈，再记录下载日期、检查人和团队保存位置。不要只看下载按钮或文件名就写“材料齐全”。需要补充操作步骤时，把问题交给测试负责人或相关测试员，不要替他们编写复现过程；后续取得的新信息应单独注明来源和时间。
- 评论、画面观察、原因推测分栏。
- 检查 ZIP 实际内容后再登记材料状态。
- 复现步骤不足时记录待补问题。
匿名反馈只交接页面确实显示的信息
Apple 说明，公开链接加入且未填写邮箱的测试员在反馈详情中显示为匿名；邮件邀请的测试员邮箱会显示。
交接这条反馈时，团队可分配自建编号，并把当前页面实际显示的筛选条件、评论和已取得的材料记在同一条记录中。身份栏只照录当次查看时可见的内容；没有看到的姓名或邮箱就留空，不用截图或评论猜测是谁。若工作确需联系测试员，请先由有相应职能的成员核对原页面及团队资料规则，再决定是否在内部记录中使用邮箱。技术分流先传递构建、评论与实际材料，联系信息另行控制。
复查人可在团队自建记录里为每条反馈填写内部编号、核对人、核对时间和待补问题。交接与身份有关的材料时，只摘录当次查看时确实取得的原文；没有取得的内容留空，不另设推测性的身份状态，也不复制上一条反馈的记录。再次核对时，先比对同一条反馈已保存的原文与材料；发现不一致，就在工作表中标为“待核对”，交由有相应职能的成员回查。公开问题单只保留排查所需的构建和问题线索，联系资料另按团队资料规则处理。
- 每条反馈单独编号，另记核对人和时间。
- 内部编号标为团队自建，避免和页面字段混淆。
- 技术交接优先传递构建与问题证据。
核对崩溃 ZIP 内容与 120 天边界
Apple 说明崩溃报告可在 120 天内下载；如果 App 因崩溃而无响应，下载的 ZIP 不会包含崩溃报告。
拿到崩溃反馈时，先确认正在核对的是目标构建和目标反馈，再检查下载的 ZIP 能否打开、实际取得了哪些材料。团队工作表可把“未下载”“已下载但未检查”“已检查且有报告”“已检查但无报告”分开记录；这些状态仅用于团队交接。回查原反馈时，请照录实际取得的内容，不用工作表状态替代原材料。文件与反馈对不上时暂停合并，留下待复核项。
Apple 说明崩溃报告可在 120 天内下载；如果 App 因崩溃而无响应，下载的 ZIP 不会包含崩溃报告。交接表只记录实际核对到的材料与下载时间。请勿把上句数字用于截屏、评论、构建或整份反馈；本文没有提供这些材料的期限，相关栏目留空。遇到 ZIP 不含崩溃报告，先如实记录实际文件和页面可见评论，再请有权限的成员复查；不要把缺报告写成空白报告，也不要用另一条相似反馈的文件补位。团队如需保管副本，应按自己的资料规则办理。
- 区分尚未下载和已下载但没有报告。
- 其他材料的期限栏先留空，不套用崩溃报告的下载数字。
- 文件与反馈编号对不上时保持待复核。
如另行收到测试邮件，怎样与后台反馈分开整理
如果团队另行收到与这轮测试有关的邮件，先把它当作独立材料登记。不要根据测试员群组的反馈设置推断邮件的发送方式，也不要直接并入 App Store Connect 中的截屏或崩溃反馈。先保留原始邮件、收到时间和来源线索，再决定是否需要请有权限的成员复核。
若团队要追踪这类邮件，可为邮件分配自建编号，并记录原有主题、正文、收到时间和邮件中确实可核对的构建线索。若某封邮件的描述与后台一条截屏或崩溃反馈相近，也先分别保留两份原材料；描述相近不能代替关联证据。需要关联时，请分别摘录两边确实出现的线索，再由有权限的成员核对。
团队自建交接表可以增加“邮件来源”“后台反馈来源”“关联待确认”三种标记，方便说明每项材料从哪里来。邮件未写构建时，可在团队记录中标为“构建待核对”，不要为了让表格完整而填入猜测值。团队分派邮件、保存资料和确认关联时，按实际收到的信息决定下一步；不要从群组设置直接推断邮件与后台反馈必然相关。
- 团队记录可给邮件与后台反馈分别编号、标注来源。
- 构建线索不足时保持待核对。
- 没有证据时不合并两种来源。
用一张分流表交接修复与待补证据
团队可以为每条反馈建一行分流表：自建编号、来源类型、目标 App、构建筛选条件、团队核对到的设备与系统线索、测试员评论、实际取得的截屏或崩溃文件、待验证判断、接手人、下一次复查安排。筛选条件来自前文核对的 Apple 帮助页；编号、负责人和复查安排属于团队管理信息，建议在交接表中标明这些是自建记录。
填写团队自建分流表时，先给每项信息标注“原材料可见”“测试员描述”或“团队待验证”，再写明对应反馈编号。未看到的字段请写“未显示”。请将 ZIP 尚未下载、已下载但未检查、检查后缺少预期材料分别按实际情况登记。接手人依团队记录中的筛选条件回查原反馈，核对文件是否匹配；联系测试员则遵守团队现有渠道和权限。
交接前抽查三件事：能否按条件找到原记录、材料是否确实对应当前编号、未决问题是否有跟进人。可用“待查看”“待补材料”“待复现”等团队自定标签记录整理进度，但分派负责人不代表问题已经复现或修复。只有在相应构建完成验证后，才更新团队对故障的结论，并注明验证证据。
- 一条反馈一行，来源、构建和材料放在一起。
- 事实、测试员描述与待验证判断分开。
- 交接完成不等于问题已修复。