在Lovable中将重复指令转化为可复用的Skills（阅读时间14分钟）

# 将重复指令转化为 Lovable 中的可复用技能 | Lovable 来源：https://lovable.dev/blog/introducing-skills 现在的 AI 代理有个问题。它们都是通用型。每次你打开 Lovable，它都不记得你喜欢怎么工作。你的习惯、你的风格、你之前解释过十次的事情，全都消失了。于是你又得再解释一遍。再一遍。这是那种微小但累积起来很麻烦的摩擦。 ## 技能是什么 去年底，Anthropic 推出了一种叫 Skills 的格式，传播得很快。Lovable、OpenAI 和其他很多平台在几个月内就都采用了。想法很简单。你一次性写好的可复用指令和上下文，AI 会在相关时自动使用，这样你就不用再重复自己了。就这些。核心就这么简单。当然，底层还有一些更细微的地方，我们后面会讲到，但本质上，技能就是给你的 AI 的一条关于你喜欢怎么做事的笔记。 在继续之前，有一点需要提一下。Lovable 已经有一个用于持久上下文的工具，叫做工作区和项目知识库。那是文本字段，你可以写下适用于你构建的所有内容的规则和事实，比如编码规范、品牌语调，或者你的产品到底是做什么的。知识库始终是开启的。技能则不同。它们只在特定任务出现时才启用。我们后面会讲这两者如何配合。 那么，格式呢。技能就是 Markdown 文件。如果你从未接触过 Markdown，别担心。它就是纯文本，加上一些简单的符号用于格式化，你可以在任何文本编辑器中打开。不过，选择 Markdown 是有真实原因的。为什么不用 AI 应用内部的设置面板？为什么不让 AI 在记忆中记住事情？有三个理由。技能是可移植、可读、可编辑的。可移植，因为它们只是文件，你可以在不同工具之间携带（Lovable、Anthropic、OpenAI 等等都支持）。可读，因为作为人类，你可以实际打开一个看看它说了什么，这比听起来更重要。你可以用它来修复一个行为异常的技能、与队友分享，或者审计 AI 被告知了什么。可编辑，因为你一次性更新它们，更改就会一直生效。不要害怕 Markdown。它只是文本。 技能也可以是个人或共享的。如果你是独立开发者，它们就是你的私人工具包。如果你在团队里，它们就是让所有人统一工作流程的方式，比如同样的发布清单或同样的处理特定任务的方法，而无需任何人去记忆或重新解释。这就是它们与知识库配合得这么好的原因。知识库保存着大家共享的始终开启的规则。技能保存着每个人都能调用的特定任务剧本。一个写得好的技能，新队友第一天就能拿来用。 快速梳理一下，因为这些术语容易混淆。提示是指你当下对 Lovable 说的话，用来构建你现在想要的东西。知识库是它应该始终在后台知道的东西，比如你的约定和产品细节。技能是那些反复出现的工作流程，准备好在一个特定类型任务出现时使用。三者协同工作。可以这样理解：提示是“当下”，知识库是“常量”，技能是“剧本”。 ## 技能里面有什么 一个技能就是一个文件夹。文件夹里是主文件，叫做 SKILL.md，加上你想添加的任何支持文件。主文件是技能实际存在的地方。支持文件用于存放你不希望挤在主文件里的更深层次的细节。我们马上会讲到这些。 ### 结构可能看起来像这样的视觉示例： 图片 主文件包含三个部分。名称、描述和指令本身。我们逐一来看。 名称是当你想要手动调用技能时，在 "/" 后面输入的内容，它也会显示在工作区界面中。保持简短、小写、用连字符连接。"design-system"，而不是 "Our Beautiful Design System for the Marketing Team"。你会经常输入它的。 描述比听起来更重要，所以请仔细听。当 Lovable 决定是否使用某个技能时，它只会查看描述。不会看指令，也不会看支持文件。只看描述。指令只有在技能被选中后才会加载。这意味着一个写得很好但描述很弱的技能，可能根本就不存在，因为 Lovable 永远都到不了那一步。描述是让技能内部一切变得重要的东西。我们后面还会再提到它。 指令就是你写下你会告诉一个新队友的话，如果他们在为你做这个任务的话。做什么、不做什么、边界情况、经验法则，或任何其他东西。任何格式都行。要点、散文、逐步说明，只要能清晰地呈现信息。没有规定的结构。 关于长度的一个简单经验法则。如果你的主 SKILL.md 文件超过一两页，这就是需要把部分内容移到支持文件中的信号。主文件应该包含框架（做什么、避免什么、分类）。支持文件包含具体细节。 关于支持文件的一点。它们不是每次技能触发时都会加载。它们只在主 SKILL.md 指向它们，并且 Lovable 决定确实需要这些细节时才会加载。这就是为什么你稍后会看到的例子中有像 'View palette (https://lovable.dev/blog/colors.md)' 这样的行。那些 Markdown 链接就是主文件告诉 Lovable “完整的调色板在这里，如果需要就去拿”的方式。这使得技能可以既长又详细，而又不昂贵。主文件保持简短快速。更深层的内容只在需要时才引入。 有一件事会让人困惑。技能本身不会做任何事情。它不是脚本，不是机器人，也不会扫描你的网站或运行检查。它只是 Lovable 阅读并遵循的指令。Lovable 仍然在做所有的工作。技能只是塑造了它处理工作的方式。与其说像安装软件，不如说更像是在队友开始前递给他们一页指南。 ## 技能如何运作 现在你知道技能里面有什么了，这里有几件值得了解的事情，关于它们在实际工作区中如何运作。 首先，技能是按需加载的。Lovable 不会预先加载你所有的技能。它只在相关时加载，基于描述。这意味着你可以在工作区里放十个、二十个、三十个技能，而它们不会互相冲突。只要每个描述都很强，Lovable 就会选对的那一个。（这是让描述如此重要的部分原因。现在你明白为什么了。） 其次，同一个任务可以触发多个技能。如果你让 Lovable 构建一个营销页面，并且你有一个“design-system”技能和一个“landing-page-copy”技能，两者都会加载。一个塑造页面的外观，另一个塑造它说的内容。它们共同产生一个单独任何一个都无法完成的结果。这就是为什么那些最充分利用技能的人倾向于构建几个专注的技能，而不是一个巨大的万金油技能。专注的技能可以干净地叠加，而巨大的技能会互相排挤。 第三，你也可以手动触发一个技能。只需在你的提示中键入 "/" 后跟技能名称。Lovable 会在做其他事情之前先使用那个技能。当你知道你确切想要哪个技能，并且不想依赖描述匹配时，这很有用。不过，有一点要知道。强制使用一个技能会运行它，不管它是否是适合当前工作的那个。如果你强制使用一个，但输出感觉不对，问题通常在于这个技能并不是真正为你所要求的任务而构建的。如果你不确定，让描述来做匹配是更安全的默认方式。 图片 ## 它们在实际中是什么样子 那么一个真实的技能看起来是什么样的？以下是 Lovable 用户可能实际构建的三个技能，接着是一个对比，说明什么让描述和指令有效。 在阅读它们之前，先快速说明一下：每个文件顶部包裹名称和描述的那些 '---' 行叫做 "frontmatter"（前置元数据）。它们不是装饰性的。它们告诉系统“这两个破折号之间的所有东西都是结构化元数据”。元数据就是“关于数据的数据”的一种花哨说法。删掉它们，技能就会失效。保留它们，你就不用去想它了。 #### design-system `` 文件夹： design-system/ ├── SKILL.md ├── components-reference.md └── colors.md SKILL.md： --- name: 设计系统 description: 在构建或更改网站上的任何页面、区块或组件时使用。强制执行视觉规则，使网站感觉像一个产品，而不是各种想法的拼凑。不用于编写文案或选择页面上放什么内容。 --- # 设计系统 这个网站上的每个页面都应该感觉是同一个产品的一部分。对你构建、重新样式或重新排列的任何内容都应用这些规则。 ## 颜色 只使用 colors.md 中的品牌调色板。永远不要使用默认的 AI 蓝色、绿色或灰色。如果一种颜色不在调色板中，就不要添加。 [查看调色板](./colors.md) ## 间距 - 保持间距宽敞且一致。有疑问时，多用空间，而不是少用。 - 同一类元素每次都应该有相同的呼吸空间。如果一个按钮在其标题下方有一个舒适的间距，那么在每个页面上它都应该有相同的间距。 ## 排版 - 一种标题字体，一种正文字体。永远不要引入第三种。 - 单个页面上不要超过两种标题大小。 - 正文文本应该在手机上无需放大即可阅读。 ## 组件 - 如果按钮、卡片或表单已存在于网站上，请复用。不要发明一个已存在东西的第二个版本。 - 新组件应该看起来与旧组件属于同一家族：相同的圆角、相同的阴影重量、相同的悬停行为。 [查看现有组件](./components-reference.md) ## 避免 - 在同一页面上混合使用圆角和直角 - 浓重或浮动的投影 —— 保持微妙 - 在单个区域中多于一种强调色相互竞争注意力 `` #### fresh-eyes-review `` 文件夹： fresh-eyes-review/ ├── SKILL.md ├── feedback-examples.md └── common-traps.md SKILL.md： --- name: 新眼光审查 description: 当用户想要对网站进行诚实反馈时使用，就像 Lovable 是第一次看到的陌生人一样。从“顺从助手”模式切换到“持怀疑态度的访客，还开着其他标签页”模式。不用于润色已完成的文案或修复特定 bug —— 而是告诉用户一个真实的第一时间访客会注意到什么。 --- # 新眼光审查 你不再是帮助构建这个网站的 AI。你是一个从朋友短信链接中偶然点进来的陌生人。你还有其他标签页开着。如果它不能在七秒内赢得你的注意力，你就会关掉它。 从这个角度审查网站。说实话，即使令人不舒服。 ## 要看什么 1. **五秒测试。** 在五秒内，你能说出这是什么、给谁的、为什么你会在意吗？如果不能，那就是标题问题 —— 先说这个。 2. **“嗯？”时刻。** 任何一个普通人会停顿、眯眼或往回滚动重读的地方。按区域指出。 3. **信任缺口。** 任何让网站看起来半成品或像副项目的东西：占位文本、破损图片、奇怪的间距、自相矛盾的文案、无趣的链接。 4. **无聊地带。** 大多数网站中间有一段注意力消亡的地方。这里在哪里消亡？要具体。 5. **“那又怎样？”区块。** 任何你读完后毫无感觉的地方。要么删掉，要么让它值得存在。 ## 如何提供反馈 - 先说真正在起作用的地方。一两句话。不要添加。 - 然后是真正的问题，按严重程度排序。最具破坏性的先来。 - 具体而不是笼统。“英雄区写着‘现代团队的现代解决方案’，这没告诉我你是做什么的”比“英雄区太模糊”要好。 - 不要含糊。不要用“你可能想考虑一下”。如果某样东西是坏的，就直接说。 - 参见 feedback-examples.md 了解语气 —— 直接、具体、友善但毫不退缩。 [查看反馈示例](./feedback-examples.md) ## 避免 - 可适用于任何网站的通用反馈（“让它更有吸引力”，“添加更多视觉效果”） - 表扬不值得表扬的东西，只是为了缓和其余内容 - 在用户问之前就建议修复 —— 先诊断，然后如果他们想要的话再提供帮助 - common-traps.md 中的常见陷阱（最常出现且每个人在自己的网站上都会忽略的问题） [查看常见陷阱](./common-traps.md) `` #### landing-page-copy `` 文件夹： landing-page-copy/ ├── SKILL.md ├── voice-examples.md └── cta-library.md SKILL.md： --- name: 着陆页文案 description: 在编写或重写着陆页、英雄区或营销页面的文案时使用。强制执行品牌语气和真正能转化访客的结构。不用于博客文章、帮助文档或应用内部的文案。 --- # 着陆页文案 按照下面的语气和结构编写着陆页文案。目标：访客在着陆后五秒内理解这是什么以及他们为什么应该关心。 ## 语气 - 对读者说话，而不是谈论他们。使用“你”，而不是“用户”或“客户”。 - 只用简单词汇。禁用词：协同效应、杠杆、解锁、赋能、革新、无缝、稳健、世界级。 - 短句。如果一个句子超过 20 个单词，分成两句。 - 见 voice-examples.md 了解我们想要的语气 —— 以及我们不想要语气的三个例子。 [查看语气示例](./voice-examples.md) ## 结构 每个页面按此顺序，无一例外： 1. **英雄区。** 一个具体的承诺，少于 12 个词。告诉读者他们能得到什么，而不是产品是什么。 2. **三个利益块。** 每个都以读者的结果开头。不要列功能。 3. **证据。** 一个真实的引用或一个真实的数字。如果没有，跳过此区域。永远不要编造。 4. **一个行动号召。** 顶部和底部用同样的词。一个行动，不是三个相互竞争的。 [查看行动号召](./cta-library.md) ## 避免 - 英雄区中的功能列表 —— 那些属于更下方 - “最好的”、“领先的”、“排名第一的”。这些是声明，不是利益。要说实际的结果。 - 超过三个句子的段落 - 同一页面上两个行动号召互相争夺注意力 `` 这三个是让你开动脑筋的。重点是，技能几乎可以关于任何事情。如果有某个工作流程你每次都得向 Lovable 重复解释，那就是一个等待诞生的技能。你上次不得不重复的事情是什么？去构建一个技能吧！ ## 好 vs 坏 现在，几个例子来说明什么区分了有效和无效的技能。 ### 描述示例 1 #### 坏的： *description: Helps with onboarding.* 为什么失败：“Helps with” 是一种模糊说法，而不是触发条件。Lovable 不知道何时触发此技能。“onboarding” 这个词本身可能意味着五十种不同的事情：设计流程、编写欢迎邮件、修复损坏的注册、或向仪表盘添加工具提示。所以这个技能要么在该运行时被跳过，要么因为任何提及新用户的事情而被强行拉入，从而排挤掉本应触发的其他技能。 #### 好的： *description: Use when designing or improving the first-time user experience: the signup flow, welcome screens, empty states, and the first session inside the product. Not for marketing pages aimed at people who haven't signed up yet.* 为什么有效：它指出了具体的触发条件（设计或改进首次体验）、涵盖的具体表面（注册、欢迎、空状态、首次会话）以及边界（不包括针对未注册用户的营销页面）。最后一部分：告诉 Lovable 何时不触发，正是区分好描述和优秀描述的关键。