Table of Contents
上篇博客说到我只用了3天,就利用AI,将一个点子实现出来了,不得不感慨一下这半年 AI 的进步真是飞速。先回顾一下我对于 AI 的认知历史
我使用生成式AI的历史回顾
23年3月吧,那时候 ChatGPT 突然爆火,具体记不得了,有人说 ChatGPT 是22年12月发布的,但是我知道这个东西是在 23年3月,当时身边同事都被震惊,组内还有同事调用 openai 接口用周末时间做了个套壳版的 GPT 内部用。那时候接口调用价格很贵,速度很慢,但是领导花钱买了apiKey那我们就用好了,不过那会儿的 AI 确实很傻,只能回答简单问题,所以网上很多人以愚弄 AI 为乐。
openai 爆火以后,国内的公司也都跟进了,我印象最深的是百度李彦宏说跟 openai 的差距只有2个月,当时王小川还在公开嘲笑李彦宏不懂 AI,确实,现在过去2年了,百度的AI也没赶上openai,这些搞互联网的真是不要脸,吹牛不打草稿。
当然后面几个月AI热度稍微降低了,因为当时训练大模型成本太高,所以很多媒体说美国人再搞AI军备竞赛,希望把中国的企业也拉进去,最终实现消耗我们的目的。这种说法可能也有很多人信了,所以国内很多AI企业放弃了原生大模型的训练,开始选择从开源大模型微调,这时候李彦宏又出来放了个大,说闭源大模型才是先进的,开源大模型就是为了跑分,发论文证明自己强,实际上屁用没有因为没有落地的应用场景。这种说法现在看来真是可笑,但是当时可不一定,因为那会儿AI除了可以回答问题,可以生成一点不太正确,基本上不能运行的代码,确实没别的实际作用。
我忘记 github copilot AI 版本是从何时开始发布的,也许是23年10月吧,反正发布后我就订阅了每月10美金的会员,一直用到现在,最早期的 copilot 效果也很差,只有内联补齐,而且补齐准确性也很差,连括号的匹配都会出错。不过这个产品一直在迭代,因为对微软有信心,所以后面出现了很多编程助手,如 cody, cine, cursor, v0, windsurf 等等我都没换,导致前期确实是花了冤枉钱。
到24年6月,cursor横空出世,它的口号是能用自然语言编程,就是说你不会写代码没事,你说一句话告诉AI你想做个什么样的网站,用什么技术,AI就会给你生成项目文件,基本上直接就可以运行。我没用过cursor所以不知道真假,现在看来应该不太真,因为24年6月的AI质量还是不高,当时有个段子说是大部分AI大模型不知道 草莓 这个英文单词里面有几个r,而且大部分AI都不知道自己是什么模型。不过这个cursor带火了一堆公司做AI编程代理,因为大家都发现这个方向的可行性了,先驱者确实是最厉害的,因为他从无探索出了一条路,而跟进者只需要跟着先驱的脚步往后走就行了,不得不说技术领域就是这么残酷。
因为我没买cursor所以还是一直忍受着github copilot凑合用的功能,当然我很懂代码,我不需要AI帮我从0创建项目,我自己就能搭框架,AI帮我补充一点细节就行。不过到了25年2月份,github copilot出了重磅更新,自己也变成了一个编程代理,有了跟cursor拼刺刀的实力。在上周做那个markflow插件的时候,我就深深的体验到了copilot的强大实力,在那篇博客上我也感叹了一下,未来程序员必定会被AI取代,如果一个程序员不能指挥AI帮自己写代码,那么他绝对竞争不过其他人。
AI 对互联网产品开发流程的革新
以前互联网产品开发都是老板有了点子,安排给产品经理去实现,产品经理拉起技术、设计、运营、数据开会安排工作。然后设计出设计稿,给前端切页面,后端开发接口,最后前后端对接,产品验收,并且交给测试去找bug。这一套流程下来,一个想法最快也要1个月上线,大家还都会很累,因为一旦点子有了调整,所有人都得跟着改,所以就会出现很多扯皮推锅加班的事情。
因为这种开发模式的人力要求很大,所以开发成本还是很高的,所以很多小团队不愿意自己维护一个程序员团队来开发自己的网站,因此出现了一个服务叫低代码平台,就是说不懂技术的人,也可以在上面妥妥拽拽就设计好一个可用的网站,然后根据自身业务更新内容,一键发布。那时候也有很多创业公司在做低代码平台,试图用这种方式取代产研团队,不过这个产业到现在应该是无了,因为AI太强大了,你自己去拖拽创建网站,还不如说句话让AI帮你生成一个可以部署的网站。
23年还有一个比较火的功能,就是从图片生成网站代码,就是你看别人的网站好看,截图告诉AI,AI就能给你生成类似的前端代码,这个功能到现在也已经没人用了,因为对于公司来说有设计师,有前端,为啥要根据截图生成页面代码,而对于个人开发者来说,根本不用这么麻烦,直接跟AI说,“请给我设计一个类似 medium 的网站”就可以了,那需要截图,生成代码,改代码。
在 AI 的作用下,我想未来UI设计师的需求会减少,因为AI直接就能生成前端代码,而前端工程师的要求也会减少,因为AI一句话也能生成一个前端页面。后端影响会小点,
我如何使用AI来交流点子
以前我脑海中闪过什么点子我会赶紧记录到微信文件传输助手,或者 obsidian 里面,等有空的时候就去思考一下或者跟朋友交流一下,现在有了AI,我不再需要自己思考,然后跟朋友交流了,直接先跟AI讲,等聊得差不多,我已经很明确了之后再跟朋友分享。或者因为现在AI写代码太快了,我甚至能再花一两天时间把这个点子实现了再跟朋友分享。
以我去年11月份想到的那个做一个众筹VPS代理的点子为例,以下是我跟 AI 的交流过程:

