“帮我做一个好看的页面”不是可以验收的需求。要让 AI 生成能接进项目的网页代码，必须把视觉意图翻译为组件、状态、数据和边界条件。先写清契约，再让它落代码，返工会少很多。
一份前端提示词至少写清五件事
| 部分 | 需要说明 |
|---|---|
| 页面目标 | 用户来到页面后要完成什么动作 |
| 技术约束 | 框架、组件库、样式方案和已有规范 |
| 数据状态 | 加载、为空、出错、成功时分别显示什么 |
| 响应式规则 | 窄屏如何折叠、按钮如何换行 |
| 验收标准 | 可访问性、交互、性能与测试要求 |
可复用的页面生成模板
请为现有项目实现一个页面组件，不新增未经说明的依赖。
页面目标：[例如：让用户筛选并查看教程列表]
技术环境：[框架、语言、样式约束]
已有组件：[可复用的 Button、Card、EmptyState 等]
状态要求：加载中、无数据、请求失败、正常数据都要处理。
响应式：小于 768px 时筛选区换行，卡片单列。
输出顺序：
1. 组件结构说明；
2. 完整代码；
3. 需要我补充的接口字段；
4. 最少的测试用例清单。
不要虚构接口；未知字段用类型注释标记。先拆组件，再生成实现
先让 AI 画出组件树，例如 FilterBar、ArticleGrid、ArticleCard 和 EmptyState。确认输入输出后，再逐个生成。这样既便于评审，也能让样式和状态逻辑保持一致。生成后可再用提示词结构化控制的思路检查输入是否遗漏。
代码交付前的四项检查
- 是否真的使用了项目现有组件与样式规范。
- 空数据和失败状态是否可见、可操作。
- 表单与按钮是否具备清晰的焦点和错误提示。
- 有没有把密钥、假接口或不必要的依赖带进代码。
把验收反馈继续喂回去
不要只说“这里不对”。把浏览器报错、截图描述、控制台信息和期望行为一起给 AI，并要求它说明修改范围。每次只处理一个问题，才能判断修复是否真的生效，也能为后续组件积累可复用的提示词模板。
