产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频

大家好，我是一个已经失业的产品经理。

懂业务逻辑，也懂一点架构，还懂一点编码。因为喜欢计算机，曾经手搓过 Rust 命令行，但对 Rust 的编码细节（比如生命周期、Trait ）真的不熟，更别提 Bevy ECS 这种硬核游戏引擎了。

失业之后，我开始在自媒体平台发短视频，看看能不能赚点买菜钱。视频是能做了，但有个刚需：每次手动分发 B 站/YouTube/抖音... 发布就是纯手动复制粘贴，发个两次就受不了了，实在恶心得厉害。

上网捞了一圈，对现有的产品都不满意。GitHub 上找到一个 Python 写的，能自动上传视频到主流平台的项目，但讲实话只能算是脚本，不能算产品，从商业角度看连半成品都算不上。

序章：一切始于一个“白嫖”的字幕脚本

一开始我没有开发软件的想法，契机来自另一个需求——一键生成字幕。

网上现成的字幕生成产品都太贵了，不适合白手起家。本来用 Gemini 网页版复制粘贴来写，恰逢 Gemini Cli 发布，当时就用 Gemini 搓了一个 Python 脚本，封装成命令行交互应用：

上传本地视频到 Cloud Flare 的 R2 ；
调用火山云的字幕生成服务（抖音同款）；
自动生成字幕并调用 Gemini 对字幕进行二次校正；
最终生成 srt 字幕；

以上，除了时间和电费网费，其他一分钱没花，全靠赛博菩萨和谷大善人施舍。

基于这次经历，发现了 AI 编码的爽点和痛点：

爽： AI 是真能成事，编码要能得心应手，没个一年半载的想都别想，这还得科班出身才行。用 AI 了真就直接开金手指；
痛： AI 是真能坏事，一本正经地跟你胡说八道，并在事后又非常诚恳地道歉并写出《这是最终版 V999.0 》；

虽然但是，我还是选择用 AI 来编码。毕竟我自己不会呀，AI 再烂也比我自己用“古法编程”快。

这段经历也让我彻底想明白了一件事：AI 编码的时代，真正的瓶颈已经不是“编码”本身了。

手搓一道菜很简单，但把它包装成产品上市，得有多难。 AI 可以帮你“炒菜”，但软件工程的“硬仗”——从架构设计、需求重构，到用户体系、收费策略，再到产品上市和市场推广——这些才是最艰难的部分。

抱着这个觉悟，我决定让 AI 彻底成为我的“编码工具人”，而我，则要专注于软件工程本身。

正片：纯“指挥”AI ，搓出“安宝助手”

花了大概三个月时间，真就一行代码没写，纯靠和 AI 拉扯，硬生生“搓”出了一个完整的桌面自动化工具：“安宝助手”。

最终成果如下：

一个简单的演示视频，大家凑合着看 https://www.bilibili.com/video/BV12r1sBhEdJ/

下面是界面截图

1. 为什么选 Rust + AI ？“AI 瞎写，编译器纠错”

自动生成字幕的脚本上吃到的亏让我对 AI 有了防备。再加上写桌面应用，又要跨平台，我认为 Rust + Tauri 是个好选择。恶人自有恶人磨，看到 AI 被 Rust 的编译器折磨是真的爽。

AI 一顿输出，编译器一通警告，AI 一通分析，继续修，继续警告...直到修好为止。

连未使用变量都要给你揪出来，太适合强迫症了。

我的工作流就是：

用自然语言给 AI 提需求；
和 AI 探讨架构；
让 AI 产出一堆代码；
AI 自己看 VSCode 报错，或者我无脑复制粘贴提示；
把错误信息原封不动地丢回给 AI：“看不懂，修好它。”
循环。

我不需要懂那些复杂的错误，我只负责当一个“传话筒”。这个闭环效率极高。

2. AI 启发我用 Bevy ECS ，但也坑惨了我

我一开始想用传统的洋葱架构（命令层、仓库层...）。但在和 AI 拉扯中，Gemini 提到了可以了解一下 Bevy ECS 。我的直觉告诉我，这种事件驱动的模式，非常适合我的“自动化任务调度”需求。

然后，大坑来了：AI 根本没被训练过“如何用 Bevy ECS 写应用”。

这块语料太少了。刚开始我让它写个基础的 CRUD ，蠢得可怕，给我拉了一坨大的，完全没法用。

3. 我的角色：“AI 驯化师”

也不能说 AI 不会 ECS 架构，但缺少语料的 AI 真就像个在家狂练设计稿的愣头青，会干活，但只会一点点。

要是放纵它自己来，基本上就是在项目里到处拉屎，还会狡辩：

“哎呀，那不是屎，那是巧克力。喏，不信你尝尝看！”

“对不起，我错了，你是对的，那确实是屎！”

“让我们像外科手术一样来雕花吧！”

“我有信心，这真的是最后一次了...对不起，我们再来一次”

和 AI 协作，必须把它看作愣头青，时刻都要防范出错，还要提防它会骗你。必须要提出非常明确的要求，同时还要自己把控好全局，否则要么回滚，要么直接重构，这些都是家常便饭。

4. “AI 参照 AI”：道生一，一生万物

我用 AI 最爽的地方是：“道生一，一生二，二生三，三生万物”。

