为了自动化写了很多脚本，却总是边用边丢，所以我写了一个脚本管理工具 https://juejin.cn/post/7369211590363430923

[easychen]

因为经常做一些自动化的工作，所以我会写一些脚本，不管是用无头浏览器去获取一些网站的内容，还是利用 apple script 将 Keynote 转为视频。这些年陆陆续续的算下来手上的脚本已经有几十上百个。

但是它们散落在代码库的各个地方，每次用的时候都很难找到。更麻烦的是各个脚本之间使用的语言接口都不一样。有时候想把它们串起来用，还需要进行重写。

所以我想要不我就干脆写一个工具把这些脚本统一管理起来... → https://juejin.cn/post/7369211590363430923

按网友建议，直接贴出仓库地址

- 仓库： https://github.com/easychen/fxd
- 手册： https://ft07.com/fxd/
- 视频教程：编写一个自动推文发布应用 - https://www.bilibili.com/video/BV1bC41177W7/

[tairan2006]

gist 你不知道么

[qq316107934]

一楼没看完文章就发表评论，不是很友善。 这个感觉更像是脚本版的快捷指令管理器

[kkk9]

捡了西瓜，丢了芝麻

[kkk9]

说实话，op 之前的推送服务很好，但是现在变味了，不否认变现的重要性，但是不能软饭硬吃吧。

对于本帖，我更觉得更像是引流的推广软文，标题正文全部挂 juejin 链接，github 地址还得跳 juejin 去找？

@Livid

[w568w]

挺好的，已 star 。几个小建议：

1. 每个小工具要单独写一个 schema json ，其实不很人体工学（既指 schema 也指 json ）。有没有考虑让写脚本只需单文件？比如直接从 typescript 脚本里解析两个 interface 来确定输入输出结构和 Manifest 这些内容；

2. 和写脚本直接放到 ~/.local/bin 相比有什么优势？

我觉得脚本的意义就是用完即丢，不用考虑兼容性这些，随便硬编码也无所谓。但这个管理器看起来还能安装别人上传的脚本。说白了，越随意的需求越私人，没有发出去的必要；越公众的需求越正式，一般也不以「脚本」而是以「 API 」或「工具」相称，我写完了也不会发到你的仓库里。

我觉得不如转变思路，做个脚本的瑞士军刀 SDK ，把监控网页、显示 UI 输入、保存设置之类的常见需求都聚合起来，方便用户快速编写脚本，类似一个全平台的桌面端 autojs 。

[angeni]

@kkk9
1. 挺方案这种动不动就圈管理的行为，感觉想小孩给家长告状。
2.虽然引流到了外站但是个人认为是情理之中的，内容创作并且开源。总不能全链路的为爱发电吧？

[angeni]

@angeni
* 挺反感这种动不动就圈管理的行为，感觉像小孩给家长告状。

[kkk9]

@angeni #6

1. 可以理解，互相尊重。

2. V2EX 是个技术社区，不是内容农场。如果是为了推广自己的产品，完全可以把全文贴上，留下捐助信息。

[easychen]

@kkk9

Server 酱现在一样有大量的免费用户，PushDeer 到现在一直是开源免费的，企业推送的代码之前我们也开源了，可以自己搭。觉得不需要，不用就好，没必要阴阳怪气。

希望能就事论事，不要拿其他事情来攻击。

至于为啥不在 V2EX 贴全文，单纯的是因为没法编辑，改错字很麻烦。我甚至把网址都放 title 里边了。

V 站不光是你的，即使你认为是产品广告，我们依然有，至少有在「分享创造」节点发布自己的产品的权利吧。

[easychen]

@w568w

1. 其实现在 schema 是 GPT 在写 😂 过段时间弄个自动生成的命令行。
2. 通过 npm 大规模的、开放式的分享，可以最大程度的重用。脚本只是一个方便程序员理解的说法，我们产品文档是称为应用。实际上现在的 fxd app 大部分都是重用性非常高的，比如 fetch 、search 、weibo/x publish 。

