观点 | 用 AI 做了一个小工具后,我开始重新看待工作里的“小麻烦”

最近，我用 OpenAI 的 Codex 做了一个很小的 Chrome 插件，叫「网页批注反馈助手」。

这个插件的作用很简单：在检查网页细节、做页面评审时，可以直接在当前网页上添加点位标记、框选区域、填写反馈内容，最后导出一份 PDF 反馈报告。

插件本身并不复杂。

但做完之后，我开始重新看待工作里那些过去只能“凑合一下”的小麻烦。

平时评审网页页面，经常会遇到一些细碎问题：某段文案不够清楚，某个按钮位置不太对，某个链接需要检查，某块视觉区域和预期有偏差。

问题本身都不大，但记录起来很碎。

过去常见的方式是：截图、画圈、写说明、整理文档，然后再同步给相关同事。评审会上如果多人一起提意见，也经常是大家口头说，运营同学负责记录。

这个流程可以完成任务，但用起来有点折腾。

以前遇到这种问题，我大概率会觉得：这也不是一个大需求，专门让开发实现不现实。于是继续用截图、表格、文档这些方式凑合。

这次经历后，我意识到三件事：

工作里的很多小麻烦，开始值得被工具化了。

AI 除了回答问题、总结材料、润色文案，也可以帮我把一个想法做成能试用的小工具。

边做边试之后，我反而越来越清楚自己真正需要什么。

一开始，我给 Codex 的需求还比较粗糙：做一个网页截图批注工具，能截屏、能画框、能写反馈、能导出文档。

Codex 很快给了第一版。插件已经能用，但真正试了一下，我发现自己一开始想偏了。

我一开始以为自己需要截图批注。

试用之后才发现，我真正需要的是：

浏览网页的时候，顺手批注。

这个差别挺大。

截图批注需要离开当前页面，回到一张图片上编辑；网页内批注可以在真实页面里边看边标，问题和上下文都还在。

于是工具开始调整：从截图编辑，改成网页内批注。

页面右下角有一个小小的悬浮入口，需要反馈时点开，可以添加点位标记、框选区域，或者针对文字写反馈；平时它就待在一旁，不影响正常浏览。

后面又陆续改了一些细节。

页面上的标注一开始太明显，会影响正常看页面；后来改成默认只显示编号，鼠标移上去时再展开反馈内容。

反馈弹框一开始字段太多，看起来完整，实际使用有点重；后来只保留最关键的反馈内容。

导出的报告也从简单罗列，调整成更适合协作的反馈清单。

这些改动本身都很小。

但它们让我意识到一件事：

很多需求并不是一开始就能想清楚，它是在试用中慢慢变清楚的。

整个过程里，我几乎没有自己动代码。

我做的事情主要是不断描述：哪里用起来不顺，哪里信息太多、容易打扰，哪里不符合真实场景，哪里可以再简化。

Codex 根据反馈一版版修改，我再试用，再继续补充新的判断。

这个反馈循环很快。

也正因为快，我对自己的需求反而越来越清楚。

最开始，我并没有想明白这个工具最终应该长什么样。它是在一次次试用、修改、再试用的过程中，慢慢变具体的。

这也是这次最有意思的地方。

AI 没有一开始就帮我做出一个完整工具。

它更重要的作用，是让我用很低的成本，把一个模糊想法快速变成可试用的东西。

试用之后，我再反过来发现：原来我需要的是这个方向。

以前很多工作里的小问题，因为开发成本高，往往会被自动忽略。

问题一直存在，只是“不值得专门做”。

但当做一个小工具的成本降下来以后，这些日常的小摩擦，好像就值得重新考虑了。

这可能是我这次最大的体会。

AI 的价值不止在于回答问题、总结材料、润色文案。那些当然有用，但如果想改一改工作方式，还需要再往前走一步：

把问题变成需求。

把需求拆成流程。

把流程做成工具。

比如“网页评审记录很麻烦”，这只是一个感受。

继续往下拆，其实就是几件很具体的事：

需要标出问题在哪里；

需要记录反馈内容；

需要保留当时的页面上下文；

需要导出给别人看。

再往下拆，它就变成了一个可以被实现的小工具。

回头看，我这次做得并不算高效。

我在还没有完全想清楚需求的时候，就让 Codex 开始写代码。中间确实有返工。

有些问题本来可以先通过对话想清楚，比如到底要做截图批注，还是网页内批注；面向个人审阅，还是多人评审记录；导出简单文档，还是正式反馈报告。

如果是正式商业项目，前期当然还需要更清楚地定义边界、角色和交付标准。

但作为一次个人探索，边做边想、边试边改，本身也有价值。

它让我更快看到结果，也更快意识到问题。每一次改完之后马上能看到效果，都会带来新的判断。

这和过去想象中的“开发一个应用”很不一样。

以前我总觉得，做工具是一件离普通业务人员很远的事。需要会代码，需要完整设计，需要开发排期。

实际试下来，很多小工具的第一版并没有想象中那么遥远。

只要问题足够具体，AI 可以把中间的技术门槛压低很多。

它像是打开了一个新的入口：

当我在工作中遇到一个反复出现的小麻烦时，我可以先问一句：这件事能不能被工具化？

如果你也想试，可以先不用急着做工具，而是问自己四个问题：

- 这个小麻烦是不是反复出现？

- 它现在是不是靠一些繁琐操作在凑合？

- 里面有没有固定步骤，比如记录、分类、导出、同步？

- 如果只做一个最小版本，它能不能先帮我省掉一部分重复动作？

能回答清楚这几个问题，一个小工具的雏形就出来了。

不一定一开始就做成复杂的协同系统。

先把一个真实的小问题解决掉，就已经有意义。

这次尝试之后，我对 AI 的使用方式有了一个更具体的感受：

如果只是停留在对话层面，AI 更像一个回答问题的助手；如果能把问题继续拆下去，它也可以成为把想法变成工具的帮手。

很多小问题以前只能忍，核心原因是解决成本太高。

现在，这件事情开始变了。