表单页面看起来简单，但它往往是产品转化、注册、支付、询价、KYC、后台配置里最容易出问题的环节。一个按钮文案不清楚、一个错误提示不具体、一个手机号键盘类型没设置、一个提交失败没有重试入口，都可能让用户直接离开。

很多人让 Codex 检查表单时，只会写一句“帮我看看这个表单有没有问题”。这类指令太粗，Codex 可能只会指出代码风格、字段命名或局部 UI 问题，无法覆盖真实用户填写路径。更稳的方式是把表单可用性拆成可检查的维度：字段是否必要、顺序是否合理、校验是否一致、错误是否可恢复、提交是否有反馈、移动端是否好填、键盘和辅助技术是否能正常使用。

核心判断：表单可用性检查不是单纯改样式，而是检查用户从看到表单、理解字段、输入内容、处理错误、提交成功或失败的完整路径。Codex 适合做这类检查，但前提是你要给它明确的页面范围、业务目标、用户角色和验收标准。

一、为什么表单页面不能只靠肉眼检查

设计师看表单，容易先看间距、对齐、字号和视觉层级；开发者看表单，容易先看组件复用、状态管理和校验代码。这些都重要，但真实用户遇到的问题经常藏在流程里，而不是截图里。

• 字段太多：用户不知道哪些字段是真正必须填写，尤其是询价、注册、企业认证、后台配置类表单。

• 提示太虚：“输入不合法”“提交失败”这类文案没有告诉用户下一步该怎么改。

• 校验太晚：用户填完一整页才发现格式错误，返工成本高。

• 状态缺失：点击提交后没有 loading、禁用、成功、失败、重试状态，用户会重复点击或误以为页面卡死。

• 移动端难填：键盘遮挡输入框、底部按钮被遮住、输入类型不对、验证码倒计时位置混乱。

• 辅助体验差：label 没有关联输入框，Tab 顺序混乱，错误信息没有被读屏器感知。

所以，表单检查不能只问“好不好看”，而要问“用户能不能低成本、少迷惑、可恢复地完成提交”。

二、Codex 适合检查哪些表单页面

Codex 适合检查已经有代码实现的表单页面，尤其是 Next.js、React、Vue、后台管理系统、SaaS 控制台、营销落地页和小程序 WebView 页面。只要表单逻辑在项目里能被定位，Codex 就可以读组件、读校验逻辑、读状态处理，并给出更具体的问题清单。

三、让 Codex 检查前，你要先给清楚 6 件事

表单检查最怕范围不清。你不给业务目标，Codex 只能按通用代码规范查；你不给用户角色，它不知道哪些字段是必要的；你不给禁止修改范围，它可能顺手改了视觉结构或接口逻辑。

• 页面路径：例如 app/(auth)/register/page.tsx、src/pages/contact.tsx、components/forms/LeadForm.tsx。

• 表单目标：用户填写完成后要达成什么结果，例如注册账号、提交询盘、保存配置、发起支付。

• 用户角色：例如新用户、企业客户、后台运营、移动端访客、海外用户。

• 业务约束：哪些字段必须保留，哪些字段来自后端协议，哪些字段不能改名。

• 技术栈和命令：例如 npm run lint、npm run test、npm run build、npx playwright test。

• 本轮目标：先审查不改代码，还是允许 Codex 直接修复低风险问题。

建议：第一次不要直接让 Codex 修改表单。先让它输出“问题清单 + 严重程度 + 修改建议 + 涉及文件”。确认方向后，再让它分批修复。

四、表单可用性检查维度

下面这张表可以直接变成 Codex 的审查清单。它的价值是把“体验问题”转成 Codex 可以逐项读取代码和验证行为的检查项。

五、推荐的 Codex 检查流程

不要把表单检查写成一次大任务。更稳的流程是三轮：第一轮只审查，第二轮修复低风险问题，第三轮补测试和验收。

第 1 轮：只审查，不修改

先让 Codex 读取页面和相关表单组件，输出字段清单、状态清单、校验逻辑和可用性问题。这个阶段不要让它改代码，因为你需要先判断哪些建议符合业务。

第 2 轮：只修低风险问题

低风险问题包括：label 关联、错误文案、按钮 loading 文案、input type、autocomplete、aria-describedby、禁用重复提交、字段说明补充。这些通常不会改变业务协议。

第 3 轮：补充测试和验收

让 Codex 补充单元测试、组件测试或 Playwright 测试，至少覆盖：正常提交、必填为空、格式错误、接口失败、防重复提交、移动端视口下的关键路径。

