如何配置 Copilot 结合自定义提示词库提升复杂业务逻辑的生成质量

Copilot 的默认补全在处理简单函数时很强，但一旦进入公司内部那种层层嵌套、依赖各种自定义 BaseService 的复杂业务逻辑，它就开始胡编乱造。解决这个问题的核心不是指望它能读懂整个仓库，而是通过 .github/copilot-instructions.md (或者在 IDE 设置中配置 Custom Instructions) 给它喂一套“业务逻辑约束集”。

我目前在项目里维护的一套指令集，重点在于强制它遵循特定的设计模式，而不是让它随缘生成。

具体的配置逻辑：

不要写“请写出高质量代码”这种废话，要写具体的约束。我在指令库里配置了以下内容：

# 业务开发规范
- 所有的 Service 层方法必须包含对 `BusinessException` 的异常处理，禁止直接抛出 Generic Exception。
- 数据库操作必须通过 `BaseRepository` 的泛型方法，严禁直接在 Service 中写原生 SQL。
- 所有的 DTO 转换必须调用 `Mapper.toEntity()`，禁止手动用 new 关键字赋值。
- 复杂业务逻辑必须遵循：校验参数 -> 状态检查 -> 执行原子操作 -> 发送异步事件。

实战操作技巧：

当我要写一个涉及多表状态流转的复杂接口时，我不再直接写 // 实现订单取消逻辑，而是采用“上下文锚点法”。

第一步： 在当前文件的顶部或一个临时文档中，通过 @ 符号（如果是 Cursor 或 Copilot Chat）引用相关的实体类和 Base 类。
第二步： 使用精准的提示词触发。例如：

参考 .github/copilot-instructions.md 的状态检查规范，实现 OrderService.cancelOrder 方法。
要求：先检查订单状态是否为 'PAID'，若非此状态抛出 OrderStateException。

踩过的坑：

最严重的一个坑是指令过载。我曾经把整个项目的 API 文档都塞进自定义提示词里，结果导致 Copilot 出现了明显的“注意力漂移”，它开始在代码注释里重复我的指令，而不是写代码。

优化方案： 将指令分为【全局规范】（放在配置文件）和【临时上下文】（在 Chat 窗口输入）。全局规范只写不变量（如：命名习惯、异常处理机制），具体业务逻辑在对话中动态输入。

效率提升点：

配置完这套方案后，最明显的体感是：生成的代码直接可用率从 40% 提升到了 80%。以前我需要手动修改 5-6 处 DTO 转换或异常处理，现在它生成的代码基本符合团队的 Code Review 标准，我只需要关注核心算法逻辑是否正确。