我有一个创业的想法,目前很多中国人为了访问国外网站,需要购买机场翻墙服务,但是自己搭建机场成为机场主存在法律风险,因此我想到了一个基于众筹VPS,提供去中心化的代理服务器,然后使用区块链支付实现激励,具体步骤如下:
- 个人在自己的闲置VPS上搭建shadowsocks 程序
- 将 shadowsocks 的账号密码,以及服务器的ip 端口信息提交到一个中心化的服务器
- 用户在中心化服务器上使用区块链支付月费购买会员
- 中心化服务器给用户返回一个 clash 的订阅链接
- 用户拿到 clash 订阅链接就有权限访问其他人众筹的VPS节点
- 中心化服务器将用户充值的月费作为激励,奖励给VPS节点提供者
你觉得我这个点子如何?现在是否有类似的服务
你的创业想法结合了去中心化、区块链支付和众筹VPS的概念,具有一定的创新性,但也面临一些挑战和风险。以下是对你点子的分析:
优点:
- 去中心化:通过众筹VPS,避免了单一节点提供者的法律风险,分散了责任。
- 区块链支付:使用区块链支付可以提高支付的匿名性和安全性,适合这种敏感的服务。
- 激励机制:通过激励VPS提供者,可以吸引更多人参与,增加节点的多样性和稳定性。
- 市场需求:确实有很多人有访问国外网站的需求,市场潜力较大。
挑战和风险:
- 法律风险:虽然你试图通过去中心化降低风险,但在中国,提供翻墙服务本身是违法的,无论是否去中心化。即使使用区块链支付,政府仍可能通过技术手段追踪和打击。
- 技术复杂性:搭建和维护一个去中心化的代理网络需要较高的技术水平,尤其是确保节点的稳定性和安全性。
- 中心化服务器的风险:虽然节点是去中心化的,但中心化服务器仍然存在单点故障的风险,一旦被查封,整个系统可能瘫痪。
- 区块链支付的局限性:虽然区块链支付提供了匿名性,但其波动性和交易速度可能影响用户体验。此外,政府对加密货币的监管也可能带来不确定性。
- 竞争:市场上已经存在一些类似的去中心化VPN或代理服务,如Tor、Orchid等,它们已经有一定的用户基础和技术积累。
类似服务:
- Tor:一个去中心化的匿名网络,用户可以通过Tor访问被封锁的网站,但速度较慢。
- Orchid:一个基于区块链的去中心化VPN服务,用户可以使用加密货币支付,节点提供者通过代币激励。
- Psiphon:一个开源的代理工具,通过众筹节点提供访问被封锁内容的服务。
建议:
- 法律合规:在实施之前,务必咨询法律专家,确保你的业务模式在法律允许的范围内。
- 技术优化:考虑如何提高节点的稳定性和速度,确保用户体验。
- 隐私保护:加强用户隐私保护措施,避免用户数据泄露。
- 市场调研:深入了解现有竞争对手的优缺点,找到差异化竞争点。
总的来说,你的点子有创新性,但需要仔细评估法律风险和技术挑战。如果能够有效解决这些问题,可能会有一定的市场机会。