六、可复制的 Codex 一键审查指令

下面这条指令适合第一次让 Codex 检查表单页面。重点是“先审查、不改代码”，输出结构要清楚。

你现在是一个前端表单可用性审查助手。 请检查本项目中的表单页面：[填写页面路径或组件路径]。 业务背景： - 表单目标：[例如：用户提交询价 / 注册账号 / 保存后台配置] - 主要用户：[例如：移动端新用户 / 企业客户 / 后台运营人员] - 成功状态：[例如：提交成功后进入感谢页 / 保存成功并提示 / 返回列表] 本轮任务： 先只做审查，不要修改代码。 请阅读相关页面、组件、校验 schema、接口调用和状态处理代码，输出完整问题清单。 请按以下维度检查： 1. 字段是否必要，字段顺序和分组是否合理。 2. label、placeholder、说明文案是否清楚。 3. 必填 / 选填标识是否一致，前端和后端校验是否一致。 4. input type、inputMode、autoComplete 是否适合移动端填写。 5. 错误提示是否具体，是否告诉用户下一步怎么修复。 6. loading、disabled、success、error、retry 状态是否完整。 7. 是否存在重复提交、提交失败清空表单、接口错误不可恢复等问题。 8. 移动端视口下是否可能出现键盘遮挡、按钮不可见、滚动定位错误。 9. label 关联、aria-describedby、焦点顺序、键盘操作是否符合基础可访问性要求。 10. 是否需要补充组件测试、单元测试或 Playwright 测试。 输出格式： - 先列出你发现的表单字段清单。 - 再列出问题表格：问题、严重程度 P0/P1/P2、涉及文件、原因、建议修复方式。 - 最后给出一份“允许低风险修复的任务清单”。 限制条件： - 不要改业务接口字段名。 - 不要重写整个表单架构。 - 不要改变页面视觉风格。 - 不要引入新的生产依赖，除非先说明理由。 - 如果信息不足，先列出需要我确认的问题。

七、允许 Codex 修改时，用这条修复指令

当你确认审查结果后，可以让 Codex 只修低风险问题。不要直接说“全部修掉”，否则容易出现大范围重构。

请基于上一轮表单可用性审查结果，只修复低风险问题。 允许修改： - 补充或修正 label 与 htmlFor / id 关联。 - 优化 input type、inputMode、autoComplete。 - 补充 aria-describedby，让错误信息和字段说明能被关联。 - 优化错误提示文案，让用户知道应该怎么改。 - 增加 loading、disabled、防重复提交状态。 - 保留用户已填写内容，不要因为提交失败清空表单。 - 补充必要的测试，覆盖正常提交、必填为空、格式错误和提交失败。 禁止修改： - 不要修改后端接口字段名和请求结构。 - 不要改变页面布局和品牌视觉。 - 不要新增大型表单库或校验库。 - 不要把多个表单重构成全新的架构。 完成后请输出： 1. 修改了哪些文件。 2. 每个修改对应解决了哪个可用性问题。 3. 已运行的检查命令和结果。 4. 仍然需要人工确认的问题。 请运行： - npm run lint - npm run test（如果项目有测试） - npm run build（如果本次修改影响构建）

八、AGENTS.md 里可以加入的表单规则

如果你的项目经常做表单页面，不要每次都重复写规则。可以把稳定的表单规范放进 AGENTS.md，让 Codex 每次处理表单时自动继承这些约束。

表单页面开发与审查规则 ## 基础原则 - 表单修改必须优先保证业务字段和接口协议不变。 - 不允许为了优化体验而删除业务必需字段。 - 不允许在没有确认的情况下引入新的表单库、校验库或状态管理库。 ## 输入字段 - 每个输入控件必须有明确 label，不允许只依赖 placeholder。 - label、说明文案、错误信息应与字段建立可访问性关联。 - 手机号、邮箱、数字、密码等字段必须使用合适的 type / inputMode / autoComplete。 ## 校验和错误 - 必填、格式、长度、范围等规则要尽量与后端保持一致。 - 错误提示必须说明具体问题和下一步修复方式。 - 提交失败不能清空用户已输入内容，除非业务明确要求。 ## 提交状态 - 提交中必须有 loading 状态。 - 提交中应禁用重复提交。 - 提交成功和失败都必须给用户明确反馈。 ## 验证 - 修改表单后至少运行 lint。 - 如果已有测试体系，补充或更新关键路径测试。 - 输出最终结果时必须说明已验证的路径和未验证的风险。

九、不同类型表单的专项检查提示词

