用 Codex 检查 Tailwind 移动端样式

Tailwind 写页面很快，但移动端问题也很容易藏起来。桌面端看着整齐，手机上可能出现标题挤出屏幕、按钮太小、卡片横向滚动、导航遮挡内容、图片比例变形、表单字段难点。Codex 可以帮助你阅读 class、找可疑布局和生成修复建议，但移动端是否真的可用，必须靠人工在具体视口里验证。

这篇文章适合小网站、作品集页、落地页、服务页和 AI 生成页面的移动端复核。若你要完整交付流程，可以配合 小网站交付前检查；若只需要短表版，可以看 Tailwind 移动端检查清单。

适合谁

适合会写基础 Tailwind class、但还没形成移动端检查习惯的新手。你可能已经会用 flex、grid、p-4、md:、lg:，但不确定什么时候需要换行、堆叠、限制宽度或调整按钮尺寸。

也适合接小网站样式修复的人。客户常说“手机上看起来怪”，但不会告诉你具体原因。你需要把问题拆成可复现截图、视口宽度、影响范围和修复建议。

不适合谁

不适合只看桌面端预览就交付的人。移动端样式必须打开小屏检查，尤其是导航、CTA、表单和长标题。

也不适合在大型设计系统里随意改共享 class 的新手。如果一个组件被很多页面复用，改动前要确认影响范围，不能只修当前页面截图。

风险提醒

移动端样式修复常见风险是“修一个宽度，坏三个页面”。比如给某个容器加 w-full、overflow-hidden、absolute 或固定高度，当前截图看起来好了，但其他内容被裁剪。Codex 可能给出局部修复，你要检查共享组件和多个视口。

项目场景还要注意客户素材。logo、长英文单词、产品图、价格表、第三方嵌入和表单字段都可能撑破布局。不要只用你自己的短文案测试。

具体步骤

1. 先复现问题。记录页面路径、设备或视口宽度、浏览器、截图和客户原话。不要只写“移动端不对”。

1. 确认影响范围。判断是单个页面、单个组件，还是全站导航、卡片、表单等共享部分。

1. 让 Codex 读 class。可以要求它只指出可能导致溢出、固定宽度、错位或遮挡的 class，不要直接大改组件。

1. 检查断点逻辑。看默认样式是否先适配小屏，再用 sm:、md:、lg: 往上增强。很多新手反过来写，导致手机继承桌面布局。

1. 检查可点击区域。按钮、菜单、表单输入框不要太小，文字不要贴边，CTA 不要被 sticky 元素遮挡。

1. 检查内容极端值。长标题、长邮箱、价格表、多行按钮、客户 logo、不同图片比例都要看。只有短文案通过不算完整验证。

1. 保存交付证据。至少保留修改前截图、修改后截图、检查视口、已覆盖页面和未覆盖范围。需要排查日志时可用 报错解释器，报价可用 报价计算器。

Codex 提示词示例

请检查这个 Tailwind 组件的移动端风险。
先不要重写代码，只列出可能导致横向滚动、遮挡、固定宽度、按钮过小或内容溢出的 class。
请说明每个风险需要在哪些视口验证。

先审查，再修改，比直接生成新布局更稳。尤其做项目时，客户关心的是问题是否被可靠修复，而不是代码看起来更复杂。

交付记录怎么写

交付记录可以写：检查页面、视口宽度、问题截图、修复摘要、验证截图、未覆盖设备和客户待确认事项。若这次修复属于小网站交付的一部分，可以把记录放入 模板库 的交付记录模板。

如果客户还没有明确修复范围，可以用 Proposal 生成器整理确认问题，再人工改成简短消息。

常见验证场景

建议至少准备三种内容场景。第一种是短内容：标题、按钮和图片都比较短，用来确认基本布局。第二种是真实内容：放入客户最终文案、真实 logo 和真实图片，看是否撑破。第三种是极端内容：长英文、长邮箱、多行价格、三到四个 CTA、图片比例不一致，用来找边界。

如果只用短内容检查，移动端问题很容易被掩盖。尤其服务页、价格页和作品集页，真实客户文案通常比 demo 文案长。交付前把这些场景跑一遍，能减少上线后的尴尬返工。

和客户沟通怎么说

可以把移动端检查描述成“按指定视口和页面做诊断”，不要说成无限修复。比如：“我会检查首页、服务页和联系页在 375px、768px、桌面宽度下的布局，输出截图、问题等级和建议修复；如果发现共享组件或设计范围变化，会单独确认。”

这句话把页面数量、视口、交付物和暂停条件都说清楚。对新手来说，清楚边界比表现得什么都能做更重要。

CTA：下一步

打开一个 Tailwind 页面，在 375px、768px 和桌面宽度各看一次。把所有横向滚动、遮挡、按钮太小和长文案溢出记录下来，再用 检查清单 逐项复核。

免责声明

本文是学习和流程整理，不构成法律、财务、安全或职业承诺。具体修复需要结合项目代码、设计要求、客户素材、浏览器环境和真实设备人工判断。