shadowsocks 服务端能动态配置用户访问权限吗?这样就可以多个授权的用户访问同一个 shadowsocks 服务器
是的,Shadowsocks 服务端可以通过一些配置和管理工具实现动态的用户访问权限管理,允许多个授权的用户访问同一个服务器。以下是几种常见的实现方式:
1. 使用 Shadowsocks 的多用户配置
Shadowsocks 本身支持多用户配置,可以在配置文件中为每个用户设置不同的端口和密码。虽然这不是完全动态的,但可以通过修改配置文件并重启服务来实现用户权限的更新。
示例配置文件(config.json
):
{ "server": "0.0.0.0", "port_password": { "8388": "password1", "8389": "password2", "8390": "password3" }, "method": "aes-256-gcm", "timeout": 300}
- 每个端口对应一个用户,用户通过不同的端口和密码连接。
- 如果需要动态添加或删除用户,可以修改配置文件并重启 Shadowsocks 服务。
2. 使用 Shadowsocks 的管理工具
有一些第三方工具可以帮助动态管理 Shadowsocks 用户权限,例如:
- Shadowsocks-manager:一个基于 Web 的管理面板,支持多用户管理和流量统计。
- ShadowsocksR:Shadowsocks 的一个分支,支持更复杂的用户管理和权限控制。
功能特点:
- 动态添加或删除用户。
- 设置用户的流量限制和过期时间。
- 实时监控用户连接状态。
3. 结合数据库实现动态权限管理
可以通过编写脚本或程序,将用户信息存储在数据库(如 MySQL、Redis)中,并动态生成 Shadowsocks 的配置文件。这种方式可以实现更灵活的权限管理。
实现步骤:
- 将用户信息(端口、密码、流量限制等)存储在数据库中。
- 编写脚本定期从数据库读取用户信息,生成 Shadowsocks 的配置文件。
- 使用
supervisor
或systemd
管理 Shadowsocks 服务,实现配置更新后自动重启。
4. 使用插件或 API 实现动态管理
一些 Shadowsocks 的实现(如 Shadowsocks-libev)支持插件系统,可以通过插件实现动态权限管理。例如:
- v2ray-plugin:可以为 Shadowsocks 提供更高级的功能,包括动态用户管理。
- API 接口:通过开发自定义 API,实现用户权限的动态添加、删除和修改。
5. 使用 Clash 或其他代理工具
如果你希望更灵活地管理用户权限,可以考虑使用 Clash 或其他代理工具。Clash 支持订阅链接和规则管理,可以通过订阅链接动态更新节点和用户权限。
实现方式:
- 将 Shadowsocks 节点信息存储在服务器上。
- 为用户生成不同的订阅链接,控制其访问权限。
- 用户通过 Clash 客户端加载订阅链接,获取节点信息。
6. 流量控制和用户隔离
为了确保多个用户共享同一个服务器时的公平性,可以使用以下工具进行流量控制和隔离:
- iptables:限制每个用户的带宽。
- tc (Traffic Control):实现更精细的流量控制。
- Docker 容器:将每个用户的 Shadowsocks 实例隔离在独立的容器中。
总结
Shadowsocks 服务端可以通过多用户配置、管理工具、数据库结合脚本、插件或 API 等方式实现动态的用户权限管理。如果你需要更灵活的控制,建议结合数据库和脚本实现动态配置,或者使用 Clash 等工具进行用户权限管理。同时,注意确保服务器的性能和稳定性,避免因多用户共享而导致的服务质量下降。

