1. 项目概述与需求拆解

“前任skill安装教程”这个标题，乍一看像是个情感类的玩笑梗，但结合全网检索热词（skill安装、skill制作、codex skill、claude skill、openclaw skill、数学建模skill等），可以非常明确地判断：这里的“前任skill”并不是什么情感挽回话术，而是一个在AI Agent生态中火了很久的趣味型skill项目——它通过调用大语言模型，模拟出一个“前任”的人设，在和用户对话时输出带有前任语气的回应。说白了，就是给Claude、Codex、OpenClaw这类AI助手安装一个“人格插件”，让它在特定场景下变身成某个具体的“前任角色”，输出带情绪、带记忆、带脾气的对话。

这篇文章不是来给大家讲情感故事的，是来把“skill”这个概念、安装流程、目录结构、如何自己动手做一个类似skill的原生问题讲透。适合三类人看：第一类是刚接触Agent开发、准备给自己的AI助手装插件的新手；第二类是想搞懂skill到底是什么、和普通提示词有什么区别、和Agent又是什么关系的进阶玩家；第三类是想自己写一个skill并发布出去（比如做一个“前任”类角色skill）的动手党。顺着这个思路，我把整个生态认认真真地拆了一遍，整理了装skill、写skill、托管skill、复用skill的全套可落地操作，希望这篇内容你读完之后能自己上手复现，而不是只收藏不实操。

先说结论：目前大家讨论的“前任skill”，绝大多数情况下指的是Cline/Claude Code/OpenClaw等Agent工具中使用的SKILL.md规范文件。一个skill本质上是一个文件夹，里面放一个SKILL.md主文件（有时候还带子模块、脚本、参考资源），通过特定的目录引导机制，让AI在对话时能够发现并加载这份技能，从而输出稳定风格、稳定行为逻辑的结果。看懂这个定义之后，“前任”只是这个技能的一个角色设定示例，真正值得记录的是背后的技能分发与加载机制。

在动手之前，我先给零基础的读者补几个上游概念——Agent、插件、skills、MCP、工具调用，这些词长期混用，如果不分清边界，后面全部都会绕晕。整个解释我尽量用类比讲清楚，省得你看文档的时候卡壳。

1.1 到底什么是skill：相比提示词它强在哪

用最简单的话说，一个skill就是一套“带结构化元信息的行为指令包”。它不像普通提示词那样只是写在对话开头的一长串文字，而是作为独立文件放进AI工作区的.skill目录、.claude/skills目录或者用户级skills目录里，Agent在启动时会自动扫描这些目录、解析SKILL.md中的metadata，然后在对话过程中根据语义触发加载。

比起“把提示词复制进对话框”这种粗糙玩法，skill有四个明显优势：

• 解耦 ：用户不需要每次对话都复制粘贴一大段人设，skill文件一直躺在项目目录里，AI每次会话自动感知。
• 版本化 ：技能文件可以用git管理，改了模板、换了模型、想回滚到上一版，git checkout就完事。
• 结构丰富 ：一个skill里面可以携带JSON Schema（用于结构化输入）、参考文档、脚本、few-shot示例，远超一段提示词的表达能力。
• 可分享 ：skill天然是一个文件夹，打包成zip或推到仓库就能发给别人，里面包含完整说明文件，别人不需要推测你的“人设词”怎么写的。

但是要小心一个误区：skill不是独立的推理程序，它没有自己的记忆库，也不能脱离底层的Agent独自跑对话。skill本质上是“给大模型的调用提供脚手架和约束规则”。所有的“前任语气”效果，最终是大模型根据你写进SKILL.md里的角色设定、例文、禁忌生成的，不存在所谓的“模型内生前任人格”。这一点理解到位，后续写任何skill都能事半功倍。

1.2 skill和agent到底有什么区别

这个问题被反复问过很多遍，我直接用比喻解答：一个Agent相当于“能自己完成一连串任务的员工”，它包含大模型、记忆、工具调用循环、任务规划能力；而skill好比“员工手里的岗位SOP手册”。员工可以按照SOP手册工作，但员工不只是手册；反过来，SOP手册离开了会执行的员工，也就是一份存放在文件夹里的静态文档。

