Bitfinex 借贷自动化这个方向最近有一个很务实的项目姿势整个脚本跑在你自己电脑上不依赖云服务器。它的核心价值不是模型多聪明、策略多复杂而是把“查余额—看利率—提交借出订单—记录结果”这套重复动作用本地脚本完整接住。如果你手里有数字资产平时又不想每天登录网页端手动点借贷那这种工具正好对上需求。适合阅读这篇文章的人主要是已经有过手动借贷经验、想尝试自动化但暂时不想买服务器的人。还有一点需要先说清楚自动化只是减少重复操作不构成收益保证也不能替你处理极端行情。策略本身的风险最终还是要自己判断。我前面花了一些时间把这类本地自动化运行模式的套路拆开来看发现真正值得关注的并不是“能不能跑起来”而是它为什么选择 PC 而不是 server以及从“跑一次”到“连续跑几个月”之间到底藏着多少坑。下面按实操顺序把项目价值、环境准备、最小流程、参数设置、稳定性、边界和排查链路完整过一遍。1. 为什么强调 “Run on Your PC, Not a Server”看到 “Show HN: Bitfinex lending automation that runs on your PC, not a server” 这个标题第一反应不是去看它有什么功能而是要先理解“PC not server”这个定位。很多类似工具更喜欢做成服务端部署甚至直接给你一个网页端后台。这个项目特意把运行环境放在 PC 上背后有一套很实际的设计取舍。1.1 服务器方案和 PC 方案的实际差异服务器方案的优势是 7x24 在线、网络固定、不依赖家里电费适合把任务当成一个长期服务来跑。但它也有问题需要选机器、配环境、开防火墙、管理密钥、承担被扫描和攻击的风险。对一个个人用户来说很多时候这些成本比脚本本身还高。PC 方案正好反过来。脚本跑在本地配置上更贴近日常开发环境密钥也留在自己机器里不用上传到任何云端。它更适合那种“每天跑几次、每次几分钟”的任务而不是高并发、多用户共用的大系统。用 PC 跑还有一个隐藏优势迭代调试非常快。你在本地改一下策略参数马上就能看日志、看账户返回结果不用经历“提交代码—重新部署—看远程日志”的漫长循环。1.2 什么样的用户更适合 PC 方案根据我自己接触这类工具的体会PC 方案适合这几类人个人用户资金量不大不想为一个小脚本额外承担服务器费用。本身就有开发环境习惯在本地跑数据分析或交易辅助脚本。对“把 API 密钥放到第三方服务器”这件事比较敏感希望密钥只留在自己电脑上。刚开始尝试自动化不打算一开始就做成高可用系统。不太适合的场景也很明显如果你希望连续几个月完全无人值守任何一次电脑重启、系统更新、网络波动都不能中断任务那 PC 方案会吃力。这种情况要么加一个进程守护和断电自启要么还是得考虑低功耗小主机或云服务器。项目强调 PC not server不代表 PC 是唯一正确答案而是它主动放弃了一部分可用性换取更低的进入门槛和更私密的密钥管理。理解这一点很重要不要一上来就骂它不够“企业级”。2. 本地跑之前先把环境、API 权限和时间同步搞定很多人在跑这种自动化脚本时第一步不是死在策略逻辑上而是死在环境准备不完整。环境问题看起来小而碎一旦发生报错信息又特别容易误导人。所以我会建议正式跑脚本前先花十几分钟把环境、密钥权限和系统时间这三件事确认清楚。2.1 基础环境系统、运行时和依赖这个项目具体用什么语言实现源码仓库里会有明确说明。按常见情况推测大概率是 Python 或 Node.js 脚本。如果是 Python 项目我一般会先准备一个干净的虚拟环境避免把依赖装到系统全局环境里。常见依赖无非是网络请求库、配置读取库、日志库这一类具体清单看项目的 requirements 文件。如果你用的是 Windows还需要额外注意控制台编码问题。很多脚本默认输出 UTF-8Windows 的 PowerShell 或 CMD 如果代码页不匹配日志可能显示乱码这会让后续排查非常痛苦。建议提前把终端代码页切到 UTF-8或者直接使用 Windows Terminal。macOS 和 Linux 在这块问题少一些但也要确认 Python 或 Node 版本符合项目要求。不要想当然用系统自带版本先跑一条--version确认。注意如果脚本是从网上直接拿下来的运行前一定要先读一遍源码看清楚它是否会访问额外域名、是否会上传本地文件。任何涉及 API 密钥的脚本来源审计都是第一步。2.2 API 密钥权限与安全边界跑借贷自动化绕不开交易所 API 密钥。这里的安全建议比脚本本身更重要。很多自动化工具只需要读取余额、查询市场、提交借贷订单这几项权限不需要资产的提现权限。创建 API 密钥时按最小权限原则来能不勾选的权限一律不勾选。这样即使脚本本身存在缺陷或者电脑被入侵损失范围也能被限制住。密钥写入脚本的方式也值得注意。最忌讳的做法是把 API Key 和 Secret 硬编码在源码里然后随手提交到 Git。正确做法是放到环境变量或者本地.env文件里并确保.env被.gitignore忽略。你可能觉得一个个人项目没必要这么讲究但一旦你后面想把这个脚本公开、分享、或者放到新电脑上运行时密钥泄露问题就会瞬间爆发。另外有些交易所允许给 API 密钥绑定 IP 白名单。如果脚本固定在家里跑可以把这个功能打开但要注意家里宽带如果经常变换出口 IP白名单可能导致认证失败这时需要权衡安全性还是便利性。2.3 容易被忽略的时间同步和网络问题API 签名认证通常依赖时间戳机制。你的电脑如果长时间不校准时间系统时钟和实际时间产生偏差认证请求就可能被拒绝。这个问题在 Windows 上尤其常见主板电池老化、长期休眠、双系统切换都可能导致时间不准。运行脚本前先手动同步一次系统时间观察后续几天时间偏移是否明显。网络方面本地脚本需要能稳定访问交易所 API。如果你所在网络环境访问不通第一步不要怀疑脚本先用ping、curl或者浏览器直接确认 API 地址是否可达。这里不涉及任何特殊网络工具纯粹是验证连通性。还要注意某些安全软件或防火墙可能拦截脚本发起的网络请求遇到奇怪的连接异常可以先临时关闭相关拦截规则测试一次。3. 最小流程怎么走查余额、看利率、提交借出订单不管这个脚本最终写得多么复杂底层核心动作其实只有三个查余额、看当前借贷市场利率、提交一笔借出订单。先理解这三个动作再去看脚本里的循环和参数就清晰多了。3.1 先跑通一次手工调用不急着写循环我第一次跑这类脚本时习惯先做一次单发验证而不是立刻启动循环。单发验证的目标只有一个确认 API 权限、账户余额读取、订单提交链路都通。具体流程可以拆成四步读取当前账户可用余额确认脚本拿到的数字和网页端一致。查询借贷市场当前的利率情况确认返回结果包含期限、利率、可借数量等字段。提交一笔最小金额的借出订单观察是否返回订单编号。到网页端确认这笔挂单是否真实存在然后手动撤销完成一次闭环验证。这个过程不需要写死长期策略但能把 90% 的环境和权限问题暴露出来。如果连最小金额的订单都提交不成功那后面写再多循环逻辑也没有意义。先跑通单次调用能帮你把“脚本问题”和“策略问题”分开排查这是效率最高的路线。3.2 提交借贷订单的通用判断标准不同交易所、不同 API 版本借出订单的字段名可能不一样但一般会包含期限、利率、数量这几项。脚本提交成功后服务端会返回一笔订单标识如果返回错误则需要重点看错误码和错误消息而不是只看出不出异常。我建议你在提交订单前脚本里先做一次前置检查可用余额是否大于本次借出数量。当前市场是否接受该期限的借出。设置的利率是否在合理范围避免因为手误填了一个极低利率导致订单被瞬间成交或者填了一个极高利率导致永远挂不出去。这些检查逻辑虽然简单但能有效避免程序在异常状态下继续跑下去。很多“看起来像是策略问题”的情况其实只是参数校验没做好。3.3 首次测试建议用最小金额第一次完整跑通时不要用自己的全部可用资金。先取一个不影响正常交易的小金额做测试确认整个链路安全可靠后再逐步放大金额。这样做的好处是即使脚本存在隐藏 bug比如重复提交、金额计算错误、撤销逻辑失效你实际损失也有限。测试期间还要重点观察一件事脚本提交的订单在网页端是否立即出现。如果出现后又被脚本撤销日志里应该有明确记录。如果网页端根本没有这笔订单但脚本显示成功说明可能读取的账户不对、请求环境不对或者是测试网和生产网混了。这类问题出现频率不低务必优先确认绝对路径和网络环境。注意任何借贷自动化工具都要先假设程序会出错。第一次试跑、第一次上真实资金、第一次开启自动循环每一步之间都要观察足够久。不要在同一天把三个“第一次”全做完。4. 从单次执行到循环策略参数怎么设置才不容易乱单次调用跑通之后多数人会立刻想到加一个循环让脚本每隔一段时间自动检查市场情况并提交订单。这一步本身不复杂复杂度在于参数怎么设以及循环过程中如何避免重复、冲突和资源浪费。4.1 循环频率和利率参数怎么取舍循环频率取决于你目标利率的变化速度。如果借贷市场利率波动很慢几分钟检查一次完全够用如果利率变化很快你可以缩短轮询间隔但要意识到这只是满足策略时效不是在追求服务器级实时性。这里最容易翻车的是循环间隔设置太短。太短的间隔会带来三个问题账户请求频次过高可能触发 API 限流日志文件增长速度变快电脑风扇不断加速影响静谧性和功耗。我更建议先从一个相对保守的间隔开始比如 10 到 15 分钟一次观察一段时间之后再逐步缩短。利率参数建议采用“市场利率 固定偏移”的方式而不是写死一个绝对值。借贷市场的利率会随供需变化写死利率很可能出现两种情况市场利率远低于设定利率订单一直挂不出去市场利率突然飙升设定利率又显得太低。使用偏移量可以让策略跟随市场整体水平同时保留人工设置的调整空间。4.2 资金分配和仓位上限自动化脚本跑久了最怕的不是单次失败而是资金被重复占用。比如一笔资金借出后尚未到期脚本又试图把它再次借出就会因为可用余额不足而报错。为了避免这种情况脚本需要维护一个资金状态表记录哪些资金还在借贷中、预计什么时候回款。更稳妥的做法是设置总资金使用上限。例如只允许把账户资金的 70% 用于借贷剩下 30% 作为应对异常情况的缓冲。这样即使某笔订单提前还回、利率剧烈变化或者需要手动操作都有可用的余额空间。4.3 手动操作与脚本并存的冲突这是最容易忽略的问题。脚本在运行时如果你又登录网页端手动提交了一笔借出两边的资金记录就可能对不上。脚本按自己的状态表判断“还有多少钱可借”而实际情况已经被手动操作改变最终结果要么重复提交要么显示余额不足。我的建议是脚本运行时尽量别手动操作同一批资产。如果必须手动介入比如因为临时原因要撤销某笔挂单或调整利率先暂停脚本等手动操作完成并确认状态后再重新启动。不要图省事让脚本一边跑、手动一边改这种并发冲突排查起来非常费时间。5. 稳定运行的关键日志、状态记录、失败重试和通知一个脚本能跑通一次和能连续跑一个月完全不是一回事。后者依赖的不只是核心借贷逻辑还有周边设施日志、状态、重试和通知。很多人的脚本刚开始很顺利跑了两三天就出现奇怪问题原因往往是周边设施没搭好。5.1 日志记录什么订单、余额、异常日志是事后排查的第一手资料所以不要只记“成功”“失败”两个词要记足够多的上下文。我建议每条关键日志至少包含时间点精确到秒。动作类型查询余额、查询利率、提交订单、撤销订单、捕获异常。关键数据可用余额、借贷数量、利率、期限、订单编号、错误码。如果请求失败还要记录失败时的请求参数和响应内容。日志文件最好按天拆分例如lending-2025-06-01.log。否则运行几个月后单个日志文件会非常大打开、搜索、定位都变慢。另外日志里不要记录完整的 API Secret这是安全底线。5.2 状态保存避免重复提交和重复判断脚本重启后最怕的是忘记之前已经提交过哪些订单。如果状态只保存在内存里重启后状态丢失脚本就可能把上一轮已提交的订单再次提交一遍。为了避免这个问题建议把状态持久化到本地文件或轻量数据库比如 JSON 文件、SQLite。状态记录建议包含三项当前挂单信息、在贷中的订单列表、历史已完成订单。每次脚本启动时先读取状态文件再和交易所账户实际状态做一次同步以服务端数据为准修正本地状态。这里要特别注意不要只相信本地状态因为可能有手动操作、部分成交、提前还款等意外情况最终判断标准应该是交易所返回的账户数据。5.3 失败重试和通知机制网络请求失败在长时间运行中几乎是必然的所以脚本必须设计重试机制。重试要注意几点设置最大重试次数避免无限重试造成资源浪费。每次重试之间加退避时间比如 5 秒、30 秒、2 分钟递增。对不同类型的失败区别对待网络超时可以重试权限错误、参数错误通常重试也没用需要直接报警。通知方式建议选简单可靠的比如邮件通知、Webhook 到自己可控的服务或者本地弹窗。通知不是越多越好否则很快会疲劳。我一般只在两类情况下通知策略持续多次失败时账户状态出现异常比如可用余额低于预期时。正常执行成功不需要每次都通知看日志就够了。6. PC 方案的真实边界哪些场景能扛住哪些不能项目强调 PC not server这本身就说明它接受了 PC 的边界。一个长期运行的本地自动化任务最怕的不是代码 bug而是运行环境的不可控。这里把 PC 方案最容易踩的边界问题列一遍。6.1 电脑休眠、断网、重启的影响笔记本如果合盖就休眠那任务自然停止。台式机如果设置了系统自动更新也可能在凌晨重启任务同样中断。这是 PC 方案最真实的弱点。想缓解这个问题可以做几件事把电源计划设置为“从不睡眠”“从不休眠”。关闭系统的自动更新重启至少错开交易时段。给脚本设置开机自启并配合进程守护工具一旦脚本进程退出就自动拉起。如果条件允许给电脑配一个 UPS 防止断电。即使做了这些PC 方案也不可能达到服务器级别的可用性。你要先想清楚如果某天脚本中断了几个小时带来的损失是否可接受。如果答案是“完全不能接受”那 PC 方案就不适合直接考虑低功耗小主机或云服务器更稳妥。6.2 脚本来源和密钥安全本地跑脚本不意味着绝对安全它只是把风险从云端搬到了本地。如果脚本来自不可信来源却拥有读取余额和提交订单的权限那它完全可以利用这些权限做一些不安全的操作。所以运行任何来源不明的自动化脚本前一定要做两件事通读源码特别是涉及网络请求和密钥读取的部分。确认脚本没有把密钥、账号信息上传到未知域名。更保险的方案是在正式使用前用试运行的方式观察脚本所有网络请求的目标地址。如果你看到脚本向未知地址发送请求立即停用。密钥本身也建议定期轮换不要一个密钥用一年。6.3 什么时候应该换到低功耗设备或服务器如果你已经用 PC 跑了几个月发现任务稳定、值得长期维护下一步可以考虑迁移到更合适的设备。迁移时机主要看几点你开始同时跑多个策略PC 经常处于高负载状态。你希望即使家里停电、断网任务也能由其他环境接管。你想把策略分享给多人使用而不是只给自己跑。你对延迟有更高要求希望每次轮询间隔更短。选择迁移目标时不要一上来就选大规格云服务器。借贷自动化本身只是低频 API 调用资源占用很低一台低功耗小主机或者最低配云服务器往往就够用。迁移时要注意先停掉 PC 脚本再部署到新环境避免两边同时跑实际可出借资金被双重计算。7. 常见报错和排查顺序长时间运行后各类报错会陆续出现。这里给出一个实用的排查顺序以及几张我常用的排查表。记住一个原则先看现象再看输入接着看环境和参数最后才怀疑脚本逻辑本身。7.1 现象到根因的排查表现象可能原因优先排查顺序脚本启动后立即退出依赖未安装、运行时版本不对、配置文件缺失看控制台错误信息检查依赖安装检查配置文件路径提交订单一直失败余额不足、额度占用、API 权限不够、参数不合法先查账户可用余额再查本地状态记录最后看 API 错误码认证或登录相关错误时间戳偏差、密钥过期、密钥权限不足、请求签名错误同步系统时间检查密钥有效性和权限确认请求签名逻辑网络请求超时或中断本地网络波动、API 服务不可用、防火墙拦截先手动请求 API 地址确认网络可达再查脚本是否被拦截脚本卡住不往下走等待返回结果没有超时、网络请求阻塞、死循环查看进程状态检查最近日志看是否有请求长时间未返回日志乱码终端代码页不匹配、编码格式不对调整终端编码确认脚本输出使用 UTF-8重复提交相同订单状态文件未及时更新、重启后状态丢失检查状态文件的读写时机确认每次提交后立即记录余额显示和网页端不一致读取钱包类型不对、测试网和生产网混用确认查询的钱包类型确认环境地址正确这张表并不针对某个具体错误码而是覆盖了我在实际运行中遇到最多的高频问题。如果你的报错正好在表里优先按“优先排查顺序”逐层处理不要跳步。7.2 我建议的排查顺序很多人遇到报错后第一反应是去翻脚本逻辑把代码逐行读一遍。我的建议刚好相反先别急着读代码先按下面这个顺序走。第一看现象描述。报错信息如果直接给出了错误码先把错误码记下来去查对应含义。一个简单的“余额不足”可能并不是真的余额不足而是你查错了钱包类型。第二看输入数据。脚本收到的账户余额、市场利率、订单数量是否符合预期。很多“提交失败”实际上是在用错误的数据提交。第三看环境状态。系统时间是否准确网络是否可达依赖是否完整密钥是否有效配置文件的路径和权限是否正确。这些环境因素能解释大量看似是脚本 bug 的问题。第四看运行参数。轮询间隔、利率偏移、最大借出比例这些参数是否合理。参数过大会导致订单挂不出去或余额不足参数过小可能导致频繁成交或收益极低。第五最后才看脚本逻辑。从头看一遍关键流程确认有没有状态更新遗漏、异常处理缺失、边界条件判断错误。如果这时还找不到问题再考虑是不是需要添加更详细的日志把中间变量打出来。这个顺序看起来慢实际上是最快的。因为它能避免你在环境问题还没搞清的情况下反复修改正确代码。我几乎每次按这个顺序排查都能在第三、第四步解决问题。如果把“Bitfinex 借贷自动化要跑在 PC 上”当成一个普通的小项目那它确实只是把重复动作自动化了。但如果你愿意多花一点时间把环境、参数、状态、日志、重试、边界这些细节补齐它至少可以成为一个长期稳定运转的个人工具。我个人的建议比较直接先用手动方式把流程完整走一遍再让脚本接管先用小金额验证再放量先跑单次再开循环。自动化不是让风险消失而是把人工重复交给程序让风险控制这件事本身变得可观察、可回滚、可复盘。