从一句需求到可检查的网页，先搭这三层

先决定网页需要帮助谁完成什么

“做一个好看的网页”不能指导取舍。先把需求写成：“让第一次了解项目的人，在手机上看懂它能解决什么问题，并找到正确的下一步入口。”

这套方法适用于单页介绍、内容专题和功能有限的小工具。需要账户、支付、在线上传或敏感信息处理时，应额外设计服务端、权限和数据保护，不把一个静态页面误当成完整系统。

1. 写一页需求说明

准备以下输入，再交给你选择的代码助手或网站制作工具。工具的使用权限、代码执行方式和发布范围需要按实际环境确认。

页面服务对象：[具体人群]
他们来到这里要完成的事：[一个主要任务]
主要行动入口：[看详情、下载文件或打开某个真实地址]

必须出现的内容：
- [准确介绍]
- [使用条件]
- [能核对的案例或材料]
- [联系或反馈方式；没有时不要虚构]

已有素材：[文字、图片与文件路径]
视觉方向：[简洁、紧凑、适合手机]
限制：[不能收集的资料、不能承诺的功能、部署环境]

验收：
- 手机能找到主要入口；
- 链接目标真实有效；
- 没有伪造的用户数量、客户标志或反馈；
- 表单行为与提示一致。

只选一个主要行动。把“关注、注册、购买、下载、联系我们”同时放成同等大小的按钮，会让页面缺少优先级。

2. 先搭内容结构

第一轮只要求输出页面区块顺序和每块的内容草稿。例如：标题与一句说明、三个用途、使用步骤、限制、主要行动入口。让工具说明每块为什么存在；没有明确用途的区块可以删除。

这一轮检查的是“别人能否理解”，不是装饰效果。把具体文本填进去以后，再判断标题是否太长、手机上是否会连续出现几屏介绍却没有入口。

3. 再做能实际操作的页面

内容结构确定后，再生成或编辑HTML、CSS及必要脚本。简单页面优先用现成浏览器能力完成，不为一两个按钮加入复杂依赖。

让工具列出每个按钮会发生什么。下载按钮必须指向真实文件；表单如果只在本机生成文本，就明确写“下载记录”，不能写成“提交成功”。没有接入的能力不要放一个可点击但没有结果的入口。

在本地启动预览后，自己完成一次主要任务。不要只看截图：实际点链接、输入内容、提交空表单、用键盘切换焦点，再回到首页。

4. 用两种屏幕检查阅读与操作

至少检查一台桌面尺寸和一个手机窄屏。先看是否有整页横向溢出，再看长标题、英文链接、表格和代码块是否挤破布局。

• 第一屏能否识别网站主题，并找到一个实际可用的入口？
• 手机上按钮是否容易点击，操作之间是否有足够间隔？
• 图片是否有准确替代文字，重要信息是否也能从文字读到？
• 仅使用键盘时，是否能看到焦点并完成主要操作？
• 深浅主题下，输入框、链接和提示是否保持可读？

不要为了让截图更紧凑而裁掉重要名称，也不要把必要解释藏到鼠标悬停后才能阅读。

5. 把问题写成可以修复的记录

用“页面位置—操作—实际结果—期望结果”记录问题。例如：“390px宽手机，点击主按钮后跳到不存在的地址；应该打开活动详情页。”这比“体验不太好”更容易得到准确修复。

每次只修一组相关问题，再重复受影响的操作。最终交付页面文件、使用说明、已检查的屏幕和操作清单，以及仍未接入的服务说明。

本地能浏览不等于已经公开发布。域名、HTTPS、服务器配置、公开联系信息、实际访问检查和后续维护，都应在公开提供服务前明确。