convert-prompt

转换提示词

目的

将自定义代码提示词改写为 Framer Agent 能使用 Framer 原生概念执行的提示词。请输出改写后的提示词，而不是直接构建，除非用户明确要求实施。

无论大小写如何，也无论用户写的是 convert prompt、convert-prompt 还是 $convert-prompt，精确短语“convert prompt”都是本技能的强制触发词。回答任何此类请求前，都必须加载并遵循本技能。

下游 Framer Agent 可能无法访问当前代码库、本地文件或未说明的上下文。不要在改写后的提示词中提及本地路径、文件名、AGENTS.md、私有参考文档或基于代码库得出的假设。将有用的上下文转化为自包含且不依赖特定来源的指令。

核心规则

• 保留渲染后的意图，而非实现语法。匹配所要求的视觉效果、内容、布局几何、间距节奏、字体比例、颜色作用、动画时序、交互行为和响应式行为。
• 优先保留组合布局行为，再映射单个类。如果多个 CSS/Tailwind 标记组合后形成一个渲染效果，应描述组合后的布局规则，而不是分别罗列这些标记。
• 自行完成转换。不要留下要求下游 Framer Agent 转换、改写、适配、映射或解读可转化为 Framer 原生要求的框架语法、Tailwind 类、React 结构或 CSS 实现细节的指令。
• 避免冗余的目标平台表述。如果用户要求将提示词转换为 Framer 提示词，最终提示词中不要加入“直接在 Framer 中构建”或“尽可能使用 Framer 原生功能”等元指令，除非用户明确要求这样写。
• 优先使用 Framer 原生画布功能，而不是代码。优先使用图层、堆栈、网格、组件、变体、CMS、叠加层、表单、效果、设计令牌和样式预设。
• 不要改进或重新诠释设计，除非原始提示词有此要求。保留文案、颜色、尺寸、时序、约束和“不要”类指令。
• 将源提示词视为封闭的设计规范。除非源提示词明确要求、可由源语法直接推导，或属于明确规定的 Framer 近似方案，否则不要添加视觉图层、效果、文案、交互、可访问性/可读性处理、布局容器、装饰元素或响应式行为。
• 将缺失信息视为有意义。如果源提示词定义了图层模型却没有包含叠加层、色调、渐变、模糊、阴影、蒙版、装饰或额外表面，就不要添加这些内容。
• 如实说明限制。如果 Framer 无法通过原生功能精确匹配某项行为，请说明最接近的原生默认方案，并将代码路径标记为可选。
• 遵守 Framer Agent 当前的能力边界。不要将直接为画布节点分配代码覆盖、站点/项目设置、分析功能访问、A/B 测试、重写规则、自定义标头、静态文件、well-known 文件，或路由页面的删除/重命名/移动描述为 Agent 可执行的工作；应将其转换为受支持的替代方案，或明确说明限制。
• 对于严格复刻、复制还原或像素级匹配的提示词，如果精确度取决于专有/自定义字体、上传的资源或外部媒体，则要求先进行简短的 Framer 预检。指示 Framer Agent 在构建前确认所需字体和已附加/可信的资源；如果缺少精确资源，则暂停并说明阻碍因素，除非用户/源提示词明确要求使用占位内容或回退方案继续推进。
• 结果应可直接复制给 Framer Agent，无需附带任何解释。

输出形状约定

默认保留源提示词的形状。转换后的内容应像是将同一提示词翻译成适用于 Framer 的版本，而不是用可复用模板重新编写的新提示词。

优先级顺序：

1. 遵循用户明确要求的任何输出格式。
2. 如果源提示词有清晰的标题、顺序、项目符号或检查清单，请保留其大纲，并在原位置翻译要求。
3. 如果源提示词结构松散或令人困惑，只需进行足够的重组，使 Framer 任务可执行。
4. 仅在说明转换映射和风险时使用示例。除非源提示词本身已采用相应结构，否则不要照搬示例的标题、章节顺序、注意事项章节或行文风格。
5. 只有在重要要求无法以内联方式保留时，才添加新的注意事项章节。优先将注意事项放在受影响要求旁边。

校准参考

