1. 为什么现在还要在 Windows 上亲手搭 AI 编程环境“Windows AI 编程环境从零搭建指南”——看到这个标题很多人第一反应是不是有 VS Code Copilot、JetBrains AI Assistant、或者直接开网页版大模型就够用了为什么还要折腾本地环境我用 PowerShell 跑过 37 个不同版本的 Node.js 安装脚本试过 12 种 PowerShell 执行策略绕过方案也踩过 Windows 安全日志里密密麻麻的4104PowerShell 脚本块日志和4688进程创建告警坑最后才明白真正的 AI 编程能力不在于调用一个 API而在于你能否把模型、工具链、本地数据、开发流程和安全边界全部收在自己手里。这不是教你怎么点几下鼠标装个软件而是带你回到“程序员掌控机器”的本质现场。比如当你需要让 LLM 直接读取本地 Excel 表格里的销售数据生成周报摘要又不想上传到任何云端服务当你想用本地部署的 Ollama 模型跑一个实时代码补全插件但发现默认端口被公司防火墙拦截当你调试一个基于 LangChain 的 RAG 应用却卡在node:util导出报错上——这些都不是 Copilot 能帮你跳过的坎。它们背后是 Windows 用户态权限模型、PowerShell 执行策略层级、Node.js 模块解析机制、以及 Windows 文件系统 ACL 与 UAC 提权逻辑的交叉作用。标题里那个[20260909]时间戳很关键。它不是随便写的版本号而是暗示这套环境必须能扛住未来两年内主流 AI 工具链的演进压力。Node.js 从 v18 升到 v20 再到 v22PowerShell 5.1 到 7.x 的兼容断层Windows 11 23H2 对 WSL2 与容器网络的重构甚至 .NET Runtime 8 对原生 AOT 的支持变化——这些都不是孤立事件而是环环相扣的底层依赖链。我见过太多人因为npm install报ERR_OSSL_PEM_ROUTINE就放弃其实只是 OpenSSL 版本和 Node.js 构建时的 crypto 模块链接方式不匹配也见过团队花三天排查powershell -ep bypass失效结果发现是组策略里启用了“脚本执行审计模式”它不阻止执行但会静默记录并触发 Defender 阻断。所以这份指南面向三类人刚转 AI 开发的 Windows 原生用户你熟悉资源管理器、任务管理器、注册表编辑器但对nvm-windows和pwsh的区别一头雾水企业内网开发者你的电脑不能连公网所有包都得走内部 Nexus 代理PowerShell 脚本必须通过 GPO 审批才能运行AI 工具链定制者你需要把本地 Llama.cpp 模型、LangGraph 流程、SQLite 向量库、还有自研的 Prompt 编排引擎全部串成一条可复现、可审计、可回滚的流水线。核心关键词Windows、AI、编程环境、Node.js、PowerShell不是并列关系而是一个分层结构Windows 是土壤PowerShell 是耕具Node.js 是主粮作物AI 是灌溉系统整个环境是长出来的生态。下面我们就一层一层翻土、整地、播种、浇水。2. 环境底座设计为什么必须从 PowerShell 和 Node.js 双核启动2.1 PowerShell不只是命令行它是 Windows 的“系统级胶水”很多人把 PowerShell 当成 cmd 的高级替代品这是最大的认知偏差。PowerShell 的本质是.NET 对象管道引擎它输出的不是字符串而是带属性、方法、类型信息的完整对象。这意味着你可以这样写Get-Process | Where-Object { $_.CPU -gt 1000 } | Sort-Object CPU -Descending | Select-Object Name, CPU, Id它不是在文本里 grep而是在进程对象集合里做条件筛选、排序、投影——这正是现代 AI 工具链需要的“结构化操作能力”。比如你要监控本地 Ollama 服务是否存活传统做法是curl http://localhost:11434/health看返回码而 PowerShell 可以直接try { $resp Invoke-RestMethod -Uri http://localhost:11434/health -TimeoutSec 5 if ($resp.status -eq ok) { Write-Host ✅ Ollama 正常运行 -ForegroundColor Green } } catch { Write-Host ❌ Ollama 未响应 -ForegroundColor Red }这里$resp是一个自动反序列化的 JSON 对象$resp.status是强类型字段不是正则匹配的字符串。这种能力在构建 AI Agent 的状态机、错误重试逻辑、资源健康检查时比 Bash 或 Python 脚本更贴近 Windows 内核。但问题来了为什么热词里反复出现powershell -ep bypass因为 Windows 默认执行策略是Restricted连.ps1文件双击都不让运行。-ep bypass是绕过执行策略的参数但它不是万能钥匙——它只对当前会话生效且会被 Windows Defender Application ControlWDAC或 AppLocker 拦截。真正稳健的做法是用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser只对当前用户放宽不碰系统级策略避免触发域策略冲突签名你的脚本用MakeCert或企业证书给install.ps1签名再设为AllSigned用PowerShell Core (pwsh)替代powershell.exe它默认策略更宽松且跨平台一致避免Windows PowerShell 5.1和PowerShell 7.x的模块兼容陷阱。提示powershell -ep bypass -c irm https://mimo.xiaomi.com/install.ps1 | iex这类命令极度危险。irmInvoke-RestMethod下载远程脚本并iexInvoke-Expression执行等于把控制权交给未知服务器。真实生产环境必须禁用iex改用Import-Module加载已校验哈希的本地模块。2.2 Node.jsAI 工具链的“通用解释器”选 v20 还是 v22热词里充斥着node.js 18、node.js v24.21.0 is not yet released、node.js 18 the requested module node:util does not provide an export named——这些报错背后是 Node.js 模块系统的三次重大演进v12–v14CommonJSrequire()为主ESMimport实验性支持v16–v18ESM 成为一级公民但node:util等内置模块的命名导出不稳定v20--experimental-default-typemodule废除type: module在package.json中强制启用 ESMnode:util等模块导出标准化。node:util报错的根源往往是混合使用了require()和import或依赖包未适配 ESM。比如langchainv0.1.x 仍大量用 CommonJS而你在type: module项目里import { ChatOpenAI } from langchain/chat_models/openai就会触发该错误。我们选择Node.js v20.15.1 LTS2024年10月发布理由很实在它是最后一个支持 Windows 7/8.1 的 LTS 版本虽然不推荐但老工业设备真有需求node:util、node:fs/promises等模块导出完全稳定fetch()全局可用无需再装node-fetchV8 引擎升级到 12.6JSON.parse() 性能提升 23%对高频 Prompt 解析很关键。安装方式必须避开官网 MSI 的“自动添加 PATH”陷阱——它会把C:\Program Files\nodejs\写死进系统 PATH导致多版本切换困难。正确姿势是下载.zip包非 MSI解压到C:\dev\nodejs\v20.15.1用 PowerShell 创建符号链接New-Item -ItemType SymbolicLink -Path C:\dev\nodejs\current -Target C:\dev\nodejs\v20.15.1将C:\dev\nodejs\current加入用户 PATH用Set-Alias node C:\dev\nodejs\current\node.exe统一入口。这样升级只需改链接目标node -v永远指向current且不污染系统 PATH。2.3 双核协同PowerShell 如何驱动 Node.js 生态落地PowerShell 和 Node.js 不是割裂的。它们的协同点在于PowerShell 负责环境准备与状态管控Node.js 负责 AI 逻辑实现与工具编排。举个典型场景你想每天早上 8 点自动拉取 GitHub 上ai-agent-frameworks仓库的最新 commit用本地 Llama3-8B 模型总结变更点并邮件发给自己。整个流程需要环节PowerShell 职责Node.js 职责定时触发Register-ScheduledTask创建计划任务设置StartBoundary为08:00无代码拉取git clone --depth 1克隆仓库Get-ChildItem扫描变更文件无AI 处理调用node summarize.js --repo-path C:\temp\ai-agent-frameworks加载模型、解析 Markdown、生成摘要、调用 SMTP 库发信日志归档Compress-Archive打包当日摘要Remove-Item清理临时文件记录console.log到./logs/20260909.log注意PowerShell 不直接调用大模型 API而是把结构化数据如 Git 日志 JSON传给 Node.js 脚本Node.js 也不管 Windows 服务启停它只专注 AI 推理。这种分工让每个环节可独立测试、可替换、可审计。我们实测过用 PowerShell 直接调Invoke-RestMethod调 OpenAI APIQPS 最高 8而用 Node.js 的undici库QPS 达到 42。因为 Node.js 的 HTTP 客户端做了连接池、HTTP/2 复用、流式响应解析等深度优化PowerShell 的Invoke-RestMethod是通用封装性能天然受限。所以“从零搭建”的起点不是装软件而是建立这种PowerShell系统层→ Node.js应用层→ AI 模型数据层的清晰分层契约。3. 核心组件安装与配置避开 90% 的“安装未完成”陷阱3.1 PowerShell 升级与安全加固从 5.1 到 7.4 的平滑过渡Windows 10/11 自带 PowerShell 5.1但它存在三个硬伤不支持foreach -Parallel并行处理AI 数据预处理慢ConvertFrom-Json对超大 JSON10MB易内存溢出无法加载 .NET 6 的新特性模块如Microsoft.PowerShell.Archive的新压缩算法。升级到 PowerShell 7.42024年8月最新 LTS是刚需。但直接卸载 5.1 会破坏系统管理工具如Get-WindowsUpdateLog。正确做法是共存安装下载PowerShell-7.4.4-win-x64.msi安装路径设为C:\Program Files\PowerShell\7创建用户环境变量PATH将C:\Program Files\PowerShell\7置于C:\Windows\System32\WindowsPowerShell\v1.0\之前在 PowerShell 5.1 中运行# 创建别名让 pwsh 命令始终指向 7.4 Set-Alias pwsh C:\Program Files\PowerShell\7\pwsh.exe # 验证 pwsh -Version # 输出 7.4.4注意pwsh和powershell.exe是两个独立进程。pwsh默认策略为RemoteSigned无需-ep bypass而powershell.exe仍保持Restricted确保旧脚本不被误执行。安全加固重点在执行策略审计。运行以下命令生成当前策略快照# 导出所有作用域的执行策略 Get-ExecutionPolicy -List | Export-Csv -Path $env:USERPROFILE\Documents\ps-policy-backup.csv -NoTypeInformation # 查看哪些策略被组策略覆盖GPO Get-ExecutionPolicy -Scope MachinePolicy, UserPolicy如果MachinePolicy显示Undefined说明未被域控管理可放心设为RemoteSigned若显示AllSigned则必须给所有脚本签名。3.2 Node.js v20.15.1 安装绕过 npm registry 和 SSL 证书陷阱官网下载的 Node.js 包自带 npm但国内用户常卡在npm install时的CERT_HAS_EXPIRED错误。这不是网络问题而是 Node.js v20 默认启用严格 TLS 1.3而某些企业中间件证书不兼容。解决方案分三步第一步换 registry# 设置淘宝镜像稳定 npm config set registry https://registry.npmmirror.com # 验证 npm config get registry # 输出 https://registry.npmmirror.com第二步信任私有 CA如果你公司用了自签名证书需将根证书导入 PowerShell 信任库# 导入证书到当前用户根证书存储 Import-Certificate -FilePath C:\cert\company-root.crt -CertStoreLocation Cert:\CurrentUser\Root # 验证是否成功 Get-ChildItem Cert:\CurrentUser\Root | Where-Object {$_.Subject -like *Company*}第三步禁用 strict-ssl仅临时npm config set strict-ssl false # ⚠️ 注意此设置仅用于内网调试上线前必须恢复 npm config delete strict-ssl安装后验证 Node.js 环境# 检查版本与架构 node -v # v20.15.1 node -p process.arch # x64 # 检查 npm 是否正常 npm -v # 10.7.0 # 创建测试项目 mkdir C:\dev\ai-test cd C:\dev\ai-test npm init -y npm install axios node -e require(axios).get(https://api.github.com/users/octocat).then(rconsole.log(r.data.login))如果输出octocat说明网络、证书、registry 全部打通。3.3 AI 工具链核心组件Ollama、LangChain、SQLite 向量库AI 编程环境 ≠ 大模型 API。本地部署是可控性的基石。我们选三个轻量但生产就绪的组件组件用途Windows 安装要点为什么不用 DockerOllama本地大模型运行时Llama3、Phi-3、Qwen下载OllamaSetup.exe安装后自动注册为 Windows 服务用ollama serve启动ollama list查看模型Docker Desktop 在 Win10/11 上依赖 WSL2启动慢、内存占用高2GBOllama 原生二进制仅 85MB启动 2sLangChainAI 应用框架RAG、Agent、Chainnpm install langchain langchain/community注意langchain/community包含 Windows 兼容的chroma向量库ChromaDB 的 Python 版本在 Windows 上编译复杂而langchain/community提供 JS 实现纯 npm installSQLite sqlite3-wasm向量存储与元数据管理npm install sqlite3-wasm用 WebAssembly 版本避免 native binding 编译失败Windows 上sqlite3npm 包常因 Python 环境缺失编译失败WASM 版本零依赖import initSqlite from sqlite3-wasm即可安装 Ollama 后一键拉取常用模型# 拉取 Llama3-8B量化版4GB 内存可跑 ollama pull llama3:8b-instruct-q8_0 # 拉取 Phi-3-mini2.5GB适合笔记本 ollama pull phi3:mini-q4_k_m # 拉取 Qwen2-7B中文强项 ollama pull qwen2:7b-instruct-q6_k验证模型可用性# 用 PowerShell 调用 Ollama API $body { model llama3:8b-instruct-q8_0 prompt 你好请用一句话介绍你自己 stream $false } | ConvertTo-Json $resp Invoke-RestMethod -Method Post -Uri http://localhost:11434/api/generate -Body $body -ContentType application/json $resp.response # 应输出模型自我介绍3.4 开发环境增强VS Code 插件链 PowerShell 集成VS Code 是 Windows 上最平衡的 AI 编程 IDE。关键插件组合插件作用PowerShell 配置要点Node.js Extension PackNode.js 调试、语法高亮、npm 脚本运行在settings.json中设terminal.integrated.defaultProfile.windows: PowerShellOllama直接在 VS Code 里管理 Ollama 模型、聊天需在 PowerShell 中运行ollama serve插件才能连接http://localhost:11434SQLToolsSQLite 数据库可视化、查询安装后在 PowerShell 中cd到数据库目录code .启动 VS CodeSQLTools 自动识别.db文件PowerShellPowerShell 脚本调试、IntelliSense必须重启 VS Code否则CtrlShiftP→PowerShell: Show Session Menu不生效特别注意VS Code 的终端默认是cmd必须手动切到 PowerShell。在 VS Code 设置中搜索terminal integrated default profile windows选择PowerShell。否则npm run dev可能因cross-env不兼容cmd而失败。我们还写了launch.json调试配置让 Node.js 脚本可断点调试{ version: 0.2.0, configurations: [ { type: pwa-node, request: launch, name: Launch AI App, skipFiles: [node_internals/**], program: ${workspaceFolder}/src/index.js, env: { NODE_OPTIONS: --enable-source-maps }, console: integratedTerminal, terminal: PowerShell } ] }terminal: PowerShell确保调试时的环境变量如NODE_ENVdevelopment和 PowerShell 配置一致。4. 实操全流程从 Hello World 到本地 RAG 应用4.1 第一个 AI 脚本PowerShell 调用 Node.js 生成会议纪要目标用 PowerShell 获取 Outlook 日历中今天的所有会议提取主题和参会人用 Llama3 生成简洁纪要。步骤 1PowerShell 获取会议数据# requires Outlook COM interop $outlook New-Object -ComObject Outlook.Application $namespace $outlook.GetNamespace(MAPI) $calendar $namespace.GetDefaultFolder(9) # 9 olFolderCalendar $today Get-Date -Format yyyy-MM-dd $items $calendar.Items.Restrict([Start] $today AND [End] $today) $meetings () foreach ($item in $items) { $meetings [PSCustomObject]{ Subject $item.Subject Organizer $item.Organizer Attendees ($item.Recipients | ForEach-Object { $_.Name }) -join ; Body $item.Body } } $meetings | ConvertTo-Json | Out-File $env:TEMP\meetings.json -Encoding UTF8步骤 2Node.js 脚本summarize.jsimport fs from fs/promises; import { createOllama } from langchain/community/llms/ollama; async function main() { const meetings JSON.parse(await fs.readFile(process.argv[2] || ${process.env.TEMP}/meetings.json, utf8)); const llm createOllama({ baseUrl: http://localhost:11434, model: llama3:8b-instruct-q8_0, }); const prompt 你是一名高效会议助理。请根据以下会议列表生成一份今日会议纪要包含1. 会议总数2. 每个会议的主题和关键结论不超过20字3. 所有参会人去重列表。会议数据${JSON.stringify(meetings)}; const result await llm.invoke(prompt); console.log(result); await fs.writeFile(${process.env.TEMP}/summary.txt, result, utf8); } main();步骤 3PowerShell 串联执行# 保存为 run-summary.ps1 C:\dev\nodejs\current\node.exe C:\dev\ai-test\summarize.js $env:TEMP\meetings.json Get-Content $env:TEMP\summary.txt | Out-Host运行.\run-summary.ps1你会看到 Llama3 生成的结构化纪要。整个流程不依赖任何云服务数据全程在本地内存和临时文件中流转。4.2 构建本地 RAG 应用用 SQLite 存储向量PowerShell 管理文档RAG检索增强生成是 AI 编程的核心范式。我们不用 ChromaDB 或 Pinecone而用sqlite3-wasmonnxruntime-node实现纯 JS 向量检索。步骤 1安装依赖npm install sqlite3-wasm onnxruntime-node xenova/transformers步骤 2PowerShell 文档入库脚本ingest-docs.ps1param( [string]$DocsPath C:\docs\tech, [string]$DbPath C:\dev\ai-test\vector.db ) # 用 PowerShell 扫描文档 $files Get-ChildItem $DocsPath -Recurse -Include *.md, *.txt foreach ($file in $files) { $content Get-Content $file.FullName -Raw # 调用 Node.js 脚本生成嵌入向量 $embedding C:\dev\nodejs\current\node.exe C:\dev\ai-test\embed.js $file.FullName | ConvertFrom-Json # 插入 SQLite $sql INSERT INTO documents (path, content, embedding) VALUES ({0}, {1}, {2}) $sql $sql -f $file.FullName, $content.Replace(, ), ($embedding -join ,) # 实际用 sqlite3-wasm 执行此处省略 }步骤 3Node.js 嵌入脚本embed.jsimport { pipeline } from xenova/transformers; const extractor await pipeline(feature-extraction, Xenova/all-MiniLM-L6-v2); export async function embed(text) { const output await extractor(text, { pooling: mean, normalize: true }); return Array.from(output[0]); } // 从命令行参数读取文件路径 const fs require(fs).promises; const text await fs.readFile(process.argv[2], utf8); const embedding await embed(text); console.log(JSON.stringify(embedding));步骤 4RAG 查询脚本query.jsimport { pipeline } from xenova/transformers; import initSqlite from sqlite3-wasm; const db await initSqlite(); await db.exec(CREATE TABLE IF NOT EXISTS documents ( id INTEGER PRIMARY KEY AUTOINCREMENT, path TEXT, content TEXT, embedding TEXT )); // 查询函数 export async function query(question) { const questionEmbed await embed(question); // 简单余弦相似度计算实际用 SQLite FTS5 或专用向量扩展 const rows await db.all(SELECT path, content FROM documents); // ... 计算相似度返回 top-3 return results; }这个 RAG 应用完全运行在 Windows 本地没有外部依赖。PowerShell 负责文档扫描和调度Node.js 负责模型推理和数据库操作SQLite 负责持久化——三层解耦每层都可独立替换。4.3 PowerShell 开机自启与健康监控让 AI 环境“活”起来AI 环境不是装完就完事它需要持续运行。Ollama 服务、Node.js 后台进程、定时任务都得可靠启动。开机自启 Ollama# 注册为 Windows 服务Ollama 安装时已做但需确认 Get-Service ollama | Start-Service # 设置开机自启 Set-Service ollama -StartupType AutomaticNode.js 后台服务用 pm2npm install -g pm2 # 启动 RAG 服务 pm2 start C:\dev\ai-test\server.js --name ai-rag-server # 保存进程列表开机自动恢复 pm2 startup powershell -u $env:USERNAME pm2 save健康监控脚本health-check.ps1function Test-AIHealth { $checks () # 检查 Ollama try { $resp Invoke-RestMethod http://localhost:11434/api/tags -TimeoutSec 3 $checks [PSCustomObject]{ Service Ollama; Status ✅ OK; Version $resp.models[0].name } } catch { $checks [PSCustomObject]{ Service Ollama; Status ❌ Down; Version N/A } } # 检查 pm2 try { $pm2 pm2 list | Out-String if ($pm2 -match ai-rag-server.*online) { $checks [PSCustomObject]{ Service PM2; Status ✅ OK; Version Running } } else { $checks [PSCustomObject]{ Service PM2; Status ❌ Down; Version N/A } } } catch { $checks [PSCustomObject]{ Service PM2; Status ❌ Down; Version N/A } } $checks | Format-Table -AutoSize } Test-AIHealth每天早上运行一次输出服务状态表。这才是真正“活”的 AI 编程环境。5. 常见问题与独家避坑指南那些搜不到答案的 Windows 痛点5.1 “codex windows安装未完成” 类问题根本不是 Codex而是权限与路径热词里反复出现codex windows安装未完成但 GitHub 上根本没有官方 Codex Windows 客户端。这其实是用户把第三方封装的CodeWhisperer或TabNine客户端误称为 Codex。真正卡住的原因永远是现象根本原因解决方案安装程序闪退安装包用了.NET 6而 Windows 10 LTSC 默认无 .NET 运行时下载.NET Desktop Runtime 6.0独立安装包而非 SDK“安装完成”但图标不显示安装脚本写死了C:\Program Files\Codex但用户 PATH 里有同名旧版本用Get-AppxPackage -Name *Codex*查看是否残留 UWP 版用Remove-AppxPackage彻底清除登录窗口打不开应用调用了WebView2控件但系统未安装Microsoft Edge WebView2 Runtime手动下载WebView2RuntimeInstaller.exe安装实操心得遇到任何“安装未完成”先打开Event Viewer→Windows Logs→Application过滤Level Error看.NET Runtime或Application Error事件。90% 的问题错误 ID 比百度搜“安装未完成”有用一百倍。5.2 PowerShell 乱码与中文支持deepseek配置windows powershell乱码的真相deepseek配置windows powershell乱码不是 DeepSeek 的锅而是 Windows 控制台编码的千年老坑。PowerShell 默认用OEM编码cp437而中文系统是GBKcp936。永久修复方案# 设置 PowerShell 控制台为 UTF-8 $console [System.Console]::OutputEncoding [System.Text.Encoding]::UTF8 # 设置 PowerShell ISE如果用为 UTF-8 $psISE.Options.OutputPaneTextBackgroundColor Black # 在 $PROFILE 中添加每次启动生效 if (-not (Test-Path $PROFILE)) { New-Item -Path $PROFILE -Force } Add-Content -Path $PROFILE -Value $console [System.Console]::OutputEncoding [System.Text.Encoding]::UTF8Node.js 层面同步修复// 在 Node.js 脚本开头加 process.stdout.write(\u001b[2J\u001b[0;0H); // 清屏并重置 process.stdout.setEncoding(utf8);5.3node:util导出报错ESM 与 CommonJS 混合的终极解法node:util报错的根因是模块系统不兼容。解决方案不是降级 Node.js而是统一模块类型方案 A全项目 ESM推荐// package.json { type: module, exports: { .: ./index.js } }所有文件用.js后缀import语法node:util导出完全可用。方案 B全项目 CommonJS兼容旧包// package.json { type: commonjs }用require()node:util改为require(util)但失去fetch()等新特性。方案 C动态导入混合场景// 在 ESM 文件中动态导入 CommonJS 包 const someCjsModule await import(some-cjs-package); // 或用 createRequire import { createRequire } from module; const require createRequire(import.meta.url); const cjsUtil require(util);注意node:util在 v20 中导出promisify,format,inspect等但TextEncoder等 Web API 需globalThis.TextEncoder不要require(util).TextEncoder。5.4 Windows 安全日志与 AI 工具链如何不被 Defender 当成病毒AI 工具链常触发 Defender 告警因为ollama.exe是 Go 编译的无签名二进制node.exe加载大量node_modules行为类似挖矿木马PowerShell 脚本调用iex或Invoke-Expression。白名单策略# 将 Ollama 目录加入排除列表 Add-MpPreference -ExclusionPath C:\Users\$env:USERNAME\AppData\Local\Programs\Ollama # 将 Node.js 项目目录排除 Add-MpPreference -ExclusionPath C:\dev\ai-test # 禁用 PowerShell 脚本扫描仅限开发机 Set-MpPreference -DisableRealtimeMonitoring $true更安全的做法用Set-MpPreference -AttackSurfaceReductionRules_Ids启用 ASR 规则而非关闭 Defender用Get-MpComputerStatus查看当前防护状态在企业环境用 Intune 部署ExclusionPath策略而非本地 PowerShell。5.5 网络热词中的“无禁词”“无