做了一个效率工具，要不要写“效率提升多少倍”？
我想先把比较条件说明白：同一项任务、同一批数据、同样的完成标准。省下的是查询执行时间，还是寻找脚本、整理结果的时间？录屏是不是剪掉了等待？
在这些问题没有回答之前，我更愿意先展示实际步骤。
如果你也经常重复查询或整理结果，欢迎交流哪一步最费事。不用发真实数据，把工作过程说清楚，就能开始讨论。
微博
碎片想法与日常记录，从新到旧。
-
-
自用工具有很多默认前提：连接早就配好了，脚本已经存着，遇到问题也知道该看哪里。
公开给别人体验，这些前提都要重新交代。
我在整理 Query Toolkit 时，想把第一次使用的路径说明白：先做什么，用什么模拟资料，怎样判断结果。演示应当帮助人了解工具，而不是要求人先提供真实业务数据。
产品介绍除了讲功能，也应该让第一次接触的人知道从哪里开始。
-
Query Toolkit 的版本记录里，有一次旧版表格导入失败的修复：实现调用了所用数据库组件不支持的接口，需要调整取列数的方式。
这件事提醒我，验收数据迁移，不能只看有没有入口和进度条。
原来有多少，实际导入多少，关键内容能否打开和查询，这些才是要检查的结果。数量一致也只是起点，内容还要抽查。
代码由谁完成都一样。准备交付一个功能，就要知道该怎样判断它完成了。
-
AI 对我的帮助，不只是少写一些代码，也让我能更早拿到一个可以操作的东西。
过去讨论“脚本保存”，可能都觉得明白。真正点几次，才发现临时修改、正式版本、退出后继续编辑，是不同的要求。
借助 AI，这些问题可以更早摆到眼前确认。业务经验仍然有用，只是多了一种把想法直接做出来、再继续讨论的方式。
我写了做 Query Toolkit 时的几个体会：实现变快之后，产品经理仍然要判断什么。
-
保存、停止、全部。这三个词，日常说起来很简单。
变成软件功能，就要再问几句：保存的是临时编辑还是正式版本？停止的是界面等待还是后台任务？全部是这次已经返回的数据，还是数据库里所有符合条件的记录？
这些问题在需求里没有说明，使用时就容易各自理解。
做 Query Toolkit 时，我越来越在意按钮背后的实际含义。操作顺手很重要，让人知道操作之后发生了什么，同样重要。
-
查询工具已经能编辑 SQL，为什么不顺手把修改也开放？
我的考虑是，查明现状和决定修改，承担的是不同的事情。查到一笔异常，并不自动说明应该怎么改，也不自动获得修改权限。
Query Toolkit 的查询入口设有写入限制，生成脚本与执行修改也分开。工具侧检查不能代替数据库权限，但可以让日常操作的用途更清楚。
做功能时，我也会问：多开放这一步以后，使用者是否仍然知道自己正在做什么？
-
有些表格不是拿来计算的，只是经常需要翻查：代码说明、字段备注、自己整理的资料索引。
Query Toolkit 可以把 CSV 导入本地表格，再按关键词搜索。但集中放在一个地方，只解决“找得到”的问题，并不保证内容一直正确。
我会给这类资料保留来源、适用范围和整理日期。原始资料变了，本地副本也需要维护。
旧资料整理得再漂亮，如果忘了它适用于什么时候，同样可能误导判断。
-
SQL 存下来了，最容易忘的往往不是语法，而是当时为什么这么写。
为什么取这个日期？为什么排除那类状态？这条查询适不适用于拆分业务？几个月以后，代码本身未必能回答这些问题。
我更愿意在备注里留下用途、口径和限制。比如“仅适用于每笔业务一条有效记录”，就比“查询重复数据”多交代了一条重要前提。
管理几百条 SQL，真正想留下来的，是查询背后的判断，不只是代码文本。
-
把查询结果发出去，别人往往还会问：这是什么范围的数据？用的哪个日期？包含哪些状态？
所以我希望导出的文件不只有数字，也能留下查询的来由。
Query Toolkit 导出全部结果为 Excel 时，可以按查询分工作表，并附查询脚本页。这样方便回看，但业务口径和结论仍然要自己说明，文件里的 SQL 和数据也要检查是否适合分享。
交出去的是一份结果，最好也能让接手的人知道怎样继续核对。
-
做一个很小的模拟：来源有 A、B 两笔业务，各 1,000 元；导入后却变成两笔 B，各 1,000 元。
两边都是两笔，合计都是 2,000 元。但 A 漏了，B 重复了。
这个例子没有复杂技术，只说明一件事：汇总检查只能给出汇总层面的结论。准备判断“数据已经一致”，还得看看业务标识、记录状态和明细匹配规则。
我把核对时会先确认的几层问题，写成了一篇文章。示例全部虚构，不涉及真实业务。