如何在 GitHub Copilot 中通过自定义 .github/copilot-instructions.md 规范代码风格

很多人的 Copilot 总是写出那种“虽然能跑但看着心烦”的代码，比如在 TypeScript 项目里莫名其妙地给所有变量加类型定义，或者在 React 组件里乱用 useEffect。其实不需要每次在 Prompt 里强调，直接在项目根目录丢一个 .github/copilot-instructions.md 文件，就能强行给 AI 戴上“风格枷锁”。

这个文件的优先级极高，Copilot 在生成代码前会自动读取其中的指令。我之前在处理一个大型 Monorepo 时，为了防止 AI 把不同模块的命名规范搞混，配置了一套严格的指令集。

实操配置技巧

不要写“请尽量使用函数式编程”这种模糊的话，AI 听不懂。要写具体的禁令和强制要求。我的配置逻辑是：基础规范 → 技术栈禁忌 → 命名约定 → 错误处理方案。

以下是我目前在生产项目中使用的一段配置片段：

# 代码风格规范

**TypeScript & React 强制要求**
- 严禁使用 `any`，必须定义具体的 Interface 或 Type。
- 所有的组件必须使用函数式组件 + Arrow Function 形式。
- 状态管理必须优先使用 Zustand，禁止在不需要的地方使用 Redux。

**命名约定**
- 接口定义必须以 `I` 开头，例如 `IUserResponse`。
- 异步函数必须以 `fetch` 或 `handle` 开头。
- 常量必须全部大写，使用下划线分隔，如 `MAX_RETRY_COUNT`。

**逻辑实现**
- 优先使用 Optional Chaining (`?.`) 和 Nullish Coalescing (`??`)。
- 所有的 API 请求必须包裹在 try-catch 块中，并调用 `logger.error()` 记录错误。

避坑指南与效率提升

1. 避免指令冲突：如果你在 .github/copilot-instructions.md 里要求用 Tailwind CSS，但在代码注释里写了用 CSS Modules，AI 会在两种风格之间反复横跳，导致生成的类名极其混乱。统一一个地方配置。
2. 颗粒度控制：不要把整个公司的 50 页编码规范全部塞进去，那样会浪费 Token 且降低响应速度。只放那些 AI 经常写错、且对项目至关重要的核心规则。
3. 动态调整：当你发现 Copilot 在某个特定模块反复犯同一个错误时，立刻把这个错误模式写成一条“禁令”加入到该文件中，比你手动改十次代码要高效得多。

配置完这个文件后，你会发现 Copilot 生成的补全结果与现有代码库的融合度大幅提升，基本告别了“生成 → 手动修改风格 → 再次生成”的低效循环。