这次遇到的场景很具体：同一套成片审看页面，要同时服务两种相近的口播工作流。它们看起来像是同一个产品里的两个入口，实际上数据状态并不完全一样。页面文件只有一套，通过不同的 profile 区分当前工作流。于是，改动一个地方，很可能同时改变两边的体验；而一边看起来正常，也不能证明另一边真的可用。
改造开始前，首屏中间和右栏大面积留白，缩略图是灰块，顶部有 6 个状态筛选和 2 个日期框，挤在一起既不利于浏览，也不利于审看。另一种工作流的统计还长期呈现类似“0/17”的单调状态。表面上看，这是一次页面美化；实际上，我面对的是一个共享页面如何承受两套数据现实的问题。
共享页面改造的第一原则，是先守住业务边界，再讨论视觉是否更漂亮。
先确认一页到底服务谁
我一开始很容易把它理解成“把空白填满”。但看清页面结构后，真正的问题不是页面没有足够多的装饰，而是同一份展示层要根据 profile 呈现不同队列。两种工作流共用文件，意味着组件、筛选、播放区和空态都必须能适应不同数据；也意味着不能因为其中一边的样本更完整，就把另一边的真实状态隐藏起来。
所以我先把共享依赖列出来：状态列如何分组，卡片从哪里取标题和时间，选中项如何进入播放区，筛选如何影响当前列表，失败信息从哪里显示。与此同时，把不可改的部分写清楚：业务接口不动，原有同步失败提示保留，真实数据是什么就呈现什么。这个边界不是形式上的约束，它决定了我只能调整布局、层级、默认选中项和空态说明，不能用页面代码替后端补数据。
如果不先划清边界，后面很容易把“页面看起来没有内容”误判成“接口需要重新设计”。这样做会导致两个问题：一方面，正在被其他流程使用的接口可能被无意改坏；另一方面，页面虽然充满了卡片，却失去了对真实同步状态的诚实表达。
空白首屏不等于没有内容
改造前的空白很有迷惑性。中间没有首屏成片，右侧也没有默认审看对象，第一眼会让人以为系统没有数据。可是已有的成片并不是不存在，只是没有被组织成一个能被看见、能被点击的队列。页面承担的是审看任务，首屏却没有把“现在可以看什么”告诉使用者。
我选择先把成片按审核状态分列，再让选中的成片进入大窗和右侧播放区，是因为这条路径同时解决了发现和行动两个问题。使用者先看到作品处于什么状态，再直接开始播放，而不是先在空白里猜测下一步。页面顶部的 REVIEW 区也压缩到约 72px，把更多空间还给真实队列；筛选则收进更紧凑的区域，避免把审看对象挤到首屏之外。
这里最容易误判的是，把“首屏有东西”当成“首屏有效”。如果只是放几块静态示例卡，页面会显得完整，却不能证明播放、筛选和状态切换真的连得上。真正有效的首屏，至少要让人看见真实标题或事实条，能选中一条成片，并能在播放区看到进度变化。
两套数据决定两种布局判断
第一种工作流的数据相对分散，按状态分列后，每一列都需要保留足够的识别空间。第二种工作流则出现了 17 条记录集中在“已确认·待发布”一列，另外两列为空。如果机械地给每列分配相同宽度，就会得到两条很宽的空列和一条被压缩的内容列，页面看似规整，阅读效率反而下降。
因此我没有用一套固定列宽覆盖两边，而是让空列折叠成约 56px 的窄条，保留竖排名称和数量，并允许点击展开；有内容的列则把空间让出来，在列内使用 2-3 列小卡网格。当某个状态占比超过 80% 时，默认进入更适合浏览的网格视图。这个判断不是为了追求特殊效果，而是回应真实数据分布：空状态需要被看见，但不应该消耗和有效内容一样的空间。
同一个页面的验收标准不能只来自设计稿，还必须来自每个 profile 的真实数据分布。
卡片密度也要跟着场景变。原来的竖卡太高，1440 宽度下首屏只能看到很少几张，审看者还要频繁滚动。调整后，缩略图采用 9:16 的小图放在左侧，标题、时间和状态放在右侧；没有封面的记录不再用灰块伪装成图片，而是显示时长、日期等事实条。这样做保留了信息密度，也没有把缺封面这个数据问题藏掉。
视觉完成不能替代数据诚实
页面改造中最容易走的错误捷径，是直接改业务接口，让返回结果看起来更整齐；或者在前端写一批静态假数据，把空列和统计数字填满。它们短期内都很有效：截图更丰富，首屏更饱满，评审也更容易产生“已经好了”的感觉。
我没有这么做，是因为页面的任务不是展示一张漂亮的海报，而是让人判断成片能不能审、处于哪一步、哪里还没有同步成功。静态假数据无法证明播放地址真实可用，也无法证明筛选会影响正确的队列。更严重的是，假数据会把真实的失败盖住，等到使用者依据页面做决定时，才发现看见的状态并不对应系统实际状态。
这次改造保留了原有同步失败提示，也如实保留了缺封面数据。页面可以展示已有成片，可以把默认对象放入播放区，但不能把“同步失败”改写成“没有问题”。界面层的完成，应该改善理解和操作，不应该替数据层制造一个虚假的成功。
验收要按行为拆开
我把验收拆成两部分。第一部分是展示层是否达到目标：两种工作流都能看到按状态组织的队列，卡片能识别，选中成片可以播放，大窗可以打开并用 Esc 关闭，筛选和搜索重置可以工作，空列可以展开或收起。第二部分是数据层仍有哪些欠项：同步失败提示是否还在，哪些记录缺少封面，统计数字是否只是当前真实返回结果。
两边都在 1440、1024、375 这 3 种宽度下检查。宽屏重点看列的密度和首屏可见数量，中等宽度看筛选与播放区是否互相挤压，窄屏则看有没有横向溢出、卡片信息是否仍能读。播放不是“按钮能点”就算通过，而是实际观察进度推进；筛选也不是“菜单能展开”就算通过，而是确认队列真的随条件改变。
这一区分很重要。最后可以得到一种看起来矛盾、实际更可靠的结论：页面效果已经通过，但同步失败和缺封面仍然存在。它不是交付失败，而是把界面改造的成果和数据问题的边界分别报告。若把两者混成一句“全部完成”，后续维护者就不知道该继续修页面，还是去追数据源。
下次我会怎么做
下次再遇到一个页面服务两种相近工作流，我会先问 4 个问题：它们是否共用展示文件，差异由什么 profile 决定，哪些接口和状态绝对不能动，每个 profile 当前真实数据是什么。只有这 4 个问题有答案，才开始调整布局。这样可以避免先做视觉方案，做完才发现它只适合其中一边。
接着我会把验收对象写成一张小表：每个 profile 至少有一条真实成片、一条空状态、一条失败提示或缺字段记录，并在 3 种宽度下重复检查。空列怎么收、内容列怎么扩，不由设计者的习惯决定，而由数据分布决定；封面缺失怎么显示，也不由“看起来好不好看”决定，而由是否能诚实提示事实决定。
这件事让我重新意识到，界面改造真正守住的不是原来的像素，而是原来的意义。共享页面可以变得更清楚、更紧凑、更好用，但它仍然要告诉人现在有什么、缺什么、下一步能做什么。一个成熟的改造流程，不是把所有状态都修饰成成功，而是让成功、空态和失败都能被准确看见。
我更愿意把这看成一种工作习惯，而不是一次设计技巧：先守住边界，再理解数据；先验证行为，再评价效果；最后把已通过的界面项和仍待处理的数据项分开交付。这样下一次换成别的双工作流页面时，不必从“怎么填满首屏”开始，而能从“哪些事实必须被保留”开始。