GitHub Copilot 这种 AI 插件怎么用才能不让它瞎写代码？

很多人觉得 Copilot 或者 Cursor 生成的代码一股“塑料味”，满屏都是没用的注释和逻辑冗余。这其实不是模型不行，是你喂给它的信息太脏了。AI 补全的本质是概率预测，如果你只给一个函数名，它只能根据统计学概率去猜；如果你把相关的 Interface 定义、甚至上文的报错日志直接丢进对话框，它的逻辑准确度会瞬间从 60% 提到 90% 以上。

Cursor 的 Context 模式到底在玩什么花样

上周二我在重构一个复杂的 React Hook 时，发现直接问“帮我优化这段代码”简直是浪费 Token。Cursor 强在它的 @ 符号。

这是一个很细节的操作：当你需要 AI 理解整个项目的逻辑流时，不要指望它自己能“读懂”你的硬盘。你要用 @Files 指定具体的业务逻辑文件，或者用 @Codebase 让它进行全量检索。

我做了一个简单的对比测试，针对同一个复杂的算法重构需求：

| 输入方式 | 生成代码的逻辑正确率 | 是否包含冗余注释 | 响应耗时 (s) |
| :--- | :--- | :--- | :--- |
| 直接输入需求 | 45% | 严重严重 | ~5s |
| 使用 @File 指定上下文 | 82% | 较少 | ~8s |
| 使用 @Codebase + 具体的错误日志 | 94% | 极少 | ~15s |

你会发现，虽然 @Codebase 慢一点，但它能帮你省下大量的 Debug 时间。如果你正在进行高强度的 AI编程实战，这种对上下文精准控制的能力就是分水岭。

别把 Copilot 当聊天机器人，把它当成“自动补全引擎”

很多人习惯在 Copilot Chat 里跟它聊天，这其实是错位的。Copilot 最强的地方在于它的 Inline Suggestion（行内建议）。

我总结了一个避坑指南：如果你发现它开始疯狂生成一大堆废话注释，通常是因为你当前文件的逻辑太散了。

解决办法是：
1. 保持文件职责单一。如果一个文件超过 500 行，Copilot 的注意力会分散。
2. 利用注释引导。别写 // function to add two numbers，这种废话 AI 也会写。你要写 // TODO: 处理用户权限校验，如果失败则抛出 CustomAuthError。这种带有明确逻辑指向的注释，能强制引导模型进入特定的逻辑路径。

有时候，直接在编辑器里写下 // Step 1: Fetch data from API，比你在 Chat 窗口里描述半天要有效得多。

一个能跑通的 Prompt 模版

在 Cursor 里使用 Composer 模式（Cmd+I）时，如果你想让它写一个特定功能的测试用例，千万别说“写个测试”。试试这个结构：

Context: @auth_service.ts @user_model.ts
Task: 使用 Jest 编写针对 login 函数的边界测试
Constraint: 必须覆盖 password_expired 的场景，mock 掉 database 的返回值为 error
Output Format: 只输出代码，不要解释原理

这种带有 Context、Task、Constraint 和 Output Format 的四段式结构，是我在处理 AI编程实战 项目时总结出的最高效写法。

关于 Copilot 报错的冷知识

我上个月遇到过一个离谱的情况：Copilot 竟然建议我用一个已经废弃的 API。

这通常是因为它的训练数据里包含了大量旧项目的代码。这时候你不能只靠“重试”，你要强制纠偏。在对话框里输入：Note: Using version 4.x of library X. Avoid using deprecated method Y. 这一句简单的声明，比你改十遍代码都管用。

另外，如果你的 GitHub Copilot 响应速度突然变慢（实测从 1s 变成 5s 以上），大概率不是网络问题，而是你当前打开的文件里有太多的类型定义导致它的 Context Window 溢出了。这时候，关掉那些无关紧要的标签页，或者手动清空一下 Chat 历史，效果立竿见影。