上半篇的反响不错，其实真正的干货都在下半篇。

下半篇内容憋了好几天才写出来，因为介绍系统的帖子并不好写。写的太深奥大部分人没基础根本看不懂，写的太简单大家又觉得不过如此。只能憋一点是一点，写到哪算哪。

如果说散户手撸党属于农耕社会的话，脚本工作室应该算是工业革命，而我们的自动化撸毛系统可以算是核武器了。

有人在推下面留言说我是卖系统的。大家觉得我的格局是这么低的吗？ 其实我是来劝退诸位农民，哈哈。

一、需求和痛点

开发一个系统最重要的不是技术而是充分了解需求和痛点。在整个系统的开发过程中，我也向很多行业的大佬请教学习，了解了各种团队的运作模式和痛点，也学习了不少好的策略。

手撸工作室的痛点：

1、人力成本、设备成本高昂

2、管理成本高，包括新项目的培训、每天任务的验收等等。

3、资金安全问题。被人盗走怎么办、人工误操作也可能造成损失。虽然可以通过阉割小狐狸钱包等方式解决，但是治标不治本，不敢上大资金。

4、操作模式同质化、操作时间集中等等。

一、需求和痛点

脚本工作室的痛点：

1、同样是资金安全问题。大部分私钥都是明文或者简单加密保存，直接用脚本调用的，安全性很低，也不敢上大资金。

2、脚本比较同质化，灵活性不够，容易女巫。

3、没有完善的管理系统，运营管理的难度较大。

4、大部分都是通过selenium模拟前端点击， 脚本开发效率低，每个项目都得重新开发。而且比较吃服务器和带宽

总结起来主要的需求和痛点就是：提高资金安全性、降低运营管理和人力成本、降低服务器等的消耗和成本、提高策略的丰富程度（让每个钱包的操作都独一无二，像一个独立的人）、简化脚本和策略的开发难度

结合我们团队的实际需求出发，我们觉得安全性的优先级最高，因为我们都是精品号策略，而且账号数量大。以团队5个人，每个项目人均1000个账号为例，像zksync就算我们每个账号留存最低的0.2E，一个项目5000个号就得1000E了。这些长期保存在服务器上，必须确保安全。

其次是降低人力成本，能做到完全自动运行无人值守。

最后是简化策略和脚本的开发难度，做到90%以上可配置化，开发速度快是后期的核心竞争力。

二、系统的架构

基于以上的需求和痛点，我们设计的系统架构如下，主要分几个模块：

下面是一张简单的架构图

1、私钥中心：

考虑到我们大资金安全的问题，当然也是考虑到服务器成本原因，我们除私钥中心数据库以外的服务器全部是放在办公室的自建服务器上，平均5000元一台的双路服务器，用EXSI分割10个虚拟机（linux和windows），至少可以同时运行10000个脚本，性价比极高。

所有的私钥通过双重加密后，存在在阿里云的私钥服务器中，脚本服务器每次执行任务时连接私钥服务器解密后才能使用，而且密码只有本人知道。

脚本服务器和私钥服务器之间也有白名单等安全措施，无论是脚本服务器或者私钥服务器单独被黑都不会泄密，安全级别基本等同于现在外面一些MPC钱包。

2、资产管理中心：

这里的资产指的是包括IP、推特、DC、邮箱、充值地址等信息，每一个撸毛账号对应一套完全独立的资产，根据不同的任务进行分配，实现100%的隔离和防女巫。

3、网络管理中心：

网络也是我们花了很多时间摸索和优化的地方。外面买的IP不管花多少钱，其实在国内的连接速度普遍都不快。大家买过IP的都知道，在指纹浏览器里连接打开一个网页都要好几秒钟。

而我们买的又是最便宜的1000个IP才100U一个月的那种。 所以我们做了一个牛逼的路由架构，办公室的企业宽带连接一个负载均衡的自建机场集群，再连接这些IP，速度和稳定性大大提升，成本又极低。

