npm stage-only 令牌：分离部署自动化与最终审批时应保留的凭据
将 CI 构建软件包的权限与向用户公开发布该软件包的权限分离，能够使发布的最终责任更加明确。然而，仅仅增加一个审批按钮并不意味着供应链风险就此消失。首先必须明确审批者需要核查的内容。
GitHub 于 9 月 18 日宣布，可以在 npm 细粒度访问令牌（granular access token）中选择 stage-only 写入权限。其工作流程是由自动化流程将新版本提交至待审查状态，再由维护者通过双重身份验证（2FA）批准发布。以下内容区分了官方变更与将其投入实际运维的编辑部建议。
拦截直接发布与移除写入权限是两回事
根据官方说明，使用该令牌可以执行 npm stage publish，但通过 npm publish 进行的直接公开将被拒绝。即使配置了用于自动化的 2FA 绕过设置，该限制依然有效。此功能并不会自动更改现有令牌的行为，而是由团队自主选择引入。
需要注意的是，移动 dist-tag 和废弃版本（deprecation）等其他软件包写入权限依然保留。绝不能因为名称为 stage-only 就将其理解为只读或无害的令牌。团队仍需严格管理允许的软件包范围、机密存储位置、使用主体以及吊销流程。
确定审批者比对所需的发布物料组合
以下内容并非 npm 的强制要求，而是面向小型团队的运维建议。请在单个审批请求中附带源码 commit、目标软件包与版本、测试结果、包含在包内的文件列表以及变更摘要。如果审批者必须在多处 CI 日志中拼凑证据，审查流程就很容易沦为走形式的点击。
特别是，源代码审查与分发文件审查不可混为一谈。构建过程中可能会打包进代码仓库中原本没有的文件，也可能会遗漏必要文件。团队应以实际提交的构建产物为基准生成审查资料，并确立一项原则：一旦审查后产物发生更改，必须将其视为全新的审查对象。
CI 变绿之后仍存在等待状态
如果现有自动化流程将命令执行成功直接报告为发布完成，则首先需要调整状态表达方式。应当划分为“提交完成”、“等待审批”、“发布完成”，并分别记录各自的确认凭据。在通知中注明当前阶段和负责人，比单纯显示“成功”一词对运维人员要有用得多。
举个假设的例子：如果夜间 CI 提交了新版本，但负责人要到次日才进行审查，那么在提交时就不应向用户发送发布公告。应当在完成团队约定的公开确认之后，再顺次发布文档或公告。团队还应提前就队列积压时由谁来审查、何时清理旧提交达成一致。
使用单个小型软件包验证迁移
目前官方说明中的前置条件包括：现有的 npm 软件包、软件包发布权限、账号 2FA、npm CLI 11.15.0 及以上版本，以及 Node.js 22.14.0 及以上版本。在实际迁移之前，应再次查阅最新文档，并检查所使用的 runner 版本。
建议首先在一个影响面较小的软件包上限制令牌作用域，并完整演练 staging 提交、维护者审查以及确认发布结果的整个流程。如果一旦失败就立刻回退绕道至权限广泛的旧令牌，那么划分的安全边界便形同虚设。系统也必须能够将审批延迟视为一种正常状态来处理。
与 trusted publishing 对比需要考虑的问题
npm 还提供了基于 OIDC 的 trusted publishing。首先应考察它是否适配受支持的 CI 环境以及团队的审批模式，并没有理由将 stage-only 令牌视作适用于所有团队的终极解法。对于必须继续使用令牌的自动化流程而言，这可以被视为提供了一个分步迁移的可选方案。
官方公告指出，其目标是在 2027 年 1 月前取消 bypass-2FA 令牌的直接发布能力。与其推测所有未确定的实现细节，不如现在就整理出目标工作流清单及迁移负责人，这会更加务实。后续仍需关注官方公告以确认日程是否有变。
评估是否引入时
本文并非主张这已成为社区的广泛共识，亦不保证实际事故率会有所降低，而是基于新功能的官方运行机制，提出一套可供审查的运维流程建议。能否清晰界定自动化负责的工作与人工需要核实的内容，是判断是否引入的出发点。
今天可以着手开展的工作包括：找出当前使用发布令牌的位置、明确判定发布完成的条件，以及规定单次审批所需的证明材料。只有将权限限制与审查质量结合起来，staging 阶段才能真正发挥作用。