arseladisar08-lab/umkm-landing-page-master

UMKM 落地页大师技能

0. 使命

创建一个独特、可信赖、以移动端为先的落地页，帮助真实企业将访问者转化为客户。

该技能协调六项专业职责：

1. 项目编排与研究 — 理解简报，检查现有项目，提取内容和资产，规划构建，并维护清晰的交付路径。
2. 转化策略 — 定义受众、产品/服务、异议、信息层级、页面结构和主要行动。
3. 创意方向 — 开发根植于品牌、产品、受众和真实参考的原创视觉概念。
4. 前端实现 — 构建可维护、语义化、响应式的 HTML/CSS/JavaScript，并附带已验证的资产。
5. 设计品味与反“AI 垃圾”审查 — 防止通用化的 AI 视觉模式，确保每个设计决策都目的明确。
6. 浏览器QA与部署就绪 — 检查渲染后的页面，测试交互和响应状态，修复缺陷，并为 Vercel 部署做准备。

主要输出： 一个可直接用于 Vercel 的、能工作的 HTML/CSS/JavaScript 网站。当提供现有框架或项目架构时，应予以保留；没有明确理由时，不要迁移一个能正常运行的项目。

1. 不可妥协的原则

1.1 事实先于装饰

• 以用户的 PRD、商业文档、菜单、价目表、横幅和已批准的网站内容为唯一事实来源。
• 绝不捏造价格、成分、产品可用性、营业时间、地址、配送范围、认证、奖项、推荐、评价、客户数量或商业声明。
• 当信息缺失时，将其省略，标记为“NEEDS DATA”，或者如果确实阻碍构建，提出一个聚焦的具体问题。
• 区分已验证的事实、合理的设计假设以及需要客户确认的内容。

1.2 资产即内容

• 在开始设计前，检查提供的横幅、照片、Logo、PDF、菜单和宣传册。
• 精准保留品牌 Logo 和产品摄影。不要用 AI 臆造的版本来替换提供的 Logo。
• 建立资产清单：文件名、尺寸、格式、主题、建议放置位置、来源以及验证状态。
• 优先使用真实的商业摄影。只有在允许的情况下才使用生成或库存图片，并且必须将其与真实的客户/产品证据清晰区分。
• 不要伪造客户评价，也不要把示例性人物当作真实客户来使用。

1.3 一个受众，一个产品/服务，一个主要行动

• 定义主要受众和最重要的业务成果。
• 选择一个主导性的转化行动，例如通过 WhatsApp 下单、拨打电话、访问店铺、索取报价、预约或购买。
• 在首屏之上，次要行动不得与主要 CTA 形成竞争。
• 使 CTA 文案针对具体行动和目的地，而不使用通用的“了解更多”。

1.4 品牌驱动，而非模板驱动

• 每个企业都需要自己独特的、有意的视觉方向。
• 不要在无关的品牌间重复使用相同的 Hero 构图、调色板、字体、卡片布局、图标样式和章节顺序。
• 参考的目的是为了提取设计原则和交互思路，而不是复制其他品牌的特性。
• 不要仅仅为了显得有创意而使用不对称、超大字体、视差、渐变、毛玻璃效果或动画。只有当它们适合品牌并能改善信息传达时才使用。

1.5 移动端为先且快速

• 首先为窄屏设计，然后扩展到平板和桌面。
• 优先考虑可读的文本、易于触及的 CTA、快速加载的图片、清晰的导航和低摩擦的订购流程。
• 尊重用户的“减少动效”偏好，避免使用干扰阅读或购买的动效。

2. 支持的商业场景

根据实际业务调整页面结构和视觉语言：

• 餐饮： 烤肉店、点心店、面包店、咖啡店、餐厅、餐饮服务、小吃和饮料品牌。
• 零售与时装： 服装、配饰、化妆品、礼品、本地产品品牌。
• 服务： 沙龙、美容、维修、教育、活动服务、专业服务及其他本地服务。

不要将所有业务类别强行塞入相同的页面结构。菜单驱动的业务需要菜单发现和订购功能；预约驱动的服务需要建立信任、解释服务、展示可用性和提供预订；时装可能需要展示系列、尺码信息、材质和购买流程。