[nicoljiang]

@kkk9 是哦，都开源了还不恭恭敬敬把东西喂你嘴里，现在玩开源的人真是太把自己当回事了。

另外，什么是内容农场啊？哪里都 Copy 一遍全文才叫内容农场好吗？

yc news 、techmeme 全是外链，也是内容农场？

[kkk9]

@easychen #9
@nicoljiang #11

希望好好看看前面的对话，阴阳怪气的是谁？

就事论事，那说的就是软文的事情，何时说过你开源的不是？

[kkk9]

@easychen #9 发帖后一段时间内是可以 EDIT 的，按钮在 title 下方， 望知道

[easychen]

@kkk9 那请问：

1：我的「软文」和我们的推送服务有什么关系？
2：我们的推送服务和软饭又有什么关系？就因为它收费？
3：发帖后只有 30 分钟可以编辑，这段时间没有发现的错字依然改不了，依然不适合发长文。

[MrSheng]

@easychen #14

首先掘金原文并不复杂，在这里直接发全文并不是一个难事。

其次，不可编辑的特性正是 V 站所倡导的，就如同发言也无法删除一样，就是希望每个人在发言的时候可以思考斟酌。有什么错误或者遗漏可以补充，这样比较容易还原事情的真相。

真实生活中的说出去的话可以更改吗？

[doublebu]

当作 LLM Tools 这个确实很好，脚本一多就忘了某个脚本是做啥的。

[ersic]

@kkk9 #4 他这也也获取不到啥利益，就是个文章，算不上推广吧

[easychen]

@MrSheng

发不发全文只是一个选择，而不是强制的。如果站长在社区规则中添加这一条，我很乐意遵守。
你喜欢看自己文字里边充满错字，但有些人可能都难以忍受，这可以理解吧？

我纳闷的就是，为什么我一个（自以为）遵守了社区规则的帖子要被你们（甚至还不是管理）指责？

或者我换一个更友善的说法，你们能给我一个在 V2EX 社区发帖不会被不友善对待的潜规则列表吗？

比如：

1. 必须发开源
2. 必须贴全文
3. 必须不带二维码
4. 必须不带除 GitHub 以外的外链

???

[foolnius]

https://www.v2ex.com/about

• 这里绝对不会全文转载任何文章，而只会以链接方式分享(V2EX 不反对文章的原作者自己全文转载自己写的原创文章)

楼上的几位要不先看看

[shunia]

@kkk9 #4
"说实话，op 之前的推送服务很好，但是现在变味了，不否认变现的重要性，但是不能软饭硬吃吧。"
咋了？为什么突然在这里喷这事？引战了就把话说明白。我目前一直在使用 server 酱的免费服务，刚好符合我的需求，服务也很稳定，没有广告。我觉得足够友好。

"对于本帖，我更觉得更像是引流的推广软文，标题正文全部挂 juejin 链接，github 地址还得跳 juejin 去找？"
v2 确实更建议贴全文，不过你说话带的情绪太重了，上来就给人扣帽子，然后才开始揪全文的事。就算你 100%正确也不代表你可以表现得极其不友善。既然你这么尊重规则，那按照一般人理解，你和人家有仇有新开贴把事情说明白，抖出来让大家看看。这么一个相对正常的分享/推广贴就因为你在 4L 的回复而变得乱七八糟，实在让人恼火。说到“相互尊重”不知道你哪来的对规则，对 OP ，对看客的尊重。

利益无关，我甚至没点开 juejin 的链接，因为我不想打开任何 juejin 的链接。

[wdssmq]

1 、博文或者文档建议加上「盘古之白」←英文/数字和中文之间的空格

可以使用 md-lint 工具。。V 站好像一直是自动添加的？

现在我手动输入时习惯自己手动加上空格。习惯了好像也没特么麻烦。。

