1. VSCode CodeX 写长代码，中文为什么突然变乱码
如果你在 Windows 下用 VSCode 配合 CodeX 这类 AI 编码助手生成含中文的长代码，大概率遇到过这种场景：生成的时候看着一切正常，保存后重新打开，中文注释变成了一堆问号或者方块；再严重一点，文件编码从UTF-8漂移成了UTF-8 with BOM，甚至出现UTF-16 LE，Git diff 里整片整片地飘红。
这个问题不是 CodeX 本身写错了代码，而是它把长代码交给终端去落盘时，中间那层 shell 的编码行为不统一。Windows 上默认的终端往往是Windows PowerShell 5.1，而 5.1 在文件输出编码这件事上历史包袱很重：Out-File、>、>>、Set-Content、Add-Content这几种写法，在不同参数组合下可能产出UTF-16 LE，也可能产出UTF-8 with BOM，跟仓库里约定的UTF-8 无 BOM对不上。
更麻烦的是长代码。一条命令塞不下整份文件时，CodeX 会改成分批写入。每一批写入都可能用不同的编码和换行风格，任何一步失败，文件就停在半成品状态，补写和修复又会制造额外 diff。于是任务从"写代码"演变成"先修代码、再修编码、再修乱码、最后重新核对 diff"。
这篇面向需要在 VSCode 里稳定生成含中文长代码的开发者，给出可跟做的排查路径：装 PowerShell 7、把 VSCode 终端默认 shell 切到pwsh、用settings.json固化配置，最后用一段含中文的长代码写入并校验文件编码。整套动作下来，乱码问题基本能从根上消掉。
2. 前置准备：装 PowerShell 7 并确认 pwsh 可用
核心思路一句话：把执行写入的那层 shell 从Windows PowerShell 5.1换成PowerShell 7（命令名pwsh）。5.1 和 7 是两个独立产品，装完会共存，互不影响。
先用 winget 看一下可安装的版本，确认源里有货：
winget search --id Microsoft.PowerShell正常会列出稳定版和预览版，类似：
名称 ID 版本 源 -------------------------------------------------------------------- PowerShell Microsoft.PowerShell 7.6.0.0 winget PowerShell Preview Microsoft.PowerShell.Preview 7.6.0.101 winget选稳定版安装即可：
winget install --id Microsoft.PowerShell --source winget装完后不要急着关终端，先开一个新的 PowerShell 窗口验证。这里有个高频坑：装完不等于默认链路已经切过去。即使C:\Program Files\PowerShell\7已经进了PATH，如果当前会话或工具默认调用的还是powershell.exe，实际跑的仍然是 5.1。
验证四连，逐条敲：
Get-Command pwsh pwsh --version $PSVersionTable.PSVersion $PSHOME期望结果对照：
| 检查项 | 期望输出 |
|---|---|
Get-Command pwsh | C:\Program Files\PowerShell\7\pwsh.exe |
pwsh --version | PowerShell 7.6.0 |
$PSVersionTable.PSVersion | 主版本为7 |
$PSHOME | C:\Program Files\PowerShell\7 |
如果Get-Command pwsh报找不到，说明安装目录没进PATH，重开一个终端再试；还不行就手动把C:\Program Files\PowerShell\7加到系统环境变量里。这一步过了，才轮到 VSCode 那边配置。
3. 可复制配置：VSCode 终端 profile 与 settings.json
VSCode 的集成终端默认走的是系统默认 shell，得手动把它指到pwsh。有两种做法，建议两个都做，双保险。
第一种，改 VSCode 的settings.json。按Ctrl+Shift+P，输入Preferences: Open User Settings (JSON)，在打开的 JSON 里加上终端 profile 配置：
{ "terminal.integrated.profiles.windows": { "PowerShell 7": { "path": "C:\\Program Files\\PowerShell\\7\\pwsh.exe", "args": ["-NoLogo"] } }, "terminal.integrated.defaultProfile.windows": "PowerShell 7" }-NoLogo是去掉启动横幅，让终端输出干净一点，方便看写入日志。路径里的反斜杠要写成双反斜杠，这是 JSON 转义要求，写错了 VSCode 会直接报 profile 无效。
第二种，如果你用的是 CodeX 这类会自己拉起终端的工具，还要确认它调用的 shell。有些工具会读环境变量SHELL或者自己维护一份 shell 路径配置，把它显式指向pwsh.exe的完整路径，别留成powershell。
改完配置后重启 VSCode，然后新建一个终端，敲：
$PSVersionTable.PSVersion输出主版本是7，说明 VSCode 集成终端已经切过去了。这一步没验证就往下走，后面乱码照旧，白折腾。
注意：
terminal.integrated.defaultProfile.windows这个键在旧版 VSCode 里叫terminal.integrated.shell.windows，已经废弃。如果你照着老教程改没生效，先确认键名是不是新的。
4. 验证请求：写一段含中文长代码并校验编码
配置对不对，得用真实写入来验。下面这段脚本模拟 CodeX 分批写入含中文的长代码，然后检查落盘文件的编码和内容完整性。
先准备一段含中文的长代码内容，用 here-string 写进变量，避免引号转义把命令撑爆：
$content = @' // 用户信息管理模块 // 负责用户资料的读取、更新与缓存同步 export interface UserProfile { id: number; name: string; // 昵称，允许中文 nickname: string; // 备注信息，可能包含多行中文 remark: string; } // 更新用户资料，返回最新对象 export function updateProfile(profile: UserProfile): UserProfile { // 这里做一次浅拷贝，避免污染原始引用 const next = { ...profile }; // 中文备注做一次 trim，去掉首尾空白 next.remark = next.remark.trim(); return next; } '@ $target = Join-Path $PWD "profile-demo.ts" Set-Content -Path $target -Value $content -Encoding utf8NoBOM关键在-Encoding utf8NoBOM。PowerShell 7 支持这个值，写出来就是UTF-8 无 BOM，跟大多数仓库约定一致。5.1 没有这个选项，这也是必须换 7 的原因之一。
写完立刻校验编码和内容：
# 读前 3 个字节，判断有没有 BOM $bytes = [System.IO.File]::ReadAllBytes($target)[0..2] $bytes -join ',' # 用 UTF-8 读回内容，确认中文没坏 Get-Content -Path $target -Encoding utf8 | Select-String "昵称"期望结果：前 3 个字节不是239,187,191（那是 UTF-8 BOM 的标志），Select-String能匹配到"昵称"这一行。如果字节里出现了255,254，说明写成了UTF-16 LE，编码还是没统一。
再验一次分批写入的场景，模拟长代码被拆成多段：
$part1 = "// 第一段：中文注释`n" $part2 = "const msg = '你好，世界';`n" $part3 = "// 第三段：结束`n" Set-Content -Path $target -Value $part1 -Encoding utf8NoBOM Add-Content -Path $target -Value $part2 -Encoding utf8NoBOM Add-Content -Path $target -Value $part3 -Encoding utf8NoBOM Get-Content -Path $target -Encoding utf8三段都指定utf8NoBOM，读回来中文完整、换行正常，就说明分批写入这条链路稳了。实测下来，只要每一批都显式带编码参数，BOM 漂移和乱码基本不会再出现。
5. 本篇常见错排查
报错一：Set-Content : 找不到与参数名称"Encoding"匹配的参数
说明当前跑的还是 5.1，它不认识utf8NoBOM。回到第 2 节，确认$PSVersionTable.PSVersion主版本是 7。如果 VSCode 终端里是 7、但 CodeX 调用的终端还是 5.1，那就是工具侧的 shell 配置没改，去它的配置里把 shell 路径指到pwsh.exe。
报错二：文件写出来带 BOM，Git diff 整片飘红
检查写入命令有没有漏掉-Encoding utf8NoBOM。>和>>重定向在 7 里默认是utf8NoBOM，但为了可读性和一致性，建议统一用Set-Content/Add-Content显式带参数，别依赖默认值。
报错三：中文变成问号或方块
多半是写入时用了UTF-16 LE，或者读取时编码没对上。用第 4 节的字节检查法确认落盘编码，再用Get-Content -Encoding utf8读回。如果文件已经被写坏，别在原文件上追加修复，直接重新生成一份，避免半成品状态叠加。
报错四：命令太长执行失败，或者中间被截断
这是长代码内联到单条命令的固有问题，跟编码无关。解决办法就是分批写入，每批都带-Encoding utf8NoBOM，并且每批写完做一次内容校验。别指望一条命令塞下整份文件，文件越大、中文越多、模板字符串越多，越容易失败。
报错五：装了 PowerShell 7，但pwsh命令找不到
安装目录没进PATH。重开终端；还不行就手动把C:\Program Files\PowerShell\7加到系统环境变量，重启 VSCode 再试。
提示：排查顺序建议固定成"先验版本、再验编码、最后验内容"。版本不对，后面全是白费；编码不对，内容校验也过不了。按这个顺序走，能少绕很多弯。
6. 把链路固化下来，让 CodeX 稳定写中文
整套动作的核心就三件事：装 PowerShell 7、把 VSCode 终端和 CodeX 调用的 shell 都指到pwsh、所有写入命令显式带-Encoding utf8NoBOM。这三步做完，长代码分批写入时的编码漂移和中文乱码基本能消掉。
如果你还在用 CodeX 这类工具做长期编码和 Agent 任务，建议把 shell 配置和编码参数写进项目级的配置里，别每次靠记忆。需要长期跑编码任务的话，可以看看 Coding Plan 的接入方式：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
接入前先去控制台把 API Key 建好：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
具体的接入参数和终端配置说明在文档里：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
想先验证模型对中文长代码的生成效果，可以直接在模型对话里试：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
API 入口统一走 https://taotoken.net/api，配置时把 base URL 指过去就行。官网首页在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，需要看整体能力再点进去。
最后留一个我踩过的坑：改完settings.json一定要重启 VSCode，光新建终端有时候不生效，profile 是启动时加载的。重启后先敲$PSVersionTable.PSVersion确认版本，再跑写入验证，别跳过这步直接上长代码，不然乱码了还得回头查是不是配置没生效。
