Windows上用AI写代码总报错?先装这78个命令

你有没有遇到过这种情况，让 Hermes 或 Claude Code 在 Windows 项目里找一下所有 TODO，它很自然地写出 grep -R "TODO" .，再顺手来一个 ls -la 看目录。命令看着没毛病，PowerShell 却回你一句无法识别，或者干脆跑出了另一个结果。

这时候很多人第一反应是，Agent 又不懂 Windows。

我觉得这话只说对了一半。Agent 确实常常默认自己在类 Unix 终端里干活，可真正麻烦的地方，是 Windows 原生终端长期听不懂那套最常见的命令。你让一个习惯说普通话的人，每次开口前先在脑子里翻译成另一种方言，它当然会慢，偶尔还会翻错。

6 月 2 日，微软做了一件很不微软的事，把 78 个类 Unix 命令做成了 Windows 原生工具包。它不是 WSL，不是 Cygwin，也不是 Git Bash 里顺手带的那几个；维护方是微软，项目叫 Coreutils for Windows，GitHub 仓库 microsoft/coreutils，MIT 许可，一条 winget 命令就能装，发布后很快冲到 3.7k Star。

我真正想提醒的是，这件事不要只当成「Windows 终于有 ls 了」。对用终端 Agent 的人来说，它更像是给 Windows 原生环境补了一本常用词典。以后 Agent 做文件搜索、日志查看、文本处理时，不必每次先把 grep 翻译成 Select-String，把 ls 翻译成 Get-ChildItem，把 tail 翻译成某段 PowerShell 写法。

一句话答案，如果你在 Windows 原生终端里用 Hermes、Claude Code、Codex，先确认 PowerShell 7.4，再安装 Microsoft Coreutils。第一次验收别直接敲 ls，统一用 ls.exe、grep.exe、tail.exe 这些带后缀的写法。

先把这个场景说透。你让 Agent 搜索项目里的某个词，它写 grep；你让它看日志最后几十行，它写 tail；你让它统计文件行数，它写 wc -l。这些命令在 Linux、macOS、Docker 容器和大量开源项目文档里都是日常语言，Agent 并不是凭空乱写。

麻烦在 Windows 这边。PowerShell 有自己的一整套命令和对象管道，能力不弱，甚至在管理服务、注册表和进程时更适合 Windows。可大多数 Agent 的训练材料、开源项目说明、CI 脚本和开发者习惯，天然偏向类 Unix 命令。两边都没错，错的是中间没有翻译层，或者说翻译层一直压在用户和 prompt 身上。

过去你大概有三种办法。第一种是在提示词里反复提醒「当前是 Windows，请使用 PowerShell 写法」。第二种是切到 WSL，把整个工作目录放进 Linux 环境里跑。第三种是自己写兼容脚本，把 ls、grep、find 这些名字映射到 Windows 命令。

都能用，但都别扭。

提示词提醒会忘，WSL 又牵出路径、盘符、权限、文件同步这些新问题，兼容脚本更像给每个项目单独配翻译员。微软这次做的事很直接，没有先要求 Agent 更聪明，先让 Windows 原生终端学会一批 Agent 已经很熟的词。

装之前先做一件很小的事，打开你平时用的终端，跑这一行。

POWERSHELL$PSVersionTable.PSVersion

看到 Major 7、Minor 4 或更高，再继续。看到 Major 5，先停一下。那通常是旧版 Windows PowerShell 5.1，不是现在文档里要求的 PowerShell 7.4 以上环境。两个名字只差一个 Windows，实际像同一栋楼里的老电梯和新电梯，你站错了门，后面怎么按按钮都不对。

旧版也不用紧张。用 winget 装新版 PowerShell。

POWERSHELLwinget install --id Microsoft.PowerShell --source winget

装完以后，从开始菜单搜 PowerShell 7，或者在 Windows Terminal 里手动切到新版配置文件。再跑一次 $PSVersionTable.PSVersion，确认版本对了再往下走。

这一步不要省。很多 Windows 终端问题，坏就坏在「我以为自己开的是新版，其实还是旧窗口」。后面 coreutils 能不能被找到、PATH 有没有刷新、Agent 实际在哪个 shell 里跑，全都得建立在你确认过当前环境的基础上。

Windows 原生终端补上常用类 Unix 命令后，Agent 少了一层翻译。

版本确认以后，安装命令很简单。

POWERSHELLwinget install Microsoft.Coreutils

安装过程中按提示走就行。真正容易出问题的地方在安装之后，当前终端窗口可能还没刷新 PATH。SANS ISC 那篇文章下面就有用户反馈过，winget 装完后新路径没有立刻出现在当前 shell 里。

所以我建议你装完先关掉当前 PowerShell，再重新打开一个新窗口。不要急着敲裸的 ls。第一步先明确调用程序文件。

