Gemini Gems 是谷歌 AI 对话模型 Gemini 早期版本中引入的一项功能它允许用户通过特定的提示词Prompt来创建、分享和调用一些预设的、功能化的对话模板。这些 Gems 可以理解为用户自定义的、可复用的“技能”或“助手”例如一个专门用于代码审查的 Gem一个用于旅行规划的 Gem或者一个用于学习新概念的 Gem。用户无需每次都编写复杂的提示词直接选择对应的 Gem 即可获得针对性的对话体验。然而根据谷歌的官方公告Gemini Gems 这一功能名称和部分实现方式将在今年十月正式退役。取而代之的是一个在概念上延续但更清晰、功能可能更强大的新体系——Skills。对于已经依赖 Gems 来提高工作效率或作为工作流一部分的开发者、研究者和普通用户来说理解这一变化、评估其影响并提前做好迁移准备至关重要。本文旨在为这类读者提供一个清晰的技术迁移指南。我们将首先剖析 Gems 与 Skills 的核心差异然后提供一套从现有 Gems 到未来 Skills 的评估与迁移实践方案最后讨论在此过渡期间的最佳实践和注意事项。1. 理解 Gems 退役与 Skills 转型的核心动因要平稳应对这次变更不能只停留在“改名”的层面需要理解其背后的产品逻辑和技术演进方向。这有助于我们判断哪些使用模式会受到影响以及如何更好地适应新的 Skills 体系。1.1 Gems 的设计初衷与局限性Gems 的诞生是为了降低高级提示工程的使用门槛。在大型语言模型LLM应用的早期要稳定地获得高质量、特定领域的输出需要精心设计并不断迭代提示词。Gems 试图将这个过程产品化模板化 将一个复杂的提示词包括系统指令、上下文示例、输出格式要求等打包成一个可点击的按钮或选项。可分享性 用户创建的 Gem 可以通过链接分享给他人他人一键即可使用促进了提示词社区的萌芽。简易调用 在 Gemini 界面中Gems 通常以显眼的方式陈列用户无需记忆或粘贴冗长的提示词。然而这种设计在实践中也暴露出一些局限性功能边界模糊 “Gem”这个术语本身没有清晰定义其能力范围。一个简单的问答模板和一个需要调用外部工具、有复杂逻辑链的“助手”都被称为 Gem导致用户预期混乱。管理复杂度高 对于创建了大量 Gems 的用户缺乏有效的分类、搜索和版本管理工具容易变得杂乱无章。集成度不足 Gems 主要作为对话的“启动器”存在与谷歌的其他产品和服务如 Workspace、Cloud APIs的深度集成能力有限难以构建真正的自动化工作流。1.2 Skills 的演进方向与预期优势“Skills”技能是一个在AI和自动化领域更成熟、语义更明确的概念。从 Gems 转向 Skills预示着谷歌希望构建一个更结构化、更强大、更易集成的AI能力生态系统。结构化与标准化 “Skill”一词暗示了更清晰的功能定义和输入输出规范。未来的 Skills 可能会拥有更明确的元数据描述例如技能类别、所需输入参数、输出格式、适用场景等便于系统管理和用户发现。更强的可组合性 Skills 的设计目标可能是为了实现技能之间的相互调用和组合。例如一个“数据提取”Skill 的输出可以直接作为“图表生成”Skill 的输入从而构建更复杂的AI智能体Agent工作流。深度平台集成 Skills 有望与谷歌的生态系统进行更深度的绑定。这可能包括与 Google Workspace 集成 直接在 Docs、Sheets、Slides 中调用特定 Skill。与 Google Cloud 服务打通 Skill 可以方便地调用 Cloud Functions、Vertex AI 模型或其他 API。更完善的开发与管理工具 可能会提供专门的 Skills 开发套件SDK、测试环境和部署管理面板。企业级支持 Skills 体系可能更侧重于团队协作、权限管理、使用审计和生命周期管理以满足企业客户的需求。简单来说从 Gems 到 Skills是从“可分享的提示词模板”向“可编程、可组合、可集成的AI功能模块”的升级。2. 迁移前准备盘点现有 Gems 并评估影响在十月变更到来之前最务实的行动是对你当前使用的 Gems 进行一次全面盘点。这将帮助你区分哪些可以平滑过渡哪些需要重新设计甚至哪些可能被淘汰。2.1 创建你的 Gems 资产清单首先整理出你所有创建或收藏的 Gems。建议使用表格进行记录以便后续分析。Gem 名称主要功能描述使用频率 (高/中/低)依赖的核心提示词是否调用外部知识/工具关键程度 (核心/有用/实验性)代码审查助手审查指定编程语言的代码提供优化建议和安全检查。高“你是一个专业的 [语言] 开发专家。请逐行审查以下代码指出潜在的性能问题、安全漏洞、代码风格问题并提供修改建议。代码是 [代码片段]”否核心周报生成器根据输入的每日工作要点生成结构化的周报。中“请将以下零散的工作条目整理成一份专业的周报包含概述、主要工作、成果、下周计划。条目[工作条目列表]”否有用竞品分析框架给定一个产品名称生成一份竞品分析报告大纲。低“请扮演一名产品经理。针对‘[产品名]’生成一份竞品分析框架包括市场定位、目标用户、功能对比、SWOT分析等部分。”否 (但依赖模型的最新知识)实验性API 调试助手帮助分析和格式化复杂的 API 请求与响应。高“这是一个 HTTP 请求/响应。请帮我格式化 JSON/XML解释各个字段的含义并判断状态码是否正常。内容[API 内容]”否核心2.2 基于清单进行影响评估根据上表的记录你可以对每个 Gem 进行迁移风险评估低风险直接迁移型 功能纯粹由提示词驱动不涉及复杂逻辑或外部集成且提示词本身是自包含的。例如“周报生成器”。这类 Gems 最有可能在 Skills 平台提供后通过创建一个内容相同的新 Skill 来直接替代。行动建议 备份好核心提示词文本等待 Skills 功能开放后首批迁移。中风险需要适配型 提示词中包含了“联网搜索”或“使用最新信息”等指令其效果依赖于 Gemini 模型本身的能力更新或扩展插件。这类 Gems 的功能可能因 Skills 体系下插件调用方式的改变而需要调整。行动建议 明确该 Gem 的核心价值是信息的新鲜度还是分析框架。如果是后者保留框架同时关注 Skills 将如何集成实时信息获取能力。高风险可能需要重构思 你通过复杂的提示词工程模拟了多步骤推理、工具调用虽然 Gemini 当时可能并未真正调用或特定工作流。例如一个提示词里先让模型“思考”再“搜索”最后“总结”。这类 Gems 是 Skills 理念旨在原生支持的但实现方式可能完全不同。行动建议 将其拆解为更原子化的任务。思考在 Skills 体系下是否可以将“思考”、“搜索”、“总结”分别设计成独立的 Skills然后通过组合来实现原功能。开始用流程图或伪代码重新设计该工作流。淘汰评估型 使用频率极低或实验性的 Gems。这次变更是一个很好的机会来进行清理。行动建议 考虑直接归档或删除。如果其中包含有价值的提示词思路可以将其保存到个人笔记中而不是作为可执行资产保留。注意 目前在变更发生前谷歌很可能不会提供自动从 Gems 到 Skills 的转换工具。手动盘点、评估和备份是确保平稳过渡的唯一可靠方法。3. 面向 Skills 的思维转变与设计实践在等待 Skills 具体功能上线期间你可以提前将思维模式从“编写提示词”转向“设计技能”。这能让你在未来更快地上手。3.1 从“提示词”到“技能接口”的设计一个健壮的 Skill 不应只是一个黑盒提示词。在设计时需要考虑清晰的输入输出接口。旧思维 (Gem): “我给模型一段包含所有指令和占位符的文本。”你是一个翻译专家请将以下英文技术文档翻译成中文要求术语准确、语言流畅。文档内容[DOCUMENT]新思维 (Skill): “我定义一个有明确参数的函数内部封装了模型调用逻辑。”技能名称:TechnicalTranslator输入参数:source_text(string, required): 待翻译的英文技术文本。target_language(string, optional): 目标语言默认为 “zh-CN”。domain_hint(string, optional): 技术领域提示如 “cloud-computing”, “frontend”。输出描述: 返回翻译后的中文文本并确保专业术语准确。内部实现: 封装了优化后的系统提示词和可能的后处理逻辑。这种思维转变迫使你思考技能的复用性和组合性。上述TechnicalTranslatorSkill 可以很容易地被另一个“技术文档处理流水线” Skill 所调用。3.2 构建可组合的技能链Skills 的强大之处在于链式调用。现在就可以为你复杂的工作流设计蓝图。场景 自动处理用户反馈生成摘要并分类。Gem 时代 你可能写一个极其冗长的提示词要求模型依次完成“提取关键句”、“情感分析”、“分类”、“生成摘要”。Skills 时代 你可以设计三个独立的 Skills然后组合它们FeedbackParser: 输入原始文本输出结构化的反馈条目列表包含用户ID、反馈内容、时间戳。SentimentClassifier: 输入一段文本输出情感极性积极、消极、中性和置信度。SummaryGenerator: 输入一组相关文本输出一段总结性文字。工作流变为原始反馈-FeedbackParser-SentimentClassifier(对每条反馈) -SummaryGenerator(对同类反馈组)。这种设计更模块化易于调试和更新。3.3 示例将“代码审查助手”重构为 Skill 设计假设我们有一个常用的“Python 代码审查” Gem。以下是其向 Skill 演进的思考过程解构原提示词 原提示词可能混合了角色设定、代码输入、审查维度安全、性能、风格、输出格式要求。定义 Skill 接口名称:CodeReviewer输入:code_snippet(string): 需要审查的代码。language(string): 编程语言如 “python”, “javascript”。review_focus(array, optional): 审查重点如 [“security”, “performance”, “style”]默认为全部。output_format(string, optional): 输出格式如 “markdown”, “json”。输出: 根据output_format返回审查结果。设计内部提示词模板 基于输入参数动态生成最终发送给模型的提示词。# 伪代码示例Skill内部逻辑 def build_review_prompt(code_snippet, language, review_focus): base_system_prompt “你是一个经验丰富的{language}开发专家。” focus_instruction “请重点审查以下方面” “, “.join(review_focus) if review_focus else “请进行全面的代码审查。” format_instruction “请以{output_format}格式返回结果清晰列出问题、位置和建议。” user_prompt f“请审查以下代码\n{language}\n{code_snippet}\n” final_prompt f“{base_system_prompt} {focus_instruction} {format_instruction}\n\n{user_prompt}” return final_prompt思考扩展性 这个CodeReviewerSkill 未来是否可以集成静态分析工具如pylint,eslint的结果是否可以将审查结果自动创建为 GitHub Issue这些都是在 Skills 体系下更可能实现的深度集成。4. 过渡期最佳实践与风险规避在官方迁移路径完全明确之前遵循以下实践可以最大程度降低服务中断风险。4.1 当前Gems 可用期的行动清单立即备份 将你所有核心 Gems 的完整提示词文本导出并保存到本地文档如 Markdown 文件或可靠的笔记软件中。不要只依赖云端的收藏夹链接。文档化 为每个重要的 Gem 编写简短的使用说明包括其用途、示例输入、预期输出以及任何特殊的调用上下文。这在你需要重建或向队友解释时至关重要。寻找替代方案 对于关键工作流依赖的 Gem研究是否可以通过其他方式实现直接使用提示词 将 Gem 的核心提示词保存为文本片段需要时手动粘贴到 Gemini 对话中。这是最直接的降级方案。使用浏览器书签或快捷方式 将常用提示词保存为浏览器书签通过data:URL 或书签小工具实现一键填充。探索其他AI平台 评估其他提供类似“自定义指令”、“快捷方式”或“GPTs”功能的平台看是否能实现类似功能。保持关注 密切关注谷歌官方开发者博客、Gemini 帮助中心或相关技术社区的公告以获取关于 Skills 上线时间、迁移工具和具体 API 的第一手信息。4.2 变更发生后的预期与排查假设在十月Gems 入口突然消失或不可用你应该按照以下步骤排查和应对问题现象可能原因检查与应对措施Gemini 界面中找不到 “Gems” 或 “My Gems” 选项。功能已按计划下线。1. 检查官方公告确认下线时间。2. 立即启用你的本地备份提示词采用手动粘贴方式继续工作。通过旧链接访问 Gem提示“不存在”或“已失效”。后端服务已关闭链接重定向或失效。同上依赖本地备份。不要指望旧链接恢复。新的 “Skills” 功能已上线但界面和创建方式不熟悉。产品界面和交互逻辑已更新。1. 查阅最新的官方 Skills 开发文档。2. 尝试将你备份的最简单的一个提示词创建为新的 Skill测试流程。将旧提示词创建为 Skill 后效果不如从前。模型版本可能更新或 Skills 的调用上下文与 Gems 不同。1. 对比新旧输出差异。2. 根据 Skills 文档调整系统指令或参数设置可能需要微调提示词以适应新接口。复杂的、依赖多步骤的 Gem 无法在 Skills 中简单重建。Skills 的原子化设计与原有复杂提示不匹配。按照第3.2节的思路将复杂功能拆解为多个 Skills并尝试通过工作流引擎如果支持或顺序调用来组合实现。4.3 长期建议构建不依赖特定UI的AI工作流这次变更提醒我们过度依赖某个平台的具体用户界面功能存在风险。为了提升韧性可以考虑以下方向拥抱 API 对于核心、稳定的AI调用需求优先考虑使用 Gemini API 或其他模型的 API。通过代码Python, Node.js等来构建你的工作流这样你拥有完全的控制权包括提示词管理、错误处理、日志记录和版本控制。# 示例使用 Gemini API 代替依赖 Gem 界面 import google.generativeai as genai genai.configure(api_key“YOUR_API_KEY”) model genai.GenerativeModel(‘gemini-pro’) # 你的“代码审查”提示词保存在本地变量或配置文件中 code_review_prompt_template “”” 你是一个专业的{language}开发专家。请审查以下代码 {language} {code}请列出潜在问题并提供建议。 “””def code_review(code, language“python”): prompt code_review_prompt_template.format(languagelanguage, codecode) response model.generate_content(prompt) return response.text提示词版本化 使用 Git 等版本控制系统来管理你的核心提示词模板。将其视为重要的配置文件记录每次修改的缘由。抽象层设计 在你的应用代码和AI模型之间设计一个抽象层。这个层负责组装提示词、调用模型API、解析响应。当底层模型或平台功能如从Gems到Skills发生变化时你只需要修改这个抽象层而不是到处散落的业务代码。从 Gems 到 Skills 的转变远不止一次简单的功能重命名。它标志着谷歌正在将其AI助手从“拥有一些有趣预设的聊天机器人”推向“一个具备可编程、可组合技能的操作系统”。对于开发者而言这既是挑战也是机遇。挑战在于需要迁移现有的资产和习惯机遇在于新的 Skills 体系可能带来更强大、更灵活的自动化能力。立即开始盘点你的 Gems用设计技能的思维重新审视你的AI工作流并逐步将核心能力构建在更可控的API和代码基础上将是应对这次变革最有效的策略。