我的 AI 工作台：日常真正在用的几个小工具

这个分类用来放我日常真正在用的东西。不追新，不堆数量，只写那些我连续用了一个月以上、并且能说得出「它替我省掉了什么」的。

工具会变，所以这篇我会定期更新。写下判断依据，比写下结论更重要。

先说我怎么挑工具

我的判断标准只有三条：能不能离线或半离线用、出问题的时候日志能不能查、以及它会不会在不合适的时候替我做决定。

第三条淘汰掉的工具最多。很多工具默认替你把一件小事做得更快，同时让你失去了理解它怎么运作的机会。对开发工具来说，这种损失通常比省下的几分钟贵。

 private void assertVoucherCarrierLimitOne(Integer productId, Integer productNum) {
        if (productNum == null || productNum <= 1 || productId == null || productId <= 0) {
            return;
        }
        // G1（复核轮 §17.3）判据源收敛到 VoucherOrderMatcher：以前这里自己抄了一份 listByProductId+isShow
        // 的判据，与发卡钩子（matchVoucherType）是两份代码——钩子改了限购就漏，正是 G1 的成因之一。
        if (voucherOrderMatcher.isCarrierProduct(productId)) {
            throw new CrmebException("凭证卡商品每单限购 1 份，多份请分开下单");
        }
    }

日常写得最多的：AI 编码助手

我用它做三件事：读陌生代码、把需求翻译成接口草稿、以及把刚写完的代码反过来问它「这里有什么坑」。第三种用法收益最高，因为它逼我重新去看自己刚写的逻辑。

它不适合用来做架构决策，也不适合在我还没想清楚的时候替我设计。把它当放大器，不当设计师。

抓取和整理信息的脚本

大多数时候我不需要一个大而全的产品，需要的是几十行能跑通的脚本：抓一个页面的结构化数据、批量改一批文件名、把一堆杂乱的导出文件合并成一张表。

这种脚本写一次用很久，而且完全不依赖云服务。我把它放在单独的目录里，命名规则简单到半年后还能一眼看懂。

笔记系统

我试过很多种，最后回到最朴素的：一个目录、纯文本、一个全文搜索。工具越重，我越容易把记录变成「整理」而不是「思考」。

唯一的要求是，任何一条笔记都要能在三秒内找到。现在这套满足。

后面我会陆续把这个分类补起来，每个工具写清楚它是干什么的、替代了什么、什么情况下不值得用。如果某个工具我已经不用了，我也会把它标成停用，而不是悄悄删掉。