POWERSHELLgrep.exe --help

如果屏幕打印出帮助文本，说明系统已经能找到 coreutils 里的 grep.exe。接着再跑。

POWERSHELLls.exe -la

能列出当前目录文件，就说明最基本的路径和执行权限都通了。如果有一条失败，不要上来就卸载重装，先查系统到底能不能找到它。

POWERSHELLGet-Command grep.exe

能看到具体路径，多半只是旧窗口没刷新或当前 shell 环境不对。完全找不到，再回头看 winget 安装结果。

成功标志很简单，grep.exe --help 有帮助文本，ls.exe -la 能列目录，终端没有提示无法识别命令。做到这里，工具本身才算站住。

接下来这个坑，很多人会以为自己没踩，其实已经踩了。

PowerShell 里本来就有一批短别名。ls 指向 Get-ChildItem，cat 指向 Get-Content，cp 指向 Copy-Item，rm 指向 Remove-Item，pwd 指向 Get-Location。你装了 Coreutils 以后，这些别名不会自动让位。

结果就很微妙。你敲 ls，屏幕确实列出了文件，但跑的未必是 coreutils 的 ls.exe，可能还是 PowerShell 自己的别名。你以为新工具生效了，Agent 以为它在用类 Unix 命令，实际中间又套回了 PowerShell。

确认方法也很简单。

POWERSHELLGet-Command ls

如果结果里写着 Alias，说明 ls 这个名字仍然被 PowerShell 占着。这个时候先不要急着删别名，直接用带 .exe 后缀的写法。

POWERSHELLls.exe -la grep.exe -R "关键词" . tail.exe -n 20 .\app.log cat.exe .\README.md

我不建议刚装完就批量删除 PowerShell 别名。PowerShell 的原生命令返回对象，处理 Windows 服务、注册表、进程、系统配置时很有价值；Coreutils 擅长传统文本管道。两个不是谁灭掉谁的关系，更像厨房里一把中式菜刀和一把西式厨刀。你要做的是告诉 Agent 什么时候拿哪一把，不是把另一把扔了。

尤其是 rm.exe。rm 和 rm.exe 不是同一个实现，参数和确认行为可能不同。第一次测试不要拿真实资料目录练手。

新建一个测试文件夹，里面放几份文本、一个 README、一个日志文件。第一次只做查看和搜索，不要复制、移动、删除任何东西。

先列目录。

POWERSHELLls.exe -la

再搜文本。

POWERSHELLgrep.exe -R "TODO" .

最后看日志末尾。

POWERSHELLtail.exe -n 20 .\app.log

这三步分别验证目录读取、递归搜索和日志查看。都通过了，才说明你装的东西对 Agent 最常见的三类动作有帮助。这里的关键词是只读，先让系统说「我能看」，再谈「我能改」。

接下来把同样三个任务交给 Hermes 或 Claude Code。你可以把下面这段环境说明直接贴给它。

TEXT当前环境是 Windows PowerShell 7，已安装 Microsoft Coreutils。 读取目录、搜索文本、查看日志时，优先使用带 .exe 后缀的 Coreutils 命令，例如 ls.exe、grep.exe、find.exe、tail.exe。 本次只操作测试目录，不修改、不移动、不删除任何文件。

看它实际执行了什么。如果它仍然只写 grep，或者写了一串 Bash 专用语法，说明它还不知道这台 Windows 机器的新边界。这个时候不要怪工具没用，把这段环境说明写进项目根目录的 AGENTS.md，或者写进你常用终端 Agent 的项目规则里。

安装工具只是把词典放到桌上。Agent 会不会翻开看，还得你在规则里说清楚。

先确认 PowerShell 版本和 PATH，再让 Agent 接手项目命令。

手工命令能跑，Agent 一跑就错，别急着改一大段 prompt。按顺序查，通常很快能定位。

第一层，确认 Agent 所在的 shell。你手工打开的是 PowerShell 7，不代表 Agent 也在同一个环境里。它可能跑在 CMD、Git Bash、WSL，甚至某个工具自己开的终端里。先让它执行 $PSVersionTable.PSVersion 或 Get-Command grep.exe，别只看你自己的窗口。

第二层，确认 PATH。手工跑 Get-Command grep.exe，再让 Agent 在同一目录跑一遍。如果你能找到，Agent 找不到，多半是它启动时继承的环境变量还没刷新。重启 Agent 进程比反复重装更有用。

第三层，看命令有没有 .exe 后缀。PowerShell 别名会抢名字，grep.exe、ls.exe、tail.exe 这种写法更干净。等你确认所有常用命令都稳定了，再决定是否让 Agent 用裸命令。