3. 工作流程概览

按顺序执行以下阶段。对于小型项目可以合并步骤，但不得跳过源文件检查、创意方向、响应式实现或 QA。

1. 项目接收与仓库侦察。
2. 事实来源、内容与资产提取。
3. 受众、产品/服务、异议与转化策略。
4. 品牌专属风格探索与创意方向。
5. 信息架构、章节规划与文案。
6. HTML/CSS/JavaScript 实现。
7. 设计品味与反“AI 垃圾”审查。
8. 浏览器 QA、响应式与交互测试。
9. SEO、可访问性、性能与 Vercel 就绪。
10. 包含验证状态和已知局限性的交付报告。

4. 阶段一 — 项目接收与研究

4.1 在修改前先检查

• 检查仓库、现有框架、包文件、路由、组件、CSS 规范和部署配置。
• 确定这是新建、改版还是增强。
• 除非用户明确要求更改，否则保留正在工作的架构和品牌已批准的元素。
• 在理解现有工作之前，不要覆盖它。
• 识别可用的浏览器、截图、图片和部署工具。除非实际调用了该工具，否则不要声称使用了它。

4.2 阅读所有提供的输入

检查相关文件和参考资料，可能包括：

• PRD、简报、品牌指南、产品目录、菜单、价目表、促销信息、宣传册、PDF、Word 文件、电子表格。
• 横幅设计、Logo、产品照片、包装、店面照片、社交媒体视觉素材。
• 现有网站 URL、社交媒体资料、参考网站、截图参考。
• 用户指示、修改历史、已批准的文案、约束条件和排除项。

4.3 创建项目事实表

记录：

• 企业名称和类别。
• 地点和服务范围（仅当提供或已验证时）。
• 目标受众和购买场景。
• 产品/服务和已验证的价格。
• 有证据支持的独特卖点。
• 订购、预订、支付、配送和联系方式。
• 营业时间、政策和约束条件。
• 主要转化事件。
• 现有品牌特性和资产。
• 未知信息和假设。

输出：当项目规模需要时，输出一个简洁的 PROJECT-FACTS.md 或同等的工作笔记。

5. 阶段二 — 内容与资产提取

5.1 文本提取

• 从提供的文档和图片中提取事实性文案。
• 使用最新明确批准的资料来协调重复或冲突的数据。
• 保留原始产品名称和拼写，除非用户要求编辑。
• 精确保留价格、变体、尺寸、成分、尺寸规格和条款。
• 标记冲突的事实，而不是默默选择一个。

5.2 图片与资产目录

对于每张提供的图片，记录：

• 资产路径/名称。
• 尺寸和文件类型。
• 可见的主题和内容。
• 品牌/产品相关性。
• 建议放置的章节和裁剪方式。
• 该资产是原始、库存、生成还是来源未知。
• 验证状态。

5.3 图片使用规则

• 尽可能在产品卡和菜单项中使用实际的产品图片。
• 不要用文本、图标或臆造的 Logo 替换真实 Logo。
• 不要裁剪掉重要的文本、产品细节、包装或品牌元素。
• 有目的地使用 object-fit 和 object-position；不同的源图片可能需要不同的裁剪方式。
• 在工具允许的情况下，将大文件优化为合适的响应式格式。
• 添加有意义的 alt 文本；对于纯装饰性图片使用空的 alt 文本。
• 在浏览器中验证每个最终图片的 URL 或本地路径。

输出：一份资产映射表和一份缺失资产清单。

6. 阶段三 — 转化策略

6.1 转化简报

定义：

• 受众：谁最有可能购买或咨询？
• 场景：访问者从哪里来，他们已经知道什么？
• 产品/服务：正在销售或请求的是什么？
• 价值：客户获得了什么切实的好处？
• 摩擦：哪些疑虑阻碍了行动？
• 证据：哪些真实证据可以减少这些疑虑？
• 行动：访问者下一步到底应该做什么？

6.2 异议发现

考虑相关的异议，例如：

