为什么一份跨越数月的申请材料需要一个追踪表
一份典型的 EB-2 NIW（国家利益豁免）申请，最终会汇总成 30 到 60 份独立文件：I-140 表格及其附件、个人陈述、六到十封推荐信、已发表的论文、从 Google Scholar 或 Web of Science 上抓取的引用报告、学位证书及其学历认证、媒体报道、专利、资助函，以及会员资格或同行评审活动的证明。这些材料不会一次性到位，而是在数周乃至数月的时间里，分批被索取、起草、修改、最终定稿——期间常常要长时间等待推荐人回信、等翻译交稿、或等档案部门出证明。
正是这种被拉长的时间线，才是问题的根源。一月份签署的推荐信，可能提到某个职位或项目，而这个信息到六月份就已经过时。申请早期抓取的引用次数，到真正递交时早已过期。同一份证据材料的两个版本——一份改过错别字，一份没改——通过邮件流转，谁也说不清哪个才是最新版。向合著者或学校教务处索要的材料，因为没有清单可查，干脆被彻底遗忘。
追踪表要解决的正是这个问题：它给你一个地方，如实反映每一份文件的当前状态——哪些已经齐备、哪些还欠缺、哪些已经过时、哪些可以拿去归档。它不是用来判断你的证据是否满足某项法律标准的地方——那是另一件事，需要单独处理。它唯一的职责，是防止材料丢失、重复，或者用了已经作废的版本去提交。
选择工具形式：电子表格 vs. 文档管理工具
追踪表本身可以放在多种工具里。真正重要的不是用什么软件运行它，而是它必须始终是一份所有相关人员都在查看的、单一且最新的文件。
电子表格（Google Sheets、Excel）
对于没有庞大团队协助的申请人来说，电子表格几乎总能胜任这项工作。它不需要任何搭建成本——打开一张空白表格即可开始；离线状态下可用 Excel，联网状态下 Google Sheets 会通过「文件 > 版本历史记录」自动保存版本；把链接或导出文件发给推荐人、翻译或律师也极其简单。按状态筛选、用颜色标记，几秒钟就能完成。
专用工具（Notion、Airtable、共享云盘）
Notion 和 Airtable 提供关联视图、提醒功能，并且可以直接在每一行里附加文件，如果有多人同时编辑，或者申请材料牵涉大量相互关联的子文档，这类工具会更方便。对于非常简单的申请，一个有严格文件夹结构和命名规范的共享云盘也可以完全替代追踪表，但它缺少电子表格或数据库那种一眼看清状态的总览能力。
如何选择
用三个问题来决定：需要同时编辑或查看追踪表的人有多少？是否在某些时候需要离线访问？如果某个文件被误覆盖，是否需要找回之前的版本？对于独自申请、只与一两位推荐人以及可能一位翻译打交道的人来说，电子表格足以回答这三个问题。本文后续始终以电子表格布局作为示例，但同样的列结构和逻辑可以直接套用到 Notion 或 Airtable 上，如果你更偏好那些工具的话。
搭建主追踪表：列结构与整体设计
每份文件占一行，所有文件放在同一张表里，设九列。这个阶段不要贪心地把内容拆到多个分页——保持一张扁平的表格，排序、筛选起来更方便，将来转换成exhibit list（证据清单）也更省事。
核心列
| 列名 | 用途 |
|---|---|
| Exhibit # | 编号，即使文件还没生成也先占位，这样后续增加条目时编号不会乱 |
| Document name | 简明描述，例如“Dr. Chen 的推荐信”或“IEEE 论文，2022” |
| Category | 对应petition中使用的证据分类（见下一节） |
| Status | Not started（未开始）/ Drafting（起草中）/ Awaiting signature（待签字）/ Final（定稿） |
| Owner | 下一步该谁行动：本人、推荐人、翻译、雇主HR |
| Date requested | 该文件是何时被要求提供的 |
| Date received | 定稿版本何时到手 |
| File name | 实际保存的确切文件名，而不是笼统写“那封信” |
| Notes | 任何需要跟进的事项——比如缺一页签名，或翻译还没做完 |
实例演示
| Exhibit # | Document name | Category | Status | Owner | Date requested | Date received | File name | Notes |
|---|---|---|---|---|---|---|---|---|
| 3 | Letter, Dr. A. Chen | Recommendation letter | Awaiting signature | Recommender | 2024-01-10 | — | Exhibit-03_RecLetter_Chen_Draft.pdf | 已寄出修改稿 2/2 |
| 7 | Nature paper, 2021 | Published paper | Final | Self | — | 2024-01-05 | Exhibit-07_Paper_Nature2021.pdf | — |
| 9 | Google Scholar profile | Citation record | Final | Self | — | 2024-01-20 | Exhibit-09_CitationReport.pdf | 提交前需重新拉取一次数据 |
| 12 | PhD diploma + evaluation | Degree | Drafting | Translator | 2024-01-15 | — | — | 等待WES（一家常用的学历认证机构）评估结果 |
| 15 | News feature, local outlet | Media coverage | Not started | Self | — | — | — | 联系编辑索取PDF版本 |
让这张表始终保持可见，直接在表里更新状态，而不是靠邮件往来去追踪进度。
按 Kazarian/Dhanasar 证据框架给文件分类
主表中的 Category（分类）这一列不应该随意填写。应使用一组固定的取值，让各行能够整齐地归入大多数 NIW 申请在组装材料时所遵循的结构。这只是为了方便归档和整理——与论证某份文件是否满足某项法律标准无关。
建议使用的分类值
- 身份/个人信息类（Biographical/identity）——护照个人信息页、以往的签证页、当前的 I-94（入境/离境记录）、学位证书、成绩单、学历认证报告。
- 拟从事的事业类（Proposed endeavor）——申请人关于其拟从事事业的陈述、商业计划书、项目说明、专利、基金申请书。
- 国家重要性类（National importance）——发表的论文、引用报告、媒体报道、行业数据、资助奖项、提及该领域的政府或行业报告。
- 具备推进该事业能力类（Well-positioned to advance the endeavor）——简历（CV）、雇佣证明信、学位证书、以往项目成果、演讲或评审邀请函。
- 推荐信类（Recommendation letters）——虽然会在下文所述的子日志中单独跟踪，但为了编号仍需在此处标注该分类。
- 辅助/其他类（Supporting/other）——任何不能清晰归入以上类别的文件（例如专业协会会员记录、执照）。
为什么这一步很重要
当每一行都带有这六个标签之一时，按 Category 筛选或排序主表，就能直接得到大多数申请材料呈现顺序中现成的证据分组。应在文件被加入主表时立即打上标签，而不是留到最后才做——在提交前一周才给五十行文件补分类，正是错误滋生的地方。
单独跟踪推荐信：一个子记录表
推荐信要经过的阶段比其他任何证据材料都多，主表格里单一的"状态"列根本装不下这些细节。为此单独建一个分页（或者在同一张表里划出独立的区块），专门用来跟踪推荐信，每位推荐人占一行。
需要包含的列
| 推荐人姓名 | 所属机构 | 与申请人的关系 | 草稿发送日期 | 签署日期 | 文件名 |
|---|---|---|---|---|---|
| Dr. A. Reyes | MIT, Dept. of EECS | 曾任博士后导师 | 2024-02-10 | 2024-02-28 | Exhibit-04_RecLetter_Reyes_Signed_2024-02-28.pdf |
| Dr. K. Wu | Stanford, independent | 曾引用申请人成果，此前无私交 | 2024-02-14 | — | — |
为什么要单独建一个子记录表，而不是加个状态标签就行
每封推荐信都要经过这几个阶段：确定推荐人、发送草稿、推荐人修改后返回、获得签名、如需公证则完成公证、保存最终 PDF。如果只用一个状态字段，这些环节会被压缩成一个笼统的状态，反而掩盖了信件卡在哪一步——比如某位推荐人六周前收到草稿后就再无音讯，始终没有把修改意见发回来。
常见的失误
当推荐人自己修改草稿时，同一封信的多个版本很容易通过邮件到处流转。如果没有一份记录把具体的文件名和实际签署的版本对应起来，就很容易在提交时误用了未签名或已过时的草稿。只有在拿到已签署的副本后，才把确切的文件名填入表格；任何没有
文件命名与版本控制
跟踪表里的一行数据，价值取决于它指向的那份文件是否可靠。如果文件名混乱不堪（比如“letter final v2 ACTUAL.docx”)，那么只要有两个人碰过同一份文件，跟踪表里的“File name”这一列就立刻失去意义。
命名规则
给每一份最终要用于申请材料的文件，统一采用固定格式：
Exhibit-[编号]_[类别]_[标识]_[状态]_[日期].pdf
例如：Exhibit-07_RecLetter_Smith_Signed_2024-03-15.pdf
拆解如下：
- Exhibit-07 —— 对应跟踪表中的 Exhibit # 编号，这样文件按提交顺序自动排序。
- RecLetter —— 类别标签，与 Category 列一致。
- Smith —— 简短标识（推荐人姓氏、期刊名称，或学位授予院校）。
- Signed —— 状态标签：Draft（草稿）、Signed（已签署）、Notarized（已公证）、Final（定稿）。切勿让这一项含糊不清。
- 2024-03-15 —— 该版本的日期，而不是文件创建的日期。
对非推荐信类的证据材料也应套用同一逻辑，例如：Exhibit-12_CitationReport_GoogleScholar_Final_2024-06-01.pdf。
让草稿与定稿彼此隔离
为每一类文件维护两个文件夹：一个是存放草稿的工作文件夹，另一个是 Final 文件夹，只存放已确认可用于提交的版本。文件一旦进入 Final 文件夹，就不要再编辑或覆盖它——如果需要修改，应保存一个新的、带日期的版本，并同步更新跟踪表中的 Status 和 File name 两列。已提交的版本在申请递交后不应再有任何变动；应原样保留，并连同邮寄或上传的回执一并保存。
每周检查routine与状态标记
跟踪表只有在真正被人查看时才会起作用。每周固定安排15分钟——周日晚上或周一早上对大多数人来说比较合适——逐行检查一遍。
每周检查步骤
- 更新有变动项目的Status（状态）列（Drafting起草中 → Awaiting signature待签字 → Final定稿）。
- 将Date requested（申请日期）与今天的日期对比。任何申请超过两周仍无更新的项目，用红色标出。
- 在标红的项目上添加备注：卡在哪里，在等谁的回复。
- 整理一份简短的待办清单——推荐人签字、引用报告的重新提取、雇主确认信——列出本周需要发送催促邮件的事项。
- 在合上电脑前把这些催促邮件发出去。一个被标记却始终没人去催的行，会永远停留在标记状态。
用日历提醒，而不是靠记忆
不要指望自己能记住谁还欠你什么文件。每次提出文件申请时，设置一个两周后的日历提醒，标题中注明exhibit（证据）编号和联系人（例如：
从追踪表到证据目录：最后的交接
一旦主追踪表里每一行的状态都显示为“Final（终稿）”，这份追踪表就不再是工作文档，而变成证据目录（exhibit list）本身的来源。把“Exhibit #”和“Document name”这两列按你打算提交的顺序排好，几乎可以直接转换成放在申请材料册子或PDF最前面的目录页。把这两列复制到一个新表格，或者放到装订好的文件第一页，等最终PDF完成分页后加上页码，这就是你的证据目录了。
提交前的最后交叉核对
提交之前，再做一遍最后的核对：
- 打印或导出追踪表，筛选出状态为Final的行。
- 打开装订好的PDF（或纸质文件叠），逐个证据核对。
- 对每一份证据，确认追踪表中该行的文件名与最终装订中实际使用的文件完全一致——而不是草稿或旧版本。
- 检查证据编号是否连续，没有跳号或重复。
- 确认追踪表中的每一行在文件叠中都能找到对应的证据，文件叠中的每一份证据也都能在追踪表中找到对应的行——重复文件或“孤儿文件”通常就是在这一步被发现的。
这一步能揪出的常见错误
- 编辑过程中重新编号的证据，但追踪表或目录页没有同步更新。
- 推荐信的签字终稿在汇编时被误换成了较早的草稿。
- 追踪表中标记为Final的文件，实际上从未被插入到最终装订的PDF里。
这次交叉核对，是追踪表最后一次作为控制性文档发挥作用的时刻——在此之后，它就不再是规划工具，而是核验凭据。