一次动五十条也不心慌：vibe 项目的批量操作实战

批量操作是那种“没人夸奖、做错了立刻有人骂”的功能。一次勾选五十条、点一下“归档”，用户期待的是五十条都归档；实际发生的常常是：四十八条成功、两条因为权限或状态冲突失败，而界面只回一句“操作成功”。更糟的是另一种：用户以为自己只选了当前页，系统却把全量三千条都处理了。批量操作真正的难点从来不是“怎么一次调多个接口”，而是“怎么让用户在按下确认之前，就确切知道会发生什么；按下之后，又能确切知道发生了什么”。

本指南给一套可直接落地的批量操作设计：选择模型、确认文案、执行与部分失败、撤销与审计、上线清单。文中示例产品“青禾工单”与人物均为虚构。划界说明：站内数据表格指南讲的是表格组件本身（排序、分页、列定制、虚拟滚动），本篇讲的是跨列表形态的操作语义——选了什么、确认什么、失败怎么办、能不能 undo；两者在“跨页批量”处交汇，但分工不同：表格指南管“怎么展示与选”，本篇管“选完之后发生什么”。

第一步：先定选择模型，别让“全选”有歧义

批量操作的第一性原理是：选择集必须有一个用户能复述的定义。常见的三种模型要显式区分。第一，“当前页所选”：只处理本页勾选的条目，翻页即失效——适合临时整理。第二，“全部结果所选”：处理符合当前筛选条件的全部条目，哪怕有几千条——必须在界面上用数字明示，比如“已选全部 3,214 条（符合当前筛选）”。第三，“手动多选跨页”：用户逐页勾选、选择集跨页保留——需要在常驻条上显示累计数量与“查看已选”入口。

最危险的是不声明模型。很多产品把“全选”复选框做成“选中本页”，用户却理解为“选中全部”，或者反过来。补救办法不复杂：在选择动作旁边写出范围定义；当用户从“本页”切换到“全部”时，用二次确认把数字念出来。数字是批量操作里最便宜的防错手段：用户可以对文案无感，但对“3,214 条”这个数字会有反应。

还有两条边界要提前定。第一，筛选变化时选择集怎么办？推荐做法：筛选条件一变，立即清空或提示“筛选已变，已选 X 条可能不再符合条件”，绝不能静默保留一份与当前视图无关的选择集。第二，数据在操作过程中被别人改了怎么办？执行前应以主键快照为准，而不是以界面上的行号为准；行号会随排序变化，主键不会。

确认：把“将要发生什么”写成用户能核对的句子

确认对话框不是免责条款，而是最后一次核对机会。合格的确认文案包含四要素：对象（多少条、什么类型）、动作（归档、删除、改状态、发通知）、范围（是否含子项、是否影响关联数据）、不可逆程度（能不能撤销、保留多久）。反例是“确定要执行此操作吗？”——它没有给用户任何可以核对的信息，用户只能凭肌肉记忆点“确定”。

举个可直接抄的模板：“将把 48 张工单标记为‘已解决’。其中 3 张已有客户回复，标记后客户仍可继续追评；该操作可在 30 天内从‘已解决’列表批量恢复。”这句话里，数字、例外、后续影响、撤销窗口全齐了。用户读完要么放心点确定，要么发现“等等，那 3 张不该动”而去取消——两种结果都是确认对话框存在的意义。

危险操作要分级，而不是一律弹同一个框。建议三档：可逆操作（改标签、归档）用行内确认或轻量对话框；难逆操作（批量发通知、批量改负责人）用带数字与影响说明的对话框；不可逆操作（批量删除、批量覆盖）用输入确认——比如要求用户输入条数或操作关键词。分级的意义在于保留“确认”的严肃性：如果连改个标签都要输关键词，用户很快就会对所有确认麻木。

确认框里还要处理“部分不可操作”的情况。用户选了 50 条，其中 5 条因权限不足或状态不符无法执行，正确做法是在确认前就说明：“50 条中 45 条可执行，5 条因无权限将被跳过（查看详情）”，而不是等执行完再用失败列表教育用户。把不可执行项提前暴露，用户的决策才是知情的。

执行：进度、部分失败与结果报告

批量操作的执行阶段有三个必须项：进度可见、失败可定位、结果可复核。进度方面，超过两秒的操作就应当给进度指示；超过十秒的，应当支持后台执行并在完成后通知，而不是把用户钉在原地看转圈。进度文案要写“已处理 312 / 3,214 条”，而不是“处理中”——前者让用户能判断是快是慢，后者只会制造焦虑。

部分失败是常态，不是异常。设计时就按“一定会有一部分失败”来做：执行结果必须按“成功 / 失败 / 跳过”三类分别计数，失败项要列出主键、失败原因（权限、状态冲突、依赖未满足、服务端错误）与下一步动作（重试、单独处理、联系管理员）。最忌讳的是把失败藏进一句“部分成功”——用户不知道是哪几条失败，就只能全量重做一遍，而重做又可能对已成功的条目产生副作用。

幂等是批量操作的工程底线。同一批操作被用户手抖点两次、或因网络重试发两次，不应产生双倍效果。实现上，给每次批量操作一个客户端生成的请求 ID，服务端按 ID 去重；同时，单条操作本身也应是幂等的（比如“设为已解决”而不是“状态 +1”）。没有幂等保证的批量操作，上线后迟早会在一次网络抖动里制造事故。

结果报告要留档。执行完成后，界面上至少保留一条可回看的记录：操作人、时间、筛选条件快照、成功/失败/跳过数、失败明细入口。用户第二天来问“昨天那批到底动了哪些”，能翻出这条记录，客服与开发就不用去日志里大海捞针。

