移动端适配外包前应整理哪些需求：把旧页面改造范围写清楚
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7da4eea5842e.html
📄
移动端适配外包前应整理哪些需求：把旧页面改造范围写清楚
把移动端适配外包出去之前，最该整理的不是一份“我要响应式”的口号，而是一份能让对方报价和排期的现状清单：现有页面有哪些、哪些必须改、在哪些设备上算合格、内容与功能是否要同步调整。需求写得越接近可验收的标准，后期返工和加价的空间就越小。
先盘清现有页面，而不是先谈技术方案
移动端适配是在原有基础上改进，所以第一步是把“原有”说清楚。建议按下面的顺序整理，形成一份可以直接发给外包方的清单：
- 页面清单：列出所有需要适配的页面，标明哪些是核心页面、哪些可以延后。
- 现状截图：每个页面提供桌面端截图，并注明当前在手机上打开时的实际问题，例如横向滚动、文字过小、按钮点不到、图片超出屏幕。
- 内容优先级：说明手机上哪些内容必须优先展示，哪些可以折叠或下沉。
- 功能清单：表单、筛选、轮播、弹窗、地图、支付等交互，逐个标明是否需要在移动端保留。
这份清单的价值在于把“适配”拆成可判断的条目。如果只写“整体改成移动端友好”，外包方只能凭经验猜，报价自然也会留出很大浮动空间。
把验收标准写成能检查的条件
需求里最容易缺失的是验收口径。移动端适配的合格与否，不能只靠“看起来还行”，要给出可执行的检查项：
- 确定需要覆盖的屏幕宽度范围，例如从 320px 到 430px 的常见手机宽度，以及是否需要兼顾平板。
- 确定测试设备或浏览器环境，例如 iOS 与 Android 各选一到两个真实设备或模拟环境。
- 明确不允许出现的问题：横向滚动条、内容被遮挡、点击区域过小、字体小于可读下限。
- 明确导航方式：是保留顶部菜单，还是改为折叠菜单或底部导航。
- 明确图片处理方式：是否按屏幕宽度加载不同尺寸，避免手机加载桌面大图。
这些条件不是技术炫技，而是双方对“做完”这件事的共同定义。验收信号越具体，越容易在交付时判断是修还是过。
区分必须改与可以不改，控制改造范围
已有项目的适配往往牵扯历史结构，全部推倒重做通常不现实。整理需求时要主动划出边界：
- 必须改：影响用户完成核心操作的页面，例如注册、下单、提交表单。
- 可以改：访问量低、内容以阅读为主、结构简单的页面。
- 暂不改：已计划下线或改版的页面，避免重复投入。
同时要说明是否允许调整原有 HTML 结构、CSS 和脚本。如果只允许在现有样式上打补丁，适配效果可能受限；如果允许重构部分结构，方案空间更大，但也要约定改动不能破坏桌面端已有表现。这个取舍需要在需求阶段就写清楚，而不是等交付时再争论。
内容、SEO 与后续维护也要一并交代
移动端适配不只是视觉问题。页面结构变化可能影响标题层级、正文可读性和链接可点性，因此需求中应包含：
- 移动端是否保持与桌面端一致的标题和正文内容，不做隐藏关键信息处理。
- 页面地址是否保持不变，避免适配过程中产生重复页面或失效链接。
- 是否需要在交付时提供改动说明，方便后续自己维护。
如果原有页面已经有一定搜索流量，适配时更要避免把正文内容整体塞进图片或默认折叠到不可见。抓取、索引和排名是不同环节，移动端改动影响的是用户获取内容与搜索引擎理解页面的过程，不能简单理解为“改完就一定掉排名”或“改完就一定涨”。
一个可直接套用的需求整理示例
假设有一个企业展示站需要做移动端适配，需求可以这样写：
范围：首页、产品列表页、产品详情页、联系我们页。目标：在 320px–430px 宽度下无横向滚动，正文可读，表单可正常提交。不改：新闻列表页暂不处理。验收：用两台真机检查上述页面，导航可展开，按钮可点击，图片不超出屏幕。交付：提供改动文件清单和测试说明。
这段示例不是报价单，而是把范围、标准、例外和交付物写在一起。外包方拿到后能判断工作量，你也能在验收时逐条核对。适用条件是页面数量有限、结构相对稳定；如果项目包含复杂交互或大量历史页面，还需要补充接口、登录状态和第三方组件的说明。
下一步，先按上面的清单把页面逐个过一遍，标出必须改、可以改和暂不改三类，再把验收条件写成可检查的句子。这份整理完成后，再去询价和对比方案，沟通成本会明显降低。
