交易策略出错和交易系统出错是两类问题。前者意味着信号没有优势，后者意味着系统甚至没有按策略行动。只要仓位状态、成交确认或异常恢复不可信，任何收益曲线都无法说明 Alpha。
我在 2026-04-06 复盘一套 Meme Bot 源码时，最先暴露问题的是状态机，选币规则反而排在后面。
买卖条件不对称会不断堆积风险
旧逻辑依赖第三方热门榜：榜一变化触发买入，旧标的只有跌出榜单后才考虑卖出。结果是新候选不断进入，而旧仓位可能因为榜单状态、接口异常或重启被遗留。
产品规则应先回答：同一条链允许多少并发仓位，候选切换时旧仓位进入什么状态，卖出失败后是否冻结新买入。买卖必须处在同一状态机，而不是两个互不理解的定时任务。
HTTP 成功距离成交还差三步
从提交交易到真实持仓，至少有四个状态：
- 请求被本地服务接受；
- 交易被发送到网络；
- 交易在链上确认；
- 余额与内部账本完成对账。
如果系统在第一步就写入“已买入”，后续超时或交易失败会制造幽灵仓位。反过来，链上已成交但回执丢失时自动重试，可能形成重复买入。
因此每次动作需要唯一幂等键、签名或交易标识、确认超时和只读对账流程。结果未知时先冻结，不应盲目重试。
数据库持仓与钱包余额要定期对账
内部数据库是系统认知，不是真相本身。重启、人工操作、链上失败和程序 Bug 都可能让两者分叉。启动时应先读取钱包余额、未完成交易与账本动作，生成差异清单，再决定恢复策略。
卖出同样要验证实际收到的资产，而不是只看接口返回。手续费、滑点和部分成交也必须进入账本。
先用 Shadow 模式验证新状态机
重构后可以让旧逻辑继续产生信号，新状态机只记录“如果执行会怎样”。对比指标包括信号数量、重复动作、状态冲突、成交失败、持仓时间和模拟回撤。
Shadow 通过后再进入 Paper Trading，验证重启恢复、异常注入和对账。信号质量优化应排在系统正确性之后，因为只有正确执行的样本才有分析价值。
交易 Bot 的产品优先级应该是：系统正确性、风险可控性、信号质量，最后才是收益实验。先把状态机修稳，后续的信号评估才有可信样本。
来源说明：本文由个人 Obsidian 中 2026-04-06 的第三方交易 Bot 源码审计摘要公开化改写。内部接口、认证信息、真实钱包与源码路径均已删除。
研究边界：本文用于产品与机制研究，不构成投资建议；涉及的策略表现仅代表历史回放、Shadow 或 Paper Trading 结果。
