三个字节，让 JSON 解析失败、脚本无法执行、AI 与 项目互相打架。而且一个扎心事实是，“无论是提示词还是加规则，BOM 都有可能被删除。”这是社区用户的明确反馈，规则文件能起到“提醒”作用，但无法在写入层面提供保证。

一、原理：UTF-8 与 BOM

计算机存储字符，需要先有字符集，再有编码。

• 字符集：定义字符和编号，如 Unicode 中 A 是 U+0041，中 是 U+4E2D。
• 编码：定义编号如何变成字节，如 UTF-8、UTF-16、GBK。

UTF-8 是变长编码，兼容 ASCII，没有字节序问题，因此成为 Web、Linux、JSON、YAML 等领域的默认编码。

BOM 全称 Byte Order Mark，字节序标记。它原本用于 UTF-16/UTF-32 标记大端或小端。UTF-8 的 BOM 是：

EF BB BF

UTF-8 本身没有字节序（比如，两个字节表示一个整数，在计算时，就存在两个字节是怎么排列的：大端或是小端）问题，所以 UTF-8 BOM 不是必需的。它更像一个“签名”，告诉软件“这个文件是 UTF-8”。这个习惯主要来自 Windows 生态：Visual Studio、记事本等工具在保存 UTF-8 文件时可能自动加 BOM，以帮助旧软件识别编码。

因此，BOM 不是错误，但它有历史包袱。

二、陷阱：为什么 BOM 会引发问题

现代标准和跨平台工具大多默认 UTF-8 无 BOM。一旦文件带了 BOM，就可能出现：

反过来，无 BOM 的 UTF-8 在部分 Windows / .NET 场景也会出问题：

• 旧版 .NET 编译器可能按系统 ANSI 代码页解析源文件；
• C# 文件中的中文注释、字符串可能乱码或编译错误；
• Visual Studio 打开无 BOM 文件时可能无法自动识别 UTF-8；
• Excel 打开无 BOM 的 UTF-8 CSV，中文可能乱码。

所以问题不在于“BOM 好还是坏”，而在于 文件类型、工具链、项目历史是否统一。

三、核心原则：按文件类型统一

不要问“UTF-8 该不该带 BOM”，而要问：

这个文件类型、这套工具链、这个项目历史，应该统一用哪种？

推荐策略：

关键：同一类文件，全项目统一。

四、新项目一开始怎么做

1. 用 .editorconfig 作为单一事实来源

在项目根目录放置 .editorconfig：

root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true

[*.{cs,vb}]
charset = utf-8-bom

[*.{csproj,vbproj,vcxproj,proj,projitems,shproj}]
charset = utf-8-bom
indent_size = 2

[*.{json,yaml,yml,toml,ini,env}]
charset = utf-8
indent_size = 2

[*.{sh,bash,zsh,py}]
charset = utf-8

大多数现代编辑器会读取 .editorconfig。这是项目级编码规范的起点。

2. 在 CI 或 pre-commit 中检查

例如：

• *.json、*.yaml、*.sh 不得有 BOM；
• *.cs、*.csproj 必须符合项目规定的 BOM 状态。

这样能防止 AI 或新成员无意破坏编码。

五、AI Agent 协作：规则、提示词与验证

项目规则文件是否有效。答案是：有意义，但不足以可靠解决问题。

项目规则（如 .trae/rules/project_rules.md）能让 AI 在认知层面知道编码规范。但 AI 通过工具重写文件时，BOM 可能在写入层被剥离，而不是模型输出层。因此，规则文件能提醒，却不能保证。

更可靠的是三层组合：

第一层：项目规则文件写明规范

# 编码规范

- .cs / .csproj / .vb / .vbproj：UTF-8 with BOM。
- .json / .yaml / .yml / .toml / .ini / .env / .sh / .py：UTF-8 without BOM。
- 编辑已有文件时，必须保持其原有 BOM 状态，不得添加或删除 BOM。
- 修改完成后必须验证 BOM 状态。

第二层：每次任务提示词中显式约束

这是最直接有效的手段。可以把下面内容作为提示词模板：

【编码约束 - 必须遵守】

1. 编辑已有文件前，先检测文件开头 3 个字节：
   - 若为 EF BB BF，则该文件是 UTF-8 with BOM，编辑后必须保留 BOM；
   - 否则是 UTF-8 without BOM，编辑后不得添加 BOM。

2. 新建文件时：
   - .cs / .csproj / .vb / .vbproj / .sln 使用 UTF-8 with BOM；
   - .json / .yaml / .yml / .toml / .ini / .env / .sh / .py 使用 UTF-8 without BOM。

3. 修改完成后验证：
   - PowerShell：Format-Hex -Path "<文件路径>" -Count 3
   - Linux/macOS：xxd -l 3 "<文件路径>"

4. 如果 BOM 状态与规则不符，先修正，再报告完成。

重点是第 3、4 条：让 AI 自己验证并修正。即使写入层丢了 BOM，AI 也有机会在验证步骤发现并补回。

第三层：.editorconfig 兜底

.editorconfig 在编辑器保存文件时生效，与 AI 直接写入是两条路径。它能覆盖规则文件管不到的部分，尤其是 C# 文件 BOM 丢失问题。

如果 AI 仍然无法保持 BOM，可以在提示词中直接要求：

如果修改后发现 BOM 丢失，请生成一个修复脚本，
对受影响的 .cs 文件重新添加 UTF-8 BOM，并执行该脚本。

让 AI 写脚本、执行脚本、验证结果，比单纯要求“请保持 BOM”更可靠。

六、已有项目如何治理

1. 先盘点

让 AI 执行：

请扫描项目中所有 .cs、.json、.yaml、.sh 文件，检测开头 3 字节是否为 EF BB BF，
输出每个文件的路径和 BOM 状态。

2. 决定统一目标

• 历史 .NET 文件全是带 BOM：建议保持带 BOM，避免大规模转换风险；
• 配置文件、脚本、跨平台文件：统一无 BOM；
• 同一类文件必须统一。

3. 批量转换交给 AI

添加 BOM 的提示词：

请扫描所有 .cs 文件。对于缺少 UTF-8 BOM（EF BB BF）的文件，
使用 UTF-8 with BOM 重写。完成后列出每个文件的最终 BOM 状态。

移除 BOM 的提示词：

请扫描所有 .json / .yaml / .sh 文件。
对于带 UTF-8 BOM 的文件，移除 BOM 并保存为 UTF-8 without BOM。
完成后列出每个文件的最终 BOM 状态。

注意：转换前确认文件原本就是 UTF-8，否则可能乱码。

小小总结

配置文件与跨平台脚本坚持 UTF-8 无 BOM；传统 .NET 源文件若历史带 BOM，则全项目统一带 BOM；用 .editorconfig 规定，用提示词让 AI 执行并验证，用 CI 保证不回退。

阅读原文：点击这里​