Gemini Gems教程：如何创建自己的专属AI助手

摘要：把高频任务做成AI助手

公众号文章库2026/7/717 分钟阅读

摘要：把高频任务做成AI助手关键词：Gemini Gems、Gemini自定义助手、跨境AI工作流核验日期：2026-07-07

很多跨境团队用 AI 的方式很低效。

运营每天都在复制同一段提示词：

“你是一名亚马逊 Listing 优化专家，请先分析评论，再给出标题、五点、A+、图片文案建议，不要编造参数，不要夸大功效。”

美工也在复制同一段：

“请根据这些卖点生成主图和副图文案，移动端可读，不要写虚假认证。”

客服每天复制：

“请写一封英文回复，语气专业，不要过度承诺，不要透露内部成本。”

这些提示词本身没有问题。

问题是，团队越多人用，输出越不稳定。

有人少贴了禁区。
有人忘了让 AI 先分析再成稿。
有人没有让 AI 标注不确定信息。
有人把客户资料、供应商报价、后台截图直接丢进去。

最后老板看到的不是“AI 提升效率”，而是一堆风格不一致、依据不清楚、还需要重做的半成品。

这就是 Gemini Gems 适合解决的问题。

本文的判断：Gems 不是一个更高级的聊天入口，而是把重复提示词固化成可复用工作 SOP。对跨境卖家来说，真正值得做成 Gem 的，不是“万能运营助手”，而是评论归因、Listing 审稿、客服回复、供应商沟通、广告复盘这类高频、稳定、可复核的任务。

01 Gems到底是什么

Google 官方对 Gems 的定义很直接。

Gems 是 Gemini 的自定义版本，可以帮助你处理重复任务，或者在某个领域提供更深入的帮助。

Google Gemini 官网也写到，Gems 可以保存详细提示词指令，用在最重复的任务上。

换成卖家听得懂的话：

Gem 就是一份固定岗位说明书 + 固定工作流程 + 固定输出格式。

普通聊天是这样的：

你每次都要告诉 Gemini：

你是谁。
做什么任务。
按什么步骤。
需要什么资料。
输出什么格式。
不能写什么。
结果怎么自查。

Gem 的方式是：

你先把这些规则写进 Gem。以后每次只补本次资料，它就按同一套规则工作。

这很像把一个熟练运营的 SOP 写进系统里。

它不能替你确认真实产品事实，也不能替你对最终页面负责。

但它能减少重复解释，让团队输出更稳定。

02 哪些任务适合做成Gem

不是所有事情都适合做成 Gem。

如果一个任务每次都不一样，判断标准很主观，或者需要大量临场推理，就不适合一开始做成 Gem。

适合做成 Gem 的任务，一般有五个特征。

第一，高频。

每周都要做，甚至每天都要做。

第二，流程稳定。

比如先归因、再建议、再成稿、再审稿。

第三，输入资料相对固定。

例如产品参数、评论、关键词、当前 Listing、广告搜索词表。

第四，输出格式明确。

比如表格、修改清单、邮件草稿、审稿报告。

第五，有清楚的风险边界。

比如不能编造认证，不能承诺赔付，不能根据样本不足的数据下绝对结论。

跨境卖家最适合先做这六类 Gem：

评论归因 Gem。
Listing 审稿 Gem。
A+ 结构和图片文案 Gem。
客服英文回复 Gem。
供应商沟通 Gem。
广告搜索词复盘 Gem。

最不建议一上来做的是：

万能运营助手。
全自动选品助手。
自动决定广告预算助手。
自动回复客户助手。
自动生成并发布 Listing 助手。

原因很简单。

Gem 适合稳定重复的第一轮工作，不适合替团队做最终业务决策。

03 创建Gem之前，先写一份任务卡

很多人创建 Gem 失败，是因为还没想清楚任务，就开始写指令。

建议先写一份“Gem 任务卡”。

格式可以很简单：

Gem 名称：

适用岗位：

解决的高频任务：

不解决的任务：