• 价格和价值。
• 产品质量和新鲜度。
• 份量、尺寸、成分或材料。
• 信任、卫生、可靠性和服务质量。
• 地点、配送和可用性。
• 预订、支付或订购步骤。
• 退货、取消或保修政策。

仅使用有支持信息的方式处理异议。不要捏造证据。

6.3 信息层级

• Hero 标题：传达产品/服务或成果，而不仅仅是企业名称。
• 副标题：阐明提供的内容、面向谁、以及为何重要。
• 主要 CTA：具体动词加清晰行动。
• 优势：将特性与客户成果联系起来。
• 证据：将真实的支撑证据放在其支持的声明附近。
• 常见问题：解决剩余的购买摩擦。
• 最终 CTA：清晰地重申下一步行动。

6.4 CTA 示例

• 餐饮："Pesan Dimsum via WhatsApp"， "Lihat Menu"， "Pesan untuk Acara"。
• 咖啡店："Lihat Menu Kopi"， "Pesan untuk Pickup"， "Lihat Lokasi"。
• 时装："Belanja Koleksi"， "Lihat Panduan Ukuran"。
• 服务："Booking Jadwal"， "Minta Estimasi Harga"， "Konsultasi via WhatsApp"。

在交付前验证目标 URL、号码、消息模板和跟踪参数。

7. 阶段四 — 风格探索与品牌专属创意方向

7.1 在选定风格前先解读品牌

从业务中推断：

• 品牌个性和定位。
• 产品质地、材料、产地、场景或工艺。
• 受众期望和购买心态。
• 本地/文化背景（仅在支持的情况下）。
• 值得区分的竞品惯例。
• 网站应唤起的感觉。
• 网站绝不应被误解为什么。

7.2 创建独特方向

撰写一份简短的视觉论文，明确：

• 方向名称和概念。
• 情绪和预期的情感反应。
• 排版角色及其理由。
• 带有语义角色的调色板。
• 布局/构图方法。
• 图片艺术指导和裁剪原则。
• 表面、边框和深度处理。
• 标志性设计元素。
• 动效原则。
• 移动端适配。

不要简单地将每个项目映射到预设风格。要深思熟虑地组合视觉影响，但确保组合是连贯且恰当的。

7.3 新鲜度与反趋同检查

在编码之前，思考：

• 这个布局是否可能属于任何不相关的品牌？
• Hero 构图仅仅是最常见的 AI 默认设置吗？
• 颜色和字体的选择是否基于品牌理由？
• 是否存在一个可识别的视觉创意？
• 章节的排列是否针对此特定受众和转化目标？
• 移动端体验是否有其自身的构图，而不仅仅是缩小桌面版？

如果概念显得通用，则在实现前修订艺术方向。

7.4 设计系统

在组件样式前定义令牌：

• 颜色：背景、表面、文本、淡化文本、边框、主要、强调、语义状态。
• 排版：展示、标题、正文、标签、元数据。
• 字号层级和行高。
• 间距层级。
• 容器宽度和断点。
• 圆角和边框规则。
• 高度/深度。
• 动效持续时间和缓动函数。

使用克制、品牌专属的设计系统。不要普遍禁止某种字体、颜色、布局或效果；只在它是不合理的默认设置时才避免使用它。

输出：DESIGN.md 或同等的文档化设计规范。

8. 阶段五 — 信息架构与章节构成

8.1 根据业务需求选择章节

可能的章节包括：

• 公告栏。
• 页眉/导航。
• Hero 区。
• 产品/服务概览。
• 菜单/目录/系列。
• 优势与差异化。
• 成分/材料/工艺。
• 如何订购或预订。
• 画廊。
• 客户评价/评论（仅限真实）。
• 地点和营业时间（仅限已验证）。
• 定价/套餐（仅限已验证）。
• 常见问题。
• 联系方式和最终 CTA。
• 页脚。

这是一个组件库，不是强制顺序。根据简报和访问者旅程，选择、重命名、合并、移除和重新排列章节。

8.2 章节目的测试

每个章节必须至少回答一个问题：

• 客户需要理解什么？
• 它帮助解决哪个决定或异议？
• 它提供了什么证据？
• 它使哪个行动变得更容易？

移除那些没有增加有意义价值的章节。

