STUDY · M-01 · AI 协作
把 200 次点击变成 1 次：物料图纸一键批量下载
——一个"纯本地转换"解决重复点击问题的最小改动实录
在品类管理的日常里，查物料、看图纸是高频动作。物料查询技能上线后，一句"帮我查这几个料号的图纸"，机器人就能把图纸链接整整齐齐列出来——查询这一头，已经很快了。
但用户很快反馈了新痛点：一次涉及几十上百个物料时，下载那一头还是原始社会。对着消息里的链接一条一条点，点到第 30 个就记不清哪个点过、哪个没点过；稍不留神漏两三个，回头只能翻聊天记录大海捞针。
怎么把"下载 N 个图纸"从 N 次点击变成 1 次？这周的技能升级（v16.2）给了个答案：加一个批量下载页——把查询结果一键生成一个本地网页，打开点一次按钮，全部图纸自动逐个下载，漏没漏一眼看清。
一、之前：逐条点击的三个坑
把用户反馈拆开，其实是三个具体的坑：
- 容易漏。 链接是纯文本列表，点过的和没点过的长得一模一样，没有任何状态标记。30 个链接排在一起，人的注意力撑不到底。
- 容易乱。 手动点击顺序随机，文件散落在浏览器下载栏里，事后想对账"是不是每个物料都拿到了"，只能靠脑子记。
- 容易烦。 50 个物料就是 50 次点击、50 次等待。这种纯重复劳动，本来就不该由人来做。
注意，这三个坑的公共根源是缺少状态可视化——不是查询慢，是"哪些完成了、哪些没有"这件事不可见。这个判断直接决定了后面的方案形态。
二、现在：一个页面，三样东西
升级后的下载链路变成两步：
- 第一步照旧：查询物料、获取图纸链接。还是原来的脚本，串行执行、每个物料间隔 1 秒——这是接口限流的要求，一个字节都没动。
- 第二步新增：当用户明确说"打包下载/一起下载/批量下载"时，把第一步已经落盘的输出，转换成一个「批量下载页」HTML 文件发给用户。
这个页面就三样东西：
- 状态标签。 每个物料一行，三种标签红绿分明：绿色"有图纸"、红色"无图纸"、红色"未查到"。漏没漏，从上往下扫一眼就知道——这一条直接治坑 1 和坑 2。
- 一键按钮。 点一次"全部下载"，浏览器按 1.5 秒间隔自动逐个触发下载。间隔不是拍脑袋：太快要被文件服务器限流，太慢用户等得烦，1.5 秒是两边都舒服的平衡点。200 个物料，5 分钟内全部落盘，人可以完全走开。
- 明细对账。 输入料号、MDG 编码、企业项目编码、物料描述、下载链接，全在表格里。哪个物料什么状态、文件叫什么名字，事后随时可查。
之前是 N 次点击加人工对账；现在是 1 次点击加页面对账。
三、为什么是"本地网页"，而不是"打包成 zip"
设计时最先想到的方案，其实是让后端把所有图纸打成一个 zip 包。评估之后放弃了，三个原因：
- 后端打包链路太长。 要新写服务端逻辑：临时文件落盘、异步任务状态、超时清理。每多一环，就多一个出错面——打包到一半失败了怎么办？文件残留谁清理？
- 大文件中转浪费。 图纸单个几 MB，200 个物料打包就是几百 MB 在服务器上走一圈（下载到服务器、压缩、再推给用户）。而浏览器直连文件服务器下载是既有通道，早就验证过稳定，没必要让数据绕路。
- 改动面要最小。 最终方案是一个纯本地转换脚本：读第一步已经生成的文本输出，拼出一个 HTML，零网络请求、零新接口、零权限变化。图纸的 DRM 加密结构、下载链接的有效性，全部原样保留，不存在"转换把文件弄坏"的可能。
这是 Vibe Coding 给我的一条经验：能不动生产链路，就别动。新需求优先用"组合既有产物"的方式满足，而不是新造一条链路。这次的批量功能，生产侧零改动，风险几乎为零。
四、防呆：默认不开，要了才给
有个容易忽略的设计点：这个页面不会主动生成。
- 只有用户明确说了"打包下载/一起下载/批量下载/一次全下"，才走第二步；普通查询绝不塞一个 HTML 文件过来。多数场景查三五个物料，逐条点反而更快、更直观——工具得分场景，不能一刀切。
- 就算生成了批量页，消息里照样逐条输出每个物料的图纸链接。页面是附加便利，不是信息黑洞：用户想在聊天记录里直接点某一条，永远可以。
- 单次 200 个物料的上限保持不变，超了先请用户缩减范围再发起——这个约束保护的是接口，不是功能。
五、写在最后
回看这次升级：用户要的是"少点几下"，但我们没有去改后端、没有加服务器、没有引入新依赖，只是把本来就存在的查询输出，多转了一层格式。
之前：N 个物料 = N 次点击 + 人工记状态；现在：1 次点击 + 红绿标签一眼对账。
好的工具不是把功能往上堆，而是把用户本来要多点的那 N-1 次，悄悄省下来。