不同表单的风险不一样。你可以在主指令后追加专项要求，让 Codex 更聚焦。

十、让 Codex 输出什么，才方便你判断

表单检查不能只要一段结论。你需要的是可以执行和复查的结果，最好让 Codex 固定输出 4 类内容。

• 字段清单：包括字段名、显示名称、是否必填、校验规则、错误提示、默认值和提交字段。

• 问题清单：每个问题标注严重程度、影响路径、涉及文件和建议修复方式。

• 低风险修复清单：告诉你哪些可以直接交给 Codex 改，哪些需要产品或后端确认。

• 验收清单：列出正常提交、异常提交、移动端填写、键盘操作、接口失败等需要检查的路径。

如果 Codex 只输出“整体还可以，建议优化错误提示”，这个结果没有用。真正可用的输出应该能让你打开文件、定位问题、判断优先级，并决定是否让 Codex 继续修改。

十一、表单可用性验收标准

当 Codex 完成审查或修复后，可以用下面这份清单验收。

十二、常见错误

错误 1：让 Codex 直接“优化表单体验”

这个指令太泛。Codex 不知道你是要改视觉、改校验、改字段，还是改提交流程。结果很可能是局部美化，而不是系统检查。

错误 2：不给业务约束

有些字段看起来多余，但可能是后端风控、销售分配、支付结算或合规要求。不给约束，Codex 可能建议删除不该删除的字段。

错误 3：一次性检查所有表单

项目里表单很多时，不要让 Codex 一次性检查全部页面。应该先选一个高价值页面，例如注册页、询价页或支付页，形成检查模板后再扩展。

错误 4：只检查静态代码，不检查状态

表单体验的大部分问题都和状态有关：输入中、校验中、提交中、提交成功、提交失败、接口超时、用户返回。只看 JSX 结构是不够的。

错误 5：只修文案，不补验证

错误提示改得再好，如果提交失败后表单清空，或者重复点击会重复提交，问题依然存在。让 Codex 修复时要同时要求运行测试或补充关键路径测试。

十三、FAQ

1. Codex 能不能直接判断一个表单好不好用？

能做初步判断，但不要把它当成真实用户测试替代品。Codex 更适合基于代码检查结构、校验、状态、可访问性和异常路径；真实业务转化率仍然需要数据和用户反馈验证。

2. 没有测试的项目，也能让 Codex 检查表单吗？

可以。先让 Codex 做静态审查和人工验收清单，再逐步补充测试。不要因为没有测试就直接让它大改表单。

3. 表单文案要不要也交给 Codex 改？

可以，但要给语气和业务边界。例如“面向企业客户，语气专业，不要夸张营销，不要改字段含义”。错误提示尤其适合让 Codex 批量优化。

4. Codex 检查表单时需要截图吗？

有截图更好，尤其是移动端键盘遮挡、按钮位置、视觉层级和错误状态。但如果代码里状态完整，Codex 也可以先做代码层面的审查。

5. 设计师不会代码，怎么用这篇里的指令？

可以把页面路径、业务目标和你看到的问题描述清楚，让 Codex 先输出问题表。你不需要先懂所有代码，但需要能判断哪些建议会改变业务流程。

6. 表单检查完成后，最值得沉淀什么？

最值得沉淀的是表单规则：字段命名、必填标识、错误提示、提交状态、移动端输入、可访问性和测试要求。把这些写进 AGENTS.md，后面每次做表单都会更稳定。

总结

用 Codex 检查表单页面可用性，关键不是让它随便点评，而是把表单拆成用户填写路径和工程检查项。先审查字段和状态，再修低风险问题，最后补测试和验收，这样才不会把一次体验优化变成不可控重构。

最实用的做法是：给 Codex 页面路径、表单目标、用户角色、业务约束和检查维度；要求它先输出字段清单和问题表；确认后再分批修复 label、输入辅助、错误提示、提交状态和测试。表单越接近转化和交易，越要遵守“先审查、再小步修改、最后验收”的流程。

————————————————————————

参考资料与事实依据

• OpenAI Codex 官方开发者文档：Codex 是面向软件开发的 coding agent，可帮助写代码、理解代码库、审查代码、调试修复和自动化开发任务。

• OpenAI Codex AGENTS.md 官方文档：Codex 会在工作前读取 AGENTS.md，项目可以用它沉淀仓库规则、运行命令、约束和验收标准。

• OpenAI Codex Best practices 官方文档：更可靠的任务指令通常包含目标、上下文、约束和完成标准；复杂任务建议先规划，再实施和验证。