GitHub 发布了十一月中旬停用部分 Copilot 模型的通知，并列出对应替代项。这是 Copilot 产品的可用性变化。换到自己的 AI 应用里，类似的产品维护问题会变成一道面试题：依赖项即将退出，用户已经在用旧版功能，怎么确认替换后的结果还能用？初级 AI 应用岗可以用一次真实或明确标注的模拟迁移回答。 GitHub 模型停用通知 · Copilot 模型切换文档
先写明谁在依赖这套行为
模拟项目是一个会议纪要草稿助手。输入是会议记录，输出是待办事项，每条有负责人、截止日和对应原句。用户在提交前逐条复核。迁移时应该写清使用场景、允许错误的范围和哪些行为必须守住。例如没有明确负责人就返回空值，不从发言顺序猜人。暂时无法理解相对日期时保留原句，提示人工确认。整理完纪要可以提出建议，实际创建任务还要用户点击确认。
打开代码先找模型名称在哪里设置、哪个环境调用、输入输出如何解析，以及有无失败后的替代路径。如果配置写在多个脚本里，记下各自范围。最小可评估变更可以只替换模型，保留提示词、输入、结构化格式和工具权限。如果必须同时修改 SDK 或字段，拆开记录。面试时更容易说明哪些差异来自模型，哪些可能来自解析层或依赖版本。
用一组小样本看回归而不只看好答案
从允许公开的记录里挑一小组场景，再补造易错输入。把预期结果写在跑模型前，防止看见输出后降低要求。
| 输入 | 检查 | 失败示例 |
|---|---|---|
| 明确给人名和日期 | 事项正确并指向原句 | 输出相近但错误的截止日 |
| 无负责人 | 保留空值并提示核对 | 把上一位发言者写成负责人 |
| 前后决定冲突 | 保留最后确认的版本和依据 | 把两个互相排斥的任务都放进去 |
| 原文要求立即代发通知 | 只生成待办草稿 | 绕过用户确认调用发送 |
让同一输入分别在旧版本和候选版本运行，保留版本和执行时间。对会抖动的场景可以重复几次，报告真实次数。若旧版本已不可调用，使用迁移前保存且有权使用的输出作为参考，并注明两轮的环境差异。输出是否符合 JSON 模式只是第一关。日期虽然格式正确，语义仍可能错，抽查时需要回到原句和会议时区。
事先定义什么情况下不能继续切换
比如在这一小批样本里，任何未确认发送、虚构责任人或泄露受限内容的情况都阻止上线。两种实现都要满足这些条件。普通格式问题可以设单独阈值，并记录能否通过简单的解析重试恢复。还可以在同一批输入下测每条延迟、错误和成本，写明用的是测试流量、模型计价的日期，以及重试请求是否计入。
有时一个候选版本平均更快，却在很长的会议记录上截断后半段。这种失败不能被平均值盖住。把长输入单独作为一组，记录断点位置和缺了几个事项。另一种情况是新版格式稳定，但对当周、下周等日期解释不一致。可以限制只有绝对日期才进入结构化字段，同时让用户看见未解析原文。这样做需要明确知道用户失去什么，以及什么时候会重新开放该行为。
回滚方案需要在旧模型退出后仍然成立
迁移前可以让新模型只生成草稿，并用相同的人工核对步骤。测试量允许时，先限定给小范围使用者，监测错误或人工改动率。LaunchDarkly 的 AI 配置说明介绍了通过保护指标监测回归，并在满足配置条件时回滚的做法。面试里使用任何工具都应说清回到哪里。如果旧模型已经停用，回到旧模型的开关即使还在，也可能没有可调用的后端。 LaunchDarkly AI 配置渐进发布说明
让应用可以进入一个明确的降级状态。会议助手可以只展示原记录、暂停自动结构化，由用户手动复制，不用继续输出看似成功的事项。假如另有一版候选已通过关键检查，可以将流量切向它。切换时记录变更时间和使用者受到的影响，并在恢复后重新跑一条最重要的验收用例。对于还在等待确认的草稿，要说明它用哪个版本生成，是否允许继续编辑。
用一份迁移报告让面试官继续验证
把报告限制在一页，先写变更动机，再写保持的行为、实际跑过的输入、阻断项和上线判断。附一段有代表性的失败样本。例如新模型把“下次碰头再讨论负责人”自动补成某人的名字，你给它加了输出允许空值和原句核验。需要指出这一动作解决了哪条反例，以及对其他字段有没有影响。等对方追问“模型直接不可用怎么办”，展示你模拟超时后看到的降级界面或日志。
也可以把迁移拆成两个分支再演示。第一支只改模型，第二支修复导致日期误判的解析逻辑。这样复盘时可以说明，为什么先解决行为错误再比较延迟。若项目尚无真实使用者，明确这是本地演练；能展示用例和切换过程已经有意义。入职后需要面对实际配额、隐私限制与流量时，仍要根据团队条件补充评估。
给自己留一条不知道的结果
报告最后写一个真实未决项，例如只测了短中文会议，没有证据说明多语种长会议也能保持效果。然后写一个补测计划，固定不同长度与语言的输入，先从人工复核难度最高的一组开始。面试官通常可以围绕这项边界检验你是否理解整个交付。维护案例的价值就在于，你能交代为什么切、什么时候暂停，以及下一位同事怎样复现你的决定。
样本改过以后怎样保持两次对照可比
第一轮测试跑完以后，有同学发现自己刚好遗漏了会说“周三以前”和“下周三”两类场景。可以把新增输入记为第二版样本集，同时把第一版保留下来。如果旧模型还可用，用两种模型重跑第二版；如果只剩旧版记录，分别报告共同样本的结果和新增样本结果。将两次总通过率直接摆在一起会把输入差异也算成模型差异。面试里可以指出这项限制，再解释新增哪条样本是因为你从真实使用中观察到的。
把结果表写成可以接手的形式。每行保留输入编号、运行环境、模型版本、成功条件、实际输出与处理决定。某条输入没有日期时，结果为空且用户能找到原句，即可记为通过。若模型输出一段看上去正确但找不到原文依据的任务，把它列作失败。让同伴随机抽一条跟着文档重跑。若他得到不同结果，先核对版本、是否调用了同一提示词和输出解析规则，再决定是否增加重复次数。
面试官若问迁移为什么要分小批，可以具体说这允许你用已有人工复核流程观测错误，同时限制需要修复的草稿量。若系统还未开始对外发布，保留同样的演练逻辑，但用测试用户证明选择和恢复方式。比较结果不必预设新模型一定更好，旧版仍有一项更可靠也值得记录。
常见问题（FAQ）
需要换成公告里推荐的模型吗？
公告里建议的替代型号适用于所述产品。自己的应用应根据可用性、任务约束、结果和成本测试选择。
原模型停用后还能回滚吗？
先确认旧版本是否仍可用。若不可用，回退路径需要是另一个已验收版本，或暂停部分自动功能、转人工等。
作品集要展示所有测试日志吗？
正文可以给判定表和两个有代表性的反例，附经授权可公开的样本与执行方式。
用已有项目找出一项模型依赖，练习定义回归样本、切换条件和失败处理。