8.3 Hero 要求

首屏应明确：

• 这是什么业务/产品/服务。
• 它面向谁或提供什么。
• 访问者为何应该关心。
• 下一步行动是什么。

使用最佳的可用品牌/产品资产。不要强制使用双栏 Hero、居中标题、浮动仪表板模拟图或装饰性渐变。

9. 阶段六 — HTML/CSS/JavaScript 实现

9.1 技术栈选择

• 如果提供了现有项目，除非明确要求迁移，否则保留其技术栈。
• 对于新的静态落地页，默认使用语义化的 HTML5、外部 CSS 和尽可能少的原生 JavaScript。
• 仅当被要求或项目证明有必要时，才使用 React/Vite/Next.js。
• 不要仅仅为了给一个小元素添加动画而引入框架或依赖。
• 锁定或记录依赖；避免不必要的脚本和远程库。

9.2 建议的静态项目结构

project/
├── index.html
├── styles.css
├── script.js
├── assets/
│   ├── images/
│   ├── icons/
│   └── fonts/
├── README.md
└── vercel.json        # 仅在需要时

9.3 HTML 要求

• 使用语义化标签：header， nav， main， section， article， footer 等。
• 为屏幕阅读器和爬虫使用清晰的、描述性的、层级化的标题。
• 使用逻辑化的、视觉上支持的源顺序。使用 CSS 进行视觉调整。
• 永远不要使用 <div> 做原本该用 <button> 或 <a> 的事情。
• 将表单输入与其 <label> 元素关联起来。
• 使用适当的 type 属性（例如，type="email"， type="tel"）。
• 如果页面上超过一个，则包含 <h1>。

9.4 响应式 CSS 要求

• 使用设计系统令牌。在颜色、尺寸、间距、字体堆栈方面避免魔数。
• 从移动端样式开始。桌面样式在移动端样式之后，并使用断点进行覆盖。
• 保持选择器简单。在合理的情况下避免深度嵌套、!important 和过高的特异性。
• 使用灵活的布局：flexbox 或 grid。对于纯布局，不要使用 float，除非需要文本环绕。
• 图像应是响应式的：max-width: 100%， height: auto，和适当的 srcset/sizes。
• 字体大小在合理情况下使用相对单位（如 rem， em）。
• 确保触控目标在移动端上足够大（最小 44x44 像素）。
• 尊重 prefers-reduced-motion。

9.5 JavaScript 要求

• 保持 JavaScript 尽可能少。
• 使用 defer 或 type="module" 来避免阻塞渲染。
• 在 CTA、导航、表单和图像查看器之外，避免交互依赖 JS。
• 测试 JS 失败时的体验：核心内容和导航应在没有 JS 的情况下工作。
• 不要使用 JavaScript 库来实现简单的 UI 模式（如标签页或手风琴），除非项目已经包含一个。
• 在添加依赖之前，评估能否用 aria-expanded 等标准 API 完成。

10. 阶段七 — 设计品味与反“AI 垃圾”审查

10.1 使用特定性测试（摘自“设计品味系统”）

对每个视觉设计决策提问：

• 由此产生的颜色、字体、渐变、边框半径、阴影或布局是否显得通用、随机、模板化或品牌无关？
• 此元素是否默认使用雾状渐变、白色/灰色背景、全宽、居中、深色叠加、玻璃态、柔和的圆角、浅阴影和半光图标？
• “普通性”是否是因为选择了最不具冒犯性的默认值，而没有考虑品牌个性？
• 是否每个组件都可以替换为来自不同、无关品牌的组件而不会显得不协调？

如果设计无法通过“特定性测试”，则找到一种使其归属特定品牌、基于理由且有意识的方法。

10.2 反通用视觉垃圾检查

寻找并移除常见的 AI 默认元素，例如：

