前几天帮朋友排查一个调度任务卡在一个PowerShell脚本上AI一口气生成了四十多行“看起来很完整”的代码结果跑起来第一行就报“术语无法识别”后面全部白给。这不是我第一次见到AI写的PowerShell翻车了。它给出的命令确实存在语法也确实没错但放在你的会话环境里就是跑不通、跑不稳、跑不对。很多人因此得出“AI写不了PowerShell”的结论但我更倾向于换个说法问题不在AI笨而在我们给它的上下文太少了。这篇东西不聊什么高深理论就说清楚两件事第一AI生成的PowerShell为什么经常一跑就崩真正的根因是哪几个第二我怎么把AI从一个“乱写代码的自动补全器”调教成“知道当前环境、会考虑兼容性、能解释自己思路的本地助手”。标题说附解决提示词这不是噱头我会把两三套可以直接复制粘贴的提示词模板放在中间章节连同它们背后的设计理由一起拆开讲。适合谁看如果你正被“AI写的脚本不能用”这件事折磨或者你已经在用PowerShell做自动化但总在细节上被绊倒这篇应该能省下你不少排查时间。1. 为什么AI给的PowerShell脚本一跑就崩先看清三个共性根因先说结论AI生成的PowerShell脚本跑不通绝大多数不是拼写问题而是“环境不匹配”和“上下文缺失”。同样的Get-Process在普通的交互式窗口跑、在计划任务里跑、在被远程会话包裹的上下文里跑行为完全不一样。AI不理解这些差异除非你把差异喂给它。1.1 AI盲目填充命令但你的会话环境限制了可执行范围第一个坑是执行策略ExecutionPolicy。AI默认假设你能自由运行脚本但实际Windows机器上经常是Restricted或者RemoteSigned。这意味着你下载来的.ps1文件可能根本不让跑AI可感知不到这些限制。很多朋友第一反应是怀疑代码写错了实际上只是没绕过执行策略。第二个坑是权限等级。AI生成脚本时不会刻意确认“当前进程是否管理员”但很多PowerShell操作——比如安装Windows功能、修改服务启动类型、操作防火墙规则、写某些注册表项——都需要提升权限。普通会话里这些命令会抛出一堆Access deniedAI并不知道。第三个坑是模块缺失。AI可以引用Get-ADUserActive Directory模块或者Invoke-SqlcmdSQL Server模块但它不知道你的机器上到底装没装这些模块。缺模块时报错往往是“无法加载模块”或“命令不存在”看起来像代码写错实际是依赖没满足。所以结论第一条当你让AI写脚本时默认它脑子里只有语法没有你的机器。你的机器是什么状态得你负责传给它。1.2 命令语法版本混用Windows PowerShell与PowerShell 7的差异AI的训练数据里混着大量不同版本的PowerShell代码。Windows自带的Windows PowerShell 5.1和新独立安装的PowerShell 7即pwsh之间虽然大部分命令通用但有三类差异特别容易咬人编码处理Windows PowerShell 5.1默认用ANSI写文件Out-File -Encoding utf8写出来还带BOM头很多程序对它不友好PowerShell 7默认就是UTF-8无BOM行为完全不一致。并行能力PowerShell 7有ForEach-Object -Parallel5.1根本没有AI有时候会把只有7才有的参数塞进5.1脚本里。部分模块和Cmdlet的取舍比如ConvertFrom-Json在5.1里对深层次JSON的处理能力弱一些某些现代的字符串处理API在5.1里就不存在。AI经常默认你用的是PowerShell 7甚至默认你在Linux/Mac上跑的PowerShell因为网上开源脚本和GitHub Action的示例大多以新版本为准。但如果你实际在Windows的5.1环境里运行就会出现“AI写得没错但你的环境不认”的尴尬。我见过最典型的例子是AI给了一段包含??空合并运算符的脚本这在PowerShell 7里合法在5.1里直接语法错误。提示让AI写代码前把$PSVersionTable的输出结果原样丢进对话能避免一半以上的版本类问题。1.3 输出编码和区域设置的水土不服第三个根因是编码和区域设置Culture。中文环境下这个坑尤其重。AI在生成处理文本、日志、CSV导出的脚本时默认思维的编码体系通常是英文环境下的UTF-8而你的Windows PowerShell 5.1窗口跑起来后的内部代码页、默认输出编码可能都是ANSI或者GBK。结果就是Get-Content -Path log.txt读取中文文件时出现乱码脚本往外输出文字时重定向到日志里变成乱码或问号[datetime]::Parse(2024-05-01)之类的时间解析在某些区域设置下不稳定。AI不知道你的用户语言环境是zh-CN也不知道$OutputEncoding是什么值。这些“看起来不影响代码逻辑”的细节恰恰是脚本在中文环境炸掉的重灾区。所以我在实际协作中养成了一个习惯凡是跟文本、文件、日志相关的PowerShell请求都会在提示词里显式注明“请所有文件读写操作显式指定编码参数”三个字别偷懒。2. 从“生成代码”切换到“先同步环境”一条采集命令解决信息断层既然AI的问题在于不知道环境那直接把自己的环境告诉它是不是就能大幅提高命中率答案是肯定的。我现在每次跟AI协作写PowerShell之前都会先执行一条命令把环境信息打包好然后作为提示词的前置段落发给AI。整个过程不超过一分钟收益却非常明显。2.1 用一条命令把家底打包给AI直接上命令。打开PowerShell窗口把下面这段贴进去执行function Get-EnvBrief { [CmdletBinding()] param() $hostName $env:COMPUTERNAME $psVer $PSVersionTable.PSVersion.ToString() $edition $PSVersionTable.PSEdition $execPolicy (Get-ExecutionPolicy -List | ForEach-Object { $($_.Scope)$($_.ExecutionPolicy) }) -join ; $admin ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) $modules (Get-Module -ListAvailable | Sort-Object Name | Select-Object -ExpandProperty Name -Unique) -join , $culture Get-Culture $osCaption (Get-CimInstance Win32_OperatingSystem).Caption [PSCustomObject]{ HostName $hostName PowerShellVer $psVer Edition $edition ExecutionPolicy $execPolicy IsAdmin $admin Culture $culture.Name OS $osCaption AvailableModules $modules } | ConvertTo-Json -Depth 3 } Get-EnvBrief执行后会输出类似下面这样的JSON{ HostName: WORKSTATION-01, PowerShellVer: 5.1.22621.608, Edition: Desktop, ExecutionPolicy: LocalMachineRemoteSigned; CurrentUserRemoteSigned, IsAdmin: true, Culture: zh-CN, OS: Microsoft Windows 11 专业版, AvailableModules: Az, Microsoft.PowerShell.Utility, Pester, ... }把这串JSON原封不动复制放到你“接下来要发送给AI的提示词”最前面。就这么一个动作AI对环境的猜测空间会被压缩到极小。2.2 如何读懂这份环境报告并把它翻译成提示词不用急着把所有字段都丢给AI你至少要理解其中三个关键字段的含义因为这决定了后续脚本的写法PowerShellVer与Edition如果是5.1请在提示词里明确“仅使用Windows PowerShell 5.1兼容语法禁止使用PowerShell 7专属语法”如果是7.x可以适当使用新语法但也要注明目标运行平台的差异。ExecutionPolicy如果你看到Restricted那么后续脚本里如果涉及Invoke-Expression或从外部加载脚本文件AI就会知道可能需要建议你调整策略或者在脚本中明确输出警告。如果已经是RemoteSigned或Bypass那可以放心运行下载来的脚本。AvailableModules这个字段最值钱。AI知道你的环境里有哪些模块就不会再给你生成没安装依赖的代码。比如模块列表里没有ActiveDirectoryAI会主动建议改用Get-CimInstance或者Get-ADUser不可用时降级方案而不是直接给你一个跑不了的Get-ADUser脚本。这三项信息翻译进提示词的写法很简单可以像下面这样自然表述我后面章节会给完整模板我的运行环境Windows PowerShell 5.1Desktop版执行策略为RemoteSigned当前会话具有管理员权限区域设置为zh-CN。可用模块包括Az、Pester等。请严格基于上述环境编写脚本并在代码中显式处理编码和兼容性问题。2.3 提示词里加“运行上下文”段落后的实际效果对照我做过一个简单的对照实验算是个人经验不具备统计学意义但很能说明问题。同样让AI写一个“遍历指定目录下所有JSON文件并合并成数组输出”的脚本不提环境时AI给出的是PowerShell 7风格写法用了Get-ChildItem -File、ConvertFrom-Json、管道链式处理甚至假设文件夹下文件都带UTF-8无BOM编码。在我的5.1环境里一跑中文文件直接乱码而且用ConvertFrom-Json时部分对象的属性顺序和预期不一致。加上环境信息后AI生成的版本变成了显式指定-Encoding UTF8读写、用ForEach-Object替代部分花哨语法、为每个文件加try/catch、输出时用Export-Csv -Encoding UTF8并明确写出BOM注意事项。脚本虽然没有第一版“看起来现代”但一次性跑通结果正确。这个反差让我印象很深刻。从那以后我所有跟AI有关的脚本请求环境信息固定前置。你可以理解成不给AI环境信息它只能用“大众平均水平的机器”推断给了之后它就在“你的这台机器”上思考。3. 附可直接复制使用的PowerShell提示词模板标题里说的提示词放在这里。我整理了三套模板分别对应三种高频场景排查排错、脚本加固、按现有风格扩展。每套都经过我实际使用验证不是网上那种虚头巴脑的“大师级提示词”拿过去就能用。3.1 模板一本地排错助手型提示词适用场景你有一段脚本运行报错或者运行结果不符合预期需要AI帮忙定位问题。重点不是让AI重写代码而是让它陪你一起排查。你现在是一名长期在Windows环境中处理自动化任务的PowerShell运维专家。不要急着给代码先跟我一起确认信息。 我的运行环境如下 【在这里粘贴 2.1 节生成的JSON环境信息】 我有一段PowerShell脚本目的是【一句话说清脚本目标】。 实际的脚本内容如下 【粘贴脚本】 运行时报错如下或现象描述 【粘贴报错信息或者描述现象比如“运行后没有报错但输出为空”】 请按以下步骤回答 1. 先复述你对我脚本目标和运行环境的理解并用不超过三句话判断最可能的失败原因。 2. 列出你怀疑的3个排查点按概率从高到低排序每个排查点都要给出验证命令。 3. 如果确定是代码问题指出具体位置并给出修复后的完整脚本如果确定是环境问题给出调整环境或绕过问题的具体方法。 4. 所有涉及文件读写的代码必须显式指定编码参数。 5. 最后用一段话说明修复后脚本可能出现的新问题防止“踩一个坑顺便掉进另一个坑”。这个模板的核心设计是把“AI直接给代码”的默认行为掰到“先分析再动手”。你观察一下第1步和第2步要求AI先复述环境并给排查点这两步能极大减少AI凭感觉改代码的情况。很多时候它给出的排查点会指向你自己忽略的地方比如某个内网代理导致Invoke-RestMethod超时或者某个路径里有空格导致参数解析错位。提示不要在模板里把报错信息一股脑全贴上而应该截取从第一次出现红色报错开始的前200个字符以及最后一行报错。贴太多会模糊重点AI反而被噪音带偏。3.2 模板二脚本优化与加固型提示词适用场景你已经有脚本能跑但觉得它慢或者觉得它不够健壮想让它更专业。这个模板的核心是让AI像做代码审查一样帮你打磨脚本。我将给你一段可以正常运行的PowerShell脚本但希望你在不改变外部行为的前提下对脚本做健壮性和性能优化。 我的运行环境如下 【在这里粘贴环境JSON】 脚本内容和目标 功能是【一句话概括】 脚本代码 【粘贴脚本】 请按以下顺序处理 1. 指出当前脚本中3个最明显的健壮性风险点按严重程度排序。重点关注命令是否可能报“终止性错误”、变量是否可能被意外覆盖、是否存在网络或文件资源未释放的情况。 2. 指出2个性能优化点并说明优化前后的时间复杂度或执行次数差异。如果看不出明显性能问题明确说“此处无需优化”禁止为了改写而改写。 3. 对脚本中所有调用外部命令、访问文件系统、调用网络接口的地方检查是否缺少 -ErrorAction、超时时间或重试机制。 4. 对于任何可能被用户中断或失败的操作给出补充 try/catch 或 trap 处理的方式。 5. 输出优化后的完整脚本并附一段“优化说明”逐条对应我要求中的1-3项让我知道每一处改动是为了解决什么问题。 6. 如果优化会引入对模块或权限的新依赖必须在脚本开头用注释标出。这个模板的使用反馈里最高频的发现是AI会帮你发现脚本里没有超时才导致的“挂死”问题。比如Invoke-RestMethod默认一次连接请求可能卡很久AI会建议你加TimeoutSec参数。另一个高频发现是在写文件前没有创建目录日志多目录场景下第二次运行必挂。这里给个技术细节PowerShell默认$ErrorActionPreference Continue很多东西“像是没出错”地照样跑下去等到结果出来才发现少了一半数据。让AI按“Continue模式下是否仍有风险”的角度审查比普通代码评审角度更贴近PowerShell实际。3.3 模板三按现有代码风格扩展功能型提示词适用场景你手上有一个现成的项目里面已经有固定的函数命名习惯、脚本头部注释风格、日志输出约定现在你想让AI按这套风格新增一个功能模块。直接说“帮我写个XX功能”往往会被AI变成另一种格式和你的工程格格不入。我要在现有PowerShell工程里新增一个功能请你严格遵循工程现有的代码风格和约定。 工程中已有的规范如下按实际情况填写没有的删除对应行 - 函数命名风格【例如“动词-名词”格式统一使用 Approved Verbs】 - 参数定义风格【例如使用 param() 块 参数注释 是否使用 [CmdletBinding()]】 - 错误处理约定【例如统一使用 try/catch并将异常信息通过 Write-Warning 输出而不是 throw】 - 日志约定【例如所有输出通过统一函数 Write-Log 写到 $env:TEMP\info.log】 - 编码约定所有Out-File/Set-Content/Get-Content必须携带 -Encoding UTF8 - 其他约定【按需补充】 请你先从一个已有函数中学习风格 【粘贴一个代表性函数】 现在需要新增功能是【描述要做什么比如“新增获取某服务状态的函数输出为PSCustomObject”】 请按此风格输出 1. 函数代码包含参数块、过程注释和必要的边界处理。 2. 调用示例展示参数如何传入、输出结构长什么样。 3. 指出这个新功能可能影响到的现有功能点以及兼容性考虑。这个模板能在实际工程里省掉大量“移植风格”的时间。特别是团队里多人协作时AI生成代码如果风格不一致后续维护成本极高而模板第1条已经强制它先看一个样例函数相当于给它一棵“参照树”。3.4 使用这些模板时的四个注意事项第一环境信息不是一成不变的。你用管理员权限跑和普通权限跑IsAdmin字段会变装了新模块AvailableModules列表也会变。我建议每次跟AI开启新对话时重新执行一次Get-EnvBrief不要用几周前的旧报告。第二不要把提示词模板当成万能药。模板的威力在于约束AI“先想后答”但如果你提供的脚本本身信息太少比如只说“我有个脚本报错”不给代码再好的模板也救不了。第三AI给出的优化意见不一定是真理。有些优化建议会显著提高代码复杂度对一次性运维任务来说不值得。你要在提示词里明确“复杂度最小优先”还是“健壮性优先”比如上面模板二中的第2步就是为此设计的。第四跟AI对话时如果它给出的是“PowerShell 7语法”而你实际是5.1不要默默接受。直接回复它“当前环境是5.1请改写为5.1兼容语法”即可。AI对这类纠正的理解非常快这比对话一开始就堆一堆限制条件更灵活。4. 实测复盘三个典型问题AI错在哪人怎么把它拉回来光有提示词还不够你还需要具备基本的“纠偏能力”。这一章我复盘三个我真实遇到过的PowerShell AI协作翻车案例每个案例都给出AI的原始错误、根因分析、以及我的修正命令。你可以把这些当成“排错参考手册”遇到类似情况直接对照。4.1 案例一中文乱码与Out-File的编码之争某项目里有个导出功能让AI写“把一组数据导出为CSV”结果生成的文件打开后全是锟斤拷这类经典乱码。AI代码核心大概是Get-Process | Select-Object Name, CPU, WorkingSet | Export-Csv -Path result.csv在中文Windows上这行代码的问题在于Export-Csv默认编码在Windows PowerShell 5.1里是ASCII或Unicode中文内容所以直接变成乱码。AI在生成这段代码时完全没有考虑编码问题。修正很简单Get-Process | Select-Object Name, CPU, WorkingSet | Export-Csv -Path result.csv -Encoding UTF8这里有一个隐藏更深的坑如果用-Encoding UTF8Windows PowerShell 5.1写出的CSV会带BOM头。Excel对其兼容性倒还好但很多Linux工具或者Python的csv模块读它会撞上一个\ufeff。如果你的下游是任何非Windows程序更稳妥的是用utf8NoBOM——但注意utf8NoBOM在5.1的Export-Csv里并不存在它是PowerShell 7才有的枚举值。这就回到了第1章说的版本差异问题。所以我给AI的提示词里关于编码的约束永远写的是“所有文件读写操作显式指定编码参数并说明当前版本下该编码参数是否会产生BOM。如果会产生BOM且下游可能非Windows改用绕行方案例如把内容写入临时字符串再通过[System.IO.File]::WriteAllLines()指定UTF8Encoding(false)。”又绕又精确但这一顿操作后再也没有人对我说“你导出的文件打不开”了。4.2 案例二Where-Object、Where以及与$_作用域纠缠有个朋友让AI优化一段“从日志文件过滤错误行”的脚本AI给了下面这种写法Get-Content app.log | Where {$_.Contains(ERROR)} | Out-File errors.log这段代码在PowerShell里不算错Where是Where-Object的别名普通脚本用没问题。但问题出在性能和可读性在几百万行的大日志上这种逐行管道过滤方式不够快而且$_使用会让新人读起来费劲。AI的第二次优化更加激进给了一个ForEach-Object -Parallel版本直接把我的5.1环境干穿因为那个参数在5.1里不存在。我的修正是先让AI明确目标机器的PowerShell版本把这个前提固化为约束条件之后AI给出的优化方案变成用[System.IO.File]::ReadLines()加LineRead事件逐行处理或者用Select-String -Pattern ERROR直接过滤。这里我想多说一句Select-String的事。很多人忌讳用它觉得它慢其实Select-String对单文件逐行匹配的性能完全够用而且写法简洁得多。但如果你要处理的是GB级别的大文件管道传递会让你内存飞涨这时应该回到StreamReader方式。这类“什么时候用哪种方案”的判断AI在缺少环境信息和数据量预期时做不好你要做的是在提示词里补充“日志文件大小约500MB希望内存占用尽量小”这类业务信息。提示给AI提性能优化需求时把“数据规模”和“内存约束”写清楚。没有这两个参数的“帮我优化”最后几乎都会变成换了个写法但性能差不多的假优化。4.3 案例三CIM对象属性值为空AI的“健壮性修改”越帮越忙一次AI帮一个同事生成“读取系统开机时间”的脚本他用了(Get-CimInstance Win32_OperatingSystem).LastBootUpTime运行返回了正确时间但同事觉得不够可靠想让AI“加一些健壮性处理”。AI给的结果是$bootTime (Get-CimInstance Win32_OperatingSystem).LastBootUpTime if ($null -eq $bootTime) { Write-Warning 未能获取开机时间 } else { Write-Output $bootTime }加了判断本身没错但这段代码在“属性取不到值”的真实场景里依然不解决问题因为Get-CimInstance如果查询失败抛的可能是异常而不是返回$null这种if ($null -eq $bootTime)逻辑根本等不到执行。真正有效的健壮性处理是try { $os Get-CimInstance -ClassName Win32_OperatingSystem -ErrorAction Stop if ($null -eq $os.LastBootUpTime) { Write-Warning 系统未返回 LastBootUpTime 属性 } else { $os.LastBootUpTime } } catch { Write-Warning CIM 查询失败: $($_.Exception.Message) }这个案例想说明一件事AI的“健壮性”大多是“加判空”但PowerShell脚本的真正脆点往往是“命令本身失败或超时”而不是“返回空值”。你可以在提示词里要求AI“对可能失败的Cmdlet使用try/catch而不是依赖返回值判空”这样生成的代码才贴近真实情况。4.4 修正后的通用排查路径结合上面三个案例我总结了一个遇到“AI脚本跑不通”时的通用排查路径按顺序走基本能定位90%的问题用Get-EnvBrief确认环境信息执行策略、管理员权限、版本号三个字段优先看。把报错信息原样贴给AI让它先判断是“语法错误”“模块缺失”“权限不足”还是“数据/编码异常”。如果提示词里没用编码约束立刻补充“所有文件读写显式指定编码参数”。如果AI给了PowerShell 7语法而你是5.1强制它改写。如果脚本涉及网络或外部资源要求AI补上超时参数和错误处理。最后再考虑命令本身是否有更优替代比如Get-WinEvent替代Get-EventLogGet-CimInstance替代Get-WmiObject。这条路径我只花了很少的篇幅描述但每一步都是真实项目验证过的按顺序执行就能避免“跑来跑去最后发现是权限问题”的窘境。5. 和AI协作的日常习惯我踩过几次坑之后的几条铁律最后这部分是我个人在长期使用AI辅助PowerShell工作后沉淀下来的一些习惯不系统但每条都有真实教训在里面。第一条铁律让AI先给计划再给代码。我见过太多人第一句话就是“写个脚本实现XXX”AI直接甩出几十行代码然后用户就开始复制粘贴跑跑不通再回来跟AI吵。我的做法是开头先加一句话“不要直接写代码先告诉我你的脚本设计思路准备分几步、每一步做什么、用什么命令、可能的坑是什么。”等AI把思路说清楚我再补一句“可以按上述思路写代码了。”这个动作看起来多了一轮对话但能让AI在大方向正确的前提下生成代码明显降低“全盘推翻重写”的概率。第二条铁律永远不要直接在生产环境跑AI首轮生成的脚本。我的习惯是先加-WhatIf参数试运行或者在测试目录里跑再检查脚本里有没有删除类、清空类的高危操作。PowerShell脚本不像编译语言有强类型检查它执行到一半才发现某个命令不存在是完全正常的而AI生成的第一版往往不会考虑“执行到一半失败”的中间状态是啥。你可以在提示词里要求“脚本开始前先检测关键命令是否存在不存在就直接终止并输出提示”这一句能让首轮运行失败时的恢复成本大大降低。第三条铁律保持“对象思维”别让AI往“字符串思维”上带偏。PowerShell的强大之处在于管道传递的是对象不是文本。但AI出于解释型语言的惯性经常会写一堆字符串拼接、正则匹配去解析本来用Properties就能拿到的数据。我每次都会提醒AI“优先使用对象属性访问不是字符串处理优先使用Where-Object过滤对象不是把结果转成文本后再找关键字。”第四条铁律让AI解释“为什么”而不是只给“是什么”。我在每次需要理解AI改动的代码时会要求它在关键段落下面加注释说明“这一行在做什么、为什么这么写、如果当前环境不同会有什么风险”。这个习惯让我在几周后回看旧脚本时还能快速进入状态也让我能第一时间发现AI的逻辑漏洞。毕竟AI生成的代码如果没人能解释清楚那它唯一的作用就是“能跑”一旦环境变化你就得从头再来。回头看开头那个朋友的项目我们把环境JSON塞进提示词、把“PowerShell 5.1兼容”写进约束、让他按模板二的思路先让AI做了一份设计思路说明再让AI写正式代码最后脚本一次通过。他后来跟我说了一句挺有意思的话“感觉不是AI变聪明了是我终于教会它我们这儿的规矩了。”这大概也就道出了“AI大战PowerShell”的本质不是人机大战不是让AI迁就PowerShell而是让AI知道PowerShell在水土上真正需要什么。把规则讲清楚这场“大战”其实从一开始就不该发生。