极简一键脚本是为了有一个容易学习和阅读的基材 方便大家实现自己需要的一键脚本 我会做什么 我不会做什么
这两天有网友主动和我提起保姆型的大而全的菜单脚本的需求.
我突然觉得正好借此机会表达一下 我会做什么, 我不会做什么.
========
1) 我自己想要做的.
我会做得非常详细.
教程尽量每一步都图文并茂, 而且会根据反馈不断优化, 如果环境发生了变化, 只要我知道了, 我就会更新教程.
比如, 我的搭节点的教程, 从买VPS到最终能使用. 我的目标是, 爷爷奶奶都能学会, 只要会使用键盘鼠标, 能认得键盘按键上的字母和符号.
我甚至想过, 把链接的字体设置成不会混淆的. 这样, 把教程打印成纸质的, 使用者也能 一个一个字符的敲到浏览器地址栏里, 也能完成节点搭建.
2) 我自己遇到的问题.
如果网上现有的搜索结果不行, 或者不够完整, 或者需要多个信息(知识点)结合起来解决问题, 我会记录.
我希望自己遇到过的问题, 下次不用再寻找一次答案, 而是直接使用自己总结的经验.
对于网上现有的搜索结果, 我希望自己的总结能作为补充, 帮助遇到同样问题的其它人. 有时候, 网上的搜索结果, 能解决100个人中98个人的通用问题, 但是2个人会遇到像我一样的特殊情况, 那么我的总结就有价值.
3) 其它网友遇到的问题.
在论坛或telegram群组里, 有时会遇到网友提出在我比较熟悉的领域内的问题. 如果网上的搜索结果不够准确或不够完善, 这个问题和我自己的博客内容不重复或者是正交的补充, 我会记录.
比如, yt-dlp 下载时有年龄限制
4) 我的项目.
我自己的爱好和审美是 够用就好, 简洁, 正交.
而不是用一个内核支持多个协议.
我对于自己的搭节点一键脚本还有一个定位, 就是要足够简单, 容易阅读. 这样可以作为一个良好的基材, 大家可以在此基础上做出满足自己需求的脚本.
我的脚本里面没有函数, 就是从头到尾执行.
唯一会在阅读代码时需要前后跳转的原因 就是, 有一些变量 是贯穿始终的. 这个无法避免.
满足了我自己的需求之后, 面对网友的需求, 我会按以下优先级考虑:
我自己现在或将来是否会需要
有没有现成的, 已经足够好的方案
需求本身的价值有多高
需求的生命周期有多长
开发的代价和维护的代价
5) 现有的项目. 如果我有自己的想法或需求, 我向作者提了建议, 作者不接受. 那我就fork了自己动手改.
我的理念是, 如果这个想法是对的, 那么就会有足够多的人使用这个fork, 并不断地向作者建议采纳这个想法.
当talk不能达成一致意见时, 就用code运行起来的实际效果说话.
比如, v2rayN-VLESS v3.29.0.x 支持 reality, hy2, tls分片, socks下一跳出口.
当时促使我fork这一份并修改的原因 就是, 我要继续使用 v3.29 的 PAC 功能
6) 我觉得现在的时代, GPT 是一个强大的搜索器, 可以帮你找到人类已经得到过的答案. 只要你问出的问题是已经有人问过的, 而且有答案的.
GPT 的能力在慢慢变强, 越来越学会举一反三. 即使不存在和你的问题一模一样的回答, 但 GPT 可以通过类比, 找到和你的问题相似的问题的答案, 再经过变化, 生成给你的答案.
GPT 也有拆分和组装的能力. 如果你可以清晰的分阶段的描述你的需求, GPT可以生成合适的答案.
所以, 我在很多博文中, 会贴出GPT的链接, 展示我是如何向GPT提问的. 希望能用这些实例, 帮助更多的人, 可以更好的使用GPT.
* 在这里, 我用GPT代指目前所有的这些大语言模型AI.
========
好了, 说回这个要做保姆型的大而全的菜单脚本的需求.
把我回复的话 发给 GPT, 会得到这样的结果.
怎么样? 有点bash脚本能力的人 是不是一看就知道, 这已经是一个可以跑起来的成果了.
评论
发表评论