2 、顺手推一下自己的中转页自动跳过脚本，包括掘金：

「水水」链接跳转
https://greasyfork.org/zh-CN/scripts/444787

[wdssmq]

@wdssmq 特么 → 特别。。。emmm

[wdssmq]

项目本身好像能解决我的一些需求。。先收藏了。。

[Leon6868]

非常好，完美解决了我的需求

[jiangyang123]

@kkk9 v2 不推荐全文转载文章,这是网站的规则

[Popsicle]

有没有类似 Prompt 的管理工具，这种乱丢的感觉是差不多的，工作中的 Prompt 虽然不怎么复用，但有时候也有借鉴意义，想记录一下，另外就是 Prompt 也会需要版本管理，因为要一直去调试，我现在就是随便整个文档记录着，稍稍有点乱，不知是否有此类管理工具

[Tdy95]

插句题外话：作者去年众筹的 node_modules 包还发货吗

[Xinu]

如果经常用脚本做一些事，推荐一个软件 utools 下的 快捷命令
这是插件主页： https://u.tools/plugins/detail/%E5%BF%AB%E6%8D%B7%E5%91%BD%E4%BB%A4/
这是脚本分享页： https://qc.qaz.ink/

经常用自己写的小脚本，真的是极大提高效率

[deng884720982]

@Xinu 我也用的 utools 的确实好用，直接搜索就直接运行自己需要的脚本

[MrSheng]

@easychen #18
你说的没错，社区的确没有 “强制” 规范，甚至很多情况是站长一人说了算，连规范都没有。
但是你的行为的确不是 V 站所倡导的行为，希望你能重新复习一下规则：

（ 1 ） /faq 中 “我是否可以编辑或者移动自己的主题？” 章节
（ 2 ） /help/spam 中的内容
（ 3 ）/about 中第 1 点解释: `V2EX 不反对文章的原作者自己全文转载自己写的原创文章`

当然如你所说，这些都不是强制的，你有自由选择的权利

[easychen]

@MrSheng

为什么 「 V2EX 不反对文章的原作者自己全文转载自己写的原创文章 」可以推导出 「贴外链不是 V 站所倡导的行为」？

所以 「不反对 」的意思是「倡导」吗？


我建议你复习一下语文和逻辑，当然这你也有自由选择的权利，毕竟不会这两个也可以上网。

[easychen]

@MrSheng

如果你没有阅读理解能力，我可以帮你做一遍阅读理解：

以下是 /help/spam 的内容。

链接搬运
如果，你注册 V2EX 的目的，只是为了**不停**地将你的网站的链接粘贴至此，或者寄希望于这里的用户去点击会让你**受益**的 aff 链接，那么请停止这样的行为吧。

...

请停止你的链接搬运行为吧。

再来看看 V 站关于发布自己产品的规则：

我可以在这里推广自己的网站么？
我们非常欢迎创业者在这里发布自己的新作品。但是如果你在这里注册一个账号，就是为了将自己网站上的链接**一个一个**搬运过来的话，请停止这样做。



所以，我在「分享创造」节点发布自己的产品，有什么问题？

至于 Spam ，麻烦看清楚「不停」和「一个一个」。我甚至想不出来不贴外链如何发布自己的产品。就因为外链是 juejin 而不是 Github ，就 Spam 了？

[kkk9]

@shunia #20 OK ，我明白了，是我的语言表达有问题，没有引战的意思。这里，我先给 op 道歉。

@easychen 不好意思，是我的语言表达能力有问题。

我来解释下，我的本意是：op 之前做的项目（推送服务）很好，但是现在做的项目（包括 AI/爬虫等等），个人觉得变味了，没有以前（推送服务）那么纯粹。我不否认开发者需要变现，但是不要随便整点啥就发（软饭硬吃）。

@jiangyang123 #25 about 不欢迎全文转载，spam 也说了不能随意贴链接。如果标题不贴链接，我是不会特意说的。