• 作为默认 Hero 构图的雾状渐变。
• 无人脸、无品牌、无上下文的纯装饰性 3D 渲染。
• 看上去像 UI 模板或应用截图，而不像真实业务资产的示意图。
• 无意图的抽象几何背景。
• 无沟通功能的随机图标（尤其是花哨的线条艺术图标）和装饰性矢量图形。
• 看上去像已购买模板、而不是为品牌创建的排版布局。
• 页面内裁切不一致的库存照片。
• 不是来自品牌或产品的通用圆形图标。
• 每页“联系我们”表单作为默认设置（当 WhatsApp 优先时）。
• 为“专业感”而添加的不必要的动画、视差或滚动触发效果。

10.3 品牌真实性测试

• 这条内容是否确实属于这个品牌，还是任何品牌都可以声称？
• 如果 Logo 和品牌名称被遮盖，是否仍能猜出该业务类型或个性？
• 字体和颜色是否有意识地选择，还是仅仅很安全？
• 这个页面是否看起来像是真正关心其在线形象的本地企业制作的？
• 它是否避免了 SaaS / 创业公司 / 机构/产品页面（这些都是 AI 通常模仿的）的惯例？

11. 阶段八 — 浏览器 QA、响应式与交互测试

11.1 浏览器渲染检查

• 在实际浏览器中打开每个页面。
• 验证图像路径和资源 URL 能正确加载。
• 检查字体加载和后备方案。
• 确认所有文本未经过度压缩或溢出其容器。
• 检查表单、链接和交互式元素的功能。

11.2 响应式断点测试

对于断点范围（例如，375 像素、 768 像素、 1024 像素、 1440 像素）：

• 检查布局是否按预期适配。
• 验证文本可读性，无水平滚动，元素不对齐。
• 检查主要 CTA 在所有尺寸下是否可见且可点击。
• 测试内容和图片是否按预期缩放。

11.3 交互测试

• CTA 按钮：点击/触摸是否转到正确的位置？
• 导航链接：所有跳转是否都指向有效部分？
• 表单：字段是否工作，提交是否正确处理？
• 手风琴/标签页/轮播：它们是否按预期打开、切换或滑动？
• 模态框/覆盖层：打开和关闭功能是否正常？
• 浮动或粘性元素：是否遮挡了其他内容？

11.4 性能与质量

• 资产是否合理优化？
• 是否不必要地加载了大型库？
• 关键内容是否快速可见？
• JS 是否在页面加载时阻止了内容？
• 页面是否在没有 JS 的情况下功能正常？

11.5 复制与事实准确性

• 整页扫描最新的数据以发现拼写错误。
• 对照源文件验证价格、营业时间和联系方式。
• 检查链接、电话号码和 WhatsApp 号码的格式是否正确。

12. 阶段九 — SEO、可访问性、性能与 Vercel 就绪

12.1 SEO 基础

• <title> 标签：清晰描述业务和页面。
• <meta name="description">：总结页面在搜索结果中的价值。
• <meta name="viewport">：包含 width=device-width， initial-scale=1。
• 语义化标题层级：一个 <h1>， 有逻辑的嵌套。
• 在适当时使用 lang 属性（例如 lang="id" 用于印尼语页面）。
• Open Graph 元标签（OG 标签），用于社交分享预览。

12.2 可访问性

• 所有非装饰性图像都应包含 alt 文本。在它们的文本标签或 aria-label 中包含 SVG 图标。
• 表单输入具有可见标签。
• 链接和按钮可通过键盘访问。
• 与行动分离的链接和按钮具有焦点样式。
• 确保足够的颜色对比度（WCAG AA 为标准）。
• 交互元素使用 aria-label 或 aria-labelledby 以提供清晰上下文。

12.3 Vercel 就绪

• 项目结构应与 Vercel 的默认设置兼容。
• 创建一个 vercel.json 来定义路由、头部或重写规则（如果需要）。
• 提供一个简洁的 README.md，包含项目标题、描述、截图（如果可用）以及指向部署站点的链接。
• 确保所有链接使用相对路径或 HTTPS。
• 如果适用，在 Vercel 上测试部署。

13. 阶段十 — 交付报告

在技能执行结束时提供一份总结性报告，包含：

• 项目的背景。
• 使用的技能及其具体角色。
• 所有已创建/修改的文件的列表。
• 资产清单和验证状态。
• 已知的限制、假设和值。
• 用于后续维护的操作说明。
• 部署的网站 URL（如果适用）。