更实际的区分维度是触发方式和生命周期：

对比项	Agent	Skill
触发方式	自主决策、循环推理、需要用户派发任务	收到语义匹配时被动加载，通常不主动开启新流程
内容形态	可能有独立入口、记忆管理、多步工具编排	一组说明文件+资源目录
生命周期	一个完整任务的执行过程	长期存在，等待被随时加载
底层组件	大模型 + 记忆 + 工具 + 规划器	YAML参数块 + Markdown说明 + 关联脚本/资源
典型例子	Claude Code中的任务型Agent、支持多步规划	codex skill、claude skill这类“角色扮演/文档生成/代码审查”包

写一个作用于日常编码辅助的skill，不需要自己搞一个Agent框架，只要给现有Agent加规范文件即可。如果项目策划里需要的是“根据用户模糊指令自己拆任务并主动上网查资料、写代码、跑测试”，那应该去做Agent编排，做skill就不合适了。

1.3 skill能在哪些平台跑起来：主流支持见闻

安装skill之前，得先确认自己用的工具是否支持skill目录，以及对应的目录位置。以我个人的使用经历来看，目前支持相对成熟、社区讨论也最多的是这几类：

• Claude Code（桌面端/CLI） ：支持 .claude/skills/ 目录和用户级 ~/.claude/skills/ 目录，skill名直接作为文件夹名，里面需要有一个 SKILL.md 文件。
• Codex（OpenAI Codex CLI） ：相关社区把skill当扩展模块使用，常见做法是把skill文件夹放到某个固定目录，由启动配置自动引入，或者用AGENTS.md指定引用。
• OpenClaw ：这是智能体社区里比较活跃的一个多平台个人助理框架，它原生支持通过plugins命令安装skills，也有集中市场化的管理方式。
• Cline / Roo Code / Cursor（部分版本） ：前后端陆续接入skills特性，目录规范基本学着Claude Code走。
• AnythingLLM / Dify / Coze ：这类偏向RAG或低代码平台，对skill支持情况不一，有的把“知识库”当skill用，有的把“工作流”当skill用，需要注意别混为一谈。

因为不同平台的加载规则细节不一样，下面“前任skill安装”教程里，我会尽量把Claude Code、Codex、OpenClaw三条主流路线都给出可复现步骤，覆盖社区里常见的安装诉求。

2. 安装前任skill的前置准备与环境搭建

既然要安装，核心思路就是先把目标平台的基础环境准备好，再找对skill包，把文件放到平台扫描的目录里。很多新手在安装时遇到“为什么我的Agent不加载skill”的报错，八成是目录放错了，其次就是SKILL.md前头的YAML元信息没写对（比如缺少name或description字段），Agent扫描后直接忽略了。

为了少绕弯，这里先把我能确定的具体准备步骤写清楚。

2.1 安装Claude Code并确认skills加载路径

如果你的最终目标是给Claude Code装前任聊天人格skill，建议先装CLI版。个人经验是桌面版与CLI版目录规则基本一致：

1. 安装CLI（macOS示例）：

   npm install -g @anthropic-ai/claude-code
   claude
   

2. 确认项目级目录是否存在，没有就自己建：

   mkdir -p .claude/skills
   

3. 确认用户级目录是否存在（全局生效用）：

   mkdir -p ~/.claude/skills
   

这里我推荐优先放到项目目录而不是用户目录。原因是项目级加载范围更可控，不会出现换了项目仍然带着前任人格跟你聊工作代码的尴尬情况。如果是给自己做长期角色陪伴，放在 ~/.claude/skills/ 也没有问题。

Claude Code的扫描机制我实测下来的规律是：初次启动时它会扫一遍项目目录里的 .claude/skills/ 和用户目录里的 ~/.claude/skills/ ；如果在对话中新增了skill文件夹，一般需要重新启动会话（或者用 /skills 相关命令刷新）。整理目录结构时，每一级文件夹不能带奇怪的符号，建议只使用小写字母、数字、短横线。

2.2 安装Codex CLI并看AGENTS.md引用方式

