我为自己定制了一套小工具开发流程
如果要长期做很多小工具，就不能每次都重新想目录、命名、文档、打包和发布流程，所以我把这些规则沉淀成了自己的 Codex Skill。
我为自己定制了一套小工具开发流程
如果只做一个工具，很多事情可以临时决定。目录怎么放、文档叫什么、打包产物放哪里、版本号从多少开始，都可以边写边想。
但如果目标是长期做很多小工具，这种临时性会很快变成负担。每次新建项目都重新纠结一次，不仅浪费时间，也会让不同工具之间越来越不统一。
所以在开发第一个工具之前，我先做了一件看起来有点“提前”的事：为自己定制了一套小工具开发流程。
固定根目录
所有小工具统一放在：
D:\dev\yuan-tools这个目录不是公开仓库本身，而是我的本地工作区。以后不管我在哪个对话里说“开发一个 XXX 小工具”，项目都应该创建到这个根目录下面。
例如图片打码工具的目录是：
D:\dev\yuan-tools\yuan-image-redactor这样做的好处很实际：项目不会散落在不同地方，后续查找、发布、写博客、更新索引都更稳定。
英文项目名，中文工具名
项目目录使用英文 slug，例如：
yuan-image-redactor但工具界面、窗口标题和说明文档使用中文名称，例如：
图片打码工具这两个命名各自服务不同对象。英文项目名适合文件系统、GitHub、命令行和发布资产；中文工具名适合真实用户，一眼就知道这个工具是做什么的。
每个工具必须有的结构
我给小工具定了一个基础结构：
yuan-example-tool
README.md
工具使用说明.md
src
src-tauri
release
html
winREADME.md 是项目说明，给开发者和未来的自己看。工具使用说明.md 是给用户看的，解释工具能做什么、怎么用、保存文件在哪里、有什么限制。
release/html 放 Web 静态版，release/win 放 Windows 桌面版 EXE。
这些规则看起来细，但它们能避免后面很多混乱。尤其是说明文档，它不只是附属品。有些功能第一版可能还不完美，比如保存位置由浏览器或系统下载设置决定。这个时候清楚的用户说明可以减少困惑，也让工具显得更完整。
把流程写成 Skill
为了让 Codex 每次都按同样标准工作，我创建了几个专用 Skill。
第一个是 yuan-tool-builder，负责开发小工具。它知道项目应该放在哪里，知道要用什么架构，知道要生成 Web 和桌面两个版本，也知道 EXE 运行时不能显示终端窗口。
第二个是 yuan-git-publisher，负责发布到 GitHub。它知道我的仓库策略、版本规则、Release 资产命名方式，以及总索引仓库应该怎么更新。
第三个是 yuan-blog-writer，也就是现在这组文章正在使用的写作 Skill。它知道 Obsidian 目录在哪里，知道这 6 篇文章的标题，也知道文章应该保留真实开发过程，而不是写成空泛的宣传稿。
Skill 的价值
对我来说，Skill 的价值不是“让 AI 更神奇”，而是把重复性的上下文固定下来。
如果每次都要重新解释：
- 我的项目根目录在哪里。
- 工具命名规则是什么。
- release 目录怎么放。
- README 和工具说明怎么区分。
- GitHub 发布策略是什么。
- Obsidian 博客写到哪里。
那 AI 的效率会被大量上下文消耗掉。把这些规则写成 Skill 后，每次只需要说目标，流程就能自动接上。
这也是产品化的一部分
很多人以为产品化只发生在用户界面上。其实对独立开发来说，开发流程本身也需要产品化。
一个稳定流程可以让我更快开始下一个工具，也能让我在回头维护旧工具时不迷路。小工具越多，这种标准化越重要。
第一个工具 yuan-image-redactor 跑通后，我更确定这套流程值得继续沉淀。下一篇就写这个工具本身：图片打码工具是怎么设计和实现的。