Figma 转前端页面 是做什么的？
成果与范围
在现有项目中实现所选设计，并在浏览器中验证结果。通常只需一个 Figma URL 即可开始；从仓库中推断项目约定。当无法访问设计时，接受提供的截图或导出文件作为备用证据。
用户指示优先于这些指南。保留现有更改，并将编辑范围控制在请求范围内。在确定文件或路由之前，务必明确任务是新页面、现有页面更新、区块还是可复用组件。不要将组件或局部修正转换为新页面。
核心约束
- 在编辑之前，先阅读相关仓库代码。在合适时，复用其框架、路由、样式、令牌、组件、资产和数据约定。
- 将设计几何转换为布局规则。优先使用普通流、flex 和 grid；仅在需要实际重叠、装饰或覆盖层时使用绝对定位。Figma 编组是证据，而非强制性的组件边界。
- 复用相同的资产和适合的映射组件。保留独特的图像和图标，而不是用近似符号替代。不要将整个交互部分渲染为屏幕截图。
- 实现由需求、原型或现有产品行为支持的功能。不要仅凭外观推断粘性定位、过滤语义、API 契约或导航目标。
- 保留语义控件、无障碍名称、键盘操作和适当的焦点行为。排除设备界面元素（如 OS 状态栏），除非有要求。
- 在未将实现目标与设计进行比较之前，不要声称视觉一致性。明确报告被阻止或未验证的需求。
CSS 兼容性
- 对于 flex、grid 和重复项目之间的间距，使用
margin。不要使用gap、row-gap或column-gap。将间距放在具名项目类上；当第一个或最后一个项目的边距不同时，为其添加显式的修饰符类。不要使用> * + *、:first-child或:last-child等选择器替换gap。 - 针对显式的组件类编写选择器。避免在可能编译为 WXSS 的样式中使用通用选择器和兄弟选择器（
+、~）。在使用其他伪类或选择器之前，检查目标平台的选择器支持情况；不要假设浏览器 CSS 支持意味着 WXSS 支持。 - 对于遮罩和固定面板，使用显式的
top、right、bottom和left声明，而不是inset。当使用env(safe-area-inset-*)时，在声明使用env()的紧跟之前放置一个简单值回退。在固定宽度和内边距需要配合的地方设置box-sizing: border-box。 - 在 Taro H5 中，内置的
taro-button-core:active样式可能会在禁用悬停类的情况下将按下的按钮变灰。如果设计中没有按下颜色变化，则针对特定按钮类覆盖 active 背景和文字颜色，同时保留每个按钮的正常颜色。不要全局重置按钮或更改禁用状态样式。
证据与决策
当收集或刷新设计证据时，请阅读 design-evidence.md。保持一个简洁的工作摘要，包括目标、项目约定、资产映射、可用能力和不确定性。简短的任务使用上下文记录即可；除非有用或要求，否则不要生成规范文件。
对决策进行分类：
- 确认： 明确的用户要求、选定的设计属性、原型行为或相关的现有产品契约。
- 推断： 与项目一致的常规布局适配、换行和局部组件边界。选择最小的合理实现并披露重要的假设。
- 未知： 缺失的提交通货、模糊的目标、冲突的目标框架或重要的业务行为。首先检查可用证据；如果仍然需要，提出一个聚焦的问题。在等待答案的同时继续独立工作。
单独的可见控件并不确立其业务行为。不要伪造成功提交、发明端点或静默替换模拟行为。仅当任务或现有预览约定支持时，才使用 fixture，并指出该限制。
执行
遵循依赖关系，而不是重复固定的序列。对于局部修正，复用仍然有效的证据，并检查更改区域以及受影响的共享行为。仓库和设计的独立读取可以分批进行。
1. 识别目标与项目
解析文件 key 和节点 ID。检查所选节点的类型、尺寸和周围上下文。如果缺少节点 ID，则检查顶层候选节点；仅在目标明确时才选择。
使用有针对性的搜索和读取来确定：
- 适用的仓库说明和当前更改；
- 包管理器、开发和验证命令；
- 可能的目标文件及最接近的现有实现；
- 路由、样式、令牌、字体、视口/单位处理及组件约定；
- 现有的设计到代码的映射和资产（如果有）。
对于现有页面或组件的工作，保留其入口点。对于新页面，遵循现有的路由族和参数约定，检查冲突。仅将框架名称作为后备命名提示；不要强加一个通用的详情路由。
2. 获取足够的设计证据
优先使用可用的 Figma 工具获取元数据、截图、变量、组件映射和资产。在调用这些工具之前，遵循任何所需的工具特定技能前提条件。如果访问失败，尝试可用的经过身份验证的浏览器，然后使用提供的截图或导出文件。不要将网络搜索作为实际设计的替代。
从目标截图和结构概览开始，然后获取相关子树的详细信息。检查折叠线以下的内容。不要重复检索整个文件或不相关的框架。将不可用的测量值或状态记录为不确定性，而不是确切事实。
3. 映射与实现
将设计映射为有意义的模块，选择行为与外观匹配的现有组件。当组件具有复用性、独立行为或足够的复杂性时，将其提取为组件；不要拆分每个包装或为一个页面创建设计系统。
尽早解决字体和主要资产问题。保留资产的长宽比、透明度和适当的分辨率；使用仓库存储约定和语义化文件名。检查运行时资产是否从项目支持的持久位置加载。
根据提供的变体和现有项目行为，推导流体尺寸、最大宽度、换行和断点。对于单一设计尺寸，实现保守的适配，并将其与设计师指定的响应式布局区分开来。测试请求的平台；不要创建未请求的桌面或移动端重新设计。
对于在 H5 和小程序构建之间共享样式的 Taro 项目，除了源样式表外，还要检查生成的 WXSS。在可用时，在每个请求的运行时上验证间距和按下状态。
仅启用相关的行为分支：
- 导航： 使用已有的目标和路由行为。
- 表单和集合： 使用现有的数据契约；实现所需的验证、加载、空状态、错误状态和成功状态。
- 选项卡和过滤器： 根据证据确定状态所有权和选择语义。仅当有支持时，才应用草稿/提交行为。
- 表格： 保留对齐和显示的边框；提供适合目标视口的溢出处理。
- 覆盖层或粘性 UI： 阅读 overlays-and-sticky.md。
- 动效或媒体： 复现确认的行为，并在适用时处理加载和减少动效。
4. 验证与迭代
复用合适的运行服务器，或在可用的端口上启动文档化的开发命令。使用可用的浏览器自动化界面，合适时优先使用应用内浏览器，然后使用经过身份验证的外部浏览器或项目的浏览器工具。检查相关路由或现有组件预览。
阅读 acceptance-checklist.md 了解视觉比较、适用交互检查和完成标准。在局部打磨之前先修复大的结构差异。每次更改后，检查受影响的区域；最后执行一次整体目标的检查。
运行相关的仓库检查，检查最终的差异，并区分预先存在的失败与引入的失败。避免为了进行验证而添加依赖项或进行广泛的重构。保留预先存在的服务器会话，并确保为此任务启动的任何服务器的状态是明确的。
恢复与完成
如果访问或运行时验证失败，检查具体的错误并尝试可用的相关替代方案。在没有新证据的情况下，停止重复相同的失败。继续可以独立完成的工作，然后报告确切的阻塞因素、已实现的内容以及尚未验证的内容。缺少工具或凭据不能作为验证成功的证据。
当请求的目标已实现、适用的检查通过且没有已知的必要缺陷时，视为完成。轻微的渲染差异可以记录文档；未解决的布局错误、缺少必需的行为或浏览器检查被阻止的情况，不得作为完全完成来呈现。
简洁地报告：
- 实现的目标和入口点，包括路由（仅当适用时）；
- 有意义的行为和组件更改；
- 预览位置和实际执行的检查；
- 重要的假设、未解决的差异或阻塞因素。