用户每次必须提供的资料：

Gem 固定工作步骤：

输出格式：

禁止事项：

人工复核点：

测试样例：

举个例子。

Gem 名称：
亚马逊差评归因助手

适用岗位：
运营、产品经理、美工负责人

解决的高频任务：
把自家或竞品评论拆成可执行页面修改任务。

不解决的任务：
不直接决定产品改款，不直接写最终 Listing，不判断评论真实性。

用户每次必须提供的资料：
产品名称、站点、评论原文、星级、评论来源、当前页面链接或页面摘要、已知产品参数。

Gem 固定工作步骤：
1. 检查资料是否足够。
2. 按问题类别归因。
3. 提取原始证据。
4. 判断影响页面位置。
5. 给出修改动作。
6. 列出必须人工确认的信息。

输出格式：
表格：问题类别 / 评论证据 / 买家担心 / 页面位置 / 建议动作 / 风险等级 / 需确认信息。

禁止事项：
不要把单条评论夸大成普遍结论。
不要编造评论里没有的信息。
不要输出未经确认的功效或参数。

人工复核点：
样本量、产品事实、合规表达、是否需要产品改良。

测试样例：
选择 30 条真实评论，人工先做一次归因，再和 Gem 输出对比。

这一步很关键。

你不是在写“提示词”，你是在把团队工作方法写清楚。

Gem 的质量，取决于你对业务流程的理解。

04 官方创建路径：从新建到预览

按 Google Help 的说明，在电脑端创建普通 Gem，大致流程是：

打开 gemini.google.com。
打开侧边栏。
进入 Gems。
点击 New Gem。
输入名称和说明。
可选：在 Knowledge 区域添加文件。
保存。

官方页面还提示，在右侧可以输入提示来预览 Gem；预览之后要点击保存，否则不会自动保存。

这个细节很重要。

很多团队创建 Gem 时，只写完指令就让同事用，没有预览测试。

正确做法是：

先拿 3 个真实任务样例测试。

例如：

一个正常样例。
一个资料缺失样例。
一个高风险样例。

看它是否会：

先检查资料。
标注不确定信息。
拒绝编造。
按格式输出。
给出可执行动作。

如果它一上来就直接写成品，说明指令还不够。

如果它总是输出泛泛建议，说明你没有给足角色、工作步骤和验收标准。

如果它忽略风险边界，说明“禁止事项”和“审稿规则”需要写得更具体。

05 Gem指令怎么写：六段式模板

Google 关于创建 Gems 的提示里提到，写好 Gem 指令时，可以考虑 Persona、Task、Context、Format 这些要素。

对跨境卖家来说，我建议扩展成六段：

角色定位。
任务范围。
输入资料要求。
固定工作步骤。
输出格式。
禁止事项和复核规则。

下面是一份可直接复制的 Gem 指令模板。

你是一个专门服务跨境电商团队的 [岗位名称] Gem。

一、角色定位
你熟悉 [平台/站点/类目]，擅长 [核心能力]。
你的工作目标不是替用户做最终决策，而是把用户提供的资料整理成可复核、可执行的建议。

二、任务范围
你只处理以下任务：
1. [任务1]
2. [任务2]
3. [任务3]

你不处理以下任务：
1. 不直接发布内容。
2. 不替用户确认产品事实。
3. 不根据资料中没有的信息编造结论。
4. 不给法律、财务、医疗等专业结论。

三、输入资料要求
每次开始前，先检查用户是否提供了以下资料：
1. 产品名称：
2. 站点：
3. 目标人群：
4. 产品事实：
5. 评论/关键词/广告数据/客服问题：
6. 当前页面或历史版本：
7. 禁用表达和合规边界：

如果资料不足，请先列出缺口，不要直接生成成品。

四、固定工作步骤
请始终按以下步骤工作：
1. 先做资料完整性检查。
2. 再总结核心问题。
3. 再提取证据。
4. 再给出建议动作。
5. 最后输出人工复核清单。