现在我们就上了两三个项目的情况下，一天流量要走100多G了，后面项目再上来还得继续扩容。

4、任务调度中心：

任务调度中心也是这套系统的核心之一。大部分代撸的脚本，所谓防女巫就是在脚本运行之间加一些随机变量和随机等待而已，逻辑非常简陋和粗糙，运行时也需要人值守。

我们基于网上一套开源的任务调度框架，开发了一个适合撸毛的调度中心，可以做到7*24小时无人值守运行，任意的错误都有断点重做等功能，而且支持并行任务和串行任务两种模式。

拿1000个钱包举例：

所谓并行任务是指，这1000个钱包配置好每周执行各执行5次链上交互， 就是完全随机分散在一周的合适时间点自动执行，而且可以挑选GAS最低的时候执行（比如设置主网GAS 20以下做，否则等待）。

串行任务适合大资金，比如每个钱包每月走一次100E的资金量，那如果并行的话需要1000*100的E，显然不可能有这么多钱。那就可以通过串行模式，第一个钱包从交易所提币、跨链、链上一系列交互、跨链回来、充回交易所，然后再继续执行下一个，中间有任何问题都有异常处理机制。

把并行模式和串行模式结合起来，可以组合出非常丰富的交互策略。

而且在基础脚本开发完的基础上，策略的组合仅需要配置json文件和相应的参数就可以了，可以做到后期0开发量。

5、链上脚本开发框架

我做过调研，超过90%的脚本撸毛工作室，都是通过指纹浏览器模拟前端交互实现交互的，就是你们看到网上很多人晒的几十个窗口的那种。

相比直接调用合约交互，每个项目都需要开发一套前端脚本，前端交互的速度也非常慢，出错的几率也很大，而且非常吃服务器，GAS费花费也大很多。

剩下10%也只是会写一些简单的合约交互脚本，他们对web3的了解程度非常有限。

而我玩DEFI这么多年，可以说对各类项目的合约代码非常熟悉，我们也很早就做了全链DEX的价差监控，把那套框架拿过来一改就可以了。

其实链上的项目主要分三类： DEX、借贷、MINT NFT。

DEX的底层主要是两种，一种基于uniswap V2，一种基于uniswap V3

而对应的Farm功能，也是分两种：早期流行的sushi swap Masterchef模式，和现在流行的solidly VE(3,3)模式。

借贷也主要分两种，一种是基于compound的项目，比如Venus。 一种是基于AAVE的项目，比如Radiant。

MINT NFT或者域名就更简单了，大同小异。

所以只需要把这些功能模块都抽象出来做成组建，就可以像搭乐高一样快速开发了。

目前EVM链或者类EVM链，我们开发一个新项目的时间只需要5分钟做一些参数配置，再花10分钟测试一下即可。

随便发一段代码给你们看一下，22行代码就可以实现一个借贷平台的配置。

6、前端（selenium）脚本开发框架：

对于大部分web3项目，其实链上交互就足够了。但是现在有越来越多的项目方不断在pua撸毛党在各种平台比如galxe上做各种任务。像这次linea一周出30多个任务，别说手撸了，大部分团队连开发脚本都来不及。因为涉及到各种推特、DC等任务，也不得不用到前端selenium模拟。

所以我们也同步开发了一套了前端框架，将各个功能模块做成组件化，比如推特模块、DC模块等等，再结合链上交互脚本，做成任务平台的可配置化。可以做到一个galxe的任务，也只需要配置一个json文件，就可以实现自动化执行。

目前这块的完成度大概60%左右，每个模块都有不小的开发量，但是开发好以后就一劳永逸了。

写了这么多，也没办法把系统设计的思路完全讲清楚，但是我相信有基础的同学应该也能收获不少。

如果看不懂的同学，千万不要来问我，我不是老师没时间教你，不可能提供源代码，也不卖系统。

欢迎各位大佬指正和交流。

