不写一行代码,从零做了一个桌面APP!(保姆级教程)

最近这段时间，比较沉迷于研究各种小玩意。

一方面，在花精力去做好一个小工具。

另一方面，还需要把我这套制作流程写出来。

可以为大家去vibe coding的时候有个思路。

作为一个内容自媒体博主来说，写稿子是一项必然要面临的事情。

文章写完其实只是第一步，发布前还要面对一轮又一轮的审核。

审核文章有没有什么不合适的地方，内容通不通顺，有没有错别字等等。

我经常需要处理不同类型的文稿：教程、产品实测、场景化评测的文章等。

写文章对我来讲其实不算最费时间的部分。

因为每种文章的审核标准还太不一样，所以每一次写完文我都需要耗费大量的精力去通读修改文章。

如果每次都打开文档，翻出对应的写作规则，再一条条对照，工作效率就会非常低，而且很容易漏掉某一类问题。

所以我就冒出一个想法：

干脆给自己定制一套审核工具

我可以自己定义不同场景的规则，工具按照规则检查文章。

根据我选中的这些标准，把问题、原文位置和修改建议都一一整理出来。

这篇文章，我将把我开发软件的整个过程还原出来，供大家学习：

如果觉得有帮助，记得关注支持哈。

“

我如何和 GPT 聊想法，怎么把规划交给 Codex 开发，又是怎么一路改到可以安装、可以发布的桌面软件。

第一步：我先确定它应该是个什么产品

如果你也想做一个自己的工具，第一步不用急着让 AI 写代码。

我先把自己要解决的问题直接说给 GPT 听：

我想做一款文章检测系统，就是，结合我们设定的一些方面，关注的一些点，依次来给我写的文章来生成修改评分和指导建议点，你觉得我们这套系统应该如何来开发，他应该以一个什么样的产品做出来；

这句话有两层意思：

第一层，是让它根据我的一个大致需求，确定我的核心需求。

第二层，是它最后应该以什么产品形态存在，更方便我去使用。

第二步：确定第一版的开发边界

这一步，不要继续往功能里一个劲的堆想法，先限定第一版只需要完成什么。

这时候比较常见的一个问题就是，AI 很会给你提点子，给你列出来一堆看起来很好的功能。

但是这里一定要把持住，我们确保当前的目的是把核心功能先开发出来。

也就是所谓的 MVP 版本。

根据前面 GPT 给我的建议，我开始给它补充我的重点想法：

我目前需要的就是第一版的功能，我会把我的文章要求看重的点放进去，作为审查的点，作为一个维度评测点；

第一版先不追求让工具解决所有写作问题。

先把我看重的文章要求放进去，变成可被检查的评测维度。

这样，GPT 整理开发方案时就有了明确的取舍：

“

优先做规则、评测和结果，不急着加云端同步或团队协作等复杂功能。

对于做工具的人来说，这一步很重要，先说明你愿意舍弃什么，才能让第一版真正落地。

第三步：明确自己想要的核心功能

明确第一版以后，我开始描述自己希望怎样用这些规则：

我其实想的一点是，我会把每一个需要注意的点，添加成长条标签，然后，我会按照不同类型的分类文章，去做分组，每个分组里面我去勾选中对应的标签，以后，每个分组就表示我对一种文章的整体评测方向，而且我后面还可以自定义增加各种细小标签进去，增加评测维度

这句话就是在确定我这个工具的核心结构了：

“

一条注意事项是一个标签；一篇文章属于哪种场景，就选对应的评测组；评测组里再勾选需要的标签。

它的流程就是：

文章类型 → 评测组 → 勾选的标签 → AI 检查 → 评分和修改建议

再往后，我根据 GPT 提供的分类维度，做了一些筛选后，将评测标签做了一些细节上的区分，可以方便我找寻对应的标签。

现在，GPT 已经基本上把我的需求搞清楚了，接下来就是确定我们的工具形态。

第四步：确定最终工具形态

规则模型确定后，我就继续讨论技术实现和成品形态：

这些够用了，现在我们来讨论技术实现方面，说说底层分析的功能，比如AI接入这些，另外，是我们最后要做出来的成品是什么样的，我感觉做成桌面desktop好一点，你觉得呢。

这时，GPT 是在前面已经聊清的需求之上，继续整理 AI 接入、数据保存和桌面端形态，而不是凭空替我设定功能。

