前言
Q：为什么挑这个主题？
A：因为之前应某个朋友的询问：
我找了一圈，发现以前收藏的一个比较好用的工具，但是我却没有做过任何的实际操作，遂记录：
这是一款类似于网页或者figma（敲重点：如果真的付费了的话，可以直接导入figma生成项目文件！）的扫描仪，非常方便的生成下面三种情况下的网页（静态情况偏好）
- figma设计稿
- 截图
- links
甚至可以通过Chrome 插件直接进行网页扫描然后打开一个新的tab进行生成，废话不多说，让我们直接开始吧：
安装好上面的Chrome extension之后，因为我没有付费，所以不能演示figma（其实最好的使用方法就是figma），我们来找一个网页进行测试，比如我的个人站点：
可以看到，我用红框圈起来的按钮，点击一下，会打开一个新的Tab：
然后我们可以添加一些信息，也可以直接就点击开始：
静待完成，可以看到：
生成了一堆代码，然后实际效果和实际上的差别不大，除了一些字体之外，还原的相当不错，左上角有一些插入式的DOM插件，问题不大，可以后期清除
代码结构：
很可惜的一点是，生成好的代码，要下载的话，需要开通upgrade计划。不过他还是把代码贴出来了，所以我们可以曲线救国把代码复制出来。。。让我们来试试：
交给ChatGPT！生成代码省点力气。
然后我们可以打开Cursor了：
对于Cursor的user rules，这里可以贴一个rule给各位用Cursor的朋友们用，非常的好用，可以避免绝大部分很简单的bug：
rule
接着，让我们来解决直接复制粘贴过来之后，代码的问题，此步跳过，我们可以发现，是可以直接运行的：
好，在开始之前，我们要认识到一些非常重要的事情！！！！👇🏻
Anima 代码 → UI 蓝本（只读）
Anima 的产出不是项目代码，是 UI 证据
Cursor 的职责不是“写页面”，而是“工程化 UI 蓝本”
最终质量，100% 取决于你对下面 Step2~Step5 的掌控能力
接下来我们要让Cursor来实现剩下的几个步骤，按照一个合格的企业级项目需要以下几点：
- 静态结构 & 样式（已有，Anima）
- 组件边界 & 状态模型
- 交互事件（点击 / hover / focus / keyboard）
- 动效 & 响应式（motion + breakpoint）
- 合规性（a11y / 可维护 / 可测试）
我们来让Cursor一步步实现：
以下是我长期作为前端开发总结出来的经验↓
我这里贴一张prompt的责任矩阵：
| Step | 解决什么 | Cursor 扮演角色 | 人要做什么 |
|---|---|---|---|
| Step2 | 架构拆分 | 架构助理 | 判断边界是否合理 |
| Step3 | 行为实现 | 熟练工程师 | 校验交互是否符合产品 |
| Step4 | 表现层 | UI 工程师 | 控制设计风格 |
| Step5 | 合规 | Tech Lead | 定义“底线” |
Step2： 组件边界 & 状态模型
这里只做拆分与状态，不加什么响应式啥的
你是资深前端架构师。当前项目来自 Anima 的静态 UI 蓝本。
【本次任务仅做 Step 2：组件边界与状态模型】
请你：
1) 明确并重构组件边界：sections 负责页面编排，components 负责可复用 UI
2) 为每个 section 输出清晰的文件职责（用注释写在文件顶部）
3) 设计并实现“最小状态模型”（只包含必要状态），例如：
- modal 的 open/close
- 选中态、hover 相关不做（留到 Step 3）
4) 仅实现 state / props / 组件拆分，不实现动效、响应式细节，不加复杂事件（除了最基本的 onClick 打开/关闭如果确实需要挂线）
5) TypeScript 类型必须完整：Props、State 类型、回调函数类型
输出要求：
- 按当前目录结构输出每个文件的完整代码（可以替换/新增文件，但要解释新增原因）
- 不要引入新库（不引入 framer-motion、zustand 等）
- 不要写测试、不要写 a11y、不要写响应式、不要写动画（这些留到后续步骤）
验收标准：
- App.tsx 能清晰编排 sections
- 每个组件 props 单一职责且可复用
- modal/核心交互相关 state 只有一个数据源（单向流）
- `npm run dev` 能跑
参考：以下是 Anima 蓝本代码（仅用于布局参考）：
<PASTE_ANIMA_CODE_OR_FILES>每一步都会对原来的纯UI项目进行翻新处理，这个要看实际项目需求来修改，我这里只是对于现在的这个例子进行prompt编写，每一步都会进行很多的操作，所以比较费时间。
Step3：交互事件
基于你在 Step 2 完成的组件边界与状态模型：
【本次任务仅做 Step 3：交互事件】
请你为以下交互补齐实现（按项目实际组件命名调整）：
1) FloatingButton 点击打开 TimeCapsuleModal
2) Modal 关闭方式：
- 点击遮罩关闭（可配置：点击内容区不关闭）
- 点击关闭按钮关闭
- 按 ESC 关闭
3) 键盘与焦点：
- Modal 打开后焦点应进入 Modal（focus 到第一个可交互元素或容器）
- Modal 关闭后焦点回到触发按钮（FloatingButton）
- Tab 键不会把焦点跑到 Modal 外（实现简易 focus trap，不引入第三方库）
4) 背景滚动锁定：
- Modal 打开时禁止 body 滚动
- 关闭时恢复
5) hover/focus/active 的可视状态：
- Button 的 hover / focus-visible 样式（Tailwind class 或现有样式体系）
限制：
- 不引入新依赖（不使用 focus-trap 库）
- 不改动 Step 2 的组件职责边界（必要时只做最小调整）
- 不做动画、不做响应式（留到 Step 4）
- 不做 a11y（留到 Step 5，但可以为之后预留最小结构）
输出要求：
- 按文件输出完整代码（只输出有改动的文件也可以，但要完整内容）
- 给关键交互逻辑写少量注释
验收标准：
- 鼠标可完整开关 Modal
- ESC 可关闭
- Tab 不会跑出 Modal
- 打开/关闭焦点来回正确
- body 不会在 Modal 打开时滚动Step4：动效与响应式
基于 Step 3 已完成的交互逻辑：
【本次任务仅做 Step 4：动效与响应式】
请你：
A) 动效（优先使用 CSS transition；如结构复杂可引入 framer-motion，但必须说明理由）
1) Modal 的 enter/exit 动效：
- Overlay: fade in/out
- Modal: translateY + scale + fade
- 时长 200~300ms，easing 自然
2) prefers-reduced-motion：
- 用户系统开启减少动态效果时，禁用或显著减少动画
3) hover 动效只做轻量（例如阴影/位移/透明度），不搞花哨
B) 响应式（Tailwind 断点）
1) Mobile（<sm）：单列布局、按钮触达友好、Modal 占满宽度
2) Tablet（sm~lg）：间距加大、内容两列（如果设计允许）
3) Desktop（lg+）：保持原设计的布局比例与 max-width
4) 不使用 magic number，优先使用 Tailwind spacing/width 体系
限制：
- 不改变 Step 2 的组件边界
- 不改变 Step 3 的交互规则与状态模型（只在渲染层加动画/断点）
- 动画实现要可维护，不允许在多个地方复制粘贴一堆 keyframes
输出要求：
- 输出涉及改动的文件完整代码
- 若引入 framer-motion，请同时输出安装命令与最小使用范围（只用于 Modal/关键区域）
验收标准：
- 动画自然，无闪烁，无首次渲染抖动
- 手机、平板、桌面三档布局都合理
- reduced-motion 生效Step5：合规性
基于 Step 4 已完成的结构、交互、动效与响应式：
【本次任务仅做 Step 5：合规性（a11y / 可维护 / 可测试）】
A) a11y（必须）
1) Modal：
- role="dialog" 或 aria-modal="true"
- aria-labelledby / aria-describedby（如果有标题/描述）
2) 触发按钮与关闭按钮：
- button 元素，不用 div 假按钮
- aria-label（如果只有图标）
3) 焦点可见性：
- focus-visible 样式明确（Tailwind）
4) 颜色对比：
- 关键文本颜色与背景保持可读（不要求完美 WCAG 计算，但不能“浅灰对白底”）
B) 可维护性（必须）
1) 清理明显冗余：重复组件、重复样式片段
2) 抽取最小 design tokens（可选）：
- constants 或 tailwind theme 扩展（只做必要的：主色/背景/圆角/阴影）
3) 统一导出方式（index.tsx barrel export，如果你认为值得）
4) 组件 props 文档化：用 TS 注释写清楚（简短）
C) 可测试性（最小集）
1) 引入 Vitest + React Testing Library（只做最小配置）
2) 为关键交互写 2~3 个测试：
- 点击打开 Modal
- ESC 关闭 Modal
- 打开后焦点在 Modal 内（或关闭后焦点回到按钮，择一）
3) 测试不要覆盖样式与动画，只测行为
输出要求：
- 输出新增/修改的配置文件、测试文件、以及相关组件代码
- 给出运行测试命令
- 不要写大量测试，只做最小“企业级底线”覆盖
验收标准：
- 无障碍基本合规（键盘可用、role/aria 正确）
- `npm run test` 可跑
- 关键交互有测试兜底完事儿了之后呢：我们再交给Cursor进行代码的微调以及解决一些微小型的bug就可以了，或者其实到了这个份上也可以完全交给经验丰富的各位开发自己来解决式样问题啦~
让我们来看看Cursor的效果如何！
可以看到右侧的文件目录进行了一些调整，并且每个关键的部分都在开头进行了说明
一个基本的demo就完成了，可以基于此基础进行更多的功能开发，Anima的功能其实说白了主要是省下1：1复刻figma的时间，如果是本文章的网页那种形式的话，UI上会有一些不太一样的地方，但是如果是figma的设计稿，则可以直接省略掉大量的重复的冗余的CSS设计，将开发的重心集中到业务逻辑上来，或者。。让你从前端做到全栈，研究研究后端！
彩蛋：
如果你已经使用了Cursor或者类似的AI IDEA，那么，你可以在项目层面加上这么一句bonus：
你是项目的 Tech Lead。
请只做以下事情：
1) 标出当前代码中“未来一定会重构”的部分
2) 标出“可以接受但不优雅”的部分
3) 不要直接改代码，只写 review comment最后
我们来讲一下到底该用什么心态来应对AI工具：
Anima 解决的是“UI 从哪来”，
Cursor 解决的是“工程如何成立”，
**而真正决定项目上限的，仍然是你是否知道：
每一步该让 AI 做什么，不该让 AI 做什么。
希望大家都能配合AI玩出更多的花样，得到更多的提升~