夜雨聆风大家好，这里是数字木鱼 TK 科技观察 ✨
记录 AI、数字工具和智能制造领域的一些个人观察。
最近，一项曾经很方便的 AI 模型服务正式退出了历史舞台。
2026年7月30日，GitHub Models 全面停止服务。原有的模型体验区、模型目录、推理 API 和自带密钥功能，均不再向新老用户开放。
GitHub 同时强调，GitHub Models 是一项独立服务，与 GitHub Copilot 并不是同一个产品。对于仍然需要模型调用的项目，官方给出的后续方向包括 Microsoft Foundry；如果要直接在 GitHub 中构建 AI 工作流，则可以考虑 GitHub Copilot。
这件事本身并不复杂。
但它提醒了我一个在 AI 工具快速迭代时期很容易被忽略的问题：
当我们把项目接入一个方便的平台时，有没有同时给自己留下离开的能力？
一、能调用，不等于能长期依赖
很多 AI 项目的第一版都非常简单：
申请一个密钥，填写模型名称，复制一段示例代码，然后发送第一次请求。
在验证想法的阶段，这种做法没有问题。开发者最需要的是快速判断功能能不能实现，而不是一开始就设计一套复杂架构。
问题在于，验证代码很容易在不断添加功能后，悄悄变成正式系统。
如果提示词、错误处理、日志格式、文件上传和业务判断全部围绕某个平台编写，项目对平台的依赖就会越来越深。
到了需要更换服务时，面对的可能不只是修改一个 API 地址，而是重新调整大量业务代码。
而且，平台变化不一定表现为彻底停用，还可能是：
模型名称或版本调整； 调用价格发生变化； 免费额度和请求限额变化； 某些模型退出特定地区； 结构化输出规则改变； 预览功能停止维护； 数据处理和服务条款更新。
所以，判断一个 AI 项目是否稳定，不能只看“今天能不能请求成功”。
还应该看：
明天换一个模型或服务商，需要修改多少东西？
二、应用应该认识“能力”，而不是模型名字
假设一个系统里有很多功能：
根据材料生成一段总结； 从文件中提取固定字段； 返回符合要求的 JSON； 根据图片识别内容； 调用搜索、数据库或其他工具； 根据已有资料回答问题。
这些才是应用真正需要的“能力”。
至于这些能力由哪家平台、哪个模型完成，原则上不应该直接写进每一项业务功能里。
一个更稳妥的结构是：
业务功能 → 统一模型接口 → 平台适配器 → 云端模型或本地模型
业务层只负责说明需要完成什么任务。
统一接口负责规定输入、输出、错误信息和日志格式。
平台适配器再处理不同服务商的模型名称、认证方式、请求参数和返回结构。
以后需要更换平台时，主要修改适配器，而不是重新改写所有业务流程。
这当然会增加一些前期工作，但它也可能把未来的迁移从“重写项目”，变成“替换一个模块”。
普通开发者选择 AI SDK 时，除了看示例是否简单，也可以多问一句：
如果有一天不用这套 SDK，我的数据结构、提示词和业务流程还能不能保留？
三、真正值得积累的，不是API地址
一个 AI 项目运行一段时间后，真正有价值的资产，往往不是模型地址和调用密钥，而是这些内容：
不断修改完善的提示词； 典型输入和期望输出； 容易出错的边界案例； 用户反馈形成的判断规则； 工具调用的权限边界； 人工审核和异常处理流程； 响应时间、成功率与成本记录； 经过脱敏处理的测试数据。
这些内容决定了项目为什么能够正常工作。
如果它们被独立保存并纳入版本管理，即使模型服务发生变化，也可以使用同一批测试样例重新评估替代方案。
反过来，如果所有提示词、测试记录和对话都只存在某个平台的在线界面里，平台发生变化时，开发者失去的可能不只是一个入口，还包括长期积累的使用经验。
因此，我更愿意把模型看作一种可以替换的执行引擎。
提示词、测试数据、业务规则和工作流程，才是项目需要长期维护的核心资产。
四、迁移成功，不只是接口返回了200
GitHub 为原有用户列出了 Microsoft Foundry 和 GitHub Copilot 等后续方向。
但“官方列出替代方向”，并不意味着项目可以无成本、无差异地迁移。
不同服务即使都能够生成文本，在实际使用中仍可能存在很多差异：
身份认证和密钥管理方式； 模型名称与版本管理； 上下文长度和文件大小限制； 工具调用参数格式； JSON 等结构化输出的稳定性； 内容安全和拒绝策略； 并发限制和调用配额； 价格、计费单位和可用地区； 日志、监控和数据保留方式。
因此，真正的迁移测试至少要回答四个问题：
1. 功能是否正确
原来的任务还能不能完成？关键字段有没有丢失？工具能不能正常调用？
2. 输出是否稳定
同一批测试样例中，格式错误、遗漏和异常结果是否明显增加？
3. 成本是否可接受
不能只比较单次 Token 价格，还要考虑失败重试、长文本输入、工具调用和并发限制。
4. 权限是否合规
项目向外部服务发送了哪些数据？日志保存在哪里？密钥和访问权限是否重新配置？
接口成功返回，只能说明网络和认证基本正常。
它并不代表迁移已经完成。
五、本地模型是一条退路，但不是万能答案
Microsoft Foundry 当前也提供 Foundry Local 等设备端运行路径。
本地模型的优势比较明确：部分任务可以在用户设备上处理，在网络不稳定时继续运行，并减少数据离开设备的需求。
但本地运行同样存在现实成本：
设备性能和内存有限； 模型能力可能低于大型云端模型； 首次下载和部署需要时间； 不同电脑的运行速度差异较大； 模型升级和兼容性需要维护； 多用户、高并发服务并不是它的主要使用场景。
因此，更现实的做法并不是在“全部上云”和“全部本地”之间二选一。
可以先按照任务特点进行划分：
隐私敏感、能力要求适中、需要离线完成的任务，可以评估本地模型；需要更强推理能力、更大上下文或弹性资源的任务，则继续使用云端服务。
关键仍然不是一定选择哪一种方案。
而是让项目结构保留选择的可能。
六、个人项目也应该有一份最小退出清单
即使只是一个人开发的小项目，也可以先完成一份简单的退出准备。
接口管理
将模型调用集中到独立模块； 不在不同页面和功能中重复编写调用代码； 使用环境变量管理模型名称、地址和密钥； 为模型返回结果定义自己的统一数据结构； 把平台专属参数限制在适配层中。
提示词和数据
将重要提示词纳入版本管理； 保存脱敏后的典型测试样例； 记录哪些数据会发送到外部服务； 不把唯一一份提示词或评估记录留在在线界面； 为重要输出保留人工复核节点。
回归测试
准备一组固定输入和期望结果； 记录响应时间、成功率和大致成本； 更换模型后重新检查事实准确性； 检查 JSON、表格等固定格式是否稳定； 单独测试工具调用和异常处理。
退出准备
至少了解一个可替换的云端服务； 评估一个能够在本地运行的备用方案； 记录迁移时需要修改的配置和代码位置； 对关键流程设计降级方案，而不是只设置失败重试； 定期确认当前依赖的模型和接口是否仍在维护。
这些工作看起来不像增加了新的产品功能，却可能决定一个项目在外部服务发生变化后，能否继续运行。
七、真正能带走的是项目能力
AI 工具的迭代速度很快。
今天最方便的平台入口，未必会一直存在；今天效果最好的模型，也未必永远适合当前项目。
个人开发者真正能够长期带走的，不应该只是对某个平台的熟悉程度，而应该是：
把需求描述清楚，把平台依赖隔离，把提示词和数据保存下来，把测试做成可以重复执行的流程。
这样，当模型更新、价格变化或服务停止时，我们面对的就不再是“项目还能不能继续”，而是“下一步选择哪个替代方案”。
平台可能会消失，但清晰的应用结构、可复用的测试数据和替换服务的能力，可以一直留下来。
未来选择 AI 服务时，你更看重它现在的模型效果，还是项目以后能否低成本迁移？
本文基于 GitHub、Microsoft 官方公开资料整理，并结合个人项目方法进行分析。AI 工具用于资料整理与文字辅助，内容已由作者人工复核。
资料来源
GitHub Changelog：《GitHub Models is now retired》，2026年7月30日 GitHub Docs：GitHub Models 官方说明 Microsoft Learn：Microsoft Foundry 与 Foundry Local 官方文档