• 作者: 作者
  • 时间:
  • 分类: 文章

大家有没有遇到过这种情况？

终端报错示意图

AI 生成的代码在终端运行时报错的常见场景

最近几次让大模型帮我写 PowerShell 脚本，简直是“一言难尽”。明明模型版本号都迭代到 GPT-4 或者更高级的 Claude 3 了，按理说代码能力应该突飞猛进才对。

结果呢？

生成的脚本经常是看着挺像那么回事，一跑就红一片报错。

  • 模块加载失败？
  • 参数拼接错误？
  • 或者干脆就是凭空捏造了一个不存在的 cmdlet（指令）？

每次都要在终端和聊天窗口之间反复横跳，复制报错信息丢回去给模型重试，几次下来，心累无比。于是我不禁想问：

到底为什么，练了这么久的大模型，依旧用不好 PowerShell？

一、 根本原因：语料里的“杂质”太多了

这其实不能全怪模型“笨”，很大程度上是训练数据“偏科”造成的。

  1. 开源社区的代码质量参差不齐 PowerShell 在很多自动化运维场景下用得很多（比如 Exchange 管理、Azure 交互）。但是，网上能抓取到的 PowerShell 代码，很多是 StackOverflow 上十年前的“古董代码”，或者是某些论坛里为了临时解决问题写的“即兴脚本”。 这些代码里充斥着过时的别名、已经被弃用的参数，甚至是不规范的写法。模型在训练时，如果大量吞食了这些数据，它学到的就不是“最佳实践”，而是“各种奇怪的写法”。

  2. PowerShell 的版本跨度极大 这一点和 Python 或 Go 不太一样。PowerShell 5.1（Windows 自带）和 PowerShell 7+（跨平台核心版）之间是有不少差异的。 模型在生成代码时，有时候会混淆这两个环境。它给你写了一段在 PowerShell 7 上跑得很溜的代码，结果你是在本地的 Windows 10 默认终端里跑，直接报错。

  3. 幻觉（Hallucination）在 API 调用上最明显 大模型本质上是个“文本接龙专家”。当你让它调用一个冷门模块的 API 时，它并没有真的去查阅文档，而是基于概率猜测这行代码该怎么写。 PowerShell 的那些 -Identity、-ObjectId、-Id 参数名长得都差不多，模型一“发挥创造力”，把参数名写错一位，整个脚本就废了。

二、 PowerShell 本身的复杂度也是“坑”

除了训练数据，语言本身的特性也让 AI 比较头疼。

  • 管道流 对模型理解上下文有挑战： PowerShell 强调对象在管道中传递。虽然这很强大，但对于模型来说，要想完美预测管道前一个对象输出了什么属性，并精确匹配下一个命令的参数，需要极强的上下文保持能力。稍微一走神，属性名就错了。

  • .NET 的强依赖： PowerShell 背后是 .NET。有时候为了实现一个功能，必须调用 .NET 的类库。这时候模型就容易混淆 C# 的语法和 PowerShell 的语法，导致出来的代码不伦不类。

三、 实操：如何让模型写出能用的脚本？

既然知道它有这些毛病，我们就要换个玩法，不要当“甩手掌柜”，试着当“架构师”来引导它。下面这几个技巧，实测能大幅提升成功率。

1. 指定版本，拒绝猜测

在提示词里必须明确环境。不要只说“写个脚本”，要说：

“请基于 PowerShell 7.4 编写脚本，确保兼容跨平台。”

或者如果你是在 Windows 上跑：

“请使用 Windows PowerShell 5.1 原生 cmdlet，不要依赖 .NET Core 类库。”

2. 拒绝别名，强制全称

很多老鸟喜欢用 ls, cp, % 这种别名。模型看到这东西容易产生歧义。要求模型：

“不要使用任何别名，所有命令必须使用完整的 cmdlet 名称（如 Get-ChildItem 而不是 ls），所有参数使用全名。”

这样虽然代码会啰嗦一点，但准确率会直线上升，而且你自己阅读维护也方便。

3. 分步生成，先写验证函数

如果你要写一个很复杂的交互脚本，别让模型一次性写完。

VS Code PowerShell 扩展界面

VS Code 中的 PowerShell 扩展与 PSScriptAnalyzer 静态检查工具

  • 第一步：“先给我写一个函数，用来连接并验证目标服务器的连通性，仅输出 True/False。”
  • 自己跑通这一步。
  • 第二步：“通过验证后，添加获取列表的功能。”

把大任务拆解成小步骤，每一次都人工验证一下逻辑，这样就算后面出错了，你也能快速定位是哪一步崩了。

4. 让它解释每一行代码

生成完代码后，追加一句指令：

“请逐行解释这段代码的逻辑，并标明涉及到的外部模块。”

在它解释的过程中，你往往能一眼看到它是不是在“瞎编”参数。如果它说“这里的 -ForceX 参数用来强制覆盖”，而你心里明明知道那个参数应该叫 -Force，那就是出问题了，趁早别跑，让它改。

5. 使用官方文档作为参考上下文

如果你有具体的 API 文档链接（比如 Microsoft Docs），把关键的参数说明复制给模型，或者说：

“参考 Set-Mailbox 的官方文档语法，确保参数传递正确。”

这相当于给了它一个“开卷考试”的小抄，能极大减少幻觉。

四、 最后的杀手锏：VSCode 的扩展

别忘了，AI 只是辅助，本地工具才是保障。

推荐配合 VS Code 的 PowerShell Extension 使用。它内置的 PSScriptAnalyzer 会在你把 AI 生成的代码贴进去的那一刻，直接用波浪线标出潜在的错误（比如未声明的变量、过世的命令）。

流程建议： AI 生成 -> 粘贴到 VS Code -> 看 PSScriptAnalyzer 报错 -> 修复低级语法错误 -> 再运行。

这样能过滤掉 90% 因模型“手抖”导致的低级错误。

总结

大模型并不是写不好 PowerShell，而是它太容易产生幻觉，且容易被低质量的训练数据带偏。

作为使用者，我们目前还不能完全盲目信任它生成的所有脚本。指定版本、拒绝别名、分步验证，配合好本地的静态检查工具，才是目前玩转自动化脚本的最佳姿势。

如果你最近也被 AI 写的脚本坑过，欢迎在评论区分享你的“踩坑”经历！

标签: none

评论已关闭