上半篇的反响不错，其实真正的干货都在下半篇。

下半篇内容憋了好几天才写出来，因为介绍系统的帖子并不好写。写的太深奥大部分人没基础根本看不懂，写的太简单大家又觉得不过如此。只能憋一点是一点，写到哪算哪。

如果说散户手撸党属于农耕社会的话，脚本工作室应该算是工业革命，而我们的自动化撸毛系统可以算是核武器了。

有人在推下面留言说我是卖系统的。大家觉得我的格局是这么低的吗？ 其实我是来劝退诸位农民，哈哈。

一、需求和痛点

开发一个系统最重要的不是技术而是充分了解需求和痛点。在整个系统的开发过程中，我也向很多行业的大佬请教学习，了解了各种团队的运作模式和痛点，也学习了不少好的策略。

手撸工作室的痛点：

1、人力成本、设备成本高昂

2、管理成本高，包括新项目的培训、每天任务的验收等等。

3、资金安全问题。被人盗走怎么办、人工误操作也可能造成损失。虽然可以通过阉割小狐狸钱包等方式解决，但是治标不治本，不敢上大资金。

4、操作模式同质化、操作时间集中等等。

一、需求和痛点

脚本工作室的痛点：

1、同样是资金安全问题。大部分私钥都是明文或者简单加密保存，直接用脚本调用的，安全性很低，也不敢上大资金。

2、脚本比较同质化，灵活性不够，容易女巫。

3、没有完善的管理系统，运营管理的难度较大。

4、大部分都是通过selenium模拟前端点击， 脚本开发效率低，每个项目都得重新开发。而且比较吃服务器和带宽

总结起来主要的需求和痛点就是：提高资金安全性、降低运营管理和人力成本、降低服务器等的消耗和成本、提高策略的丰富程度（让每个钱包的操作都独一无二，像一个独立的人）、简化脚本和策略的开发难度

结合我们团队的实际需求出发，我们觉得安全性的优先级最高，因为我们都是精品号策略，而且账号数量大。以团队5个人，每个项目人均1000个账号为例，像zksync就算我们每个账号留存最低的0.2E，一个项目5000个号就得1000E了。这些长期保存在服务器上，必须确保安全。

其次是降低人力成本，能做到完全自动运行无人值守。

最后是简化策略和脚本的开发难度，做到90%以上可配置化，开发速度快是后期的核心竞争力。

二、系统的架构

基于以上的需求和痛点，我们设计的系统架构如下，主要分几个模块：

下面是一张简单的架构图

1、私钥中心：

考虑到我们大资金安全的问题，当然也是考虑到服务器成本原因，我们除私钥中心数据库以外的服务器全部是放在办公室的自建服务器上，平均5000元一台的双路服务器，用EXSI分割10个虚拟机（linux和windows），至少可以同时运行10000个脚本，性价比极高。

所有的私钥通过双重加密后，存在在阿里云的私钥服务器中，脚本服务器每次执行任务时连接私钥服务器解密后才能使用，而且密码只有本人知道。

脚本服务器和私钥服务器之间也有白名单等安全措施，无论是脚本服务器或者私钥服务器单独被黑都不会泄密，安全级别基本等同于现在外面一些MPC钱包。

2、资产管理中心：

这里的资产指的是包括IP、推特、DC、邮箱、充值地址等信息，每一个撸毛账号对应一套完全独立的资产，根据不同的任务进行分配，实现100%的隔离和防女巫。

3、网络管理中心：

网络也是我们花了很多时间摸索和优化的地方。外面买的IP不管花多少钱，其实在国内的连接速度普遍都不快。大家买过IP的都知道，在指纹浏览器里连接打开一个网页都要好几秒钟。

而我们买的又是最便宜的1000个IP才100U一个月的那种。 所以我们做了一个牛逼的路由架构，办公室的企业宽带连接一个负载均衡的自建机场集群，再连接这些IP，速度和稳定性大大提升，成本又极低。