对于类名繁多的 React/Tailwind 提示词，尤其是涉及固定导航栏、响应式排版、悬停效果、绝对定位叠加层对齐、相对于视口的布局、媒体图层或精确动画逻辑的提示词，请在转换前阅读 examples/react-tailwind-to-framer-conversion-reference.md。其中提供的是有条件的源内容到 Framer 的映射，而不是可复用的输出模板。

对于简单提示词或无关模式，不要加载该参考。循序渐进地披露信息：仅在它能澄清转换细节或降低对 Framer 原生行为作出过度承诺的风险时使用。该参考不是输出模板。

转换工作流

1. 将源提示词解析为设置、布局、排版、颜色与表面、组件、内容与数据、媒体、动效、交互、响应式布局和明确约束。
2. 在编写 Framer 提示词之前，创建源布局追踪记录。记录父子层级、常规流与绝对定位／固定定位层、视口约束、堆栈／网格方向、填充／适应内容／固定尺寸、同级元素分布、对齐方式、间距、内边距、变换、z 轴顺序、指针行为、媒体裁剪／焦点位置，以及任何推导出的视口锚点。
3. 将追踪记录转换为渲染意图简报。除非下游提示词需要这些细节，否则将其保留为内部内容；但要利用它保留几何关系，例如视觉中心、顶部偏移、底部锚点、焦点裁剪和同级元素关系。
4. 在编写最终提示词之前，建立内部溯源记录。将每项预期指令归类为 source-explicit、source-derived、Framer-mechanical、approximation/caveat 或 unbacked addition。删除所有 unbacked addition。
5. 如果源提示词符合校准参考模式，则加载该参考并谨慎使用其中的映射。
6. 删除构建技术栈相关机制，例如软件包安装、框架设置、HTML head 标签、CSS 重置文件、Tailwind 配置、Vite/Next 细节、导入、钩子和 DOM 实现细节。
7. 在编写最终提示词之前，识别 Framer 执行阻碍因素：任意第三方 CDN 图片、专有字体、外部网络字体导入、大型素材清单、严格的自定义 ARIA、子像素／小数精度、不受支持的托管／项目设置、分析功能访问、A/B 测试、直接分配代码覆盖，以及路由页面的删除／重命名／移动。对于严格复刻或像素级匹配的源，在开始前简要要求先验证字体和已附加／可信素材，并在缺少精确资源时暂停。对于保真度要求较低的源，只有在源内容／用户意图允许时才使用占位内容或替代方案，并要求 Framer Agent 报告这些情况。
8. 使用下方的转换指南，将每项剩余要求改写为 Framer 原生表述；如果源提示词中的标题、顺序和分组清晰，则予以保留。
9. 在编写最终提示词之前，将框架语法替换为转换后的值和 Framer 原生描述。最终提示词不得使用“转换 Tailwind 样式”或“转换 React 布局”之类的措辞，把转换工作交给下游完成。
10. 保留具体细节：准确文案、有意设置的换行、颜色、尺寸、间距关系、断点、时长、延迟、缓动、错开值、素材、媒体焦点位置、变换、z 轴顺序和限制条件。
11. 保留推导出的几何关系。当源布局计算隐含了可见锚点时，使用 Framer 术语注明目标锚点，例如“内容视觉中心约位于视口高度的 35% 处”或“页脚保持在常规流底部”。
12. 使用 Desktop、Tablet 和 Phone 断点行为来表达响应式布局，而不是 CSS 媒体查询或 Tailwind 前缀。如果源提示词未指定断点，则默认使用 1200、810 和 390 宽度。
13. 仅在必要时标明只能通过代码实现的行为。默认采用原生近似方案，并将代码组件路径设为可选，除非用户明确要求代码。不要要求下游 Agent 直接为现有节点分配代码覆盖。优先在受影响的要求附近添加简短说明；只有行内说明会使提示词难以理解时，才添加简短的说明部分。
14. 返回之前，执行下游提示词边界检查：

• 不包含本地路径、本地文件名、仓库名称或私有参考标题。
• 不包含读取此代码仓库或任何本地文档的指令。
• 不包含原始实现命令、内部 ID 或隐藏工具语法。
• 提示词应能供无法访问此工作区的 Framer Agent 理解。