最后形成的第一版开发文档，确定了本地优先的桌面工具，并把页面拆为文章评测、标签库、评测组、历史记录和模型设置。

技术方案服务于这个目标：让规则能保存、让模型能执行检查、让报告能回到原文，不要展示一堆专业术语。

产品方向清楚后，我就和它讨论，给我这个工具一个名字，最后就定成 Rubriq 吧。

第五步：让 GPT 整理开发文档，再交给 Codex 开始开发

到这里，GPT 已经完成了它最适合做的工作：

把我零散的审核经验、第一版边界、标签分组和桌面形态整理成开发文档。

接下来，不用复制对话或者截图对话内容，把前面的对话在 Codex 中使用 @ 直接引入开发任务里，告诉他开始开发。

这样可以减少重复解释和上下文消耗，也算是一个小tip。

我发现，对小白来说，最稳的路径是：

“

先让它基于开发文档做出能打开的版本，再按照页面和真实使用过程一点点往下走。

Codex 也会自动按架构搭建顺序去实现基础功能上的开发。

第六步：先做出能点击的版本

第一版出来以后，我看到的是一个可以打开的桌面窗口，以及几个基础页面。

这时候，我已经可以开始去使用并检查它了：

• 我能不能新建一个分类？

• 能不能写一条规则？

• 能不能把规则放进某个评测组？

• 输入文章以后，报告能不能指出具体哪一段有问题？

开发工具和写文章其实很像。

先不要追求一次写出最终版本，先拿出一个可以被使用、可以被挑错的版本。

只有真的用起来，很多问题才会暴露出来。

比如，我很快发现评分不能只显示一个总分。

我更需要看到是哪条规则出了问题，原文在哪一段，下一步应该怎么改。

所以工具后来加入了段落定位。

文章进入检测前会被拆成 P001、P002 这样的内部编号，AI 返回问题时可以指向具体段落。

第七步：一次解决一个问题

后面的开发，基本就是我操作软件，发现问题，再把问题交回给 Codex。

我在描述的时候尽量说清楚三件事：

我做了什么、实际看到了什么、我希望它变成什么样。

比如导出功能一开始不能正常使用，我直接告诉他：

标签的导出按钮点击没有效果，优化

Codex 查完以后发现，浏览器的下载方式不能直接当成桌面软件的文件保存方式，于是把 Desktop 导出改成了系统保存对话框。

之后我又补充了导出目录的要求：

导出时要自定义目标目录

再或者，系统的提示弹窗还没有做UI设计，而且 Codex 还能识别图片，那就截图批注＋描述，更加精确的修改问题。

这些对话看起来都很普通，但可以让Codex听懂的话就是好指令。

实际上手操作  → 发现问题  → 描述现象和预期（提供截图）  → Codex 检查代码并修改  → 重新运行  → 再次判断

这也是我最建议小白采用的方式。

你不需要懂事哪一个文件、哪一行代码错了。

你要做的是把问题复现出来，把“现在这样”和“我希望怎样”告诉 Codex。

你负责判断什么叫好用，Codex 负责在陌生项目里找实现路径。

第八步：让工具真正适合自己的文章流程

当基本功能跑通以后，我又把自己的写作规则逐个放进了工具里。

每条规则都尽量写成平时遇到的具体细节，不要只放一句无头无脑的“检查质量”。

例如，前面规格文档里已经出现过“不要冒充亲测”这条规则。

它后来被放进“真实性”分类，作为一条可以加入评测组的检查项。

这里展示的是已经整理出的产品规则，不把它改写成我当时没有说过的提示词。

这样一来，工具并不依赖某一套固定的标准答案。

我的写作流程变化以后，可以自己修改规则，以后即使在给视频脚本、课程资料或产品说明书做检查，也可以重新组合一套专用评测组。

这就是我觉得自己做工具最有价值的地方。

你做出来的东西不一定一开始就比成熟软件功能多，但它会更贴近你每天真正的工作场景。

第九步：从网页预览走到桌面软件

为了让开发快一点，Codex 会先把前端页面跑在浏览器里。

浏览器预览适合改界面，但我需要的工具最终要安装到电脑上使用，所以后面还要加上 Tauri 的桌面壳。

这个过程可以简单理解成：

“