现在我们就上了两三个项目的情况下，一天流量要走100多G了，后面项目再上来还得继续扩容。

4、任务调度中心：

任务调度中心也是这套系统的核心之一。大部分代撸的脚本，所谓防女巫就是在脚本运行之间加一些随机变量和随机等待而已，逻辑非常简陋和粗糙，运行时也需要人值守。

我们基于网上一套开源的任务调度框架，开发了一个适合撸毛的调度中心，可以做到7*24小时无人值守运行，任意的错误都有断点重做等功能，而且支持并行任务和串行任务两种模式。

拿1000个钱包举例：

所谓并行任务是指，这1000个钱包配置好每周执行各执行5次链上交互， 就是完全随机分散在一周的合适时间点自动执行，而且可以挑选GAS最低的时候执行（比如设置主网GAS 20以下做，否则等待）。

串行任务适合大资金，比如每个钱包每月走一次100E的资金量，那如果并行的话需要1000*100的E，显然不可能有这么多钱。那就可以通过串行模式，第一个钱包从交易所提币、跨链、链上一系列交互、跨链回来、充回交易所，然后再继续执行下一个，中间有任何问题都有异常处理机制。

把并行模式和串行模式结合起来，可以组合出非常丰富的交互策略。

而且在基础脚本开发完的基础上，策略的组合仅需要配置json文件和相应的参数就可以了，可以做到后期0开发量。

5、链上脚本开发框架

我做过调研，超过90%的脚本撸毛工作室，都是通过指纹浏览器模拟前端交互实现交互的，就是你们看到网上很多人晒的几十个窗口的那种。

相比直接调用合约交互，每个项目都需要开发一套前端脚本，前端交互的速度也非常慢，出错的几率也很大，而且非常吃服务器，GAS费花费也大很多。

剩下10%也只是会写一些简单的合约交互脚本，他们对web3的了解程度非常有限。

而我玩DEFI这么多年，可以说对各类项目的合约代码非常熟悉，我们也很早就做了全链DEX的价差监控，把那套框架拿过来一改就可以了。

其实链上的项目主要分三类： DEX、借贷、MINT NFT。

DEX的底层主要是两种，一种基于uniswap V2，一种基于uniswap V3

而对应的Farm功能，也是分两种：早期流行的sushi swap Masterchef模式，和现在流行的solidly VE(3,3)模式。

借贷也主要分两种，一种是基于compound的项目，比如Venus。 一种是基于AAVE的项目，比如Radiant。

MINT NFT或者域名就更简单了，大同小异。

所以只需要把这些功能模块都抽象出来做成组建，就可以像搭乐高一样快速开发了。

目前EVM链或者类EVM链，我们开发一个新项目的时间只需要5分钟做一些参数配置，再花10分钟测试一下即可。

随便发一段代码给你们看一下，22行代码就可以实现一个借贷平台的配置。

6、前端（selenium）脚本开发框架：

对于大部分web3项目，其实链上交互就足够了。但是现在有越来越多的项目方不断在pua撸毛党在各种平台比如galxe上做各种任务。像这次linea一周出30多个任务，别说手撸了，大部分团队连开发脚本都来不及。因为涉及到各种推特、DC等任务，也不得不用到前端selenium模拟。

所以我们也同步开发了一套了前端框架，将各个功能模块做成组件化，比如推特模块、DC模块等等，再结合链上交互脚本，做成任务平台的可配置化。可以做到一个galxe的任务，也只需要配置一个json文件，就可以实现自动化执行。

目前这块的完成度大概60%左右，每个模块都有不小的开发量，但是开发好以后就一劳永逸了。

写了这么多，也没办法把系统设计的思路完全讲清楚，但是我相信有基础的同学应该也能收获不少。

如果看不懂的同学，千万不要来问我，我不是老师没时间教你，不可能提供源代码，也不卖系统。

欢迎各位大佬指正和交流。