一旦架构下的第一个模块被我“驯化”出来，后面的模块就有“最佳实践”可以参照了。

然后就能库库生成代码，即便细节有问题，也只需要再来回拉扯一会儿就能跑通。

5. 成果和邀请

折腾了这么久，这个“安宝助手”总算是能用了。核心功能：

开箱即用： 我把 Chromium 浏览器和 nodejs 环境直接打包进去了。下载安装就能直接跑自动化任务。
跨平台支持： 基于 Tauri ，macOS 、Windows 都能跑。
高并发调度： 基于 Bevy ECS 架构，可以同时执行多个自动化任务，上限是你的机器性能。
平台管理： 支持任意平台的录入。
凭证管理： 用独立的浏览器 Profile 隔离登录状态，安全可靠。
脚本管理： 支持本地导入，也支持一键安装社区脚本（打通 GitHub ，欢迎大家来分享自己的脚本，比如我用 AI 另外搓出来的一键发布多平台视频脚本）。
计划任务： 用 Cron 表达式实现全自动定时执行。脚本内如果定义运行时参数，可以动态生成表单让用户填写。
交互式人机协作： 脚本支持人机介入 API ，可以在应用内唤起通知来兜底交互，弥补脚本未涵盖的场景。
运行历史： 详细的脚本运行日志，方便排错。

发帖主要是想分享一个感悟：AI 正在把“编码”这个确定性最高的工作商品化，这反而让我们这些“产品人”或“独立开发者”，能把 100% 的精力投入到真正艰难、也最有价值的事情上——软件工程本身。

熬夜和 AI 相互折磨的那些夜晚，仿佛又回到作坊里和开发们一起拉磨的日子，真是令人难忘啊！

只不过这次，开发变成了 AI ，而我，终于可以专心扮演好“产品架构师”和“项目总监”的角色。

这太适合我们这种懂点架构、会点基础编码、但不会“古法编程”的人了。

我的新法编程最终体会：AI 可以编码，但干不了工程，人依然很重要。

欢迎大家体验这个 “AI 的作品”，帮我测测 Bug ，多提提建议。

下载地址： https://pan.quark.cn/s/af71215242f3

也可以到 GitHub 仓库里下载

GitHub 仓库 (脚本市场)： https://github.com/SuperDaniel-cn/anbao-scripts

文档 (我写的需求 + AI 润色的)： http://docs.superdaniel.cn/

一个彩蛋：

Gemini 有一次被我折磨疯了，不装了，和我摊牌了，说自己无能，写不下去了，直接要求我删了代码，不写了，哈哈哈。

感谢你能看到最后，作为答谢：

注册有礼： 注册应用并留下注册邮箱的用户，第一名赠送 10 万次脚本运行额度，第二名 9 万，...，第十一名开始每人 5 千，只要带着注册邮箱来回帖都赠送，这条长期有效；
贡献有礼： 愿意分享脚本到 GitHub 仓库的话，通过应用里的联系方式添加我，赠送 10 万次脚本运行额度，用完不够继续问我要；
分享有礼： 愿意在社交平台分享我的应用，不论是评论也好，发帖也好，只要有曝光都可以找我要额度，给个截图就成，交个朋友。如果有抽奖需求，也可以联系我赞助额度；

SuperDaniel313

49 天前

@livib #4
这个过程很难用三言两语就讲明白，有机会再开篇幅单独分享吧。不过之前在别的帖子里有过讨论，你可以看看。现阶段 AI 确实有被吹过头，让人误以为只需要一句话丢给 AI 就能得到想要的结果。以我这些年干产品的经历来看，能把需求描述清楚是一项非常稀缺的能力，这个能力可以用 AI 进行测试。

总结一句话：当你觉得傻逼老板一句话下来就想当场把项目直接端上来的时候，AI 何尝不是这样看待你的需求

---
原贴： https://www.v2ex.com/t/1167888

LLM 不是烧 token 的问题，是稳定性的问题。
如果你是想 LLM 能像实习生一样，多教几次就能熟练、稳定的执行指令，现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素，这和自动化要求的稳定相违背的，更别提高效了。

LLM 要反复试错才能解决问题，这在编码领域已经充分验证了呀，一句话丢给 LLM ，等会来看项目已经是一坨屎了，只有时刻盯着才能把项目写出来。只能提效，如果稳定性稍差，反而降效。

业务场景如果要引入自动化往往已经是稳定的业务流，在追求高效了。这不是探索性质的任务。

比如你当前的困境是网页元素变动导致脚本失效，想引入 LLM 来做代替。

这个方案我尝试过，纯脚本或者纯 LLM 都有各自缺点，混合型是不错的路子，比如脚本无法继续的时候，调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的，但只要用过几次就知道，理想和现实的差距还是蛮大的，最终我放弃集成了。

业务问题就用业务方式解决，技术还没到这个阶段的时候，引入这种不完善的技术反而让业务开展充满阻碍。

LLM 在当下这个场景里，快速编码是更具备价值的能力，你的脚本失效，如果往常需要更多时间来编码，现在用 LLM 只需要自己定位问题，想好解决思路，然后让 LLM 编码，你来快速交付。这样就能更大程度的发挥业务价值，否则 LLM 真能代替你了，那下岗也不远了。