前面的页面负责显示和交互，Tauri 负责把它变成一个可以安装的桌面程序，并处理本地文件、数据保存和系统能力。

这一步也暴露了几个浏览器里看不出来的问题：

• 桌面软件的数据要能在关闭后保留；
• API Key 不能跟着规则包一起导出；
• 导出规则时要弹出真正的系统保存窗口；
• 浏览器能点击，不代表打包后每个按钮都能工作。

所以我后来打算直接打包出来第一版，按完整流程测试。

这一步的技术细节可以交给 Codex，但测试顺序最好由你自己设计，因为只有你知道这套工具日常要怎么用。

第十步：把桌面程序打成安装包

当核心流程稳定以后，我让 Codex 继续处理打包。

Windows 本地打包的命令很简单：

npm run desktop:devnpm run desktop:build:nsis

前一条用于启动桌面开发版，后一条生成 Windows NSIS 安装包。

这次实际生成的文件是：

src-tauri/target/release/bundle/nsis/Rubriq_0.1.0_x64-setup.exe

拿到安装包以后，我还要重新安装、打开、操作，确认它和开发环境里的页面表现一致。

如果你第一次做桌面软件，建议把打包单独作为一个阶段。

页面能运行、项目能编译、安装包能生成，是三件不同的事情。

第十一步：用 GitHub Actions 做多平台构建和发布

Windows 本地打包成功以后，我又让 Codex 帮我把后续发布流程放到 GitHub Actions 里。

我没有把“构建”和“发布”塞进同一个按钮，而是拆成两个工作流：

Build installers

负责在 Windows、macOS 和 Linux runner 上构建安装包，再把每个平台的文件保存成 Actions artifact。

Publish Release

负责找到一次成功的 Build installers 运行，下载构建产物，然后创建 GitHub Release。

这两个工作流分开以后，出了问题更容易定位：到底是代码没有构建成功，还是发布权限出了问题。

小白照着做，可以记住这 5 步

如果你也想做一个属于自己的工具，可以把过程压缩成下面这五步：

1. 先把需求说成一个具体场景

先说清楚你产生该需求的实际场景，以及想要让它帮你做哪些工作。

2. 控制住第一版的边界

确保你的目标功能满足要求，不要在意当前工具做出来的好看不好看。

UI设计这一块其实是最简单的部分，后面想怎么改就怎么改。

3. 确定产品形态

有了前面的思路，开发前要知道自己最后要做出来一个什么形态的工具。

是一个桌面产品还是一个网页工具？

4. 让 GPT 整理开发文档，再引入 Codex

让 GPT 先把产品逻辑、第一版功能和成品形态整理好；Codex 直接沿着已有对话开始开发，可以少重复说明需求，还省token。

5. 用真实操作迭代，再完成打包

先做出能点击的版本，再把每次发现的问题说清楚。

核心流程跑通后，才做 Windows 安装包、多平台构建和 Release 发布；每一层都要实际验证。

最后想说的话

开始，我每天审核文章太依赖手工检查。

后来，我把自己的审核流程说给 GPT 听，让它帮我整理成产品规划；

这份规划交给 Codex，让它进入项目、修改代码、处理问题和完成打包。

最后得到的 Rubriq 这个产品。

目前它不是一个功能完整的商业软件。

但它已经变成了一套可以持续添加规则、运行文章检测、保存结果并打包安装的桌面工具。

这个工具的基础功能已经实现了，最近在开始沿着我的使用习惯，继续完善优化。

目前这个工具确实帮我节约了不少时间，要不我真没时间写更多高质量的文章给大家学习了。

后续，我也会根据大家的需求程度，来决定是否将这套工具开源给大家下载，可以期待一波。

这次的桌面 APP 开发过程让我确定了一件事：

小白做工具的起点，是要能把自己的核心流程说清楚。

你知道什么算合格，GPT 可以帮你把想法整理成方案，Codex 可以帮你把方案推进成项目。

中间真正不能省掉的，是你亲自打开软件、实际操作、指出哪里不对，再让它继续修改。

相信看了这篇文章后，你也可以从一段对话开始，做出一个贴近自己工作方式的工具了。

AI 时代真好呀，短短一个月时间，我已经开发了很多款小产品了。

很多人，也给我反馈，使用体验特别好。

或许，我的产品梦，真的开始了。