为什么印度出生的IT与工程专业人士面临不同的申请局面
移民法规定，任何单一出生国的移民签证发放数量，上限为当年职业类别签证总配额的7%，不论该国申请人实际占申请总量的比例是多少。由于印度出生的专业人士提交的EB-2申请数量，相对于这7%的上限而言，占比过高，EB-2 India类别的需求经常性地超过供给，由此形成的排期积压往往以年计，而非以月计。这一积压情况通过"final action date"（最终裁定日，即USCIS每月公布的截止日期，用来判断哪些申请人的priority date，即USCIS收到基础申请的日期，已经排到，可以进入下一步签证程序）来追踪。
这一制度影响什么、不影响什么
国别配额上限决定的是，已获批准的申请人何时可以提交Form I-485（身份调整申请）或进入领事程序处理，它与Form I-140本身是否获批毫无关系。USCIS对每一位申请人的I-140都按照同一套Dhanasar标准进行审查，与出生国无关。一份文件准备充分、论证扎实的申请，不论来自印度出生的工程师，还是其他任何国家的申请人，所适用的审查标准都是一样的。
行动建议
提交申请前，请在travel.state.gov查阅当月最新的Visa Bulletin（签证公告），找到EB-2类别下印度（India）一栏对应的最终裁定日期。如果你已经持有priority date，应每月复查一次该日期，因为它影响的是时间规划，而不影响你随I-140提交的实质性材料内容。
把技术职业对应到 Dhanasar 三项标准
Dhanasar 框架提出三个各自独立的问题，技术类工作必须分别对应到每一项上——仅有一个职位名称，对这三项都无法作出回答。
第一项：具有实质性价值与国家重要性（substantial merit and national importance)
描述的应该是“事业”(endeavor）本身，而不是职位。“提升金融行业客户所依赖的云基础设施的抗故障能力”指向的是国家重要性；“某公司高级 SRE（站点可靠性工程师）”则不能。同理，半导体供应链方面的工作可以围绕国内芯片制造产能来阐述，网络安全工作可以围绕关键基础设施行业（能源、医疗、金融）的保护来阐述，AI 模型部署工作可以围绕安全性、可靠性或对整个行业的生产力影响来阐述。
第二项：具备推动该事业的良好条件（well-positioned to advance it)
这一项对应的是资历、履历以及过往可量化的成果——学位、专利、论文发表、曾经大规模成功部署的经历。
第三项：豁免雇主担保对国家有利（benefit of waiving the job offer)
说明为什么要求获得特定雇主的劳工证（labor certification）会削弱这项事业本身——例如，工作跨越多个雇主、开源贡献、或某项独立研究无法被任何单一职位所涵盖的情况。
撰写事业陈述（endeavor statement)
单独写一段话，与任何职位描述分开，用结果导向的语言陈述该事业，并指明雇主之外的受益方是谁——某个行业、某类用户群体、某项监管或安全目标，或是公众。避免使用晋升、绩效评分等公司内部指标；应使用在公司外部可见的影响作为衡量标准。
软件、硬件与系统工程岗位的专项证据类别
公开记录类证据
- 开源贡献：导出 GitHub/GitLab 个人主页的统计数据（贡献图、star 数、fork 数、已合并的 pull request），并附上申请人担任维护者（maintainer）或主要贡献者的仓库。截图时确保贡献记录上的日期清晰可见。
- 专利：直接从 USPTO Patent Public Search（美国专利商标局专利公开检索系统）或相应的外国专利机构（例如印度的 IP India 官方平台）下载 PDF 文件；如条件允许，应提交已授权的专利文件，而非仅仅是申请文件。
- 论文与引用：列出 IEEE/ACM 论文并附 DOI 链接，同时生成一份 Google Scholar 引用报告，显示提交申请时的引用次数与 h-index（衡量学术影响力的指数）。
- 讲座与标准制定工作：会议议程列表、演讲录像，或标准组织会议纪要中体现申请人具名参与的记录。
- 会员等级：IEEE Senior Member（高级会员）或同等晋升信函，这类文件可以证明申请人经过了独立的同行评审。
雇主内部持有的证据
架构设计文档、故障复盘报告（incident postmortem）、性能基准测试数据等资料通常不会离开公司内部。若要使用这类材料，可按以下步骤操作：
- 明确一个具体的、可衡量的成果（例如系统正常运行时间的提升、延迟的降低、成本节约、吞吐量的增长）。
- 请主管或技术负责人撰写一封信函，对该成果进行量化说明，并注明部署的范围（受影响的用户数、系统数或覆盖地区）。
- 在保密条件允许的情况下，附上该内部文档的脱敏（redacted）版本作为支持性证据材料，并在信函中交叉引用。
带有量化数据、且能明确归属于申请人本人的陈述，比泛泛描述岗位职责的说法更有说服力。
组建推荐信阵容：该找谁写，每封信要写什么
这类背景的申请通常会附上数封推荐信，一般会混合几类人：直属主管、跨职能的合作者（产品经理、相邻团队的架构师），以及独立专家——教授、标准组织成员，或者从未与申请人共事过的其他公司工程师。独立这一组之所以重要，是因为它证明了认可度超出了申请人自己的汇报线之外。
每封信必须写明的内容
- 推荐人自己的资历和角色——职位、从业年限、为什么有资格评判这项工作。
- 推荐人如何了解申请人的工作——直接管理、代码审查、共同参与标准委员会、引用已发表的研究成果、会议同场交流等。
- 与申请人的 endeavor statement（事业陈述，即对所从事工作的national importance和影响的书面陈述）相对应的具体、量化的论述：系统处理的请求量、延迟降低的具体百分比、某项专利的权利要求及其实际应用情况、某篇论文的引用次数。避免单独使用“brilliant”（才华横溢）、“exceptional”（杰出）之类的形容词——每一项论述都应搭配一个具体数字、系统名称或有日期可查的事件。
避免落入模板陷阱
为每封信单独起草一份事实提纲，而不是把同一份模板信发给所有推荐人签字了事。每位推荐人应当用自己的语言、自己的句式和用词来写。审案官员会横向比对同一份申请里的多封信，如果几位号称互不相识的推荐人写出了几乎相同的措辞、相同的段落顺序，或者反复出现同样的特殊表达方式，这是公认会触发 RFE（Request for Evidence，要求补充证据）的信号。
撰写个人陈述，并与 Form I-140 及 ETA-9089 式劳动力市场数据相互印证
陈述的结构
个人陈述应写成一条叙事线索，而不是把简历改写成散文体。建议按以下五个部分展开：(1) 技术方向的缘起；(2) 该领域存在的具体问题或空白；(3) 申请人的贡献；(4) 证明这一贡献影响超出单一雇主范围的证据；(5) 与前文撰写的“事业陈述”（endeavor statement）相衔接的未来计划。每一部分都应标注对应的具体证据编号，这样审查官员（reader，即办案官员）无需逐页翻找就能核实每一项陈述。
在没有劳工认证的情况下使用劳动力市场数据
NIW 申请豁免了 PERM（劳工认证）流程，因此不需要提交 ETA-9089 表格——但 PERM 本应记录的劳动力市场背景信息，仍可以用来支持“国家重要性”这一项标准（prong）。可以引用与该职业对应的 O*NET-SOC 代码（例如软件开发人员对应 15-1252.00，各类系统/工程类职位对应 17-2199.xx 或 15-1299.xx），并结合美国劳工部（Department of Labor）关于就业增长预测或该代码对应的现行工资水平（prevailing wage levels）的数据加以引用。这类数据应当用来说明该领域的规模与需求，而不是用来论证申请人个人是否达到某一工资等级的资格。
到哪里查找最新代码与数据
可在 onetonline.org 上查询当前的 O*NET-SOC 代码及职业说明。至于现行工资水平和职业前景数据，可使用美国劳工部的 Foreign Labor Certification Data Center（flcdatacenter.com）以及美国劳工统计局（Bureau of Labor Statistics）编制的 Occupational Outlook Handbook——这两个来源均会定期更新，因此应在递交申请当下重新查询最新版本，而不要依赖此前保存的旧数据。
整理证据索引与申请材料包
证据索引（exhibit index）是唯一能让审案官员在不用翻遍几百页材料的情况下找到每一份证据的文件。如果申请人省略了这一步，或者把证据材料埋在冗长、没有标注的 PDF 里，等于是逼着审案官自己去找——而找不到的证据，在快速审阅的意义上，等同于不存在。
为什么结构在这里格外重要
Dhanasar 框架下的申请依赖来自多种不同来源的证据：代码仓库、专利文件、会议论文、内部备忘录、推荐信。正因为这些证据的格式并不统一，把秩序强加于其上的责任就落在了申请人身上。审阅者应当能够打开索引，看清某一份证据支持哪一项标准（prong），然后直接跳到对应页面。
在组装材料之前先定好整包的逻辑
在打印或合并 PDF 之前，先确定：
- 一套稳定的证据编号或编字方案，一旦推荐信写好之后就不需要再改动。
- 每份证据分别对应哪一项（或哪几项）标准。
- 哪些文件在收录之前需要经过认证翻译。
- 重复出现的证据（例如同一件专利既在推荐信中被引用，又单独作为一份证据）应当以互相引用的方式处理，而不是重复放入材料包。
下一节会用一个具体的表格和文件命名方案，把这套逻辑落到实处。
Organizing the exhibit index and filing packet
Build the exhibit index first
在扫描任何一份文件之前，先把 exhibit index（证据目录）草拟出来。这份目录是审核官翻阅整个材料包时用的地图，同时它也会逼着你提前发现证据链上的缺口。
| 证据编号 | 描述 | 来源 | 页数 | 支持的 Prong |
|---|---|---|---|---|
| A | US Patent 11,234,567 —— 分布式缓存方法 | USPTO（美国专利商标局） | 12 | Prong 1 |
| B | R. Iyer 博士（IEEE Senior Member，独立推荐人）推荐信 | 推荐人 | 3 | Prong 2 |
| C | 架构设计文档，延迟降低 40% | 雇主内部记录 | 8 | Prong 1、2 |
| D | GitHub 贡献汇总，1,200 星标 | github.com | 4 | Prong 2 |
| E | 会议论文，IEEE INFOCOM，被引 35 次 | Google Scholar / IEEE Xplore | 6 | Prong 1 |
| F | 学位证书 + 经认证的英文翻译件 | 学校、译者 | 2 | 辅助材料 |
File naming
采用统一的命名规则：Exhibit_A_Patent_US1234567.pdf、Exhibit_B_Letter_Iyer.pdf。避免使用 scan001.pdf 这类通用文件名——无论是审核官还是你自己，都会因为要对照目录逐一核对而浪费时间。
Assembly order
- 概述整个申请并列出各项证据的求职信（cover letter）
- Form I-140
- 各项证据，按目录顺序排列
- 个人陈述
- 推荐信
- 印度签发文件（学位证书、工作证明信等）的翻译件及认证文件，每份翻译件须附上译者出具的准确性与资质认证声明，具体格式以 USCIS 现行说明为准——提交前请在 uscis.gov 上核实相关要求。
这类申请人常见的 RFE（Request for Evidence，即“补充证据通知”）触发点及预防方法
少数几个反复出现的问题，导致了这类申请人绝大多数的 RFE。
内容空泛
一份换成任何一位软件工程师或硬件设计师都能套用的个人陈述——没有具体技术名称、没有具体部署场景、没有可衡量的成果——读起来就显得千篇一律、可替代性强。每一项主张都应该能追溯到某个具体项目、系统或出版物，并且这些项目、系统或出版物也应出现在证据索引中。
只有形容词的推荐信
推荐信中只说申请人“才华横溢”“出类拔萃”“关键贡献者”，却没有附上任何数字（服务用户数、延迟降低幅度、部署系统数量、论文被引次数），很容易招致审查人员的质疑。每封信都应至少包含一项可量化、可核实的具体主张。
缺少翻译认证
印度高校的成绩单、学位证书和工作证明如果以英文译本提交，却没有附上译者对准确性和资质的认证声明，是一个高频且完全可以避免的 RFE 起因。提交前请确认每一份翻译文件都附有经签署的认证页。
独立证据薄弱
如果整份证据几乎全部来自雇主出具的信件和内部文件，缺乏引用、专利、独立评审人，或来自申请人汇报体系之外的专业认可，审查人员会质疑这份记录是否真实反映了申请人的个人水平。
将公司业绩与个人角色混为一谈
仅描述雇主的营收、市场份额或产品普及情况，而不将申请人的具体贡献单独剥离出来说明，会使申请人的个人角色变得模糊不清。
最后检查
提交前，请按照三项 Dhanasar 标准逐一核对证据索引，确认每一项标准都由不止一种独立类型的证据支持。