type
Post
status
Published
date
Sep 17, 2026
slug
summary
今早我在笔记里记下这么一段话：「viber到了一定阶段，一旦有了需求痛点，都不喜欢第一反应去找有没有这样的工具，都是直接自己去viber一个工具，这种工具可以方便后续自己的修改调整
tags
Write
category
Messy
icon
password
url
今早我在笔记里记下这么一段话：「viber到了一定阶段，一旦有了需求痛点，都不喜欢第一反应去找有没有这样的工具，都是直接自己去viber一个工具，这种工具可以方便后续自己的修改调整，能确保做出来的是自己能用到的，能满足自己需求的，得自己能用起来，那才能确保给别人也能用。」
写的时候刚坐下来，这个念头在脑子里已经很清晰了。回头看，这大概是我在用 AI 这件事上的一个转弯：从「找工具」，到「造工具」。
一、过去的第一反应，是去找
以前遇到一个需求，脑子里冒出来的第一个问题永远是：有没有现成的工具？有就拿来用，没有就找替代品，再不行就绕着走，把这个需求忍过去。
这没什么不对，省时间、省力气，用别人验证过的东西最稳。但问题也藏在这里：现成的工具是为「大多数人」设计的，它不会专门为你的场景优化。用着用着，总有几处别扭，几个功能多余，几个需求它永远不覆盖。你只能在它的框架里将就，改不了它。
二、转折，是从修修补补开始的
这个转变不是一下子发生的。回看这一周，我大部分时间都泡在自己的工具链上：
- 给 dsh-restart 补「旧标签页自愈 + 401 引导」，把重启失败态只活在页面里的问题揪出来
- 从零开发 dsh-qqmail，一个 QQ 邮箱插件，做了 12 个工具加 CLI
- 做 dsh-updater，逐家核实聚合平台的收录结果，5 家收录 1 家排队
- 发布 dsh-cubox 0.2.0、dsh-task-dispatcher 0.2.0，走完从门禁到 npm 再到聚合平台的全链路
一开始只是想修修补补，后来发现每修一次，就对这套东西多一分掌控。修得多了，遇到新需求，第一反应不知不觉就变了——从「去搜搜有没有现成的」，变成「这个我自己能不能造一个」。
三、自己造，图什么
图三样东西。
- 能改。 现成的工具是别人的代码，想改要等作者更新，或者自己 fork 下来维护，成本高。自己造的东西，哪里不顺眼改哪里，改完立刻能用。
- 能用。 自己造的东西，一定是从自己的真实场景里长出来的，每个功能都对应一个实际痛点，不会有花架子。做出来的一定是自己能用到的，能满足自己需求的。
- 算得清。 别人的工具，你永远不知道它下一步往哪走，今天还在维护，明天可能就停更了。自己造的东西，边界清清楚楚，坏了知道去哪修。
这三点合起来是一件事：把主动权拿回自己手里。
四、自己能用，才能给别人用
最有意思的是这句话的后半段：得自己能用起来，才能确保给别人也能用。
反过来读也成立——一个连自己都不用的工具，很难想象别人会用它。自己当第一用户，工具才会被反复打磨；自己每天在用，问题才暴露得够快，改得够及时。工具的第一用户，永远应该是作者自己。
这让我想起前两天记下的另一句：「门槛被打掉的时候，真正的护城河才刚浮出来。」AI 把造工具的门槛拉低了，人人都有可能自己造一个。这时候，区别不在会不会写代码，而在有没有真的把一件事用到产生痛点。痛点越真实，造出来的东西越有用。
五、从找答案，到造答案
我给自己定过一串简介：creator、coder、内容创作者、跑者……排在最前面的，是 creator，造东西的人。
把「找工具」换成「造工具」，改变的不是技术，是一种看问题的方式：遇到麻烦，第一反应不是绕开，而是想「我能不能亲手解决它」。AI 放大了每个人的产能，但放大的是谁？是那个愿意把力气花在同一个点上、亲手把需求变成工具的人。
这一周我还在另一条笔记里写过：从「追最强的模型」，转向「搭一套能持续用下去的东西」。两句话说的是同一件事——工具可以换，但自己造出来的那套东西，会一直长在自己身上。
今早我在笔记里只写了四个字：要做工具。
下次再遇到一个痛点，先问自己一句：这个工具，能不能我自己造？