夜雨聆风
做工具时，我以前很容易先想功能。
导入、清洗、匹配、拆分、合并，想到一个就记一个。再补几个按钮，页面看起来越来越完整，但我自己未必说得清楚：这款工具到底要替我完成哪一段工作？
这次做 Jun 表工厂，我先把顺序倒过来。
先回到我平时遇到的 Excel，再从这些场景里整理出需求，最后才决定产品应该长什么样。
我平时遇到的 Excel
我的 Excel 使用场景，通常不是做报表，也不是天天整理数据。
更多时候，是客户临时需要一份数据，或者客户发来一份 Excel，让我把里面的数据导入系统。
问题在于，业务 Excel 和系统需要的数据，通常不是一回事。
业务人员填的是名称，系统需要的可能是编码；表头名称对不上；日期、手机号、编号的格式不统一；有些列要拆开，有些列要合并；多余数据还得先清掉。
所以一份表真正进入系统之前，往往要先经过一轮整理：
客户 Excel ↓ 确认数据结构 ↓ 清洗和转换 ↓ 匹配系统字段 ↓ 导出系统可导入的 Excel ↓ 导入系统 这些动作单独看都不难。麻烦在于，每次拿到的表不完全一样，处理间隔又比较久。
上个月做过的事，这个月再遇到，步骤和参数往往已经记不清了。
我以前会写几段脚本。新表来了，找一段差不多的，改几个参数，再运行。脚本散在不同目录里，时间一长，先得回忆哪段脚本处理哪类数据，然后才能开始干活。
我真正想解决的，不是 Excel 能不能完成这些操作，而是：
同一类数据处理任务，能不能少从头来一次？
工具先要解决什么
从真实场景出发，Jun 表工厂至少要满足几件事。
先把原始数据看清楚
导入文件后，第一件事不是马上处理，而是先预览。
真实的 Excel 可能没有表头，第一行就是正式数据；一个文件可能有多个 Sheet；编号可能带前导零；同一列里还可能混着数字和文本。
所以导入时，我需要确认：
• 当前打开的是哪个文件、哪个 Sheet；
• 第一行是不是表头；
• 一共有多少行、多少列；
• 工具读到的内容是否和原文件一致。
没有表头也不能直接报错。可以先使用临时列名，后面再根据实际情况调整。
这一步看起来基础，却决定了后面的处理是不是建立在正确的数据上。
每一步都能看到结果
我不想把表格丢进去，点一下按钮，等它吐出一个结果，中间发生了什么完全不知道。
比如两表匹配，需要知道匹配成功了多少、没有匹配上的有多少、有没有重复匹配；删除空行，需要知道删掉了多少；增加新列，也要先看几行结果是不是符合预期。
所以每个处理动作都应该是一个独立步骤：
原始数据 ↓ 去除空行 结果版本 1 ↓ 两表匹配 结果版本 2 ↓ 增加新列 结果版本 3 每一步都能预览。做错了，可以撤销；还没处理完，可以从当前结果继续。
同一套流程，要能处理多个批次
这是我后来越来越确定的一点。
同一类数据处理工作，通常不是只发生一次。可能这周收到一份，下周又来一份，下个月还会再来一份。原始文件换了，但处理方式大体相同。
如果每次都复制旧文件、重新搭步骤，所谓的“复用”其实还是半自动的。
我更需要的是把两件事分开：
任务 = 怎么做
批次 = 这次做了什么
比如：
任务：把客户名单转换成系统可导入数据 ├── 批次 1：第一周收到的 Excel + 处理结果 ├── 批次 2：第二周收到的 Excel + 处理结果 └── 批次 3：下个月收到的 Excel + 处理结果 任务保存的是处理流程和参数；批次保存的是某一次导入的原始文件、处理步骤和结果。
下次有新数据时，我只需要在原任务下导入一个新批次，沿用已经确认过的处理流程。
这里的批次不是简单的“另存一份文件”。它代表了一次完整的数据处理记录。哪份原始数据进来了，经过了哪些步骤，最后导出了什么结果，都应该能追溯。
它不是什么
需求说清楚以后，边界也要一起定下来。
Jun 表工厂不是在线协作表格。Excel 里经常有客户信息、产品数据和其他敏感内容，这些文件没必要为了处理方便就上传到第三方网站。
它也不是数据库查询平台。用户不是来里面做复杂分析的，而是手头有一份文件，需要把它处理成另一份可以继续使用的 Excel。
它更不是 Excel 的替代品。Excel 适合自由编辑、临时计算和手工整理；Jun 表工厂只把其中反复出现的数据处理动作单独拿出来，变成一条更容易重复使用的流程。
从需求推导产品结构
把前面的需求放在一起，Jun 表工厂可以先分成四层：
界面层
负责导入文件、预览数据、选择处理动作和查看结果。
用户看到的应该是“补充部门”“拆分地址”“匹配编码”这些具体操作，而不是 XML、函数参数或底层数据结构。
处理流程层
负责真正改变数据。
清洗、匹配、拆分、合并、填充，这些动作按步骤执行。每一步都形成新的结果版本，方便查看和撤销。
数据与任务层
负责回答两个问题：
• 这套数据处理流程怎么复用？
• 当前这个批次处理到哪一步？
任务和批次在这里被分开保存。任务记录“怎么做”，批次记录“做了什么”。
文件与本地存储层
负责原始 Excel 从哪里来，处理结果保存到哪里，以及任务关闭后如何恢复。
数据优先留在本地。对我来说，这是处理真实客户数据时的基本前提，不是后面再补的附加功能。
第一版先做什么
产品结构不是把所有可能的能力都列进去，还要明确第一版暂时不做什么。
第一阶段不做在线协作，不做多人同时编辑，也不把 Excel 全部转换成数据库表供用户查询。
十万行级别的大表、复杂统计、多人协作，这些需求以后可能会遇到，但不能因为“以后可能需要”，就提前把第一版做成另一个系统。
当前最重要的是先让一份普通办公表格顺利经过：
选择任务 ↓ 导入一个新批次 ↓ 预览 → 处理 → 查看 → 撤销 / 继续 ↓ 导出本批次结果 同一个任务下，下一周再导入一批数据，默认沿用已经确认过的处理流程。新增数据只是新增批次，不需要重新搭一遍流程。
先把产品想清楚
到这里，我还没有开始决定用 Electron、Python，还是 React。
我先确定的是几件产品事实：
• 数据在本地处理；
• 原始数据导入后可以预览；
• 每一步处理都有结果；
• 做错了可以撤销；
• 同一个任务可以不断新增批次；
• 最后导出系统可以继续使用的 Excel。
这些事情确定以后，技术架构才有依据。
做 Jun 表工厂，我不想先拼出一个看起来很完整的软件，再回头给它找用途。我更愿意从一份真实的 Excel 开始，把每一次重复处理拆开，看看它到底需要什么，再决定怎么实现。
先把需求说清楚，后面的代码才不会一直追着按钮跑。