如何通过自定义 .github/copilot-instructions.md 统一团队的代码风格

直接在项目根目录扔一个 .github/copilot-instructions.md 文件，比在团队群里发十遍《代码规范文档》管用得多。Copilot 现在会自动读取这个文件的上下文，这意味着你可以把那些“虽然没写在 ESLint 里但大家都得遵守”的潜规则直接喂给 AI，让它生成的代码第一遍就符合团队口味，省掉大量的手动 Review 时间。

我之前带的项目组，成员对异步处理和错误捕获的习惯完全不同，有的爱用 try-catch 嵌套，有的习惯用 Promise.catch。为了统一，我配置了一套针对 TypeScript 的指令集。

具体操作步骤：
1. 在项目根目录下创建 .github 文件夹（如果已有则直接进入）。
2. 新建 copilot-instructions.md 文件。
3. 将团队的强制性规范以指令形式写入。

我的配置片段（针对 TS 项目）：

# Coding Standards for Project X

## Async & Error Handling
- Always use async/await instead of raw Promises.
- Wrap asynchronous calls in a try-catch block and use the custom `AppError` class for error reporting.
- Avoid using `console.log`; use the `Logger` utility instead.

## Naming Conventions
- Boolean variables must start with a prefix: `is`, `has`, or `should`.
- Interface names must start with `I` (e.g., `IUserConfig`).

## State Management
- Use Zustand for global state; avoid using Context API for frequently updated values.

几个踩过的坑和避坑技巧：

不要写太笼统的描述。 比如写“代码要简洁”，AI 根本不知道什么叫简洁。要写具体到“函数长度不要超过 30 行，超过则必须拆分私有方法”。

优先级覆盖问题。 如果你在 .github/copilot-instructions.md 里定义了规范，但你在 Chat 窗口里又给了一个相反的 Prompt，AI 通常会听你当下的。所以建议把这个文件当作“基准线”，而把临时的需求放在对话中。

避免过度约束。 我试过把所有 API 接口的命名细节全部写进去，结果导致 AI 生成代码时变得非常死板，甚至在处理第三方库时也强行套用内部命名规范，导致编译报错。建议只写核心架构和高频争议点。

效率提升点：
配置好之后，最明显的感受是 Cmd+K 生成的代码不需要我再手动修改变量名或补 try-catch 了。对于新入职的同事，他们通过 Copilot 生成的代码天然就符合团队规范，极大地降低了上手成本。