前端界面生成器

日常要快速产出一个可预览的界面时，最大的摩擦往往不是写一个按钮，而是厘清：这个页面到底是单文件直接看，还是拆成组件进工程？风格往哪边走（极简、拟物还是玻璃拟态）？响应式断点怎么定？可访问性有没有漏掉对比度和语义标签？这类决定一旦模糊，后续返工成本很高。

解决什么问题

• 需求侧描述很粗，页面用途、目标用户和关键模块没有对齐，产出物容易偏离真实意图。
• 技术选型摇摆：什么时候用 HTML/CSS/JS 单文件，什么时候上 React 或 Vue，要不要做响应式。
• 风格表达不一致：极简、拟物、玻璃拟态混在一起，视觉语言漂移。
• 可访问性容易被遗忘：语义标签缺失、颜色对比度不足、键盘体验未验证。

它是怎么做的

这个能力先把需求说清楚，再动手写代码。流程分为四步：

1. 澄清需求：确认页面用途、目标用户、关键模块，以及风格偏好（如极简、拟物或玻璃拟态）。
2. 技术选型：判断是 纯 HTML/CSS/JS 还是引入 React/Vue；是否需要做 响应式 布局。
3. 产出代码：

- 优先交付 单文件 HTML（内联 CSS/JS），方便直接预览；
- 或者给出 组件化结构，例如 React 函数组件 + Tailwind。

1. 自检：确认是否覆盖全部需求点、是否做了响应式、是否关注无障碍（对比度与语义标签）。

输出会先给 3-5 行设计说明（布局、配色、交互思路），再给完整代码块，末尾附上 可继续优化的点。

适用边界与注意点

• 不引入未声明的外部依赖；如果确实需要 CDN 库，会在输出中注明。
• 不臆测后端接口；涉及数据时使用 mock 数据，并通过注释说明替换方式。
• 不输出无法运行的占位片段，优先保证拿到代码后可以完整预览。
• 选型建议基于描述给出，最终方案仍需在真实工程里验证；提交前建议跑一遍构建与基本可访问性检查。