撤销与审计：批量操作的安全网

撤销不是“加个 undo 按钮”那么简单，要先回答三个问题。第一，撤销的粒度是什么？整批撤销，还是单条撤销？推荐：默认提供整批撤销（回到操作前快照），同时允许对失败项单独重试——两者是互补的。第二，撤销窗口多长？删除类操作建议至少 30 天软删除期，状态类操作建议保留到下一次同类批量操作之前。第三，撤销本身会不会再失败？撤销操作同样可能部分失败，同样需要结果报告；不能假设撤销一定成功。

软删除与硬删除的区分必须在产品层面讲清楚。批量删除如果直接物理删除，撤销就无从谈起；如果先进入回收站、保留期后自动清除，撤销才有落点。回收站本身也需要批量操作（批量恢复、批量彻底删除），但那是第二层设计——先保证第一层（业务批量操作）有撤销，再谈回收站的批量。

审计日志要记“操作意图”而不仅是“数据变更”。一条合格的批量审计记录包括：操作人、操作类型、选择集定义（筛选条件快照或主键列表的哈希与数量）、执行结果三数、失败明细。只记“某字段从 A 改成 B”的审计，在批量场景下几乎无法复原“当时到底选了什么”这个关键问题。筛选条件快照尤其重要：它回答了“为什么这 3,214 条会被选中”。

权限与并发：两个人同时批量操作时会发生什么

批量操作最容易被忽视的维度是并发。两个管理员同时对重叠的选择集做批量操作，或者一个人在批量改状态、另一个人在逐条改同一批数据，都会产生“最后写入胜出”的静默覆盖。缓解办法有三层：执行前校验（操作开始时重新读取每条的状态与版本号，不符合预期条件的跳过并说明）；乐观锁（按版本号提交，版本变化的条目单独列为冲突）；操作锁（对同一选择集范围的批量操作加短期互斥，提示“另一位管理员正在对该范围执行批量操作”）。三层不必一次全上，但至少要有第一层——执行前校验。

权限方面，批量操作的权限应当按“单条权限的交集”来判定：用户对选择集中每一条都应有操作权限；只要有一条无权限，默认策略应当是“跳过并明示”，而不是“整批拒绝”或“静默越权”。前者让用户能完成大部分工作，后两者一个制造摩擦、一个制造安全事件。权限跳过的条目要在确认前就列出，而不是执行后才揭晓。

零条、空结果与“选了但没动”的边界

批量操作还有一组容易被遗漏的边界：用户明明点了执行，却没有任何条目被处理。可能的原因有三种：选择集为空（用户以为选了，其实筛选后一条都没有）、全部条目都被前置校验跳过（权限或状态全部不符）、操作本身就是“无变化”（比如把已经是“已解决”的工单再标记为“已解决”）。三种情况的界面反馈应当完全不同：空选择集要在执行前就拦截，告诉用户“当前没有选中任何条目”；全部被跳过要给出跳过原因清单，而不是一句“操作完成”；无变化操作则要说明“50 条均已是目标状态，未做修改”，让用户确信系统不是没反应，而是确实没有需要改的东西。

与此相关的是“执行后视图”的问题。批量操作完成后，用户留在原列表里，看到的应当是操作后的状态——已归档的条目消失或变灰、已改状态的条目标签更新；如果视图不刷新，用户会以为操作没生效而再点一次。刷新时还要注意分页与筛选的保持：不要把用户踢回第一页、丢掉筛选条件，那会让“核对结果”这一步变得极其痛苦。理想的完成态是：用户留在原视图、原筛选、原页码，亲眼看到变化发生。

最后是通知的克制。批量操作完成后是否发通知、发给谁，要按“谁会被影响”来定，而不是按“操作人想炫耀”来定。批量改负责人应当通知新负责人，批量归档通常不需要打扰任何人，批量发通知本身就是一次通知风暴的起点——如果被通知的五十个人每人再回复一次，工单系统当天就会被自己的通知淹没。把“是否通知、通知谁、通知文案是否合并为一条摘要”写进批量操作的规格，而不是留给实现时临时决定。

给 vibe 项目的上线清单

第一，选择模型是否在界面上用一句话写清了范围定义？第二，确认文案是否包含对象数量、动作、范围与撤销窗口？第三，危险操作是否分级，确认是否按危险程度递增？第四，执行时是否有“已处理 X / Y 条”的进度？第五，结果是否按成功/失败/跳过三类计数，失败项是否可定位、可重试？第六，批量请求是否有请求 ID 去重，单条操作是否幂等？第七，撤销窗口与软删除期是否明确，撤销本身是否也有结果报告？第八，审计日志是否记录了选择集定义（筛选快照）而不仅是字段变更？第九，并发冲突是否有执行前校验与冲突列表？第十，是否用真实数据量（比如上千条）做过一次压测，而不是只在十条数据上点过一遍？

十条里，前五条是用户体验的底线，后五条是工程的底线。vibe 项目常见的失败模式是：用 AI 一天搭出批量操作的界面，却在第一次真实使用时被“到底动了哪些”问倒。把这份清单当作批量功能的验收标准，写进 PR 描述里逐项打勾，比事后补一句“操作成功”要便宜得多。

最后回到开头那句话：批量操作的口碑不在“能一次处理多少条”，而在“用户敢不敢在没有备份的情况下点它”。当用户确切知道选了什么、会发生什么、失败了哪几条、还能不能 undo 时，批量操作才从“危险的功能”变成“省力的功能”。这份信任不是靠确认框的措辞建立的，而是靠选择模型、结果报告、撤销与审计四件套一次次兑现的。