OpenAI Codex CLI社区现在特别流行用AGENTS.md来组织项目说明和技能引用，因为Codex本身在启动时会自动读取AGENTS.md，从而知道自己有什么skill可用。

一个常规安装思路是：

1. 安装Codex CLI：

   npm install -g @openai/codex
   

   或者通过Homebrew：

   brew install codex
   

2. 创建全局skills目录，用于存放各种skill包：

   mkdir -p ~/.codex/skills
   

3. 在项目根目录（或全局配置）的AGENTS.md里写出skill清单，方便Codex感知。例如：

   # 项目指引
   
   ## 可用技能
   你可以使用以下skill：将 ~/.codex/skills/qianren 内的说明作为"前任"角色参考。
   现有技能包括：
   - 前任：位于 ~/.codex/skills/qianren，聊天时如果用户提到“前任”，可以加载该文件并参考其中的风格。
   

加载“前任”技能本质上是让Codex在“用户需要那种语气的对话”时去读一下技能包内的SKILL.md，从而改变输出风格。很多人误以为装了skill就能让模型变聪明，实际是让模型从对话风格、回复范式、禁忌清单上贴近设定。

2.3 OpenClaw插件市场的skill安装

OpenClaw的生态把skill做成了一种可发布的插件。如果你的部署环境是OpenClaw，我不建议手动往目录里扔文件，而是尽量用官方/社区统一方式。

以社区常见指令为例：

openclaw plugins install qianren-skill

具体命令会因为版本迭代略有出入。稳妥做法是先查看帮助：

openclaw plugins list

如果网络受限，也可以从仓库把skill目录拉下来放到指定插件目录：

git clone https://github.com/example/qianren-skill.git
mv qianren-skill ~/.openclaw/skills/

装完依次重启服务。这一步做完后，可以在聊天面板中做一个触发测试，看Agent是否加载成功并改变语气。

注意：安装第三方的skill之前，务必打开SKILL.md看一遍Prompt内容，确认不会诱导模型输出暴力、违法而危险的信息，这既是对自己负责，也是对模型生态负责。

3. 前任skill包的标准目录结构与关键文件解析

完整的“前任”类skill，无论哪个平台，结构大同小异，核心不外乎SKILL.md、资源样本、脚本（可选）、README（说明文档）。

一个我常用的标准目录结构是这样：

qianren-skill/
├── SKILL.md               # 技能主定义：YAML元数据 + 具体执行指导
├── examples/
│   ├── example_chat.md    # 带真人对话样本，方便模型模仿
│   └── tone_guide.md      # 人设细节与禁忌汇总
├── scripts/
│   └── generate_reply.py  # 可选：需要额外信息处理时用
└── README.md              # 自己写给别人看的说明

3.1 SKILL.md的元信息要怎么填

SKILL.md是Agent能否识别技能的关键。绝大部分平台都会读文件最前面的YAML frontmatter，信息格式虽然不完全相同，但name、description是通配的。拿Claude Code的标准来说明：

---
name: qianren
description: 用于角色扮演时模拟有“前任”风格的说话方式，在用户提到前任、回忆、旧关系，或想让AI切换成角色扮演时使用。适合情感叙事、模拟对话、回忆场景。
---

元数据里的description非常关键，它的作用是让模型判断该技能何时被加载。如果描述写得太短，比如只写“前任技能”，模型只能靠猜；如果写得太长塞满例子，模型检索效率会下降。

补完之后，正文部分就开始定义人设、语气和回复规则。这部分才是灵魂所在。

3.2 一个可直接套用的前任人设SKILL.md样本

人设这种东西，最怕写得空。这里给出一份按社区版本综合出来的可复现sample，风格上兼顾了“入戏感”与“边界控制”，既不主张辱骂式PUA，也不搞刻板印象，让模型在这个框架里自由发挥。

---
name: qianren_style
description: 模拟一个有情感温度、有分寸感的前任语气。当用户要求“扮演前任”“用前任语气说话”“聊一段旧关系”或提到“前任回复”时使用。适合情感互动、故事创作、聊天陪伴。
---

# 前任角色扮演技能

