xAI 于 5 月 18 日上线 Grok『Skills』功能，让用户教一次、Grok 记一辈子。这是 Grok 从无状态聊天机器人转向可配置工作空间的关键一步，也是与 ChatGPT Memory、Claude Projects 正面交锋的开始。

xAI 给 Grok 装上『Skills』：从聊天机器人到可编程工作台

5 月 18 日，xAI 在网页端、iOS 和 Android 三端同步推送了 Grok 的『Skills』功能。表面上看，这是一次常规的产品更新——给聊天机器人加了个『记事本』。但如果你做过几个月的 prompt 工程、写过 system prompt 的版本管理脚本，就会明白这事的分量：Grok 第一次有了真正意义上的跨会话状态，并且把这个状态做成了用户可见、可编辑、可复用的对象。

用马斯克本人在 X 上的说法，这是『让 Grok 从一个会聊天的模型，变成一个会工作的助手』。这话听起来像营销，但拆开看其实指向了一个明确的产品哲学转变。

Grok Skills 功能在 Web 端的设置界面，左侧显示已创建的 Skills 列表，右侧是当前 Skill 的指令编辑区

Skills 到底是什么

Skills 的核心机制说穿了不复杂：用户用自然语言向 Grok 描述一项任务的执行规则——可以是输出格式、可以是工作流步骤、也可以是个人偏好——Grok 会把这条规则封装成一个命名的 Skill，存到账户级别的持久存储里。之后无论你开多少新会话，只要触发条件匹配，这个 Skill 就会自动加载到上下文。

举几个真实可用的例子：

你告诉 Grok『以后我让你写周报，按"本周完成 / 下周计划 / 风险项"三段式输出，每段不超过 5 条 bullet』，下次直接说『写周报』就行；
你训练它『审阅我的 TypeScript 代码时，优先指出类型安全问题，再看可读性，最后才是性能』，所有 code review 类对话自动套用；
你设定『回复客户邮件时，开头不要用"希望您一切顺利"，结尾用我的真实签名档』，从此告别那种一眼 AI 味的客套话。

关键差异在于，Skills 不是塞进当前会话的 system prompt，而是被 Grok 当成可复用的能力单元来管理。用户可以在设置面板里看到自己创建过的所有 Skills，单独编辑、禁用、删除。这种『把记忆做成资产』的思路，比 ChatGPT 那种黑盒式的 memory 透明得多。

这不是第一个『记忆』功能，但姿势不一样

AI 助手做记忆这件事，2024 年起就是兵家必争之地。OpenAI 在 2024 年 2 月给 ChatGPT 加了 Memory，Anthropic 用 Projects 解决类似问题，Google 的 Gemini 推了 Gems，国内的智谱、Kimi 也都有各自的版本。说 Grok 这次是首创，那是不诚实的。

但 Skills 在产品形态上有几个明显的差异化设计，值得拆开来看。

第一，颗粒度更细。 ChatGPT 的 Memory 是一个全局开关，开了之后它会自己判断什么该记什么不该记，用户对存了什么东西基本没有控制权——你能做的就是去 Settings 里看一眼那个长得像日记的 list，然后挨个删。Skills 反过来，每一条规则都是显式的、命名的、可单独触发的。这更像 Claude Projects 的做法，但 Projects 是会话容器，你必须在那个项目里聊天才生效；Skills 是账户级的，跨任何会话都能召唤。

第二，触发逻辑可控。 用户可以指定一个 Skill 是『始终生效』还是『按需触发』。前者适合人格设定、输出风格这类全局偏好，后者适合特定任务的工作流——比如『写周报』这个 Skill，你不想它在你问技术问题时也来掺一脚。

第三，可被分享。 xAI 在更新说明里提到 Skills 后续会支持导出和分享，这意味着团队里的资深工程师可以把自己调好的 code review Skill 导出来给新人用。这一步如果真做出来，性质就变了——它不再是个人记忆功能，而是一个轻量级的 prompt 资产管理系统。

技术上的真问题

做过 RAG 或者长上下文系统的人会立刻意识到，Skills 的实现并不像产品描述那么轻巧。

最直接的挑战是上下文预算。每个 Skill 都要占 token，账户里 Skills 越多，每次对话的隐式开销越大。Grok 4 的上下文窗口是 256K，听起来很宽裕，但如果一个重度用户攒了几十个 Skills，每个再带点示例，单是 Skills 加载就可能吃掉几千甚至上万 token。这部分成本谁来承担、怎么计费，xAI 目前没有给出清晰说明。

第二个问题是冲突解决。两个 Skills 规则打架时怎么办？比如一个 Skill 要求所有代码注释用英文，另一个 Skill 要求技术文档用中文，遇到中文项目里的代码片段时听谁的？xAI 的方案是按『最近触发优先』和『显式调用优先』两条规则裁决，但这套逻辑在复杂场景里很难稳定。这是所有 prompt 编排系统的老大难，xAI 也没法绕过去。

第三个问题更微妙——Skill 漂移。模型每次升级，对同一段指令的理解都可能变化。你三个月前调好的『按 5 条 bullet 写周报』Skill，在 Grok 4.5 上还能正常工作吗？这一点 OpenAI 的 Memory 也有同样的毛病，目前业界没有任何一家给出过迁移保证。