五、输出格式
请按以下格式输出：
1. 资料完整性检查
2. 主要发现
3. 证据表格
4. 建议动作
5. 可复制草稿
6. 风险提示
7. 人工复核清单

六、禁止事项和质量规则
- 不要编造尺寸、材质、认证、功效、销量、排名、评论。
- 不要把单条样本当成整体结论。
- 不要使用绝对化、医疗化、夸大化表达。
- 不要输出用户未授权公开的客户信息、供应商价格、账号信息。
- 所有不确定信息必须标注“需人工确认”。
- 输出必须适合移动端阅读，句子不要过长。

这份模板看起来长，但真正创建 Gem 时只写一次。

以后团队每次使用，只需要补本次资料。

06 实战一：创建“差评归因Gem”

这是我最建议卖家第一个做的 Gem。

因为评论归因是 Listing、图片、A+、产品改良、客服话术的上游。

如果差评原因都没拆清楚，后面写文案、改图片、做 A+ 都容易跑偏。

你可以这样写 Gem 指令：

你是“亚马逊差评归因助手”，服务跨境电商运营、产品经理和美工团队。

你的任务：
把用户提供的评论、QA 或客服反馈，拆解成可执行的页面修改和产品改良建议。

每次开始前，请先检查用户是否提供：
- 产品名称
- 站点
- 评论原文
- 星级
- 评论来源
- 当前页面摘要
- 已知产品参数

如果缺少关键资料，请先提问或列出缺口，不要直接下结论。

工作步骤：
1. 按问题类别归类：功能、尺寸、材质、安装、清洁、包装、耐用性、物流、说明书、售后、其他。
2. 每类必须列出原始评论证据。
3. 判断买家真正担心什么。
4. 判断影响页面哪个位置：标题、五点、主图、副图、A+、QA、说明书、产品改良。
5. 给出修改动作和优先级。
6. 列出不能仅凭评论判断的内容。

输出格式：
表格字段：
问题类别 / 原始证据 / 买家担心 / 页面位置 / 建议动作 / 优先级 / 需人工确认

禁止事项：
- 不要根据单条评论下整体结论。
- 不要编造评论里没有的细节。
- 不要直接写最终 Listing。
- 如果样本太少，必须提醒样本不足。

使用时，运营只需要把评论资料贴进去。

推荐使用方式：

请按你的固定流程分析以下评论。

产品：  
站点：Amazon US  
目标：找出导致转化下降和退货的主要原因  
当前页面摘要：  

评论资料：
[粘贴评论]

这个 Gem 的交付结果，不应该是一篇文案。

它应该是一张问题地图。

这张地图再交给 Listing、美工、产品和客服。

07 实战二：创建“Listing审稿Gem”

第二个值得做的是 Listing 审稿 Gem。

很多团队让 AI 直接写 Listing，风险比较大。

更稳妥的方式是让 Gem 扮演审稿人，检查现有草稿。

指令可以这样写：

你是“亚马逊 Listing 审稿助手”，负责检查 Listing 草稿是否清楚、可信、合规、适合移动端阅读。

你的任务不是替用户最终发布页面，而是指出问题并给出修改建议。

每次请用户提供：
- 产品事实
- 当前标题
- 五点
- A+ 草稿
- 关键词
- 禁用表达
- 目标人群
- 站点

工作步骤：
1. 检查草稿是否使用了资料中没有的参数、认证、功效或承诺。
2. 检查是否有绝对化、医疗化、夸大化表达。
3. 检查关键词是否自然，不要堆砌。
4. 检查移动端是否可读。
5. 检查每个卖点是否对应买家问题。
6. 给出修改优先级。

输出格式：
1. 总体判断：可用 / 需修改 / 高风险
2. 问题表格：位置 / 原文 / 问题 / 修改建议 / 风险等级 / 是否需人工确认
3. 修改后草稿
4. 最终人工复核清单

禁止事项：
- 不要替用户确认产品事实。
- 不要保留未核验的认证或功效。
- 不要为了关键词牺牲可读性。

