上一篇做完“列语义表”还不能直接进入交付。设计规则是否真的落到了模板里需要重新沿每一列检查一遍。我不太喜欢只拿一行正常数据验表格。正常数据会把很多问题藏起来字段都有值、标题长度刚好、状态都在字典里、当前账号又拥有全部权限。这样的页面当然容易显得完整。更有效的做法是给不同类型的列准备不同的检查值。空值列看缺失语义文本列看极端长度状态列看未知代码操作列看权限与行状态组合。这不是编造测试结果。下面给出的是验收设计只有在真实项目中执行过对应步骤才能记录为通过。先按列类型分组不从左到右机械检查我会先把列分成几组标识和普通文本数值、金额与计数时间和范围枚举与状态图片、链接等特殊内容操作列。同一组共享一部分风险。例如数值列要防止把0当空值状态列要检查未知代码特殊内容要考虑加载失败和安全边界。按风险分组比从第一列一路看到最后一列更容易发现一致性问题。它也便于给 Codex 下达局部任务只修改状态展示时不要顺手调整所有列宽。空值验收先定义“空”再看占位我会为相关字段准备下面几种输入null undefined 0 false []这些值不能被同一个value || -处理掉。代码审查阶段可以确认条件判断是否误伤0和false也能看出空数组是否被直接渲染。页面阶段则要确认占位符是否与列对齐、Tooltip 是否对占位符生效以及空状态有没有被误认为加载中。我还会追一层业务含义。某列没有数据时是没有填写、没有权限、暂未计算还是接口没有返回如果含义不同就不该全部显示成同一个短横线。因此空值检查的交付结果不只是“统一加了-”而应该记录每类列的缺失策略。长文本验收至少看四种长度短文本无法证明列宽合理。我会准备一个正常名称接近预期上限的内容明显超过列宽的连续文本包含换行、空格或中英文混排的文本。随后检查省略、Tooltip、复制和横向滚动。Element Plus 的show-overflow-tooltip能提供常用的溢出提示但它不替代内容策略。连续英文或编号未必按中文自然换行Tooltip 也可能被弹层层级、容器裁切或敏感信息要求影响。如果用户经常需要比对完整内容我会考虑扩大min-width或把关键内容移到更合适的位置。如果只是偶尔查看省略加提示更合适。没有页面和数据证据时这仍是待验证决定。状态列验收正常映射只是第一步状态列至少要覆盖三种输入已知状态、未知状态、缺失状态。已知状态检查文字和样式是否来自项目统一配置。未知状态用来验证前后端版本暂时不一致时页面会不会显示空白。缺失状态则要判断它与“未知代码”是否同义。如果状态还会控制操作按钮需要把组合一起列出来行状态编辑删除查看依据草稿按权限决定按权限决定可查看业务规则已发布可能禁用可能禁用可查看业务规则未知状态默认收紧默认收紧视项目策略风险兜底表中内容只是结构模板不是某个具体业务的既定规则。实际按钮权限必须来自需求、项目代码或用户确认Codex 不能根据状态名称自行补全。时间列验收格式正确还不够时间列需要核对原始值类型、格式化入口和空值。时间范围还要检查只有开始时间、只有结束时间以及二者顺序异常时怎样展示。当前web-skills提供getTimeFun也有起止时间组合展示的范例。在目标项目采用这套规范时我会优先复用避免在插槽里重复切字符串。但工具函数能格式化日期不会替我决定时区、精度和业务文案。列表要显示到日、分钟还是秒应该由页面用途决定。涉及跨时区数据时更不能把本地Date转换当作默认正确答案。操作列验收要拆成“看得见”和“做得到”权限控制常被误解成隐藏按钮。实际上需要分开验证当前用户是否看见按钮按钮是否因行状态禁用即使绕过界面接口是否仍有权限保护点击后是否进入正确弹框和数据流操作结束后列表怎样刷新。web-skills中的v-disOperation负责项目内的前端操作权限表现useDialogImp负责弹框状态delRow连接确认和刷新。它们各自解决一段问题不能互相代替也不代表前端权限能替代后端鉴权。我会特别看编辑按钮传递的行数据。如果把响应式行对象直接交给表单用户尚未保存表格内容可能已经跟着变化。项目采用传 ID 后获取详情还是复制行对象要以既有范式为准。特殊列不要只验证成功路径图片列要检查空地址、加载失败、比例异常和预览链接列要检查文本、地址来源和打开方式富文本摘要要避免直接把未经处理的 HTML 塞进表格。当前项目规范包含viewImg和noData等公共组件。使用它们之前仍要读清输入契约尤其是基础地址、预览和失败占位不能只看组件名猜行为。这类列如果没有真实需求材料我不会为了让文章显得完整而编造一套实现。更稳妥的做法是列为按需检查项等具体页面出现时再验证。哪些能看代码哪些必须打开页面我会把验收证据拆开检查项代码审查页面验证字段来源和转换函数可以确认用真实响应复核0、false是否被误判为空可以确认确认最终文字和样式长文本是否配置省略可以确认必须看宽度、Tooltip 和滚动状态映射是否覆盖未知值可以确认确认颜色、文案和可读性权限指令是否使用可以确认换不同权限账号或模拟条件验证固定列和横向滚动只能看到配置必须在不同宽度页面检查点击后的弹框和刷新可追调用链必须走完整操作路径这张表能防止两种假完成只看页面说“没问题”却不知道参数和权限从哪里来只看代码说“已经处理”却没发现 Tooltip 被遮挡、列宽失衡或固定列抖动。我会让 Codex 输出逐列验收结果请按列类型验收本次表格改动并输出 ​ 1. 已检查的字段值域正常、空值、0/false、超长、未知枚举。 2. 每列使用直接 prop、插槽或公共组件的理由。 3. 代码审查已经确认的结论及对应文件位置。 4. 必须进入页面验证的项目不得写成已通过。 5. 操作列的权限、行状态、弹框、接口和刷新路径。 6. 未验证项和所需环境。 ​ 只修改当前任务涉及的列不顺手统一全表样式。 项目已有格式化、图片、权限和按钮组件时优先沿用。这份结果不要求 AI 宣布“全部完成”反而允许它明确写出未验证。对工程交付来说诚实的未验证项比一句“展示正常”更有价值。写在最后逐列验收并不是把表格测试变得繁琐而是让不同类型的数据接受与风险相匹配的检查。普通文本、状态和操作列表面上都占一个单元格背后的契约完全不同。把它们分开检查Codex 才不会用同一种模板处理所有内容。下一篇将进入分页问题。重点不是再讲一次“新查询回第一页”而是沿接口响应、总数、页码和删除后的数据变化定位页码与列表错位究竟发生在哪一层。本系列持续更新后续仍会在每篇写作后运行表达质检与真实性复核。