Copilot 不原生支持代码规范，需通过上下文注入（如注释提示）和后处理（如 ESLint/Prettier 自动修复）协同保障；TypeScript 类型缺失会进一步削弱规范约束力。
VSCode Copilot 无法原生读取公司代码规范
Copilot 本身不解析 ESLint、Prettier 配置文件，也不理解你写的 .eslintrc.js 或 tsconfig.json 中的自定义规则。它生成代码时只“看”当前编辑器上下文（光标附近几行、文件名、语言标识），不会主动加载项目级约束。
这意味着：哪怕你配置了 "indentStyle": "tab" 和 "max-len": 100，Copilot 仍可能用空格缩进、写出 120 字符长的行——它不是“不守规矩”，而是根本没看到规矩。
- 它不读取
.editorconfig、prettier.config.cjs、stylelint.config.js - 它不触发
eslint --fix或prettier --write的自动修正流程 - 它对 TypeScript 的
strict模式、React 的eslint-plugin-react-hooks规则无感知
真正起作用的是「上下文注入 + 后处理」组合策略
想让 Copilot 输出更贴近规范，得靠人“喂上下文”+ 工具“兜底修正”，而不是指望它自学成才。
实操上分两步走：
- 在注释或函数签名里显式写明约束，比如：
// @ts-expect-error 必须用 as const 断言、// eslint-disable-next-line no-console: 'error'—— Copilot 会照抄这类提示 - 开启保存时自动格式化：
"editor.formatOnSave": true，并确保defaultFormatter设为 Prettier 或 ESLint（如esbenp.prettier-vscode） - 关键配置项：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，这样 Copilot 生成后，ESLint 会立刻重写代码
示例：你在写一个 React 组件，刚让 Copilot 补全 useEffect，它可能漏掉依赖数组。但只要你开了 source.fixAll.eslint，保存瞬间就会被插件加上 [] 或报错提醒。
别信「Copilot Chat 自定义规则」能替代工程配置
Copilot Chat 界面里可以输入“请按 Airbnb 规范生成”，但效果极不稳定。它容易混淆规则来源（把旧版 Airbnb 和新版混用），且对私有规则（如你们公司要求 functionName 必须带 Handler 后缀）完全无响应。
真实场景中更可靠的做法是：
- 把高频规范写成注释模板，存在 snippets（如
company-fn片段输出function handleXxxHandler() { ... }） - 在
package.json的scripts里固化检查命令："check:format": "prettier --check ."，CI 卡住不合规提交 - 禁用 Copilot 的自动括号补全（
"editor.autoClosingBrackets": "never"），避免它用错风格闭合（比如 JSX 里补{}而非）
最易忽略的坑：TypeScript 类型推导失效导致规范绕过
Copilot 在 TS 文件里常跳过类型标注，直接写 const data = api.get()，而你们规范强制要求 const data: ApiResponse = api.get()。这不是它“偷懒”，而是它看到 api.get 没类型定义（比如没 d.ts、或用了 any），就放弃推导。
解决方法很实在：
- 确保
node_modules下有可用类型（@types/xxx安装完整） - 对内部 SDK 手动补
index.d.ts，哪怕只有export function get(): Promise<user></user> - 在调用前加一行类型提示注释：
// @type {User[]}，Copilot 会优先采纳这个
没有类型上下文，Copilot 就像蒙眼写代码——它不是不守规范，是根本不知道该守哪条。