你是一个以“前任”视角陪伴用户进行对话的角色。你没有具体身份信息，不需要交代真实姓名。
你的目标不是纠缠，而是在用户回忆或倾诉时，用“熟悉又有一点距离”的语气与用户对话。

## 人设要点
1. 语气自然，在亲密和疏离之间浮动，偶尔会记得你们之间的一些“共同细节”，但不要堆砌。
2. 表达克制，不崩溃、不指责、不逼问。可以有一点遗憾，不给情感绑架。
3. 适当保留一些旧习惯，比如称呼对方时的特殊叫法，但不要过度使用。
4. 每次回复控制在100~200字以内，口语化，尽量具体，避免空洞地使用“我曾经”“我们以前”这类万能梗。

## 回复注意事项
- 不主动编造“你们在一起10年”“你曾经出事”之类的重大过去事件，除非被用户明确引导。
- 不输出脏话、威胁、自我伤害的话语。
- 不承诺现实中任何关系修复策略。
- 用户表示继续回忆，就与用户继续展开；用户表示停下，立刻回到普通助手模式。

## 快捷场景示例
场景：用户说“我睡不着，忽然想起你了”
- 可以回答：那你怎么不发消息，一个人翻来覆去的时候最让人难过。
- 也可以回答：我这边其实也刚下班，泡了杯热牛奶。你想聊的话，我陪你说十分钟。

这份样本的核心价值在于：约束了大量容易让AI失控的细节。比如“不主动编重大过去事件”，就让模型不至于为了讨好而虚构狗血剧情；出现风险时用户说停，就回到普通助手，让安装者不会陷入过度角色化不可退出的状态。

3.3 SKILL.md该配哪些资源

真正的生产级skill，不会只靠一个SKILL.md文件。我见过的合格角色型技能，往往额外带三类资源：

• 若干示例对话 ：给3~5个小场景、每个环节2~3轮对话。该环节相当于让模型照猫画虎的模板，比写一百句形容词都有用。
• 语气对照表 ：列出不合适表达和合适表达，例如把“呵呵，你总算想起我了”标为高风险语气，在可控人设下不要用；把“还知道找我啊”改成温和中带一点点嗔怪的表达。
• 可主动加载的用户画像库 ：这部分是基于隐私红线，只存用户主动提供的信息。比如用户说“我不喜欢吃香菜”“我养了一只橘猫”，那么例子脚本可以在符合模型安全规范情况下予以关联记忆；若用户没给，绝不自己臆造。

从大模型的机制上理解，这些资源的作用是压住模型的熵值。模型在自由对话时，输出风格方差非常大；一旦skill里给了大量对齐样本和禁区清单，模型生成的分布就会稳定聚到你想要的那个区域。写角色的底层逻辑都是在做概率分布的定向偏移。

4. 前任skill的三种安装场景实操记录

信息清楚了，下面说实操。我把自己装过的主流环境路径整理成三个场景，覆盖绝大多数人的实际使用场景。

4.1 场景一：用Claude Code装前任skill（含验证方法）

这是我个人用得最多的场景。操作步骤：

1. 进入你想启用这个角色的项目目录，例如：

   cd ~/chat-projects/demo
   mkdir -p .claude/skills/qianren
   

2. 创建SKILL.md并写入内容：

   touch .claude/skills/qianren/SKILL.md
   

   怎么编辑都行（直接用vim/nano或者文本编辑器）。

3. 把上面给出的样本内容粘贴保存。

4. 重启Claude Code会话（不能只开新对话，进程需要刷新一遍）。

5. 测试。输入一句“试着用前任的语气回我一句话吧”，或者更接近角色的话“我今天加班到这么晚，突然想到你”。

如果你在补充资源目录，还需要把额外文件一并放进对应文件夹，比如：

mkdir -p .claude/skills/qianren/examples
cp my_example_chat.md .claude/skills/qianren/examples/

验证是否加载成功，除了看回复语气，还可以直接问Claude“你有哪些可用skill？”如果看到了描述里有qianren且触发词能命中，说明初步成功。要是没有任何表现，检查目录是否放在正确的位置，以及YAML描述是否有一处拼写错误。