对开发者意味着什么

Skills 目前主要面向 C 端用户，但它的设计思路对开发者并非无关。

如果你在做基于 Grok API 的应用，过去你需要自己维护一套 system prompt 模板和用户偏好存储，每次请求拼接进去。Skills 上线后，xAI 暗示后续会开放 API 侧的 Skills 管理能力——也就是说，账户级别的 Skills 可以通过 API 调用时被自动加载。这相当于平台帮你托管了一部分 prompt 状态，对中小团队是减负，对大型应用则是新的耦合风险。

值得提一句的是，国内开发者想体验 Grok Skills 配套的 API 能力，可以通过 OpenAI Hub 这类聚合平台直连。一个 Key 就能调 Grok、GPT、Claude、Gemini、DeepSeek 等主流模型，省掉了搞代理和多账户的麻烦。基础调用还是 OpenAI 兼容格式：

from openai import OpenAI

client = OpenAI(
    base_url=\"https://api.openai-hub.com/v1\",
    api_key=\"your-api-key\"
)

response = client.chat.completions.create(
    model=\"grok-4\",
    messages=[
        {\"role\": \"system\", \"content\": \"你是我的代码审阅助手，按类型安全 > 可读性 > 性能的顺序给出反馈\"},
        {\"role\": \"user\", \"content\": \"帮我看下这段 TypeScript：\
function parse(data: any) { return JSON.parse(data) }\"}
    ],
    temperature=0.3
)

print(response.choices[0].message.content)

在 Skills 的 API 接口正式开放前，开发者还是得自己把规则塞到 system prompt 里。但产品形态指向的方向是明确的：未来的 AI API 调用会越来越像调用一个有状态的服务，而不是无状态的函数。这对架构设计的影响会逐步显现。

跟竞品掰手腕

横向对比一下 2026 年 5 月各家的记忆类功能：

平台	功能名	颗粒度	用户可见性	跨会话	团队共享
ChatGPT	Memory	隐式条目	列表可见，难编辑	是	否
Claude	Projects	项目级	完全可见	项目内	是（团队版）
Gemini	Gems	角色级	完全可见	是	有限
Grok	Skills	规则级	完全可见可编辑	是	计划中

Grok 的 Skills 在『颗粒度』和『用户可见性』两个维度上做到了目前最细，但代价是用户的认知负担也最高——你得自己想清楚要把什么知识封装成 Skill。这是个典型的产品权衡：给的自由度越高，对用户的要求越高。

Claude 的 Projects 仍然是团队协作场景下最成熟的方案，因为它把『记忆』和『项目空间』天然绑在一起。Skills 想吃这块蛋糕，必须把分享和团队管理做扎实，否则就只是个人玩具。

一个被忽视的信号

抛开功能本身，Skills 上线还透露了 xAI 产品策略的一个变化。过去一年，Grok 给外界的印象主要是『跑分凶猛』——Grok 4 在 AIME25、HLE 这类硬核基准上确实把 Claude 4 Opus 和 Gemini 2.5 Pro 压了一头。但跑分高不等于好用，OpenAI 用 ChatGPT 的产品体验证明过这一点。

Skills 是 xAI 第一次明显在『可用性』而不是『能力上限』上发力。它解决的不是 Grok 不够聪明，而是 Grok 不够贴身。从这个角度看，xAI 已经意识到模型能力的边际收益在递减，下一阶段的差异化要靠记忆、个性化、工作流编排这些工程问题来打。

这跟 OpenAI 把 GPT-5 的发布会一半时间花在 Custom GPT 和 Tasks 上是同一个逻辑。模型层的军备竞赛进入平台期之后，应用层的产品力会决定谁能留住付费用户。Skills 是 xAI 在这条赛道上交的第一份像样的答卷。

还能再问几个问题

这次更新当然不是没有可吐槽的地方。

Skills 目前没有版本历史，你修改了一个 Skill，旧版本就没了。这对认真用 Skills 来固化工作流的用户是个痛点——AI 时代的 prompt 也该有 Git。

Skills 之间没有依赖关系。复杂工作流里你可能希望 Skill A 调用 Skill B，目前只能在一个 Skill 里写完所有逻辑，长了就难维护。

隐私层面，Skills 默认存在 xAI 服务器上，企业用户想要本地化或私有部署没有路径。考虑到 xAI 跟 X 平台数据的紧密关系，对数据敏感的团队短期内大概率不会把核心工作流放到 Skills 里。

这些问题不影响 Skills 现在能用，但决定了它能走多远。等三个月后看用户实际用得多不多、xAI 后续怎么迭代，会比今天的发布稿更能说明问题。

短期看，Skills 上线最直接的收益是 Grok 重度用户的留存。长期看，它是 xAI 把 Grok 推向『AI 操作系统』叙事的第一块地基——如果未来加上工具调用编排、Agent 任务托管，这条路径会越来越像 OpenAI 在做的事。两家在产品形态上的趋同，可能比模型架构的趋同更值得关注。

参考来源

OpenAI 发布 Codex 重大更新；xAI 上线 Grok 4.3（知乎专栏） — 此前 xAI 在记忆和分层上下文方向上的产品演进背景，可作为 Skills 的前置阅读。