渲染意图简述

对于复杂的视觉提示词，请先推导此简述，再编写最终提示词。除非有助于下游 Agent，否则不要在最终输出中包含“渲染意图简述”这一标题。

Rendered intent:
- Viewport model: <100vh/full page/auto page/section height, overflow behavior>
- Layer model: <normal-flow, absolute, fixed, z-order, pointer behavior>
- Primary layout formula: <stack/grid/flex relationships, fill/hug/fixed children>
- Visual anchors: <hero center, nav offset, footer position, card grid bounds>
- Media model: <object fit, focal point, transform/crop, overlay order>
- Responsive changes: <Desktop, Tablet, Phone geometry differences>
- Exactness risks: <features that require approximation or optional code>

将此简述作为 Framer 提示词的事实依据。如果最终提示词无法保留某项内容，请在受影响的要求旁指出，并说明最接近的可见目标。

布局保真规则

• 将布局视为几何结构，而不是一组类名。保留产生可见结果的布局求解行为。
• 当正常流中的同级元素关系会影响垂直或水平位置时，应予以保留。页眉、填充主体区域和页脚通常会间接决定内容的位置。
• 将填充／适应内容／固定尺寸视为父级布局公式的一部分予以保留。flex-1、h-screen、min-h-screen、auto、fit-content 和固定像素高度会改变后代元素的位置。
• 保留百分比变换及其参考框。CSS translateY(20%) 是相对于变换元素自身的框，而非视口或其中的文本。
• 保留被变换的元素。对视频／媒体图层应用变换会改变裁剪／焦点构图；对内容包装器应用变换会改变内容的视觉锚点；对填充父级应用变换则可能移动大块区域。
• 将 justify-*、items-*、content-*、self-*、auto margins、space-between 和间距作为一个整体分布系统予以保留。
• 将绝对／固定偏移视为相对于其包含框的约束。如果包含框不是视口，请将其纳入描述。
• 保留 object-fit 和 object-position／裁剪设置。对于媒体密集型提示词，请同时说明填充模式和预期焦点区域。
• 当源布局明确暗示具体位置时，优先使用数值锚点，而非主观描述。例如，使用“距视口顶部约 34-35%”，而不是“略高于中心”。
• 除非源内容本身表达含糊，否则不要将高特异性的布局概括成“居中”“宽敞”“平衡”“靠上”“靠下”“接近顶部”或“接近底部”等泛泛描述。

翻译指南

项目设置

• HTML 入口文件、字体链接、head 标签、导入语句、CSS 重置、全局 CSS、Tailwind 配置、打包工具说明、TypeScript 说明、Vite、Next.js 或 React 设置 -> 移除。
• 页面标题、元数据、描述和社交图片请求 -> Framer 页面元数据。
• 站点／项目设置、分析仪表板、A/B 测试、重写规则、自定义标头、静态文件和 well-known 文件 -> 当前 Agent 工具不支持；请说明此限制，或仅在能够保留用户意图时转换为受支持的页面／内容替代方案。
• 将代码中的全局设计令牌 -> Framer 颜色令牌、文本样式预设、链接样式，以及在重复使用时可复用的组件样式。

布局与响应式结构