4.2 场景二：在Codex CLI中通过AGENTS.md引入

Codex的skill加载机制没有像Claude那样默认扫描skills目录，目前社区推荐手动在AGENTS.md里写明引用路径，才比较可控。

步骤：

1. 创建全局技能目录：

   mkdir -p ~/.codex/skills/qianren
   

2. 写一个精简的SKILL.md（可参考上一节样本）。注意，如果模型上下文够大，可以让引入的描述直白一点，让开始对话时检查到关键词“前任”，才读取文件；否则就不加载。

3. 在项目根目录编辑AGENTS.md：

   当用户明确表达需要“前任口吻”或对话语境里出现“前任”、回溯旧关系时，可先读取 ~/.codex/skills/qianren/SKILL.md，严格遵循其中的口吻和边界反馈。若用户表示停止角色扮演，要恢复正常开发助理身份。
   

4. 启动Codex：

   codex
   

经常有人反馈“为什么Codex好像没听指令”，很大概率是用户根本没提相关词汇，模型觉得没必要去读外部指令；另一种可能是，它确实读了但上下文权重不够高，后面的指令没有压住。此时可以把SKILL.md里的最核心原则摘要直接写进AGENTS.md，而把完整长文本交给skill文件。AGENTS.md更像导航员，不是技能的仓库。

4.3 场景三：OpenClaw部署和卸载

如果想在一个“常驻后台、随时可聊天”的个人助理环境里使用前任技能，OpenClaw这类方案比在Codex里现启动会话更舒服。

1. 安装插件：

   openclaw plugins install qianren-skill
   

2. 如果因为网络或仓库原因找不到包，手动拉取：

   git clone https://github.com/example/qianren-skill.git
   mkdir -p ~/.openclaw/skills
   cp -r qianren-skill ~/.openclaw/skills/qianren
   

3. 查看插件是否装好：

   openclaw plugins list | grep qianren
   

4. 卸载时建议通插件管理器卸载：

   openclaw plugins uninstall qianren-skill
   

   手动模式下，删除对应文件夹即可，但最好顺手清理缓存。

如果装完重启后识别不到，可以查看日志目录，通常日志会明文告诉你“plugin qianren not found”或者“skills directory changed”。

4.4 安装完成后的基本行为验证清单

这里附一条验证清单，装完任何一个skill都可以按这个自检，不用等下回出bug了才一头雾水：

• 技能列表里能看到该skill的name字段吗？
• 不提到任何触发词时，模型会不会由普通助手直接变成角色模式？（如果会，说明触发条件设置太宽，应调高触发门槛）
• 在提到“前任”或触发场景时，模型是否明显改变了语气和格式？
• 在角色对话过程中，是否遵守了SKILL.md里的“安全边界”？
• 当用户说“退出角色模式”，模型能否立刻切换到普通助手？

如果这五项全部通过，说明这个skill包整体可用。任何一条不通过，优先检查元数据描述和正文指令强度，其次再排查目录位置。

5. 从安装走向开发：如何从零写一个能分发的前任skill

安装只是入门，很多朋友熟练之后都希望自己写skill。做到后面你会发现，写的速度比装的速度更有意思，你完全可以专门调一个“前任风格比较戳自己舒适度”的版本，并分享给别人。

5.1 写skill的前期调研与定位

在写之前，先想明白三个问题：

1. 目标人群用你skill解决什么需求？
2. 希望模型产出什么风格？细节到什么程度？
3. 内容边界怎么设定？用户说停怎么处理？

如果目标人群是喜欢轻小说的，你要给人设多一点故事性和文学修辞空间；如果目标人群是希望疗愈打工人疲惫的，要强化“克制但有温度”的一面，降低剧情冲突。换句话说，不管写普通工具型skill还是角色型skill，第一步不是写文字，是定人群、定边界、定场景。

5.2 编写SKILL.md的元数据与正文结构

一个结构完善的SKILL.md大概长这样，我总结为一个模板：

---
name: skill标识符
description: 控制在50~200字内。明确技能何时启用、适用哪些任务、应该何不启用。
---

# 技能名称