我如果想实现一个ethereum 上的智能合约,用来给当天在线时间 达标的VPS下发奖励,该如何设计。具体说就是加入今天中心化服务器愿意拿出 100USDT 来奖励 100台 VPS 节点。假设是均分,该如何设计合约
要实现一个基于 Ethereum 的智能合约,用于奖励当天在线时间达标的 VPS 节点,可以按照以下步骤设计合约。这个合约的核心逻辑是:
- 记录 VPS 节点的在线时间。
- 在每天结束时,检查哪些 VPS 节点的在线时间达标。
- 将奖励(100 USDT)均分给达标的 VPS 节点。
以下是具体的设计思路和代码示例:
1. 合约设计思路
- 数据结构:
- 使用一个映射(
mapping
)来记录每个 VPS 节点的在线时间。 - 使用一个数组或映射来存储当天达标的 VPS 节点地址。
- 功能:
- 上报在线时间:VPS 节点定期向合约上报自己的在线时间。
- 检查达标:在每天结束时,合约检查哪些 VPS 节点的在线时间达标。
- 分发奖励:将奖励均分给达标的 VPS 节点。
- 奖励分发:
- 使用 ERC-20 标准(如 USDT)进行奖励分发。
- 合约需要能够调用 USDT 合约的
transfer
方法。
2. 合约代码示例
以下是一个简单的 Solidity 智能合约示例:
// SPDX-License-Identifier: MITpragma solidity ^0.8.0;
// 导入 ERC-20 接口interface IERC20 { function transfer(address recipient, uint256 amount) external returns (bool); function balanceOf(address account) external view returns (uint256);}
contract VPSReward { // 管理员地址 address public admin;
// USDT 合约地址 IERC20 public usdtToken;
// 记录每个 VPS 地址的在线时间(单位:秒) mapping(address => uint256) public onlineTime;
// 记录当天达标的 VPS 地址 address[] public qualifiedVPS;
// 每天的奖励总额(100 USDT) uint256 public dailyReward = 100 * 10**6; // USDT 有 6 位小数
// 每天在线时间达标阈值(例如 86400 秒,即 24 小时) uint256 public threshold = 86400;
// 事件:记录奖励分发 event RewardDistributed(address indexed vps, uint256 amount);
// 构造函数,设置管理员和 USDT 合约地址 constructor(address _usdtToken) { admin = msg.sender; usdtToken = IERC20(_usdtToken); }
// 修饰器:仅管理员可调用 modifier onlyAdmin() { require(msg.sender == admin, "Only admin can call this function"); _; }
// VPS 节点上报在线时间 function reportOnlineTime(uint256 time) external { onlineTime[msg.sender] += time; }
// 检查并记录达标的 VPS 节点 function checkQualifiedVPS() external onlyAdmin { // 清空之前的记录 delete qualifiedVPS;
// 遍历所有 VPS 节点,检查是否达标 for (uint256 i = 0; i < qualifiedVPS.length; i++) { address vps = qualifiedVPS[i]; if (onlineTime[vps] >= threshold) { qualifiedVPS.push(vps); } } }
// 分发奖励 function distributeRewards() external onlyAdmin { // 确保合约中有足够的 USDT uint256 contractBalance = usdtToken.balanceOf(address(this)); require(contractBalance >= dailyReward, "Insufficient USDT balance");
// 计算每个 VPS 节点的奖励 uint256 rewardPerVPS = dailyReward / qualifiedVPS.length;
// 分发奖励 for (uint256 i = 0; i < qualifiedVPS.length; i++) { address vps = qualifiedVPS[i]; usdtToken.transfer(vps, rewardPerVPS); emit RewardDistributed(vps, rewardPerVPS); }
// 重置在线时间记录 for (uint256 i = 0; i < qualifiedVPS.length; i++) { address vps = qualifiedVPS[i]; onlineTime[vps] = 0; } }
// 管理员提取多余的 USDT function withdrawUSDT(uint256 amount) external onlyAdmin { usdtToken.transfer(admin, amount); }}
3. 合约功能说明
reportOnlineTime
:VPS 节点调用此函数上报自己的在线时间。checkQualifiedVPS
:管理员调用此函数,检查并记录当天在线时间达标的 VPS 节点。distributeRewards
:管理员调用此函数,将奖励均分给达标的 VPS 节点。withdrawUSDT
:管理员可以提取合约中多余的 USDT。
4. 注意事项
- Gas 费用:由于 Ethereum 上的交易需要支付 Gas 费用,频繁上报在线时间可能会导致较高的成本。可以考虑使用 Layer 2 解决方案(如 Polygon)来降低成本。
- 数据存储:Ethereum 上的存储成本较高,尽量减少不必要的数据存储。
- 安全性:确保只有管理员可以调用关键函数(如
distributeRewards
),并防止重入攻击等安全问题。 - USDT 合约:确保合约地址正确,并且合约中有足够的 USDT 余额。
5. 扩展功能
- 动态阈值:可以根据网络情况动态调整在线时间阈值。
- 非均分奖励:根据 VPS 节点的在线时间或贡献度分配不同的奖励。
- 链下计算:将在线时间的计算和达标检查放到链下,通过预言机(Oracle)将结果上传到链上。
通过以上设计,你可以实现一个基于 Ethereum 的智能合约,用于奖励在线时间达标的 VPS 节点。

管理员调用这个 distributeRewards 的方法给这些 VPS 节点发奖励,消耗的gas很多。能否设计为将每个节点应得的奖励金额保存在链下,VPS 拥有者可以不定期来链上领取他的收益
是的,将奖励金额的计算和存储放在链下,让 VPS 节点拥有者自行领取奖励,是一种更节省 Gas 的设计。这种方式可以显著降低管理员的 Gas 成本,同时也能提高系统的灵活性。以下是改进后的设计方案和智能合约实现:
1. 设计思路
- 链下计算:
- 管理员在链下计算每个 VPS 节点应得的奖励金额。
- 使用签名机制(如 EIP-712)为每个 VPS 节点生成一个领取奖励的凭证。
- 链上领取:
- VPS 节点拥有者通过调用智能合约的
claimReward
方法,提交凭证来领取奖励。 - 合约验证凭证的有效性,并发放奖励。
- 优点:
- 管理员只需在链下计算奖励,无需频繁调用合约,节省 Gas。
- VPS 节点拥有者可以随时领取奖励,灵活性更高。
2. 合约代码示例
以下是一个改进后的 Solidity 智能合约示例:
// SPDX-License-Identifier: MITpragma solidity ^0.8.0;
// 导入 ERC-20 接口interface IERC20 { function transfer(address recipient, uint256 amount) external returns (bool); function balanceOf(address account) external view returns (uint256);}
contract VPSReward { // 管理员地址 address public admin;
// USDT 合约地址 IERC20 public usdtToken;
// 记录每个 VPS 地址已领取的奖励 mapping(address => uint256) public claimedRewards;
// 事件:记录奖励领取 event RewardClaimed(address indexed vps, uint256 amount);
// 构造函数,设置管理员和 USDT 合约地址 constructor(address _usdtToken) { admin = msg.sender; usdtToken = IERC20(_usdtToken); }
// 修饰器:仅管理员可调用 modifier onlyAdmin() { require(msg.sender == admin, "Only admin can call this function"); _; }
// VPS 节点领取奖励 function claimReward(uint256 amount, bytes memory signature) external { // 验证签名 bytes32 messageHash = keccak256(abi.encodePacked(msg.sender, amount)); bytes32 ethSignedMessageHash = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", messageHash)); address signer = recoverSigner(ethSignedMessageHash, signature); require(signer == admin, "Invalid signature");
// 确保奖励未被领取 require(claimedRewards[msg.sender] < amount, "Reward already claimed");
// 更新已领取的奖励 claimedRewards[msg.sender] = amount;
// 发放奖励 require(usdtToken.transfer(msg.sender, amount), "Transfer failed"); emit RewardClaimed(msg.sender, amount); }
// 管理员提取多余的 USDT function withdrawUSDT(uint256 amount) external onlyAdmin { usdtToken.transfer(admin, amount); }
// 恢复签名地址 function recoverSigner(bytes32 ethSignedMessageHash, bytes memory signature) internal pure returns (address) { (bytes32 r, bytes32 s, uint8 v) = splitSignature(signature); return ecrecover(ethSignedMessageHash, v, r, s); }
// 拆分签名 function splitSignature(bytes memory sig) internal pure returns (bytes32 r, bytes32 s, uint8 v) { require(sig.length == 65, "Invalid signature length");
assembly { r := mload(add(sig, 32)) s := mload(add(sig, 64)) v := byte(0, mload(add(sig, 96))) } }}
3. 链下签名流程
管理员在链下为每个 VPS 节点生成一个签名凭证,步骤如下:
- 构造消息:
- 消息内容为
VPS 地址 + 奖励金额
。 - 例如:
0xVPSAddress + 1000000
(100 USDT,6 位小数)。
- 生成签名:
- 使用管理员的私钥对消息进行签名。
- 可以使用
ethers.js
或web3.js
生成签名。
- 将签名发送给 VPS 节点:
- VPS 节点拥有者使用签名调用
claimReward
方法领取奖励。
示例代码(使用 ethers.js):
const ethers = require('ethers');
// 管理员私钥const adminPrivateKey = '0x...';const wallet = new ethers.Wallet(adminPrivateKey);
// VPS 地址和奖励金额const vpsAddress = '0xVPSAddress';const amount = ethers.utils.parseUnits('100', 6); // 100 USDT
// 构造消息并签名const messageHash = ethers.utils.solidityKeccak256( ['address', 'uint256'], [vpsAddress, amount]);const signature = await wallet.signMessage(ethers.utils.arrayify(messageHash));
// 将签名发送给 VPS 节点console.log('Signature:', signature);
4. 合约功能说明
claimReward
:- VPS 节点拥有者调用此方法,提交奖励金额和管理员的签名。
- 合约验证签名有效性,并发放奖励。
withdrawUSDT
:- 管理员可以提取合约中多余的 USDT。
- 签名验证:
- 使用 EIP-712 标准的签名验证机制,确保只有管理员签名的奖励才能被领取。
5. 优点
- 节省 Gas:管理员无需频繁调用合约,只需在链下生成签名。
- 灵活性:VPS 节点拥有者可以随时领取奖励。
- 安全性:通过签名机制确保奖励发放的合法性。
6. 注意事项
- 签名安全性:确保管理员的私钥安全,避免泄露。
- 奖励金额精度:USDT 有 6 位小数,确保金额计算准确。
- 链下存储:管理员需要妥善保存每个 VPS 节点的奖励金额和签名记录。
通过这种方式,你可以显著降低 Gas 成本,同时保持系统的灵活性和安全性。
这个点子我去年11月想到后,就跟朋友交流了一下,但是后来没时间去做就搁置了,现在跟AI聊了一下后,发现知识又拓展了,而且可行性又更大了。 这就是AI的强大之处,它不仅能帮你写代码,还能帮你思考,帮你分析,帮你找到更好的解决方案。 所以我觉得未来的程序员,不再是一个写代码的人,而是一个指挥AI的人,AI会帮你完成更多的工作,而你只需要关注更高层次的事情,比如产品的方向、用户的需求、商业的模式等等。 这也是我为什么会一直关注AI的原因,因为我相信AI会改变整个世界,也会改变整个互联网行业。
总结
AI 对互联网产品开发流程的革新,不仅提高了效率,降低了成本,还拓展了创新的可能性。通过与 AI 的交流,我们可以更快地验证想法、优化方案,甚至发现更好的解决方案。 未来,AI 将成为我们的得力助手,帮助我们更好地创造和实现价值。