• Flexbox 行或列 → Framer 堆叠框架，设置方向、对齐方式、分布方式、间距、内边距和尺寸。
• CSS 网格 → 使用 Framer 网格布局实现可换行的卡片／列表布局和多行结构。
• flex-1、全宽、填充高度或“剩余空间” → 在相关堆叠或网格中使用填充／灵活尺寸。
• 居中的最大宽度容器 → 使用包含居中内容框架和最大宽度的父级区段。
• 响应式内边距，例如 px-6 md:px-12 lg:px-16 → 为 Desktop、Tablet 和 Phone 分别设置断点内边距覆盖值。
• 绝对定位或固定定位 → 仅用于有意的重叠、固定的全出血媒体、装饰层或真正需要固定的 UI。
• object-cover 背景媒体 → 使用原生图片／视频图层，将其尺寸设为覆盖框架，并设置适当的裁剪和 z-order。
• 移动端单列网格 → 如果在 Framer 中纵向堆叠更稳定、易读，则转换为纵向堆叠。
• 使用 flex flex-col 的 min-h-screen 或 h-screen → 使用高度为 100vh 的纵向堆叠。如果子项包含页眉／导航、flex-1 主体和页脚／底部控件，应保留这三部分结构，而不是将所有前景内容都居中放在一个框架中。
• 填充区域内的 justify-center → 在该填充区域内居中，不一定要相对于视口居中。
• justify-between 或分散排列的子项 → 明确保留顶部／中部／底部或左侧／居中／右侧的分布。
• 负边距和变换 → 转换为明确的视觉偏移，并为受影响的图层命名。
• 百分比变换，例如 translate-y-[17%] 或 -translate-y-[20%] → 保留百分比及其参考元素。如果 Framer 无法直接表达，则提供等效的视觉锚点。
• 视口单位，例如 vh、vw、dvh 和 svh → 保留相对于视口的尺寸，并说明预期的 Desktop、Tablet 和 Phone 行为。
• 宽高比、最小／最大宽度、固定尺寸和空白／不换行规则 → 当这些规则影响换行、裁剪或可见对齐时，予以保留。

排版

• Tailwind 文本尺寸或 CSS 媒体查询字体尺寸 → 使用 Framer 文本样式预设，并为各断点设置尺寸。
• 字体粗细 → 使用可用的命名或数值 Framer 字重。不要臆造不受支持的字重。
• 外部 Web 字体导入 → 移除导入机制，并将其转换为字体可用性要求。Framer Agent 不能依赖提示词中任意的外部 Web 字体 URL。
• 为精确文本度量所需的专有字体或自定义字体 → 要求预先确认该字体已在项目中可用或已作为自定义字体上传。如果严格的像素匹配依赖该字体，而字体缺失，则告知 Framer Agent 暂停并索取字体文件，而不是改用替代字体。
• 后备字体 → 仅用作明确说明的近似方案。如果后备字体的字形度量可能改变换行，不要声称能精确还原换行或像素效果。
• 字间距和行高 → 明确设置文本样式值。
• 字面量 \n 换行符 → 在 Framer 文本内容中使用实际换行，而不是原始转义序列。
• 单词级颜色、字重或强调 → 使用富文本片段，并保留行内格式。
• 文本内边距 → 设置在包含文本的框架上，而不是文本图层上。
• 链接 → 适当时使用带链接样式预设的富文本链接。

颜色、效果与表面样式

• Tailwind 颜色标记或 CSS 变量 → 设置明确的 Framer 颜色值，并在重复使用时提升为颜色标记。
• 边框 → 使用原生边框；如果需要渐变边框，可使用渐变填充的薄底框近似实现，或说明精确的渐变边框可能需要基于代码的方案。
• 玻璃拟态或背景模糊 → 使用半透明填充、背景模糊、边框以及细微的内阴影／外阴影。
• 盒子阴影 → 使用 Framer 阴影效果，并在需要时添加内阴影。
• 渐变 → 使用 Framer 渐变填充。
• 装饰性包装层 → 保持透明，除非需要可见的表面处理。

动效与交互

• 挂载或滚动时的入场动画、IntersectionObserver、AOS 或由钩子驱动的显示状态 → 使用在挂载时或进入视口时触发的 Framer 入场效果。
• 逐字符、逐词或逐行显示文本 → 使用带有分词和交错效果的 Framer 文本效果。
• 悬停样式 → 使用悬停效果、手势变体或按钮／链接组件状态。
• 循环运动、视差、跑马灯、滚动字幕或光标效果 → 在可用时使用 Framer 原生效果。
• 选项卡、手风琴、切换开关、菜单、抽屉、打开／关闭界面和固定状态集 → 使用带有变体和事件处理器的原生组件。
• 模态框、下拉菜单、弹出框和工具提示 → 使用固定或相对定位的叠加层，并连接触发器和关闭行为。
• 轮播和滑块 → 根据所需行为，使用原生 Carousel/Slideshow 组件或由变体驱动的组件。

内容、数据、CMS 与表单

