第 22 卷

如果想要强主题，就选铁匠铺或者压铸机；如果想长期使用、更现代轻

盈，就可以选玻璃工作台。确认风格后，再让它改工具。

我选择其中一个风格之后，它就把整个图片压缩器做成了新的视觉版本。

再选择一张图片开始处理，页面会出现类似“开始锻压”“已出炉”这

样的提示。它把功能和主题结合起来，让这个工具变成一个只有你自己

才有的风格。

这就是每个人都可以为自己创造小工具的过程：不只是解决一个问题，

还可以做成自己喜欢的样子。

打包分享，沉淀协作习惯

当然，如果这个小工具做出来之后，你发现同事也有同样的麻烦，就可

以很方便地分享给他们。对于本地小工具，你可以直接让 AI 帮你打包。

如果你不知道具体要发什么，就直接跟它说：

如果我要把这个工具发给同事，请你帮我打个包。

它会把整个小工具打成一个压缩包。你可以在文件夹里打开，直接把压

缩包发给同事，对方解压后就能用。

回顾一下今天的过程，最重要的是：不要一开始就让 AI 帮你写代码，

而是先想清楚自己要什么，再让 AI 反问你。反问的过程非常宝贵，因

为它是在不断确认你的需求边界。你自己不可能一下子想清楚所有细节，

哪怕一个成熟的产品经理也做不到。所以可以和 AI 一起把需求对齐，

再开始干。

AI 追问完之后，一定要让它出计划。看计划的时候，你才能发现哪些地

方和自己的想象不一样。它就像拿着小本来跟你确认：你布置的任务，

我理解成这几件事，对不对？这个过程很重要。

接下来，把问题和现象描述好，就可以让 AI 开始创造。写完之后，还

可以继续用两个角色：一个当产品经理，帮你理需求、做原型；另一个

当设计师，帮你优化视觉和交互。

今天我们做的是一个很小的网页产品，所以产品经理插件在做原型时，

顺便把功能也实现了。如果你做的是更复杂的产品，可能会先出网页原

型；你确认原型后，再让它开始真正写代码。

最后，如果你想把工具发给同事，可以直接把想法告诉 AI：我要打包发

给同事，或者同事不方便收压缩包，我需要给他一个网址。AI 也会继续

引导你，用更方便的方式分享出去。

今天这个过程中，我们和 AI 有很多交互。如果你经常做小工具，中间

有一些流程希望 AI 以后都能用上，还有一个方法：可以直接跟 AI 说：

请根据我们今天的协作经验，把你对我的观察和习惯写到 AGENTS.md

文件里。用你的理解来写，不用照搬我的原话；写完之后先让我预览，

再改写文件。

这个动作是让它记住你的一些工作习惯，变成这个项目里的记忆。以后

你在这个文件夹里新开对话，继续做工具，它就会读取 AGENTS.md

里的要求和优先级。

它可能会写出类似这样的协作偏好：喜欢先把产品目标、使用场景和取

舍讲清楚，再进行实现；重视先看方向，再决定落地；优先提供 3 到 4

个差异明显的方案。

它也会总结产品判断：本地可用，不依赖云端；批量拖入，自动处理；

输出必须满足明确限制；不要偷偷输出严重失真的图片；优先做用户能

直接打开使用的本地工具；如果需要给同事用，优先打成可解压的压缩

包。

这些规则里，你可以继续修改自己的优先级，比如本地不依赖云端、文

件不能超过多少 K、输出标准是什么，都可以加进去。

这里补充一个小细节：Codex 里的 AGENTS.md 有不同层级。当前目

录的 AGENTS.md，只会影响这个文件夹里的项目。如果你在别的项目

里工作，就不会读取这里的规则。除非你明确告诉它写入全局

AGENTS.md，它才会变成全局规则。

我强烈建议大家，不要写得太多全局规则。

像“必须用中文回复”“必须先确认再干活”这种常用规则，可以放到

全局；但具体项目里的产品偏好、输出标准、视觉风格，最好还是放在

当前项目里。

今天我们解决的是一个很小的图片压缩问题。但你平时工作中一定会遇

到各种各样反复发生、容易返工、让你很苦恼的小麻烦。以前你可能没

有想过用工具解决它。现在你可以把 Codex 当作你的产品经理，只要