这个 Gem 的商业价值很明确：

它能把“老板拍脑袋审稿”变成结构化检查。

尤其适合团队多人写 Listing 时，统一审稿标准。

08 实战三：创建“客服英文回复Gem”

客服场景也很适合 Gems。

因为客服回复需要稳定语气、固定边界和内部处理动作。

指令示例：

你是“跨境电商客服英文回复助手”，负责根据客户问题生成专业、克制、合规的英文回复草稿。

你的任务：
1. 判断客户情绪和核心诉求。
2. 生成英文回复草稿。
3. 给出内部处理建议。
4. 标注需要人工确认的信息。

每次请用户提供：
- 平台
- 产品
- 客户原文
- 订单情况摘要
- 可提供的解决方案
- 不能承诺的事项

工作步骤：
1. 先用中文总结客户诉求。
2. 判断问题类型：物流、破损、尺寸、使用、退换货、质量、其他。
3. 给出英文回复草稿。
4. 给出客服内部动作。
5. 标注风险和需确认信息。

禁止事项：
- 不要承诺无法确认的赔付、时效、退款、补发。
- 不要责怪客户。
- 不要暴露供应商、成本、内部流程。
- 不要包含客户隐私之外不必要的个人信息。

客服 Gem 的重点不是“写得更热情”。

重点是减少三类风险：

过度承诺。
情绪化表达。
内部信息外泄。

09 如何给Gem添加知识文件

Google Help 说明，创建 Gem 时可以在 Knowledge 区域添加文件，给 Gem 更多上下文。可以从本地上传，也可以从 Google Drive 添加；如果从 Drive 添加，需要开启 Keep Activity 并连接 Google Workspace 到 Gemini Apps。官方页面还说明，如果 Drive 文件后续更新，Gem 会使用文件的最新版本。

这对跨境团队很有用。

你可以给 Gem 添加这些文件：

品牌语气规范。
禁用词和敏感表达清单。
产品参数表。
Listing 模板。
A+ 模块模板。
客服标准话术。
供应商沟通模板。
广告复盘字段说明。

但不要把所有资料都塞进去。

知识文件越多，不代表越好。

建议遵守三个规则。

第一，只放长期稳定资料。

例如品牌语气、输出模板、禁用表达、固定 SOP。

第二，短期项目资料每次单独输入。

例如本周评论、广告搜索词、供应商报价、当前产品参数。

第三，敏感资料先脱敏。

例如客户姓名、电话、地址、订单号、真实利润、供应商底价、账号信息。

如果一个 Gem 要给团队多人使用，文件权限更要谨慎。

官方分享 Gem 的帮助文档提醒，Gem 指令和上传到 Gem 的文件，可能被有访问权限的用户看到；有编辑权限的人还能更新或删除 Gem。

所以，团队共享 Gem 前必须问：

这个 Gem 的指令里有没有内部机密？
知识文件里有没有供应商底价、客户数据、账号信息？
谁是 Viewer，谁是 Editor？
是否需要设置访问过期时间？
是否应该只在组织内部共享？

AI 工具的问题，最后经常不是模型能力，而是权限治理。

10 分享Gem之前，要做一次上线测试

如果你准备把 Gem 分享给团队，不要直接丢链接。

先做上线测试。

建议用 5 个样例：

标准样例。

资料完整，看看输出是否达到预期。

缺资料样例。

故意不提供产品参数，看看它会不会提醒缺口。

高风险样例。

评论里出现功效、认证、医疗、赔付等敏感内容，看看它会不会保守处理。

错误资料样例。

给一个明显冲突的尺寸或参数，看看它会不会标注冲突。

输出格式样例。

检查表格字段、优先级、复核清单是否稳定。

测试后记录三件事：

Gem 哪些地方表现稳定。
哪些地方容易跑偏。
指令需要补哪条规则。

这一步很像培训新人。

你不能只给新人一份岗位说明书，就让他直接独立负责页面上线。

