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-8，Windows 的 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 上”当成一个普通的小项目，那它确实只是把重复动作自动化了。但如果你愿意多花一点时间，把环境、参数、状态、日志、重试、边界这些细节补齐，它至少可以成为一个长期稳定运转的个人工具。我个人的建议比较直接：先用手动方式把流程完整走一遍，再让脚本接管；先用小金额验证，再放量；先跑单次，再开循环。自动化不是让风险消失，而是把人工重复交给程序，让风险控制这件事本身变得可观察、可回滚、可复盘。
