如何利用 GitHub Copilot 的自定义指令优化企业级项目的代码风格一致性

在处理几万行代码的企业级项目时，最头疼的不是写新功能，而是不同开发者的编码习惯打架。有人习惯用 async/await，有人还在写 .then()；有人喜欢把逻辑塞在 Controller，有人坚持 Service 层。靠 Code Review 强行统一太低效，我最近在尝试通过 .github/copilot-instructions.md 给 Copilot 强行“洗脑”，强制它在生成代码时遵守项目特定的规范。

现在的 Copilot 支持在项目根目录下放置自定义指令文件，它在生成代码前会先读取这个文件的上下文。我把这个文件当成了一个“活的编程规范手册”。

配置实操步骤

在项目根目录创建 .github/copilot-instructions.md，不要写笼统的“请写高质量代码”，要写具体的约束。比如针对一个典型的 TypeScript 企业项目，我的配置是这样的：

# Project Coding Standards

## Architecture
- Use the Repository Pattern for data access. 
- Business logic must reside in `services/` directory, never in `controllers/`.

## TypeScript Style
- Use `interface` for data models, avoid `type` for object definitions.
- Strict typing: No `any` allowed. Use `unknown` if the type is truly dynamic.
- Prefer optional chaining `?.` and nullish coalescing `??` over ternary operators for null checks.

## Naming Conventions
- Boolean variables must start with a prefix: `is`, `has`, or `should`.
- Event handlers must follow the pattern: `handle[Event][Action]` (e.g., `handleUserClick`).

## Error Handling
- Wrap all external API calls in a try-catch block.
- Use the project's custom `AppError` class for throwing exceptions.

效率提升与踩坑心得

配置完之后，最明显的体感是：当你让它“写一个获取用户信息的接口”时，它不再随手写个 express 路由把逻辑全塞进去，而是会自动生成 Controller → Service → Repository 的链路。

这里有几个避坑点：

指令冲突：如果你在 .github/copilot-instructions.md 里写了 A 规范，但在 IDE 的全局设置里写了 B 规范，Copilot 有时会产生幻觉，生成一段“缝合怪”代码。建议统一管理在项目文件里，这样团队成员拉代码后能同步生效。

过度约束：不要把所有 Lint 规则都写进去。比如“缩进两个空格”这种事交给 Prettier，没必要写在指令里，否则会浪费 Copilot 的 Token 窗口，导致它在处理复杂逻辑时丢失上下文。

动态更新：这个文件得随着项目演进。比如我们最近决定将所有 API 返回格式统一为 { code, data, msg }，我直接在指令文件里加上一行 All API responses must follow the standard envelope format，之后 Copilot 生成的所有新接口就全部自动对齐了。

验证效果的 Prompt 技巧

如果你不确定它是否生效，可以用这个指令测试：

Based on our project instructions, how should I implement a new user validation logic?

如果它能准确说出要放在 services/ 文件夹且必须使用 AppError，说明配置成功。