先说清楚一件事：不同厂商对“把多个模型、多种交互形态整合进同一条编码流程”的命名并不统一，Copilot 这边对应的实际能力是模型选择器 + 聊天 + 智能体编辑（跨文件改动并执行命令）+ 仓库级自定义指令这几块的组合。具体入口名称、可用模型列表会随版本和订阅策略变化，以官方文档当前版本为准。这篇教程讲的是这套工作流怎么在你的仓库里真正实现，以及怎么用对照实验判断它到底值不值。
这篇能做出什么
照着做完，你会得到三样东西：
1. 一个“能被 AI 读懂”的仓库：一份 .github/copilot-instructions.md，把技术栈、目录约定、测试命令、禁止事项写进去，之后不管你切哪个模型、用聊天还是智能体，它们读到的都是同一份“入职手册”。
2. 一张任务分层表：把日常需求按 L0–L3 分级，明确哪一级用行内补全、哪一级用聊天、哪一级才值得开智能体编辑。这一步能省掉大量“用大炮打蚊子”的时间。
3. 一份可复现的效果对照记录：固定任务集、固定 prompt、一次只变一个变量，记录首次通过率、人工修改行数、耗时。跑完你会得到类似“L1 任务补全就够，L2 交给智能体 + 推理型模型，L3 必须先人工出方案”这种能写进团队规范的结论，而不是“感觉挺好用”。
举个具体场景：给 GET /orders 加游标分页。这个任务要改路由、服务层、类型定义，还要补测试——典型的 L2。下面就用它当贯穿例子。
前置条件清单
动手前确认这几项，缺一项后面就会卡：
- Copilot 授权：个人订阅或组织分配的名额。免费额度、试用政策以官方页面为准。
- 编辑器：VS Code 或 JetBrains / Visual Studio 系列。不同编辑器里智能体编辑、模型选择器的入口位置和成熟度有差异，本文以 VS Code 的通用形态描述。
- 一个能跑的仓库：本地 clone 下来，测试命令能跑通。这一条最关键——智能体编辑的产出必须能被自动验证，否则你只能靠肉眼 review。
- Git 分支习惯：每次实验开新分支，方便对比和丢弃。
- 如果要接第三方模型（BYOK）：你自己的 provider API Key，费用走你自己的账户。是否需要企业策略放行，以官方文档为准。
- 一个练习任务：从最近的 issue 里挑一个“改 2–5 个文件”的小需求。
先把基线跑一遍，记下结果：
```bash
git checkout -b feat/orders-cursor-pagination
pnpm install
pnpm test
pnpm lint
```
（Node 项目用 pnpm test，Python 项目换成 pytest -q 和 ruff check .，按你的仓库实际命令来。）
第一步：把仓库上下文接进来
模型再强，不知道你的目录约定就会瞎猜。仓库根目录建 .github/copilot-instructions.md：
```markdown
项目约定
技术栈
- TypeScript + Express + Vitest
- 包管理用 pnpm，不要用 npm 或 yarn
目录结构
- src/routes/ 只放路由声明与参数校验
- src/services/ 业务逻辑，所有数据库访问都在这里
- src/types/ 共享类型
代码风格
- 不使用 default export
- 错误统一抛 AppError，不要直接 res.status().send()
- 函数超过 40 行考虑拆分
禁止事项
- 不要新增第三方依赖
- 不要改动 migrations/ 下的文件
- 不要改 package.json 的 scripts
命令
- 测试：pnpm test
- 类型检查：pnpm tsc --noEmit
- 格式：pnpm lint --fix
```
这份文件的价值不在“写得全”，而在所有模型共用同一份约束。这就是“融合”的第一层含义：融合的不是模型权重，而是上下文和规则。
在聊天里还可以用 # 引用具体文件、用 @workspace 让它在整个仓库范围检索（参与者名称和可用范围以你所装版本为准）。任务越具体，越应该精确引用文件，而不是让它自己猜。
第二步：分清三条通道各自负责什么
| 通道 | 交互形态 | 适合的任务 | 上下文范围 | 主要风险 |
|---|---|---|---|---|
| 行内补全 | 边打字边出灰字 | 样板代码、重复模式、写完签名猜实现 | 当前文件附近 | 容易“顺着错误往下编” |
| 聊天 | 对话框问答、贴片段 | 解释代码、问方案、生成单个函数或测试 | 你引用的文件 + 仓库检索 | 答案不一定落地到仓库 |
| 智能体编辑 | 描述任务，它跨文件改并跑命令 | 加接口、加字段全链路、批量重构 | 多文件 + 终端反馈 | 改动范围容易失控 |
一条实用判断：能一句话说清验收标准的，交给智能体；说不清的，先在聊天里聊明白。
第三步：模型接入与选择
在聊天面板的模型选择器里可以切换模型，列表内容随订阅和组织策略变化。通用做法是：
- 轻活给快模型：改命名、补注释、写 commit message、解释一段代码。
- 重活给推理型模型：跨文件改动、需要权衡的方案、复杂 bug 定位。
- 超长上下文任务：整个模块的理解、大文件重构，优先选AI 词典：上下文窗口">上下文窗口更大的模型。
如果你的组织需要特定供应商，或者出于合规要求要走自己的账号，可以用“自带模型”（BYOK）方式接入第三方模型。大致流程是在模型选择器里找到管理模型的入口，选择供应商、填入 API Key 和模型名，具体字段、支持的供应商、是否需要管理员在策略中开启，以官方文档当前版本为准。
一个容易忽略的点：企业版可能通过策略限制可用模型，你自己电脑上能选，换台机器就没了——先确认是策略问题再排查别的。
第四步：任务分层与分配
把日常需求分成四级，分配规则直接抄：
| 层级 | 典型任务 | 分配通道 | 人工介入程度 |
|---|---|---|---|
| L0 | 重命名、补 import、格式化、写注释 | 行内补全 | 基本不看 |
| L1 | 写单个工具函数、补一个测试用例 | 补全 + 聊天 | 扫一眼 diff |
| L2 | 加一个接口、加一个字段的全链路、改一处业务逻辑 | 智能体编辑 | 逐块 review |
| L3 | 换 ORM、重构鉴权、拆分模块 | 先聊天出方案，人工定稿后拆成多个 L2 | 全程主导 |
分层不是教条。判据是验收标准能不能写成可执行的检查：能写成“测试全绿 + 三条断言”，就是 L2；只能写成“感觉更清晰了”，那就是 L3，别交给智能体自己决定。
第五步：走一遍完整的 L2 任务
目标：给 GET /orders 加游标分页，保持向后兼容。
1）先问清楚现状。 在聊天里引用相关文件，问“现有的列表接口是怎么做分页的？涉及哪些文件？”。拿到文件清单再动手，避免智能体到处乱翻。
2）写验收标准再开智能体。 Prompt 模板直接抄：
```text
目标：给 GET /orders 增加游标分页，保持向后兼容。
约束：
- 不改动数据库 schema，不加索引迁移
- 不新增第三方依赖
- 沿用 src/services/orderService.ts 里已有的查询封装
- 路由层只做参数校验，业务逻辑放 service
验收标准：
1. 不传 cursor 时，返回结果与现在完全一致
2. 传 cursor 时返回下一页，响应体带 nextCursor 字段
3. pnpm test 全绿，新增至少 3 条测试覆盖上述两种情况
先列出你打算修改的文件清单和改动要点，等我确认后再开始改。
```
最后一句是关键：先出计划，再动手。多花三十秒确认清单，能省掉十分钟回滚。
3）逐块看 diff。 重点看三件事：有没有动到禁止清单里的文件、有没有偷偷加依赖、测试是真断言还是 expect(true).toBe(true)。
4）跑验证。
```bash
pnpm test
pnpm tsc --noEmit
pnpm lint
```
5）失败就把报错原样贴回去，并限定范围：“只改 src/services/orderService.ts 里的游标构造逻辑，其他文件不要动。” 无限范围的“修一下”会让它越改越远。
6）提交。 commit message 让它生成草稿，你自己改一版——这类小事用快模型就够。
第六步：做效果对照，别靠感觉
想回答“到底该用哪个模型、哪条通道”，只能靠对照。做法：
固定任务集：挑 5–8 个历史小需求（最好已有对应 PR），或自己写 5 个 L2 任务。任务要小到 30 分钟内能 review 完。
固定变量：同一个 prompt、同一个分支起点、同一套测试。每次只变一个变量——要么变模型，要么变通道，不要同时变。
记录指标：
| 任务 | 通道 | 模型 | 测试首次通过 | 人工修改行数 | 耗时(分) | 无关改动 | 备注 |
|---|---|---|---|---|---|---|---|
| orders 游标分页 | 智能体 | A | 否 | 38 | 22 | 有（动了 types） | 需二次提示 |
| orders 游标分页 | 智能体 | B | 是 | 6 | 14 | 无 | prompt 未变 |
| 补 3 条测试 | 聊天 | A | 是 | 2 | 6 | 无 | 直接可用 |
| 重命名 DTO 字段 | 补全 | — | 是 | 0 | 3 | 无 | — |
注意顺序效应：先做的任务你会越来越熟。至少跑两轮，第二轮把模型顺序倒过来。样本只有五六个任务时，别下强结论，看趋势就行。
把结论写成规则，例如：“L1 任务补全足够，不值得开智能体；L2 用推理型模型 + 智能体，prompt 里必须带验收标准；L3 一律先人工出设计。” 这比“某某模型更强”有用得多。
常见坑与排错
智能体改了一大片无关文件。 prompt 里明确列出允许修改的文件，并要求先出计划。review 时用逐文件视图，不要一路“全部接受”。
它说测试通过了，其实没跑。 智能体在受限环境里可能拿不到你的依赖。先本地确认命令能跑通，再把确切命令写进 prompt。
模型列表里少了某个模型。 大概率是组织策略或订阅档位限制，不是网络问题。
BYOK 配了不生效。 依次查：Key 是否有该模型的调用权限、base URL 是否填对（第三方网关常见坑）、公司网络是否需要代理。字段名以官方文档为准。
生成的代码 import 了不存在的包。 在指令文件里写死“不要新增第三方依赖”，并在 prompt 里重复一遍。约束写在两个地方不冗余。
补全总是猜错。 先把函数签名和一行注释写出来再触发补全，比空等它猜有效得多。
上下文被截断。 别让它“自己找相关文件”，用 # 精确引用三五个文件，效果通常更好。
隐私。 不要把密钥、真实客户数据贴进对话。企业版有内容排除相关策略，配置方式以官方文档为准。
先看 diff 再应用。 如果编辑器里有自动应用类设置，实验阶段先关掉。
下一步建议
- 把对照实验做成例行公事：每季度用新的 5 个任务重跑一次，模型和产品迭代很快，旧结论会过期。
- 把 prompt 模板沉淀到仓库：建
docs/ai-prompts/放常用模板，新人直接抄，比口口相传可靠。 - 让验证自动化：智能体的产出质量上限，取决于你的测试覆盖。测试越厚，越敢放手。
- 关注官方 changelog：模型列表、智能体能力、企业策略项都在变，命名和入口也可能调整，以官方文档当前版本为准。
- 把踩过的坑写回指令文件：每遇到一次“它又动了 migrations”，就加一条禁止项。这份文件是活的。