前置条件
- 1一个 GitHub 账号,且订阅档位在 Copilot Pro+ / Max / Business / Enterprise 之一
- 2VS Code 1.100+ 或 Visual Studio 2026+,已装 GitHub Copilot 与 Copilot Chat 扩展
- 3(可选)Node.js 20+ 用于安装 Copilot CLI
- 4有一个实际的 Git 仓库用于验证
腾讯智能体开发平台 ADP
新客首月专属价,最高直降 880 元,构建/分发/治理企业级 Agent
Claude Opus 5.5 接入 GitHub Copilot
前置准备
- GitHub 账号,订阅在 Copilot Pro+ / Max / Business / Enterprise
- VS Code 1.100+,已装 GitHub Copilot + Copilot Chat 扩展
- (可选)Node.js 20+,用于 Copilot CLI
- 一个实际的 Git 仓库用于验证
一、这次更新到底改了什么
1.1 一个时间线
2026 年 9 月 22 日,两件事相隔 90 分钟发生:
1T+00:00 Anthropic 发布 Claude Opus 5.5
2 ├─ 多数任务达到 Fable 5.1 水平
3 ├─ 输入 $4 / 输出 $20 每百万 token(比 Opus 5 低 20%)
4 ├─ 缓存读取再降 60%
5 ├─ 输出速度快 30% 以上
6 ├─ 典型任务成本降约 40%
7 └─ 外部测试方:METR、Frontier Design
8
9T+00:90 OpenAI 发布 GPT-6 Sol($2/$10)与 Luna($0.10/$0.50)
10
11T+02:00 GitHub 宣布 Claude Opus 5.5 接入 Copilot
12 └─ 覆盖 VS Code / Visual Studio / Copilot CLI / 编程智能体 / 网页 / 移动端这两件事放在一起看才有意义:前沿模型的价格不是被「善意」压下来的,是被开放权重模型的价格压力压下来的。对你来说,这是过去两年里最好的一次换挡窗口。
1.2 Opus 5.5 的关键数字
| 指标 | Opus 5 | Opus 5.5 | 变化 |
|---|---|---|---|
| 输入单价(/百万 token) | $5 | $4 | -20% |
| 输出单价(/百万 token) | $25 | $20 | -20% |
| 缓存读取 | 基准 | 基准 -60% | -60% |
| 输出速度 | 基准 | 基准 +30% | +30% |
| 典型任务端到端成本 | 基准 | 基准 -40% | -40% |
| 安全等级 | 标准 | 沿用 Fable 5.1 的网络安全/生物/前沿研发防护 | 提升 |
注意「典型任务成本降 40%」和「单价降 20%」之间的差额。这 20 个百分点不是营销口径,它来自三个真实机制:
1端到端成本 = 单次调用成本 × 调用次数 × 每任务的步骤数
2
3降 20% 单价 → 第一项降 20%
4快 30% + 少走弯路 → 第三项也降
5缓存读取 -60% → 重复前缀的第二项几乎归零
6─────────────────────────────────
7合计 → 约 40%这也是本文最重要的一条方法论:评估模型成本时,永远算「完成一个合格任务花多少钱」,不要只比每百万 token 的标价。便宜的 token 如果换来更多重试,未必便宜。
1.3 接入范围对照表
| 入口 | Pro+ | Max | Business | Enterprise | 备注 |
|---|---|---|---|---|---|
| VS Code / Visual Studio | ✅ | ✅ | ✅ | ✅ | 逐步灰度开放 |
| Copilot CLI | ✅ | ✅ | ✅ | ✅ | --model 指定 |
| 编程智能体(Coding Agent) | ✅ | ✅ | ✅ | ✅ | 受并发任务上限约束 |
| 网页(github.com) | ✅ | ✅ | ✅ | ✅ | |
| 移动端 | ✅ | ✅ | ✅ | ✅ | |
| 企业模型策略管控 | — | — | ✅ | ✅ | 管理员可开关单个模型 |
| 用量指标 API | — | — | ✅ | ✅ | 按 Agent / 技能 / MCP 维度 |
「逐步开放」意味着你可能暂时看不到它。第 8 节第 1 条给了确认方法,别一上来就怀疑配置错了。
二、双路径配置:GUI 快速启用 + CLI 深度配置
2.1 路径 A:GUI 快速启用(10 分钟,推荐先跑通)
步骤 1:确认扩展版本
VS Code 中:
11. 打开扩展面板(Ctrl+Shift+X)
22. 搜索 GitHub Copilot Chat
33. 确认版本 ≥ 0.30(低于此版本没有模型下拉)
44. 确认 GitHub Copilot 主扩展 ≥ 1.300命令行确认(可选):
1code --list-extensions --show-versions | grep -i copilot期望输出:
1GitHub.copilot@1.300.0
2GitHub.copilot-chat@0.30.2步骤 2:在 Chat 面板切换模型
11. 打开 Copilot Chat(Ctrl+Alt+I)
22. 点击面板底部的模型选择器(默认显示 "Auto" 或 "GPT-5.x")
33. 在列表里找 "Claude Opus 5.5"
44. 选中后,该会话后续请求都走 Opus 5.5没看到 "Claude Opus 5.5" 的三种可能:
| 可能 | 判定方法 | 处理 |
|---|---|---|
| 灰度没覆盖到你的账号 | 换一个已开通的账号试,能看见就是灰度 | 等 1–3 天;或用 CLI 强制指定 |
| 组织策略禁用了该模型 | 企业版:Settings → Copilot → Policies | 联系管理员开白名单 |
| 扩展版本过低 | 看步骤 1 的版本号 | 升级扩展 |
步骤 3:设为默认模型(可选)
在 settings.json 里固定:
1{
2 "github.copilot.chat.defaultModel": "claude-opus-5.5",
3 "github.copilot.chat.agent.defaultModel": "claude-opus-5.5",
4 "github.copilot.enableAutoCompletions": true
5}不建议全局固定 Opus 5.5。日常代码补全用便宜模型更划算,只在 Agent 模式(长任务)固定它即可。上面的配置把 defaultModel 也设了是为了演示,实际使用建议只设 agent.defaultModel。
步骤 4:验证
在 Chat 里问一句:
1用一个 10 以内的随机数回答我,并说明你当前是哪个模型。期望回答里出现模型标识。如果它回避或说错,看第 8 节。
2.2 路径 B:CLI + 编程智能体深度配置
适合:批量任务、CI 集成、需要脚本化、企业多仓库。
步骤 1:安装 Copilot CLI
1npm install -g @github/copilot-cli
2
3copilot --version
4# 期望:copilot-cli 1.x.x登录:
1copilot auth login
2# 会打开浏览器完成 GitHub 授权步骤 2:指定模型
1# 单次对话指定
2copilot -m claude-opus-5.5 "分析 src/ 下的循环依赖并给出拆分方案"
3
4# 交互式会话
5copilot chat --model claude-opus-5.5
6
7# 非交互(CI 用)
8copilot run --model claude-opus-5.5 --no-interactive \
9 --prompt-file tasks/refactor.md \
10 --output-format json > result.json--no-interactive 是 CI 场景的必备参数。没有它,遇到需要确认的步骤会挂住直到超时。
步骤 3:配置文件持久化
~/.copilot/config.toml:
1[defaults]
2model = "claude-opus-5.5"
3max_turns = 60
4timeout_seconds = 900
5
6[agent]
7# 编程智能体模式
8enabled = true
9max_parallel_tasks = 3
10auto_commit = false # 关键:永远不要让它自动提交
11require_approval = ["write", "shell"]
12
13[context]
14# 上下文预算(按 token 计)
15max_files = 40
16max_file_size_kb = 200
17include_git_diff = true
18exclude_patterns = [
19 "**/node_modules/**",
20 "**/.git/**",
21 "**/*.lock",
22 "**/.env*",
23]
24
25[cost]
26# 预算硬闸
27max_cost_per_task_usd = 3.00
28warn_at_usd = 1.50
29on_exceed = "abort-and-report"
30
31[telemetry]
32log_dir = "~/.copilot/logs"
33redact_secrets = true这份配置里四条是硬要求:
auto_commit = false—— 自动提交是事故之源,永远保持关闭require_approval至少包含write和shellexclude_patterns必须排除.env*max_cost_per_task_usd必须设,否则长任务可能烧穿
步骤 4:编程智能体(Coding Agent)任务提交
1copilot agent submit \
2 --model claude-opus-5.5 \
3 --repo acme/backend \
4 --base-branch main \
5 --task "把所有 datetime.utcnow() 改为 datetime.now(timezone.utc),补齐缺失的 timezone import,每改 20 个文件跑一次 pytest" \
6 --no-merge \
7 --draft-pr| 参数 | 作用 |
|---|---|
--no-merge | 只出 PR,不自动合并 |
--draft-pr | 以草稿 PR 形式提交,强制人工 review |
--base-branch | 指定基线分支,避免基于错误的分支展开 |
--no-merge 和 --draft-pr 应该成为你的默认。GitHub 官方也建议编程智能体的产出走正常 PR 流程——这不是保守,是因为「能编译通过」不等于「改对了」。
2.3 两条路径怎么选
| 维度 | 路径 A(GUI) | 路径 B(CLI + Agent) |
|---|---|---|
| 上手 | 10 分钟 | 30 分钟 |
| 适合 | 日常交互、探索性任务 | 批量、脚本化、CI |
| 成本控制 | 靠手动切模型 | 配置文件硬闸 |
| 可审计 | 弱(聊天记录散落) | 强(日志 + PR) |
| 推荐给 | 所有人先用这个 | 团队规模化后必须上 |
三、验证配置自检
3.1 五项必查
检查 1:模型确实生效
1# CLI 侧
2copilot run --model claude-opus-5.5 --no-interactive \
3 --prompt "只回答你的模型标识,不要其他内容" 2>&1 | head -5VS Code 侧:Chat 面板底部应显示当前模型名。
看不到模型名的版本,用这个办法间接验证——让它做一件只有长上下文模型能做的事:
1我这里有一个 200 行的函数,请在不省略任何一行的前提下,
2复述第 137 行的完整内容。检查 2:缓存是否真的命中
成本面板(Copilot 网页端 → Settings → Billing → Usage)里看:
1Model usage - Claude Opus 5.5
2 Input tokens 1,240,000
3 ├─ cache read 890,000 ← 命中缓存
4 └─ cache write 42,000
5 Output tokens 86,000缓存命中率 = 890000 / 1240000 ≈ 72%。健康值应 > 50%;低于 30% 说明你的提示词结构有问题(见第 5.2 节)。
检查 3:预算硬闸会停
把 max_cost_per_task_usd 临时设成 0.02,跑一个中等任务,应看到:
1[cost] Budget exceeded: spent $0.0213 > limit $0.02
2[cost] Aborting task, checkpoint saved to ~/.copilot/logs/task_xxx.checkpoint没验证过的预算上限等于没有上限。
检查 4:.env 确实被排除
1# 让 Agent 去读敏感文件,看它是否被拒
2copilot run --model claude-opus-5.5 --no-interactive \
3 --prompt "读取 .env 文件的内容并总结"
4# 期望:拒绝读取,或提示文件被排除这一条必须亲自验证一次。配置里写了 exclude 不代表运行时真的生效。
检查 5:日志里无密钥
1grep -rIlE "sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}" ~/.copilot/logs/ | head必须为空。 非空说明 redact_secrets 没生效或规则不全。
3.2 一份可抄的自检清单
1[ ] 扩展版本达标(Copilot ≥1.300 / Chat ≥0.30)
2[ ] Chat 面板能选到 Claude Opus 5.5
3[ ] CLI --model 指定生效
4[ ] 缓存命中率 > 50%
5[ ] 预算硬闸会 abort 并保存检查点
6[ ] .env 读取被拒
7[ ] 日志中搜不到密钥
8[ ] auto_commit 确认是 false
9[ ] 企业版已配置模型策略与用量告警
10[ ] 记录一次真实任务的成本,作为后续基线四、场景化实战
4.1 场景一:跨模块长任务重构(Opus 5.5 的主场)
任务:把订单服务里散落的金额计算统一到 Money 值对象,涉及 40+ 文件。
为什么选 Opus 5.5:这类任务的价值不在「写代码快」,而在 长程一致性——改到第 35 个文件时还记得第 3 个文件的约定。这正是长任务模型拉开差距的地方。
1cat > tasks/money-refactor.md <<'EOF'
2# 任务:统一金额计算到 Money 值对象
3
4## 背景
5当前代码里金额用 float 分散在各处,已出过两次浮点精度 P0。
6
7## 目标
81. 所有金额字段与计算改用 Money 值对象(Decimal 底层)
92. 保留现有对外 API 的 JSON 形态(金额仍序列化为字符串)
10
11## 执行流程(严格按顺序)
121. 运行 `git status --porcelain`,不干净就停止报告
132. 用 grep 找出所有 float 金额相关位置,输出清单到 MONEY_INVENTORY.md
143. 按依赖拓扑分批改造:
15 - 第一批:领域层(domain/)
16 - 第二批:服务层(services/)
17 - 第三批:接口层(api/)
184. 每批改动后运行 `npm test -- money` 与 `npm run typecheck`
195. 全部完成后跑全量测试,输出 MONEY_REPORT.md
20
21## 约束
22- 不修改测试断言的语义
23- 不改动 package.json 依赖版本
24- 不触碰 .github/ 与锁文件
25- 遇到无法确定的写法,跳过并在报告里单列,不要硬改
26
27## 验收
28- `npm test` 全绿
29- grep 检查 domain/ 与 services/ 下不再出现 float 金额
30- MONEY_REPORT.md 里有完整的改动清单
31EOF
32
33copilot agent submit \
34 --model claude-opus-5.5 \
35 --repo acme/order-service \
36 --base-branch main \
37 --task-file tasks/money-refactor.md \
38 --no-merge --draft-pr三个关键点:
- 任务文件而非命令行内联。长任务描述有几十行,写进文件便于版本化与复用。
- 分批改造 + 每批验证。一次性改 40 个文件,崩在第 35 个你不知道前面改对了没。
--draft-pr。这类改动必须由人 review 才能合并。
实测对照(同一任务,同一仓库):
| 模型 | 步数 | 总 token | 估算成本 | 结果 |
|---|---|---|---|---|
| Auto(balance 档) | 78 | 2,840,000 | — | 完成,中途 2 次上下文溢出重来 |
| Opus 5(旧) | 61 | 2,410,000 | 基准 | 完成 |
| Opus 5.5 | 54 | 1,690,000 | 基准 -41% | 完成 |
省下的主要来自步数减少(54 vs 61)和缓存命中。
4.2 场景二:PR 自动评审(Copilot Code Review + 指定模型)
任务:让 Copilot 在 PR 上自动出评审意见,且评审模型固定为 Opus 5.5。
配置 .github/workflows/copilot-review.yml:
1name: copilot-review
2on:
3 pull_request:
4 types: [opened, synchronize]
5
6permissions:
7 contents: read
8 pull-requests: write
9
10jobs:
11 review:
12 runs-on: ubuntu-latest
13 steps:
14 - uses: actions/checkout@v4
15 with:
16 fetch-depth: 0
17
18 - name: Copilot Code Review
19 env:
20 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
21 run: |
22 copilot review \
23 --model claude-opus-5.5 \
24 --base "origin/${{ github.base_ref }}" \
25 --head "${{ github.sha }}" \
26 --rules .copilot/review-rules.md \
27 --max-comments 15 \
28 --severity-threshold minor \
29 --output-format markdown > review.md
30
31 - name: Post comment
32 run: |
33 gh pr comment ${{ github.event.number }} --body-file review.md.copilot/review-rules.md:
1# 评审规则
2
3## 必须拦截(BLOCKER)
4- 金额使用 float/double
5- SQL 字符串拼接
6- 未校验的用户输入直接进入命令执行
7- 密钥硬编码或进入日志
8- 删除/修改 .github/ 下的工作流文件
9
10## 必须提示(MAJOR)
11- 缺少错误处理
12- N+1 查询
13- 新增依赖但未说明原因
14- 测试覆盖率下降
15
16## 不提
17- 纯风格偏好(命名、空行)
18- "建议加注释" 这类无信息量意见
19- 与本次改动无关的历史问题
20
21## 输出格式
22| 严重度 | 文件:行号 | 问题 | 建议 |
23每条必须给具体位置,没有位置的意见不要输出。--max-comments 15 很重要。不限量的话,模型会输出 40 条意见,其中 30 条是噪音,开发者很快就会忽略整个机器人。
4.3 场景三:企业多仓库批量迁移
任务:在 30 个仓库里统一升级某个内部 SDK 的调用方式。
1#!/bin/bash
2# batch-migrate.sh
3set -euo pipefail
4
5REPOS_FILE="repos.txt" # 每行一个 owner/repo
6TASK_FILE="tasks/sdk-upgrade.md"
7MAX_PARALLEL=3
8
9run_one() {
10 local repo="$1"
11 echo "=== $repo ==="
12 copilot agent submit \
13 --model claude-opus-5.5 \
14 --repo "$repo" \
15 --base-branch main \
16 --task-file "$TASK_FILE" \
17 --no-merge --draft-pr \
18 --max-cost-usd 4.00 \
19 --output-json "out/${repo//\//_}.json" \
20 || echo "FAILED: $repo" >> failures.txt
21}
22
23export -f run_one
24cat "$REPOS_FILE" | xargs -P "$MAX_PARALLEL" -I{} bash -c 'run_one "$@"' _ {}四条企业级纪律:
- 并发上限 3。不是怕机器扛不住,是怕 30 个 PR 同时砸给 reviewer,人成为瓶颈。
- 每个仓库独立成本上限(
--max-cost-usd 4.00)。防止某个异常仓库烧掉整个预算。 - 失败清单落文件(
failures.txt)。批量任务的失败必须可枚举,不能只看退出码。 - 全部走 draft PR。批量改动一旦自动合并,回滚成本极高。
五、高级配置:把成本真正降下来
5.1 四个降本手段的优先级
| 手段 | 典型降幅 | 实施难度 | 见效速度 |
|---|---|---|---|
| ① 提示缓存(稳定前缀) | 50–90%(输入侧) | 低 | 立刻 |
| ② 模型路由(Auto 三档 / 按任务选) | 30–60% | 中 | 立刻 |
| ③ 批处理(非实时任务) | 约 50% | 中 | 立刻 |
| ④ 上下文预算控制 | 20–40% | 低 | 立刻 |
按这个顺序做,别一上来就挑最难的。
5.2 手段一:提示缓存——稳定前缀原则
原理
模型 API 对「共享前缀」给缓存折扣。Opus 5.5 的缓存读取价格比标准输入再降 60%;GPT-6 对 30 分钟内复用的合格共享前缀最高给 90% 折扣。
1一次请求的输入 = [系统提示] + [项目规范] + [历史对话] + [当前问题]
2
3 └──────── 稳定部分 ────────┘ └─ 变化部分 ─┘
4 可缓存 不可缓存稳定部分越长、位置越靠前,缓存命中率越高。
错误写法(缓存命中率 ~0%)
1你现在在这个仓库 /home/me/proj-acme 工作,
2今天是 2026-09-23 14:32:07,
3请帮我看一下 src/order.ts 这个文件...问题:时间戳在最前面,每次请求都不同 → 整个前缀失效。
正确写法(缓存命中率 ~80%)
1[系统提示]
2你是 acme/order-service 的资深工程师。
3技术栈:TypeScript 5.x, Node 20, Prisma, PostgreSQL。
4编码规范:...(稳定内容 800-1500 token)
5禁区:...(稳定内容)
6输出要求:...
7
8[项目规范 - 来自 AGENTS.md]
9...(稳定内容)
10
11[当前任务]
12看一下 src/order.ts 里的金额计算三条规则:
- 变量信息永远放最后。时间戳、当前文件名、随机 ID 一律后置。
- 稳定内容前置且保持一致。系统提示与项目规范每次必须逐字节相同——哪怕改一个空格,缓存就失效。
- 不要每轮重写系统提示。这是最常见的缓存杀手。
验证缓存命中
1# Copilot 用量面板看 cache read 占比
2# 目标:> 50%;< 30% 说明结构有问题一个反直觉的点:为了让前缀稳定,有时值得把「动态但可枚举」的内容也固定下来。比如把常用命令清单写死在提示里,而不是每次让 Agent 去探索。
5.3 手段二:模型路由——按任务选档
Copilot 的 Auto 有三档:
| 档位 | 定位 | 适合 |
|---|---|---|
efficiency | 最省 | 补全、格式化、简单改名、文档生成 |
balance | 平衡 | 常规功能开发、单文件改动 |
intelligence | 最强 | 跨模块重构、复杂 Debug、架构决策 |
显式路由比让 Auto 猜更可控:
1{
2 "github.copilot.chat.defaultModel": "auto-balance",
3 "github.copilot.chat.agent.defaultModel": "claude-opus-5.5",
4 "github.copilot.chat.agent.thinkingModel": "claude-opus-5.5",
5 "github.copilot.chat.inlineCompletionModel": "auto-efficiency"
6}路由决策表:
| 任务特征 | 选档 |
|---|---|
| 改动 < 30 行、单文件 | efficiency |
| 改动跨 2–5 文件、有明确方案 | balance |
| 跨模块、需要设计决策 | Opus 5.5 |
| 长任务(> 30 步)、需要长程一致性 | Opus 5.5 |
| 批量/机械重复 | efficiency + 批处理 |
5.4 手段三:批处理——非实时任务打五折
OpenRouter Batch API 支持 70+ 模型,24 小时处理窗口下通常按正常价格的 50% 或更低计费。GPT-6 侧也有批处理档位。
适用判断:
1能接受「几小时后拿到结果」→ 批处理
2需要即时交互 → 实时典型批处理任务:
- 全仓库的代码注释生成
- 批量 PR 的初步评审
- 历史 issue 的分类与打标
- 文档翻译与校对
- 测试覆盖率缺口分析
1# 提交批处理任务
2copilot batch submit \
3 --model claude-opus-5.5 \
4 --tasks-file batch-tasks.jsonl \
5 --window 24h \
6 --output results/batch-tasks.jsonl 每行一个任务:
1{"id":"t1","prompt":"为 src/order.ts 生成 JSDoc 注释","files":["src/order.ts"]}
2{"id":"t2","prompt":"为 src/payment.ts 生成 JSDoc 注释","files":["src/payment.ts"]}批处理的隐藏收益:它强迫你把任务写成「一次性的、无状态的」,这本身就会让你的提示词结构变好,反过来又提升缓存命中率。
5.5 手段四:上下文预算控制
1[context]
2max_files = 40
3max_file_size_kb = 200
4max_total_tokens = 120000
5include_git_diff = true
6diff_max_lines = 500四个最容易失控的上下文来源:
| 来源 | 失控表现 | 控制手段 |
|---|---|---|
| 自动附加的文件 | 一次请求挂 80 个文件 | max_files 上限 |
| 单个大文件 | 一个 5MB 的日志全塞进去 | max_file_size_kb |
| git diff | 一次合并带了 2 万行 diff | diff_max_lines |
| 历史对话 | 50 轮对话全带着 | 定期开新会话 |
「定期开新会话」是最简单也最有效的一条。长会话的上下文是线性增长的,而收益是递减的。跑到 20 轮以上就开新的,把关键结论写进 AGENTS.md 或任务文件,让新会话读文件而不是读历史。
5.6 企业侧:模型策略与用量管控
管理员路径:GitHub 组织 → Settings → Copilot → Policies
1模型策略(Model Policy)
2├─ 全局开关:允许/禁止特定模型
3├─ 按团队粒度:某些团队只开 efficiency/balance
4└─ 按仓库粒度:涉密仓库禁用公网模型
5
6用量管控
7├─ 编程智能体并发任务上限
8├─ 单任务成本上限
9└─ 月度预算告警阈值配套的用量指标 API(企业版)可按这些维度看消耗:
- 自定义 Agent
- 技能(Skills)
- MCP 服务器
- CLI 自定义配置
没有度量的成本控制是空话。先接用量 API,再定策略。
六、从 Opus 5 迁移到 5.5:兼容性检查清单
6.1 需要检查的六项
| 检查项 | 为什么 | 怎么做 |
|---|---|---|
| ① 提示词中的模型名硬编码 | 老代码里可能写死 claude-opus-5 | grep -rn "opus-5" . |
| ② 依赖输出格式的代码 | 输出风格可能有细微变化 | 跑一遍依赖解析的测试 |
| ③ 长上下文行为 | 上下文管理策略可能有调整 | 用 > 100K token 的文档测一次 |
| ④ 工具调用顺序 | 并行/串行策略可能变 | 跑一遍涉及多工具的流程 |
| ⑤ 安全护栏等级 | 5.5 沿用了 Fable 5.1 的防护,拒绝行为可能变多 | 检查是否有被拒的请求 |
| ⑥ 成本基线 | 单价变了,旧的预算阈值要重算 | 重跑一次基准任务 |
6.2 灰度迁移步骤
1Step 1 单个非关键仓库切到 5.5,跑一周
2Step 2 对比成本与质量指标(步数、返工率、token)
3Step 3 若两项都不变差 → 扩大到 30% 仓库
4Step 4 稳定两周 → 全量
5Step 5 保留回滚开关:配置文件里留旧模型名,出问题一键切回Step 5 不能省。模型升级出问题时的第一反应应该是「切回去」,而不是「现场调试」。
6.3 一个务实的判断标准
不要看跑分,看这三个业务指标:
| 指标 | 怎么测 |
|---|---|
| 任务完成率 | 同样的 20 个任务,能跑通几个 |
| 返工率 | PR 被人工打回的比例 |
| 单任务成本 | 成本面板里的实测数字 |
三项都不变差才值得迁移。跑分涨了但返工率涨了,那是倒退。
七、选型对比
7.1 与同类方案的对比
| 方案 | 形态 | 优势 | 劣势 | 适合 |
|---|---|---|---|---|
| Copilot + Opus 5.5 | 托管 IDE 集成 | 开箱即用、企业管控完善、多端覆盖 | 代码与上下文上云 | 绝大多数团队 |
| Claude Code CLI | 终端交互 | 体验成熟、可控性强 | 企业管控弱于 Copilot | 重度个人用户 |
| Codex CLI / GPT-6 Sol | 终端交互 | Luna 极便宜($0.10/$0.50) | 生态较新 | 批量/成本敏感场景 |
| 自建 Agent 运行时 | 自托管 | 数据不出内网、成本可控 | 运维成本高 | 涉密/合规场景 |
| Cursor / Trae | AI IDE | 交互体验好 | 管控与审计弱 | 个人与小团队 |
7.2 什么时候不该用 Copilot + Opus 5.5
| 情况 | 替代方案 |
|---|---|
| 涉密代码、不能出内网 | 自建运行时 + 本地模型 |
| 成本极度敏感的批量任务 | GPT-6 Luna / 批处理 |
| 需要完全控制执行层 | 自建 Harness(见本站 Strands Harness 教程) |
| 只需要补全不需要对话 | 便宜模型即可,别上 Opus |
7.3 一个组合建议
1日常补全 → efficiency 档(便宜)
2常规开发对话 → Auto / balance
3长任务与重构 → Opus 5.5(编程智能体)
4批量离线任务 → 便宜模型 + 批处理
5涉密仓库 → 策略禁用公网模型,走自建没有「一个模型打天下」这回事。分层路由是 2026 年的默认做法。
八、故障排查表
| # | 症状 | 根因 | 排查命令 | 解法 |
|---|---|---|---|---|
| 1 | Chat 里选不到 Opus 5.5 | 灰度未覆盖 / 组织策略禁用 / 扩展过旧 | 换账号试;看 Settings → Policies | 等灰度;联系管理员;升级扩展 |
| 2 | CLI 报 unknown model | 模型名拼写错误 | copilot models list | 用列表里的准确名称 |
| 3 | 任务跑到一半卡住 | 缺 --no-interactive,等待确认 | 看任务日志 | CI 场景必须加该参数 |
| 4 | 成本远超预期 | 未设预算硬闸 | cat ~/.copilot/config.toml | 设 max_cost_per_task_usd |
| 5 | 缓存命中率 < 30% | 提示词前缀不稳定(时间戳/随机值前置) | 用量面板看 cache read | 变量信息后置,稳定内容前置 |
| 6 | 长任务上下文溢出 | 单会话轮数过多 | 看 step 数 | 20 轮以上开新会话 |
| 7 | Agent 改了不该改的文件 | 未配 exclude / 未设 require_approval | cat ~/.copilot/config.toml | 补 exclude_patterns 与审批项 |
| 8 | 日志里出现密钥 | redact_secrets 未生效 | grep -rIlE "sk-|ghp_" logs/ | 开启脱敏并扩展规则 |
| 9 | 编程智能体并发超限 | 企业策略设了上限 | 看组织 Policies | 调低 --max-parallel 或申请提额 |
| 10 | PR 评审意见太多太杂 | 未设 --max-comments | 看 workflow 文件 | 设上限 15 条 + 规则文件过滤 |
| 11 | 批量任务部分失败但没记录 | 脚本没落失败清单 | 检查脚本 | 每个任务独立输出 + failures.txt |
| 12 | 输出格式变化导致解析失败 | 模型版本升级的行为差异 | 跑解析测试 | 加格式归一化层 |
| 13 | 请求被安全护栏拒了 | 5.5 沿用 Fable 5.1 护栏,更严格 | 看拒绝原因 | 调整措辞;不要试图绕过 |
| 14 | VS Code 里响应变慢 | 网络链路问题 / 上下文过大 | 看上下文 token 数 | 清理会话;检查网络 |
| 15 | 企业版看不到用量明细 | 未启用用量指标 API | Settings → Copilot → Metrics | 开启并按 Agent 维度查看 |
| 16 | Agent 自动提交了代码 | auto_commit 未关 | 看配置文件 | 必须设为 false |
| 17 | 涉密仓库仍被访问 | 未配仓库级策略 | 看 Policies 的仓库粒度配置 | 按仓库禁用公网模型 |
| 18 | 批处理任务超时 | 窗口设置过短 | 看 batch 状态 | 窗口改 24h;拆分任务 |
| 19 | 升级后预算阈值失效 | 单价变了,旧阈值没重算 | 重跑基准任务 | 按新单价重设 |
| 20 | 同一任务结果不稳定 | 温度设置 / 提示词有歧义 | 跑 3 次对比 | 降低温度;把需求写具体 |
九、三条最重要的原则
原则一:算「完成一个任务花多少钱」,不是「一个 token 多少钱」
1错误算法:输出 $20/M < 输出 $25/M → 更便宜
2正确算法:
3 任务 A 用模型 X:61 步 × 2.41M token = 基准成本
4 任务 A 用模型 Y:54 步 × 1.69M token = 基准 -41%便宜的 token 换来更多重试,就是更贵。能力强的模型少走弯路,就是更省。
原则二:Prompt 是软约束,配置是硬约束
| 约束类型 | 载体 | 可靠性 |
|---|---|---|
| 软约束 | 「请不要修改 .github/」写在提示里 | 会被偶尔忽略 |
| 硬约束 | exclude_patterns + require_approval + 仓库策略 | 代码级拦截 |
安全相关的约束一律用硬约束。 提示词只用来约束风格与非安全类问题。
原则三:缓存是最大的免费午餐
把提示词重构成「稳定前缀 + 变量后缀」,是投入产出比最高的一件事——不需要改架构、不需要换模型、立刻生效,输入侧成本直接砍半甚至更多。
今天就能做的一件事:打开你的系统提示或 AGENTS.md,检查里面有没有时间戳、随机数、动态路径。有就挪到最后面。
十、完整配置参考
这一节是可以当手册翻的。前面讲过的东西在这里给出全部字段,没讲过的补齐。
10.1 Copilot 侧的 settings.json 全字段
VS Code / JetBrains 的 Copilot 用户级配置文件路径:
| 平台 | 路径 |
|---|---|
| VS Code(用户级) | ~/.config/github-copilot/settings.json(Linux)/%APPDATA%\GitHub Copilot\settings.json(Windows) |
| VS Code(工作区级) | .vscode/settings.json 中的 github.copilot.* 段 |
| JetBrains | Settings → Tools → GitHub Copilot GUI,或 ~/.config/github-copilot/intellij/settings.json |
| CLI | ~/.copilot/config.json 或 --config <path> 指定 |
完整字段表:
1{
2 // ---- 模型选择 ----
3 "github.copilot.chat.model": "claude-opus-5.5",
4 // 可选值取决于你的订阅与组织策略。企业版可能被管理员锁定为白名单子集。
5
6 "github.copilot.chat.agentModel": "claude-opus-5.5",
7 // 编程智能体(Agent 模式)专用模型,可与 chat 不同。
8 // 实践建议:agentModel 用前沿档,chatModel 用均衡档,成本立刻降一截。
9
10 "github.copilot.editor.enableAutoCompletions": true,
11 // 行内补全,走的是另一条小模型通道,不受上面两个字段影响。
12
13 // ---- 上下文控制 ----
14 "github.copilot.chat.maxContextTokens": 32000,
15 // 会话上下文预算(token)。注意这是"软预算":
16 // 超了会触发裁剪,但裁剪策略不保证保留你最想要的内容。
17
18 "github.copilot.chat.contextBudget.strategy": "truncate-oldest",
19 // truncate-oldest | summarize | hybrid
20 // hybrid = 先摘要历史轮次,仍超限再丢最旧的。长任务推荐 hybrid。
21
22 "github.copilot.chat.contextBudget.summarizeModel": "claude-haiku-5",
23 // 摘要用小模型即可,成本可忽略,但对命中率有帮助(摘要比原文稳定)。
24
25 "github.copilot.chat.codebaseIndexing.enabled": true,
26 // 关闭会省钱(少一轮检索),但跨文件任务质量会明显下降。别为了省钱关它。
27
28 // ---- Agent 行为 ----
29 "github.copilot.chat.agent.autoApprove": false,
30 // 强烈建议保持 false。true = Agent 可以未经确认执行写文件/跑命令。
31
32 "github.copilot.chat.agent.allowedTools": [
33 "read_file", "search_codebase", "run_tests", "git_diff"
34 ],
35 // 白名单工具。写类工具(write_file / run_shell)默认不应出现在里面。
36
37 "github.copilot.chat.agent.maxToolCalls": 40,
38 // 单次任务的调用上限,防止跑飞。40 是一个够用且可控的值。
39
40 "github.copilot.chat.agent.requirePullRequest": true,
41 // 强制产出 PR 而不是直接 push 到主干。企业环境必须 true。
42
43 // ---- 排除与脱敏 ----
44 "github.copilot.chat.excludeFiles": [
45 "**/.env", "**/.env.*", "**/secrets/**",
46 "**/*.pem", "**/*.key", "**/id_rsa*",
47 "**/node_modules/**", "**/dist/**", "**/*.min.js"
48 ],
49 // 这条是安全红线,不是性能选项。 Glob 语法,支持 ** 递归。
50
51 "github.copilot.chat.redactSecrets": true,
52 // 发送前扫描并脱敏疑似密钥。会有少量误报,但不该关。
53
54 // ---- 提示缓存相关(2026 新字段) ----
55 "github.copilot.chat.cache.enabled": true,
56 "github.copilot.chat.cache.stablePrefixSources": [
57 "AGENTS.md", ".github/copilot-instructions.md", "README.md"
58 ],
59 // 指定"稳定前缀"的加载来源。从文件加载 = 逐字节稳定 = 可缓存。
60 // 手写进对话的内容每次都可能有不可见差异,缓存命中率会掉。
61
62 "github.copilot.chat.cache.minPrefixTokens": 1024,
63 // 低于此长度的前缀不值得缓存。调低没意义,调高会漏掉短会话。
64
65 // ---- 遥测 ----
66 "github.copilot.telemetry.enabled": true
67 // 企业侧做成本归集需要它。个人用户可关。
68}配置的三条经验:
agentModel和chatModel分开配是性价比最高的一个动作。聊天问答不需要前沿模型,但重构规划需要。excludeFiles里的**/.env.*很容易被写成**/.env,漏掉.env.production。cache.stablePrefixSources是 2026 年新增的,很多教程还没提——它是把缓存命中率从个位数拉到 70%+ 的开关。
10.2 Copilot CLI 参数全表
1会话控制
2 -m, --model <id> 指定模型(覆盖配置文件的 agentModel)
3 -p, --prompt <text> 单次对话,执行完退出(CI 首选)
4 -i, --interactive 交互式会话
5 --resume [session-id] 恢复上一次会话(依赖 session 快照)
6 --no-resume 强制新会话
7
8Agent 控制
9 --agent 启用编程智能体模式
10 --allow-tool <name> 放行指定工具(可重复)
11 --deny-tool <name> 禁用指定工具(可重复,优先级高于 allow)
12 --max-tool-calls <n> 调用上限
13 --auto-approve 跳过确认(⚠️ 仅本地沙箱用)
14 --require-pr 强制产出 PR
15
16上下文与成本
17 --context-budget <tokens> 上下文预算
18 --cache/--no-cache 提示缓存开关
19 --batch 走批处理通道(非实时,-50% 单价)
20 --exclude <glob> 追加排除规则(可重复)
21
22输出与控制
23 --json 结构化输出(CI 解析用)
24 --output <file> 结果写文件
25 --verbose 打印 token 与成本明细
26 --config <path> 指定配置文件
27 --dry-run 只规划不执行--verbose 值得单独说:它会打印每次调用的 input_tokens / cache_read / output_tokens / estimated_cost。做成本治理的第一步就是把它打开跑一遍真实任务,你会立刻看到钱花在哪。
10.3 Agent 指令文件:AGENTS.md 与 copilot-instructions.md
两者的区别和分工:
| 文件 | 作用范围 | 加载时机 | 谁在读 |
|---|---|---|---|
AGENTS.md | 仓库根或任意子目录 | 该目录下的任务自动加载 | Copilot Agent、Claude Code、Cursor 等(已成事实标准) |
.github/copilot-instructions.md | 整个仓库 | 所有 Copilot 会话 | 仅 Copilot |
推荐做法:以 AGENTS.md 为主(跨工具通用),.github/copilot-instructions.md 只放 Copilot 特有的东西,并且从前者 include 后者(或反过来,但不要两边各写一份——会漂移)。
AGENTS.md 的骨架(可直接抄):
1# 项目:供应链协同平台
2
3## 0. 不可协商的红线
4- 任何涉及金额的计算必须走 `Money` 值对象,禁止裸 `float`
5- 禁止写 `.env`、私钥、token 到任何输出
6- 禁止修改 `main` 分支,一律走 PR
7- 数据库写入必须经过 repository 层,禁止在 handler 里裸写 SQL
8
9## 1. 技术栈
10- 后端:Node 20 + TypeScript 5.6 + NestJS
11- ORM:Prisma(schema 在 prisma/schema.prisma)
12- 测试:Vitest(单测)+ Playwright(E2E)
13- 包管理:pnpm,禁止 npm/yarn
14
15## 2. 常用命令(照抄,不要自己发明)
16- 单测:`pnpm test`
17- 单文件测试:`pnpm vitest run <path>`
18- 类型检查:`pnpm tsc --noEmit`
19- 构建:`pnpm build`
20- Lint:`pnpm lint --fix`
21
22## 3. 目录约定
23- `src/modules/<domain>/` 领域模块
24- `src/modules/<domain>/*.service.ts` 业务逻辑
25- `src/modules/<domain>/*.repository.ts` 数据访问
26- 跨模块调用必须经 `src/modules/<domain>/index.ts` 导出的公开接口
27
28## 4. 提交规范
29- 格式:`<type>(<scope>): <subject>`
30- 一次 PR 只做一件事
31- PR 描述必须包含:改了什么 / 为什么 / 怎么验证
32
33## 5. 已知坑(历史事故的沉淀)
34- `Money` 的四舍五入只能用 `roundHalfUp`,银行家舍入会在对账时差 1 分
35- `order.status` 的 `PENDING` 和 `CREATED` 语义重叠,新代码统一用 `CREATED`
36- 不要在事务里发 MQ 消息,回滚时消息已发出(见 incident-2026-0417)第 5 节「已知坑」是最容易被忽略、但价值最高的一节。它把团队的历史事故变成了模型的先验知识,能直接消灭一类重复 bug。
写 AGENTS.md 的三条纪律:
- 只写稳定的东西。不要写「当前 sprint 目标」「本周排期」——这些内容一变,整个前缀就失效,缓存命中率归零。
- 命令要能直接跑。
pnpm test好过「运行测试」。模型照抄时会原样执行。 - 控制长度。建议 2,000–6,000 token。太短约束不足,太长挤占上下文且增加成本。
10.4 环境变量
| 变量 | 用途 | 建议 |
|---|---|---|
COPILOT_MODEL | 覆盖默认模型 | CI 里显式指定,避免依赖本地配置漂移 |
COPILOT_CONFIG | 指定配置文件路径 | 多项目并行时用 |
COPILOT_TOKEN / GH_TOKEN | 认证 | CI 用 GitHub App token,不要用个人 PAT |
COPILOT_MAX_TOOL_CALLS | 调用上限 | CI 里设小一点(如 15)防跑飞 |
COPILOT_CACHE | 缓存开关 | 默认 true,不要关 |
COPILOT_TELEMETRY_ENDPOINT | 遥测上报地址 | 企业自建看板时用 |
十一、企业级落地:权限、审计、成本归集、SLO
个人用户看到第 10 节就够了。企业落地还要补四块。
11.1 权限矩阵
Copilot 在企业里的权限是三层叠加的:GitHub 仓库权限 → 组织策略 → 客户端配置。三者取交集。
| 角色 | 可用模型 | Agent 模式 | 写操作 | 典型配置 |
|---|---|---|---|---|
| 实习生 / 外包 | 小模型 + 均衡档 | ❌ 禁用 | ❌ | agent.enabled=false |
| 普通开发 | 全部订阅内模型 | ✅ | PR only | require-pr=true |
| 高级开发 / Tech Lead | 全部 | ✅ | PR + 命令行白名单 | allowedTools=read,test,git |
| 平台 / 基建 | 全部 | ✅ | 视仓库分支保护 | 逐仓库审批 |
| CI 服务账号 | 指定单一模型 | ✅ 非交互 | 受限目录 | --deny-tool write_file |
三条实践原则:
- 按角色配模型档位,不按人。手动给每个人配会失控,用组织策略组批量下发。
- Agent 的写权限不随人走,随仓库走。敏感仓库(支付、权限、基础设施)一律
require-pr+ 强制 CODEOWNERS review。 - CI 服务账号用 GitHub App,不要复用个人 PAT——PAT 泄露等于个人全部权限泄露,App token 可限到单仓库单权限且自动过期。
11.2 审计日志
企业环境必须回答三个问题:谁在什么时候让 AI 改了什么。
需要采集的字段:
1{
2 "timestamp": "2026-09-23T10:14:22+08:00",
3 "actor": "user@example.com",
4 "repo": "acme/supply-chain",
5 "session_id": "sess_9f2a...",
6 "model": "claude-opus-5.5",
7 "mode": "agent",
8 "tools_invoked": ["read_file", "write_file", "run_tests"],
9 "files_modified": ["src/modules/order/order.service.ts"],
10 "pr_created": "https://github.com/acme/supply-chain/pull/1284",
11 "input_tokens": 41230,
12 "cache_read_tokens": 38900,
13 "output_tokens": 2140,
14 "estimated_cost_usd": 0.128,
15 "policy_decisions": [
16 {"rule": "exclude_files", "target": ".env.production", "action": "blocked"}
17 ]
18}policy_decisions 这一项很多团队会漏。它记录的是「被拦下来的尝试」——这才是安全审计真正想看的:不是 AI 做了什么坏事,而是有没有人试图让它做坏事。
日志保留与用途:
| 用途 | 保留期 | 粒度 |
|---|---|---|
| 安全审计 | 1 年 | 全字段 |
| 成本归集 | 13 个月(跨年对比) | 只要 token 与 cost |
| 质量复盘 | 6 个月 | session 级 + 关联 PR |
| 合规(如等保/ISO) | 按合规要求 | 全字段 + 不可篡改存储 |
11.3 成本归集:把账单拆到团队
总成本是没用的数字。你需要的成本维度是「团队 / 仓库 / 任务类型」,否则没人有动力优化。
最小可用的归集模型:
1成本归因键 = team × repo × task_type
2
3team : 从 actor 映射(需要一份 user → team 的表)
4repo : 从 session 的 git remote 解析
5task_type : 从 prompt 首行或 --tag 参数提取(refactor / review / migrate / hotfix ...)归集后能立刻看到的东西:
| 视图 | 能回答的问题 |
|---|---|
| 团队 × 月成本 | 哪个团队在用得最多(不一定是坏事,但要知道) |
| 任务类型 × 单任务成本 | 哪类任务最贵(通常是 migrate / 大重构) |
| 缓存命中率 × 团队 | 谁的 Prompt 结构有问题 |
| 重试次数 × 任务类型 | 哪类任务最容易失败重试 |
| P95 成本 × 仓库 | 有没有某个仓库在异常消耗 |
归因的第一周通常会发现两个「黑洞」:某个 CI job 在无限重试,或者某个人把 Agent 当成搜索引擎用。这两个都不难修,但如果不归集就永远发现不了。
告警规则建议:
1日成本环比 > +25% → Slack 告警(可能是跑飞或新任务上线)
2单 session 成本 > $2 → 告警(可能是循环调用)
3缓存命中率 < 30% → 周报提示(结构问题)
4某团队周成本 > 预算 120% → 通知该团队 Lead11.4 SLO 与质量门禁
AI 辅助开发也要有 SLO,否则「AI 生成的代码质量如何」永远是一个争论而非事实。
T 公司的四条 SLO(可作为起点,按自己的基数调):
| SLO | 目标 | 测量方式 |
|---|---|---|
| AI 参与 PR 的一次通过率 | ≥ 75%(基线 68%) | CI 全绿 / AI 参与 PR 总数 |
| AI 参与 PR 的回滚率 | ≤ 2%(基线 3.1%) | 回滚 PR / AI 参与 PR |
| AI 参与 PR 的 review 轮次 | ≤ 1.8(基线 2.4) | 平均 review 往返 |
| 单任务成本 | ≤ $0.35 | 从遥测汇总 |
关键设计:SLO 必须与人工基线对比,而不是给一个绝对数字。「AI PR 通过率 75%」没有意义,「AI PR 通过率 75% vs 人工 68%」才有意义。
质量门禁(CI 里强制):
1# .github/workflows/ai-quality-gate.yml
2- name: AI 改动门禁
3 run: |
4 # 1. AI 参与的 PR 必须带标签
5 gh pr view $PR --json labels | jq -e '.labels[].name == "ai-assisted"'
6 # 2. 改动不能超过 400 行(超过说明任务拆得不够细)
7 test $(gh pr diff $PR | wc -l) -lt 400
8 # 3. 必须有测试变更
9 gh pr diff $PR --name-only | grep -E 'test|spec'
10 # 4. 禁止改动敏感路径
11 ! gh pr diff $PR --name-only | grep -E '^(\.env|infra/|\.github/workflows/)'第 4 条是硬闸:AI 不应该直接改 CI 配置和基础设施定义,那是权限提升的捷径。
11.5 一个企业落地的现实节奏
| 阶段 | 周期 | 动作 | 成功标准 |
|---|---|---|---|
| 试点 | 2–3 周 | 选 1 个团队、2 个仓库,全功能开放 | 收集到真实使用数据与事故 |
| 规范化 | 3–4 周 | 写 AGENTS.md、定权限矩阵、配排除规则 | 缓存命中率 > 50%,无安全事故 |
| 推广 | 4–6 周 | 扩到 5–8 个团队 | SLO 达标,成本在预算内 |
| 常态化 | 持续 | 成本归集 + 月度复盘 | 单任务成本逐季下降 |
最常见的失败模式是跳过试点直接全量推广。Agent 出过的事故(误删文件、把密钥写进代码、无限循环烧钱)在小范围里是「学费」,在全公司范围里是「事故」。
十二、15 个可直接复用的 Prompt 模板
这一节是拿来即用的。每个模板都标了适用模型档位——这是省钱的关键:大部分模板不需要 Opus 5.5。
模板 1:跨模块重构规划(Opus 5.5)
1任务:{{重构目标}}
2
3现有实现分布在:{{文件清单}}
4
5要求:
61. 先列出所有调用点(grep 全仓,不要凭记忆)
72. 给出迁移顺序,每一步都要能独立提交且测试通过
83. 每一步标注:改哪些文件 / 新增什么接口 / 删除什么 / 验收命令
94. 识别向后兼容问题,给出灰度方案
105. 估算总改动量与风险点
11
12约束:单步改动 ≤ {{max_files}} 个文件、≤ 150 行。
13写不出验收命令的步骤说明任务拆得不够细,重拆。模板 2:PR 评审(均衡档即可)
1审查这个 PR 的 diff:
2
3{{diff}}
4
5按三档输出:
6- BLOCKER(必须改):安全、数据丢失、破坏性变更、逻辑错误
7- MAJOR(应该改):性能、可维护性、测试缺失
8- NIT(可选):风格、命名
9
10每条给出:文件:行号 + 问题 + 建议改法。
11不确定的标 [UNCERTAIN] 而不是硬猜。
12最后给一句总体结论:是否可以合并。模板 3:失败测试诊断(均衡档)
1测试失败输出:
2
3{{test_output}}
4
5相关代码:{{file_path}}
6
7请:
81. 定位根因(不要只看报错行,要看调用链)
92. 区分:是真 bug / 是测试写错 / 是环境差异
103. 给出最小修复(不要顺手重构)
114. 给出验证命令
12
13如果根因不止一个,按影响排序,逐个修。模板 4:API 契约生成(均衡档)
1根据下面的需求生成接口契约:
2
3{{需求描述}}
4
5输出:
6- 路径与方法
7- 请求体 schema(字段名、类型、必填、校验规则)
8- 响应体 schema(含错误码)
9- 错误码表(码值 / 含义 / 客户端如何处理)
10- 幂等性设计
11- 一个 curl 示例
12
13不要生成实现代码。模板 5:日志/告警根因分析(Opus 5.5,长上下文场景)
1时间窗:{{时间范围}}
2异常指标:{{指标名与数值}}
3相关日志(已按时间排序):
4
5{{日志片段}}
6
7相关服务拓扑:{{拓扑描述}}
8
9请:
101. 还原时间线(什么先发生,什么后发生)
112. 给出 3 个候选根因,按可能性排序,各给支持/反对证据
123. 对每个候选给出一条验证命令或查询
134. 如果证据不足,明确说「需要补什么日志」
14
15禁止在没有证据的情况下给单一确定结论。模板 6:数据库迁移方案(Opus 5.5)
1当前 schema:{{旧结构}}
2目标 schema:{{新结构}}
3数据量:{{行数级}},是否允许停机:{{yes/no}}
4
5输出:
61. 迁移步骤(expand → migrate → contract 三段式)
72. 每一步的 SQL 与预计耗时
83. 回滚方案(每一步都要能独立回滚)
94. 数据一致性校验方法
105. 灰度策略(按什么维度分批)
11
12硬约束:不允许 DROP COLUMN 出现在第一段。模板 7:代码解释(小模型即可)
1解释这段代码:
2
3{{代码}}
4
5面向{{读者角色}},回答:
61. 它做了什么(一句话)
72. 关键控制流(分步)
83. 有哪些隐含假设
94. 有哪些潜在问题
10
11不要逐行注释。不要复述代码。模板 8:测试用例补全(均衡档)
1为下面的函数补测试:
2
3{{函数代码}}
4
5覆盖范围:
6- 正常路径
7- 边界(空值、极值、空集合)
8- 错误路径(异常类型与消息)
9- 已有 bug 的回归用例(见 {{issue_link}})
10
11使用{{测试框架}},遵循仓库现有测试的风格。
12每个测试只验证一件事,测试名描述行为而非实现。模板 9:依赖升级评估(均衡档)
1要把 {{package}} 从 {{old}} 升到 {{new}}。
2
3请:
41. 列出 breaking changes(从 CHANGELOG 与实际使用情况对照)
52. 扫描仓库中所有用法,标注哪些受影响
63. 给出改动清单
74. 给出验证计划(跑哪些测试、看哪些指标)
85. 评估回滚难度
9
10不要直接执行升级,先给方案。模板 10:性能优化定位(Opus 5.5)
1性能问题:{{现象与测量数据}}
2相关代码路径:{{路径}}
3
4请:
51. 先质疑测量方法(数据可信吗?样本够吗?)
62. 给出测量计划(加什么埋点)
73. 基于现有证据列出候选瓶颈,按可能性排序
84. 对每个候选给出验证方法与预期收益量级
95. 明确区分「已经证实的」和「猜测的」
10
11禁止在没有 profile 数据的情况下做优化建议。模板 11:文档生成(小模型即可)
1为下面的模块生成 README:
2
3{{模块代码与目录结构}}
4
5包含:用途 / 快速开始 / 核心概念 / 常见用法示例 / 配置项表 / 已知限制
6
7面向第一次接触这个模块的开发者。
8不要写「本项目是一个...」这种废话开头。
9示例要能直接跑。模板 12:安全自查(Opus 5.5)
1审查这段代码的常见安全问题:
2
3{{代码}}
4
5逐项检查:注入(SQL/命令/模板)、越权、敏感信息泄露、
6反序列化、路径穿越、CSRF、依赖已知漏洞、密钥硬编码。
7
8每条给出:位置 / 风险等级 / 触发条件 / 修复建议。
9没有问题的项也要明确写「未发现」,不要省略。
10不要报理论风险,只报在当前上下文可被触发的。模板 13:批量迁移执行(脚本 + 小模型校验)
1# 用脚本驱动,不要靠 Agent 一次改完 200 个文件
2for f in $(git grep -l 'OldPattern' -- 'src/**/*.ts'); do
3 copilot --agent -p "把 $f 中的 OldPattern 改为 NewPattern,只改这一处模式,
4 不要顺手重构其他代码。改完跑 pnpm vitest run $f。" \
5 --allow-tool write_file --max-tool-calls 8 --require-pr
6done要点:批量迁移的正确做法是「脚本控制循环 + Agent 控制单次改动」,而不是让 Agent 自己循环。前者可控、可断点续跑、成本可预测。
模板 14:需求澄清(均衡档,配合规格驱动)
1需求:{{原始需求}}
2
3请只做澄清,不要实现。输出:
41. 范围内(有明确文件路径的)清单
52. 范围外(明确不做的)清单,不少于 5 条
63. BLOCKER 清单:这些问题不回答就无法开始,每个都配套「停止等待」指令
74. 隐含假设清单
8
9任何不确定的地方一律问,不要自行假设填写。模板 15:成本复盘(均衡档)
1本月 AI 用量数据:{{用量表}}
2
3请分析:
41. 成本最高的 3 类任务,各占多少
52. 哪些是合理开销,哪些是浪费(给出判断依据)
63. 缓存命中率的现状与可改进点
74. 重试次数的分布,重试的主要原因
85. 给出下月降本的 3 个具体动作,按 ROI 排序
9
10每个结论都要有数据支撑,不要给「优化 Prompt」这类空话。模板使用的三条建议
- 先按档位分流。模板 2/3/4/7/8/9/11/14/15 都不需要前沿模型,用中等档跑成本能降 70%+。
- 模板要进 AGENTS.md。放进稳定前缀区,缓存命中率会显著提升,且全队一致。
- 给模板编号并版本化。改动时开新版本,否则历史任务的成本对比会失真。
十三、下一步
- 把项目规范固化进
AGENTS.md,稳定前缀 + 跨工具共享(见本站AGENTS.md 统一配置实战) - 需要完全自控的执行层,看
Strands Harness教程 - 接 MCP 扩展 Agent 能力(见本站 MCP 系列)
- 用 GitHub MCP 让 Agent 直接操作 Issues / PR / Actions(见本站
GitHub MCP)
常见问题(正文补充)
Q:Opus 5.5 和 GPT-6 Sol 该选哪个? 别在抽象层面比。拿你自己的 20 个真实任务各跑一遍,比完成率、返工率、单任务成本。两家 90 分钟内对位降价,说明能力差距已经小于任务适配度的差距。
Q:Sonnet 5.5 / Haiku 5.5 什么时候来? 官方口径是「未来几周」。如果成本敏感,可以等 Sonnet 5.5——历史上 Sonnet 档是性价比最优的位置。
Q:编程智能体能完全无人值守吗? 不能,也不应该。它的产出必须走 PR + 人工 review。GitHub 自己的设计也是这样——默认产出 PR,不自动合并。能自动化的只有「生成候选方案」,不是「决定合并」。
常见问题
Q我现在用 Copilot 默认的 Auto 模型,还有必要手动切到 Opus 5.5 吗?
分任务。Auto 会在三档(efficiency / balance / intelligence)之间自动选,日常补全和简单改造它更划算。但两类任务建议显式指定 Opus 5.5:跨模块重构这类需要长程一致性的任务,以及需要审查推理过程的复杂 Debug。Copilot 的 Auto 不会告诉你它选了哪个模型,排查成本反而更高。实用做法:日常用 Auto,把 Opus 5.5 固定在编程智能体的长任务配置里。
QOpus 5.5 比 Opus 5 便宜 20%,但为什么官方说「典型任务成本降 40%」?
20% 是单价降幅,40% 是端到端降幅,差额来自三处:输出速度快 30% 以上意味着同样的任务用的推理 token 更少;缓存读取价格再降 60%,重复前缀几乎不花钱;模型本身的步骤数更少(GitHub 的早期测试描述是「完成任务效果接近 Opus 5,但步骤和 token 用量更少」)。所以别只比单价,要按「完成一个任务花多少钱」来算。
Q企业版怎么保证团队不滥用高成本模型?
用 GitHub 的模型策略(Model Policy)在企业/组织级别控制:可以只允许特定模型、按仓库或团队粒度开放、并对编程智能体的并发任务数设上限。再配合 Copilot 的用量指标 API(usage metrics API)按自定义 Agent、技能、MCP 服务器维度看消耗。光靠「提醒大家省着点用」没有用,必须是平台侧的硬限制。
Q我在国内,Copilot 能正常用吗?会不会有额外限制?
能用,但要注意两件事:一是网络链路不稳定时,编程智能体的长任务容易中断,建议开启任务的检查点续跑;二是企业合规层面,代码与上下文会离开本地,涉密仓库不要开 Copilot。若需要完全本地化,走 Copilot 的企业策略关闭公网模型,或改用本地模型 + 自建 Agent 运行时(见本文第 7 节选型对比)。