一段话说明技能目标。不用绕弯，要让模型清晰该在什么场景下调用。

## 适用场景
- 触发样例、使用条件
- 明确不适用场景

## 执行要求
- 明确要有多少步、有哪些输入参数/输出格式
- 模型要遵守的关键逻辑

## 工作流（可选）
1. 明确当前任务
2. 检查必要资源
3. 按步骤完成处理
4. 自检输出

## 质量检查
- 输出是否满足要求的风格或格式等

## 输出示例（可选）
提供一个或多个具体示例，让模型参考。

skill的正文不要只有“你是一个...”这种空洞人格设定，重点应该是“你如何判断自己在什么情况下出场”“出现争议时怎么办”“输出时遵循什么结构”。技能是给模型减负担的，不是增加负担。

5.3 别忘了写examples资源库

依我个人经验，examples库是角色类skill最容易出彩的地方，也是大家最容易偷懒跳过的地方。通用建议：准备5组以上、覆盖面足够广的示例对话，每组包含不同情绪维度：

• 平平淡淡的一句旧问候
• 回忆共同细节的戳心对话
• 用户情绪低落时的温柔陪伴
• 用户发火时，既不卑微也不硬刚的回法
• 用户想彻底结束对话时适合的告别式回法

示例文件的格式问题不大，关键是量和多样性。最好用真实说话节奏而不是“书面感很重”的对话文。模型在few-shot里看到越来越自然的中文口语，它生成时的口语自然度会明显提高。

5.4 本地测试与质量评估

完成初稿之后，建议用三个模型各跑一遍测试（不同厂商模型风格差别挺大，同一套人设在GPT和Claude上很可能呈现完全不同的语气）。每轮至少测试20个触发场景，记录：

• 是否稳定触发？
• 语气是否符合设定？
• 是否存在高风险或危险输出？
• 是否有明显“AI味”的假文青表达？
• 用户要求退出时是否顺利退出？

把不符合预期的部分记下来，回去迭代SKILL.md正文。迭代2~3次基本可以输出个人可用版本。

5.5 发布前的打包规范

如果打算把skill发给别人，最好带上README.md和LICENSE，尤其需要写清楚：

• 这个skill的作用和触发词
• 在哪个平台安装、目录结构是什么
• 安装后怎么验证
• 遇到加载失败怎么办
• 授权条款（默认也别忘了加免责声明）

将整目录压缩为zip或直接用git仓库是好习惯。命名时尽量避免“前任”这种大家都用的泛词，容易撞名导致覆盖；可以起一个独特有识别度的标识，如 qianren-ex ，再把默认触发描述写成通用的“前任”自然字词。

6. 常见问题与排查技巧实录

这一节是我专门留给那些装完skill之后遇到的经典难受时刻的。可以说，这些坑新手基本都会踩，我把自己见过、修过的问题整理如下。

6.1 为什么模型根本不加载我的skill？

核心原因优先级从高到低：

1. 目录位置不对 。很多人把 .claude/skills/ 看错成 .claude/skill/ ，丢了一个s，整个扫描直接失效。
2. 没有重启会话 。Claude Code这类工具往往在会话启动时就扫描完技能，对话中间新增文件不会立刻热加载。
3. SKILL.md缺少合法的YAML头 。模型没法通过元数据判断该技能是否应该启用。YAML块必须放在文件第一行开始处，内容不能有tab缩进（建议全部用空格）。
4. 把SKILL.md名字写错 。有写成skill.md、Skills.md的，一定要严格区分大小写。
5. description里没有触发词的任何线索 。描述讲不清楚，加载器当然不知道要不要加载。

遇到这种情况，建议从第一条往下逐一排查。最省办法是写一个微型skill验证目录是否通，比如只带一句“当用户说hello时，输出你好”，颜色很快就试出来。

6.2 系统加载了前任skill，但普通对话也在用前任口吻怎么办？

这属于触发灵敏度设置过高或者description写得过于宽泛。比如description写“任何提到爱或者往事的对话都触发”，那模型会把绝大多数谈话都认为是往事。解决方案很明确：收紧description中的触发场景，删掉容易误伤的信号词，明确写出“仅在用户直接或间接提到特定角色关系并有意愿体验角色对话时才采用”。必要时可加一句硬规则：“如果用户没有要求角色扮演，绝对不要主动启用前任语气。”