[kkk9]

@easychen #32 你可以发外链（产品官网、文档、github ），但是你特意发 juejin 的链接（标题+正文），并且掘金那边的原文写的也“流水账”。那么你觉得是符合 about 还是 spam ？

[easychen]

@kkk9

你加个「个人觉得」就可以把别人辛苦写了几个月的东西变成「随便整点啥就发」，把我为了避免直接发 FXD 规范，没人深入看写的文章斥为「流水账」。

我觉得你可能不太明白「引战」和「友善」的含义。

[easychen]

@kkk9

是不是 spam 不取决于它是否放在 juejin ，而是它本身的内容。你不喜欢、对你没用不等于对别人没用。

而且如果你个人不喜欢 juejin ，大可以留言建议我补充 GitHub 链接。而不是开始攻击（软饭硬吃）和扣帽子（推广软文）。

[kkk9]

@easychen #36 建议你补充 GitHub 链接

[easychen]

@kkk9 加上了。

[X-Force]

也就是说这个是仅支持 NPM 的？要是能支持 Shell 脚本和 Python 脚本的管理和串联就好了。

[easychen]

@X-Force 因为要重用一些基础功能和管理依赖，所以用了 NPM 。其他脚本其实简单封装也行，再用 node 调用命令行。

[kuanat]

一开始看帖子没看明白是做什么用的，看了手册才反应过来这是做了一套类似 IPC 的规范，外加一个注册中心。

有一点我觉得 OP 做得非常好，schema 自动生成。但是就如 #5 @w568w 所说的，这套规范化的做法是和写脚本这个行为的初衷天然互斥的，一个追求复用，一个追求敏捷。而且楼主在文章里也说，为了这个工具重写了大量脚本，着实有一种为了这碟醋包了一顿饺子的意味。

正好借这个帖子我想探讨一下 IPC 和工作流的话题，不知楼主是否了解过 dmenu ？



鉴于很多人可能从来没有听说过 dmenu ，我就简单介绍一下。它原本是为 dwm 窗口管理器设计的动态菜单（ dynamic menu ）应用，常常用作 Linux 环境的启动器。

和其他所谓效率工具最大的不同在于，dmenu 的哲学是它仅仅只负责从 stdin 读取输入生成菜单，然后向 stdout 输出用户的选择。整个过程的交互全部是纯文本。如果有必要上一个 dmenu 的输出也可以作为下一个 dmenu 的输入。

我个人认为 dmenu 设计思想的优秀之处在于：将写脚本和写工作流恰当地分离开，写脚本依然是那个能跑就行的随手工作，当需要将脚本集成进工作流的时候，适配所需的代价非常小，关键是并不需要刻意改动脚本。



单纯这样说可能依旧看不出 dmenu 设计思路的巧妙之处，我举几个例子说明。

比如我希望命令行将 wifi 切换至手机热点。需要准备两个脚本，一个是调用 nmcli 扫描当前可用网络，然后字符串处理一下生成 wifi 列表；另一个是从命令行读入一个字符串，调用 nmcli 连接该字符串所代表的 wifi 网络。

这个过程里 dmenu 的作用是，调用第一个脚本得到输出结果，以列表的形式供用户选择，并将用户的选择输出，传递给第二个脚本使用。写成命令行就是 `script1 | dmenu | script2`，通过管道的形式传递。

从这个例子可以看出，两个脚本本身就是实现功能用的，原本怎么写就怎么写，不需要预先考虑去适配某种输出。即便是别人写的脚本，只要它是文本输出，完全可以套一层 wrapper 使用 awk/sed 等工具转换成需要的输出。脚本不支持命令行输入，也可以使用 xargs 等方式将 stdin 转换为命令行参数。

至于工作流，无非就是扩展之前的命令行 `script1 | dmenu | script2 | xargs ... script3 | dmenu | script4` 这样，在有需要用户输入或者选择的地方加入 dmenu 即可。更进一步的话，将脚本都放在 ~/.local/bin 然后设计一个“入口”工作流，让用户首先选择所需要调用的脚本，那就变成了万能入口的效率工具了。