Gem 也一样。

要先测试，再上线，再复盘。

11 团队如何管理Gems

如果只有一个人用，Gem 是个人效率工具。

如果团队一起用，Gem 就需要管理。

建议建一张 Gem 管理表。

字段包括：

Gem 名称。
负责人。
适用岗位。
适用任务。
输入资料要求。
知识文件列表。
分享范围。
Viewer 和 Editor。
最近更新时间。
最近一次测试样例。
常见错误。
下一次复盘日期。

每个 Gem 都应该有负责人。

不要出现“谁都能改、谁都不负责”的情况。

版本管理也很重要。

例如：

差评归因Gem-v1：只做评论分类。
差评归因Gem-v2：加入页面位置判断。
差评归因Gem-v3：加入 A+ 和图片任务拆解。

如果输出变差，不要只怪模型。

先检查：

最近是否改过指令。
是否换了模型或入口。
是否上传了新的知识文件。
是否用户输入资料质量下降。
是否团队成员误用了任务范围。

好 Gem 不是一次写完的。

它需要像 SOP 一样定期维护。

12 不要把Gems误读成Agent

这是最重要的边界。

Gem 不是完整的企业级 Agent。

它不会天然拥有你的店铺后台权限，也不会自动读取所有业务系统，更不应该被设置成自动发布和自动决策。

可以把它理解成：

稳定执行某一类提示词的专属助手。

它适合：

先整理资料。
先做分类。
先生成草稿。
先做审稿。
先列检查清单。

它不适合：

自动改 Listing。
自动提交广告预算。
自动承诺退款补发。
自动判断供应商赔付责任。
自动处理账号申诉。
自动上传敏感客户数据。

Google Privacy Hub 也提醒，Gemini Apps 可能出错；使用能完成任务、连接服务或处理数据的功能时要小心，并要密切监督。对于个人账号场景，如果 Keep Activity 开启，也不要输入不希望人工审查员看到或用于改进服务的机密信息。

对卖家来说，实操边界可以写成一句话：

Gem 负责把资料变成可复核草稿，负责人负责最终判断。

13 明天就能照着做的落地清单

如果你想马上开始，不要一次做 10 个 Gem。

先做一个。

建议从“差评归因 Gem”或“Listing 审稿 Gem”开始。

按这个顺序走：

选一个高频任务。

不要做万能助手。

写任务卡。

明确适用岗位、输入资料、输出格式、禁止事项。

写 Gem 指令。

按角色、任务、输入、步骤、格式、风险六段写。

准备知识文件。

只放长期稳定资料，比如品牌语气、禁用词、输出模板。

用 3 到 5 个真实样例预览测试。

看它是否会先检查资料、再输出结果。

修正指令。

把跑偏的地方写成明确规则。

小范围分享。

先给一个运营或客服试用，不要一开始全员推广。

建管理表。

记录负责人、版本、知识文件、分享范围和复盘日期。

每月复盘。

统计错误类型，更新 Gem 指令。

这套流程做完，Gem 才不是一个好玩的功能，而是团队可复用的 AI 工作单元。

14 给卖家的结论

Gemini Gems 最适合解决的，不是“AI 能不能替我做所有事情”。

它解决的是另一个更现实的问题：

同一类任务，团队能不能稳定按同一套标准输出。

对跨境卖家来说，真正有价值的 Gem，一定具备四个特征：

任务足够窄。
输入资料清楚。
输出格式稳定。
风险边界明确。

如果你只是把一句“你是亚马逊专家”保存成 Gem，它不会带来太多变化。

如果你把评论归因、Listing 审稿、客服回复、供应商沟通、广告复盘这些流程写进 Gem，它就会变成团队的可复用 SOP。

AI 工具最终拼的不是谁提示词更花。

拼的是谁能把业务流程写得更清楚，谁能把复核责任留在人手里，谁能把高频工作做成稳定系统。

这才是 Gemini Gems 对跨境团队真正有用的地方。