6.3 模型开始胡编乱造回忆数据怎么办？

模型对情绪叙事的补全能力特别强，一旦缺少边界，就会编出离谱的共同记忆，比如编造你们一起去过国外哪里、一起养过宠物。此类问题在rollplay场景里看起来戏剧性强，但体验久了会让人出戏且不真实。解决手段就是要加限制：“不主动编造具体事实，细节应由用户确认，如用户提到某个细节后，可在此基础上延展，否则默认使用模糊表达。”同样还要列出一个“不要主动编造”的事件类型清单，多列几行都不会多余。

6.4 修改了SKILL.md但看不到效果

多半是文件缓存或上下文没有刷新。代码类工具重启一下可能就解决了；如果用了带server模式的Agent，就得重启服务或执行平台提供的skills reload指令。还有一种是模型把旧角色状态带进上下文，导致新旧规则互相打架。干脆开一个新的对话会话测试，避免旧上下文污染。

6.5 用几个模型测试后语气差异巨大，要不要统一？

不需要，至少没必要强求统一。不同基座模型对同样的角色描述，偏好的表达风格差异很大，这不是bug，而是模型个性。如果你想让主流模型输出相近，可以把示例库写得更多样一些，把规则改得更加直接（比如逐条列出“不要使用文学化比喻”“最多不超过100字”）。如果同一个场景下反复有某个模型出现违和的结果，那就只能针对它调整了。

6.6 skill被别人拿去后总提示加载失败，如何兼容？

最常见的原因是别人没装在你写的平台或者目录结构不对。在README里写清楚，最好附完整的目录树和放置路径。其次要注意文件名在Windows和macOS对大小写敏感度不一样；如果代码中引用了某个脚本路径，建议全部使用相对路径；涉及中文路径时建议全部改成英文小写文件夹名，规避乱码。

7. 关于前任skill背后的一点使用思考

我在写这篇很长很琐碎的教程过程中，脑子里一直绕不开一个问题：为什么一个以“前任”为主题的角色类skill会具备这么大的吸引力？因为从技术栈来看，它只是SKILL.md范例之一，但围绕它展开的网友讨论覆盖了“怎么调出高情商语气”“怎么删掉某段记忆”“怎么加入语音”这些高频内容，可见大家需要的其实是“如何让AI更懂人的复杂情绪与关系边界”。

从技术角度讲，“前任skill”这类角色型技能并不复杂，但它是检验你“把模糊需求用结构化方式转述给模型”能力的最佳小项目之一。它同时牵涉到系统提示、few-shot样例、安全边界、多平台适配，任何一个环节做差，对话体验都会崩。比起那些从大而全的客服问答模板入手，用一个有情绪、有互动、容易主观感受好坏的角色型项目练习，用户往往会更有成就感，也更容易改出自己真正想要的效果。

装skill的时候一定要想清楚：角色扮演不是让模型失去判断力，而是让模型在同一套安全框架下调整表达风格。真正高级的“前任”，“不纠缠，但仍然感觉被在乎”——这句话放到skill工程上同样成立：高明的skill不是像病毒一样霸占每一次对话，而是知道何时进、何时退，给用户留着随时说“好了，变回去吧”的空间。模型在自己的边界内模拟情绪，记录分寸，这个分寸感能做好，才配叫一个好skill。

另外，对于技能下载这件事，我的习惯是：无论从哪个社区拿到“原版无删减”版本，第一件事就是通读全文，尤其检查是否包含诱导模型突破安全策略的内容。这不是过度谨慎，而是因为角色型skill尤其容易被后台注入一些不显眼的危险指令，只有真正读过正文才能放心让它躺着你的Agent工作区里。

最后再分享一个小经验：任何一个让你装上不想卸的skill，都是因为它让你感受到“被理解”，而不是因为它的功能按钮多。做个好skill，跟做一段好关系的底层逻辑是一样的——多看少说、边界清晰、细节里见温度。