我不记得是什么时候接触到 dmenu 了，15 年应该是有了，现在我早已不用 dmenu ，但是依旧在用基于 dmenu 思路的替代品。写这个回复的时候突然想起了很早之前比较流行的一篇文章《开发人员为何应该使用 Mac OS X 兼 OS X 小史》，链接在 https://blog.youxu.info/2010/02/28/why-mac-os-x-for-programmers/

从时代的发展来看，即便是 macOS 这么理想化的 IPC 设计（图形化界面基于 Mach 的 Service 服务概念），依旧是推广不开的。抛开技术层面统一 runtime 不靠谱这一点，更重要的应该是人性，想要别人主动去适配实在过于困难。

万能入口、启动器这种工具的生态其实挺有意思的：Linux 用户似乎从来不关心，估计是都有自己手搓的方案； Windows/macOS 平台上的实现几乎看不到基于 dmenu 思想的实现，虽然可以解释为这些工具面向的都是没有编程能力的群体，那适配脚本的工作就显得更加难以实现了。

[easychen]

@kuanat

我重写脚本有一个非常大的原因，就是把它们作为 LLM tools ，正是因此，规范才贯穿始终。

在设计上，可以把目光往后看，以后这些脚本可能不是人来写，所以规范和敏捷可能不是冲突的。

事实上，目前借助 Custom GPT ，已经可以编写简单的 FXD 脚本，我预期在 GPT5 时，应该可以直接编写 50%以上的日常脚本，剩下 50%只需要简单修改即可使用。

而通用脚本的适配，其实也不是问题，同样交给 AI 去做就好了。

只需要等待智能逐步提升，到达临界点，甚至很多软件的竞争壁垒都会消解，比如你可以用 AI 重写 wordpress 的 6 万个插件，让一个新兴项目拥有以往十年积累才能有的生态。

时代要变了，我们尝试面向下一个时代设计。当然，不一定成功就是了。

[MrSheng]

@easychen #32

本人认为此贴是 [引流] 行为，请 OP 正面给出以下两个问题的答案：

（ 1 ）请 OP 先解释下要达到什么标准才符合 [不停] 、 [一个一个] 的规则
（ 2 ）请 OP 给出 [引流] 的定义，并且说明此贴不属于 [引流] 的范畴

[0o0O0o0O0o]

@Popsicle #26 感觉流行的那些 snippets 管理工具就可以？

- https://github.com/hackjutsu/Lepton
- https://github.com/massCodeIO/massCode
- https://github.com/knqyf263/pet

[easychen]

@kuanat

我把 FXD 的代码生成加上了 https://github.com/easychen/fxd/blob/master/README.zh-cn.md#fxd-app-%E4%BB%A3%E7%A0%81%E7%94%9F%E6%88%90

现在用 gpt-4o 还比较弱智，但可以省下不少功夫，作为编程起点已经很方便。等之后模型能力提升了，应该能做更多事情。

[kuanat]

@easychen #45

我之前的思路局限在脚本和工作流都是人在写之上，如果把视野展开，让 AI 来做胶水类型的工作（这本来也是语言模型的强项），现在就具备可用性了。

我也有尝试用 AI 来辅助生成功能性脚本，目前遇到的主要问题是没有很好的验证机制，很多时候需要人参与代码审计。另外目前基于提示词的运作方式接近于声明式编程，生成代码的实现方式比较不可控，更增加了人工判断的成本。

[273601727]

@kuanat 现在的 AI 能节约很多繁杂编程的时间，试想一下：你读大学所有的理科书籍后面的习题例题，全都交给 GPT 生成 python 代码，用来求解与可视化，真的不可想象以前巨大的工作量（我也参与编写过一部本科教材），现在只需要人工审核一下即可。