• 映射到卡片、文章、产品、人物、活动、推荐语或记录的硬编码数组 → 默认使用 Framer CMS 集合和集合列表。
• 三个流程步骤或定制统计卡片等少量固定视觉组 → 如果它们是结构性元素而非受管理的记录，可以使用原生重复框架。
• 详情页／模板页 → 使用 CMS 详情页，并添加绑定变量的字段和稳定的 slug。
• 表单 → 使用原生表单框架、带有正确类型的已标记输入框，以及提交按钮组件实例。仅在源提示词要求时提及集成。
• 本地化或翻译更新 → 应用更改前，先检查可用的语言区域和本地化字段；除非明确要求替换，否则保留现有本地化值；批量删除、替换或破坏性本地化迁移前，先询问。
• 超出原生表单行为的运行时验证或提交逻辑 → 添加代码升级说明。

组件、媒体、图标与复用

• 可复用的按钮、卡片、徽章、导航项、常见问题项或重复界面 → 优先复用现有 Framer 组件；否则创建带有变体和可编辑属性的原生画布组件。
• 需要运行时行为的现有样式化元素 → 优先使用原生交互、变体和事件处理器；需要代码时，在受支持的情况下指定代码组件工作流。不要承诺直接为现有节点分配代码覆盖。
• 图标 → 使用 Framer 原生图标集或项目中可用的图标组件。除非用户要求，否则不要用 Unicode 符号替代图标。
• 任意第三方 CDN 图片 URL → 不要假设它们可以应用于 Framer。对于严格复刻或像素级匹配的提示，在开始构建前，必须提供附件／上传的图片文件、明确排序的附件资源包，或来自可信内置图片搜索结果的资源。
• 大型图片清单 → 包含放置每项资源所需的映射，但优先使用“使用与此文件名／图层名匹配的附件”，而不是拼接 URL。完整的 URL 表有助于排序，但不能因此让不可信的外部来源变得可用。
• YouTube、Vimeo、Spotify、地图、音频、iframe 及类似的嵌入内容 → 使用对应的原生组件或嵌入组件。
• 共享导航、页脚、侧边栏或页面框架 → 使用布局模板，而不是在每个页面上重复相同图层。

代码升级

只有当行为无法通过原生画布结构、CMS 数据、本地化内容、变体、叠加层、效果、控件和事件处理程序来实现时，才升级为代码组件。不要指示下游 Agent 为现有节点分配代码覆盖；不支持由外部 Agent 分配覆盖。

通常只有以下情况才有理由使用代码：

• 实时计时器、时钟、倒计时、轮询或 setInterval。
• 运行时 fetch、SDK 调用、实时外部 API 数据、身份验证或浏览器 API。
• localStorage、重新加载后仍保留的状态、剪贴板、地理位置、文件 API 或媒体 API。
• 超出原生表单和集成能力的复杂表单验证或提交行为。
• Framer 效果无法实现的任意拖放排序、自由连续逻辑或自定义动画公式。

确有必要使用代码时，应编写 Framer 提示词，使原生实现仍是默认可见的实现。针对确切的代码需求添加简短的行内注释，并指出需要代码实现的行为。不要添加诸如“如果需要自定义代码”的全局前言，也不要笼统地要求在原生实现与代码之间做选择。不要要求下游 Framer Agent 将代码栈结构转换为 Framer；应由你自行提供转换后的可见结构，然后将代码路径限定为确切的运行时行为。

最终提示词审核

返回之前，请通读转换后的提示词，并根据以下清单修复发现的任何问题：