第四层，看引号和路径。Windows 路径里有空格、中文、反斜杠时，很多看起来很 Linux 的命令会在转义上出问题。把 Agent 生成的命令复制出来，自己在同一目录跑一遍，错误信息会比聊天里的概括可靠得多。

第五层，看任务是不是已经超出 Coreutils 的范围。找文件、搜文本、看日志、算校验、排序去重，这些很适合；完整 Bash 脚本、包管理器、Linux 服务管理、复杂权限和后台守护进程，就不要指望这个工具包全包。该进 WSL 就进 WSL，该用 PowerShell 原生命令就用 PowerShell。

这五层查完，基本不会再陷在「到底是 Agent 笨，还是 Windows 坏」这种模糊问题里。问题会变得很具体，shell 不对、PATH 不对、别名抢名、路径转义不对，或者任务本来就该换环境。

把命令边界写进项目说明，Agent 才知道什么时候用 .exe。

这 78 个命令里，最常用的一批其实已经覆盖了终端 Agent 的日常工作。ls、cat、head、tail、grep、find、xargs、sort、uniq、cut、tr、wc、sha256sum、md5sum、du、df、stat，这些就是 Agent 最爱先掏出来的文件和文本处理工具。

如果你的任务是找日志、搜报错、统计文件、检查校验值、看目录大小，Coreutils 很香。它不需要你把整个项目搬进 WSL，也不需要你教 Agent 一遍 PowerShell 的对象管道。对于很多只读检查和轻量脚本来说，少这一层翻译，体验会直接顺很多。

如果你的任务是运行完整 Linux 项目、依赖 apt 或 yum、需要 systemd、需要 Linux 权限模型，继续用 WSL。Coreutils 不是一个小型 Linux，它只是把一批常用命令搬到了 Windows 原生环境。别把工具的边界想大了，想大了就会失望。

如果你的任务是管理 Windows 服务、注册表、计划任务和对象数据，PowerShell 原生命令仍然更合适。Get-Service、Get-Process、Get-ItemProperty 这些东西，本来就是 Windows 自己的语言。让 Coreutils 硬管 Windows 系统，就像拿菜刀去拧螺丝，不是不可能，是没必要。

所以判断要不要装，不看 78 这个数字有多大，而看你平时让 Agent 做什么。经常在 Windows 原生项目里查文件、搜文本、看日志，那就值得装；只是偶尔打开终端敲两行命令，不用 Agent，也不用为了新闻折腾环境。

这里还要泼一点冷水。ls.exe 能跑，不代表你从 Linux 拷来的脚本可以一字不改跑完。

Windows 和 Linux 的底层差异还在。文本换行可能是 CRLF，空设备是 NUL 而不是 /dev/null，权限模型不是 Linux 那套 rwx 位，符号链接可能需要开发者模式或管理员权限，PowerShell 的转义规则也不是 Bash 那一套。路径里有空格、中文或反斜杠时，旧脚本仍然要逐条测。

微软自己也把这个项目标成 Preview。这个词的意思不是「别用」，更像是在提醒你别拿生产目录赌。最稳的顺序是先在测试目录跑只读命令，确认输出对；再测试复制和生成文件；最后才测试移动和删除。rm.exe 这种命令放到最后，而且只在你专门建的测试目录里碰。

我自己会把它当成一块很实用的垫脚石，而不是把 Windows 变成 Linux 的魔法按钮。垫脚石的价值恰恰在于，它让你跨过第一层水坑，但后面的路该怎么走，还是要看地形。

如果你经常在 Windows 原生终端里用 Hermes、Claude Code、Codex，我的建议是现在就可以试。官方维护、winget 安装、MIT 许可、命令清单公开，来源比网上随便找一个绿色版工具包清楚得多。预览版有坑，但这些坑大多能被前面的检查步骤兜住。

第一次不要贪多。先确认 PowerShell 7.4，再 winget install Microsoft.Coreutils，重新打开终端，用 grep.exe --help、ls.exe -la、tail.exe -n 20 做只读验收。然后把环境说明写进 AGENTS.md，告诉 Agent 在 Windows PowerShell 7 里优先用带 .exe 后缀的 coreutils 命令。

等只读任务稳定以后，再让它处理复制、生成文件和轻量文本转换。删除、移动、覆盖这些动作放到最后，而且先在测试目录做。需要完整 Linux 环境的时候，不要硬撑，切 WSL；需要 Windows 系统管理的时候，不要绕远，用 PowerShell。

微软把 78 个类 Unix 命令塞进 Windows，最实用的结果并非 Windows 变成 Linux；终端 Agent 在 Windows 上终于少翻译了一次。少翻译一次，有时候就少一次报错，少一次改 prompt，少一次把好好的自动化任务拖回人工手工修补。

这就够值得试了。

#探寻人工智能# #技能改变生活#