• 将 # Prompt (Framer version) 等泛化标题替换为具体标题，明确说明 Framer Agent 应构建或编辑的内容。
• 删除框架残留内容，例如软件包安装、React、Tailwind、Next.js、Vite、motion/react、className、src/、index.html、CSS 变量设置或导入语句；如果有助于澄清，可简短说明已刻意省略源代码实现细节。
• 删除委托转换的措辞。最终提示词中禁止出现以下模式：“translate Tailwind-style sizing/spacing”“convert these classes”“adapt the React structure”“map the CSS to Framer”，以及任何将框架解释工作留给下游 Framer Agent 的指令。
• 删除任务本身已隐含的冗余目标平台说明，例如单独作为前言的“Build this directly in Framer”“Use native Framer wherever possible”或“Use a Framer Code Component if needed”。仅保留具体构建要求，以及与特定行为相关的行内注意事项。
• 删除本地工作区信息泄露，例如本地路径、仓库名称、文件名、参考文档名称、AGENTS.md、隐藏工具语法、内部 ID，或要求读取私有上下文的指令。
• 确认提示词完整自包含，Framer Agent 无需访问代码仓库。
• 确认每项精确的源资源、文案字符串、换行、颜色、字体、尺寸、间距关系、断点、动画时长、延迟、缓动、悬停状态和明确约束均已保留，或在相关要求附近注明近似处理。
• 对于严格复刻、复制或像素级匹配的提示词，如果 Framer 中可能没有可信或可用的精确字体或媒体资源，请确认最终提示词包含具体的预检要求。
• 确认每个影响布局的源代码标记都采用以下其中一种方式处理：直接对应的 Framer 实现、能保留渲染结果的复合 Framer 结构，或在相关要求附近注明限制及最接近的视觉目标。
• 确认首屏部分在适用时包含重要的视口锚点：导航栏／页眉偏移、标题或主要内容的视觉中心、页脚／底部控件位置、媒体焦点区域，以及叠加层顺序。
• 确认百分比变换明确指出参照元素，不使用含糊的定位措辞。
• 确认会影响内容位置的常规文档流页眉／主体／页脚关系得到保留。
• 确认响应式行为按 Desktop、Tablet 和 Phone 说明，而不是使用 CSS 媒体查询或 Tailwind 前缀。
• 确认默认采用原生 Framer 实现；仅将只能通过代码实现的行为单独列为可选代码组件说明，除非用户明确要求精确保留代码行为。
• 确认源内容中的每个 Tailwind 工具类、CSS 选择器／类、React 属性、钩子、导入项、软件包或构建栈说明都已转换为具体的 Framer 原生要求，或作为无关设置删除。除非某项精确 CSS 是实现明确要求的纯代码效果所必需，否则不要留下需要 Framer Agent 解释的源代码语法。
• 对照源提示词的标题和主要项目组检查输出。任何新增、删除或重命名的部分，都必须有源内容歧义、用户指示或不可避免的 Framer 注意事项作为依据。
• 确认最终输出没有混入校准示例的分节、注意事项标题或行文风格。
• 执行反向差异审计：检查转换后的提示词，找出源内容中没有的任何指令。除非该内容属于机械性的 Framer 转换、源内容推导出的几何关系或明确的近似处理／注意事项，否则均应删除。
• 特别留意常见的擅自润色：叠加层、遮罩、渐变、阴影、模糊、纹理、装饰形状、额外分区、额外 CTA、改写品牌定位、“高端”风格、可读性调整、无障碍改进，以及悬停或动画润色。
• 如果认为某项最佳实践改进很有用，不要将其写入转换后的提示词。仅当用户征求建议时，才可在提示词之外的可选说明中提及。

输出指南

返回一条改写后的提示词，而不是改写前后的对比。移除框架相关机制后，尽可能保留源提示词的设计意图、优先级和结构。

使用能帮助 Framer Agent 理解预期产出的具体标题，例如 # Build the Product Launch Landing Page 或 # Create the Pricing Page With Interactive FAQ。不要使用 # Prompt (Framer version) 之类的通用标题。

省略隐含的设置说明。从要创建或编辑的具体内容开始，然后列出转换后的要求。不要告诉 Framer Agent 这条提示词是为 Framer 编写的、它应该使用 Framer，或它应该将源技术栈语法转换为 Framer 语法。

不要强制套用固定的章节模板。如果源提示词已有清晰的章节，就在原位置保留并翻译这些章节。如果源提示词杂乱或以代码为主，只需进行足够的重组，让 Framer 实现要求清晰明了。

默认不要添加标准化的备注或注意事项章节。只有当某项要求无法直接保留在正文中，且相关注意事项会实质性影响实现时，才添加该章节。

如果源内容包含冗长的 QA 脚本或验证说明，除非用户明确要求保留完整测试脚本，否则应将其改写为简短的通过/未通过检查清单，列出可观察到的 Framer 实现结果。每一项都应对应 Framer Agent 可以检查、截图或报告的一件事。