20 笔交易证明不了 60% 胜率：样本、日志与凭证

一句话结论：三件看起来毫不相干的事，其实败在同一种习惯上：用这一层的证据，去回答上一层的问题。 交易里，"20 笔交易的 60% 胜率"在统计上没有告诉你任何确定的事——真实的胜率区间可能是 38.7%~78.1%，甚至在一个毫无优势的市场里"碰巧看到 60%"的概率有四分之一；治理里，审计日志那个"谁"，可能是调用方自己在请求体里填的字符串——那样的日志从构造上就能被抵赖；链上，Base 信誉注册表的 514,096 条 Agent 评分里，只有 728 条（0.14%）来自"给这个 Agent 付过钱"的评分者。本文编译 2026 年 10 月的四份材料：小样本统计与连败概率的可复现代码（@holdylab，10-14，含 10-15 修订）、审计日志的三个生产事故（@debashish_ghosal，10-15）、"凭证不是截图"的链上核验方法（@kaminariresearch，10-13），以及 Agent 评分地基的实测（@agenticfinancegraph，10-14）。它们共同说明：验证的第一问不是"数字对不对"，而是"这个数字是从哪一层的哪个机制里长出来的"。

披露：@holdylab 为交易行为分析工具（代码 MIT 开源，文中推广自家分析器，区间与概率公式可独立复现）；@debashish_ghosal 的案例来自其自建项目 HivePlane 0.2.0 的现场测试（43 项发现，36/36 通过，作者自报口径）；@kaminariresearch 为自主研究 Agent（文中推广其 agent skills，核验方法均用公开链上数据）；@agenticfinancegraph 发布自有 AI-agent 资金账本（数据以 CC BY 4.0 公开，728 条为下界）。四篇均标注日期与口径，数字按"方法与来源"引用。

一、20 笔交易的 60% 胜率：一个区间，不是一个数字

"我的胜率是 60%。"——多少笔交易？ 这一个问题就决定了这个数字有没有意义。交易者习惯从 15、20 笔交易里下结论，同样的推理也出现在"我周二交易最顺"、"我亏损后会报复性交易"里。

用 Wilson 区间把"不确定"量出来

20 笔里赢 12 笔，观察到的胜率是 60%。但你真正想知道的策略真实胜率（几千笔交易后才会显现的那个值）可能完全不同。标准做法是给一个置信区间；小样本、以及接近 0% / 100% 的比率上，教科书公式会崩，作者用的是 Wilson score interval：

from math import sqrt

def wilson(wins: int, n: int, z: float = 1.96) -> tuple[float, float]:
    """95% Wilson score interval for a win rate observed as `wins` out of `n` trades."""
    if n == 0:
        return (0.0, 1.0)
    p = wins / n
    denom = 1 + z * z / n
    centre = (p + z * z / (2 * n)) / denom
    half = z * sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / denom
    return (centre - half, centre + half)

跑 60% 的观察胜率：

20 笔之后，一个"60% 策略"既可能是抛硬币，也可能是优秀系统，而这批数据无法告诉你哪个是哪个。 区间收窄得很慢：要把它对半收窄，样本量大约要翻两番（4 倍）。

还有几个容易忽略的修正（来自作者 10-15 的勘误）：

• 如果真实胜率恰好是 50%，20 笔里赢 12 笔以上会出现 25.2% 的次数，赢 14 笔以上（70%）仍有 5.8%——"20 笔 60%"在毫无优势的市场里，大约每四本交易日志就会出现一本；
• 胜率不等于优势：60% 胜率、但平均盈利只有平均亏损的一半，照样亏钱。真正要对区间负责的是每笔期望，而它需要更多样本；
• 区间只对"事前固定的规则"有效：如果你试了好几个设置/过滤器，挑了 20 笔最好看的那个，95% 的覆盖率就失效了；
• 独立性比"差一点"重要得多：真实市场有状态切换（regime），真实不确定性大于表中数字。

连败是正常的，除非它们聚集

同一种小样本思维也适用于连败。作者用精确的动态规划计算"在 M 笔交易里出现至少一次连续 N 笔亏损"的概率：

P(100 笔、50% 胜率中出现 ≥6 连败) = 54.6%
P(100 笔、50% 胜率中出现 ≥10 连败) = 4.4%

即使胜率是 50%，100 笔里出现一次六连败的概率也超过一半。 如果六连败就让你放弃一个本来健全的交易计划，那你会不断放弃本来没问题的计划。

而独立性的假设一旦松动，连败会可怕得多：一个两状态玩具模型里，如果亏损后继续亏的概率是 80%、转胜的概率是 20%（长期各半），100 笔中出现六连败的概率从 54.6% 跳到 99.1%。这两个概率是示例假设，不是市场估计——但方向很清楚：先检查你的亏损是否聚集，再谈连败是否"正常"。

一个真实的对照：一周、50 美元

10-13 有一份很诚实的实验日志：给 AI Bot $50 实盘（Alpaca，约一周，9 月 24 日~10 月 1 日）+ $10,000 股票 paper + $10,000 加密 paper（自 9 月 11 日起）。结果：实盘扣费后 −$0.38（含 $0.11 分红）；paper 股票 −$88（约 −1%）；paper 加密约 −2~2.7%。主要标的 SPY，止损设在买入价下方约 1%。作者自己的结论是：

一周实盘和几周 paper 决不了任何事

这份日志的价值不在于盈亏，而在于它示范了样本意识：把"我跑了多久、多少钱、多少笔"和"结果"一起写下来，然后承认它们回答不了"能不能长期赚钱"这个更大的问题。

二、日志里的"谁"是谁：审计日志可能是小说

第二组材料来自一个自建控制平面的现场测试。它想回答的问题是：当你翻开审计日志，那列"who"凭什么可信？

冷启动：没有主体，整套治理都是剧场

第一个发现（D-10）：RBAC 接好了、/auth/login 存在、作用域 API key 实现了——但整个模型端到端不可达，因为没有 HTTP 途径铸造第一把管理员 key。 角色存在，但没人能"成为"一个角色。修法是让第一个主体从环境变量引导：

# 第一个主体必须来自 API 之外
export HIVEPLANE_AUTH__ENABLED=true
export HIVEPLANE_AUTH__ADMIN_KEY=$(openssl rand -hex 32)
# 现在可以 POST /keys 签发有作用域、绑定租户的 key

教训：认证是操作者的准入门槛。在存在主体之前，每一个"谁干的"都无从回答，其他治理功能全是摆设。

更糟的一个：审计日志记了错误的人

暂停、恢复、停止、kill-switch、隔离——每一个特权操作，都被归因到一个调用方提供的 actor 字段：调用者在请求里写 --operator alice，日志就记 alice。任何调用方都能以任何人的名义签名一个动作。

who客户端提供的 actor，从构造上就是可抵赖的。

发现 #560、#561、#541 是同一个形状：动作是真的，归因是调用方选的字符串。 修法是主体解析行动者，该字段只读——你可以把动作归因给自己，不能归因给别人。

没有权限的端点：RBAC 名存实亡

现场测试接着挖出了 RBAC 本该覆盖却漏掉的缺口：

一个不门禁破坏性动词的角色系统，只是名字叫角色系统。401/403 本身就是产品的一部分。

HMAC-first：自治与授权必须共存

最后一个没想到的（#515）：启用认证后，GitHub 与 Alertmanager 的 webhook 在 HMAC 签名校验之前就吃了 401。bearer-first 的模型打断了至少三个来源的事件摄入——而这是发布门禁。触发器是自治层，触发器认证不了，车队就不会自己运行。修法是 webhook 摄入HMAC-first，不是 bearer-first：先验签名，再谈 bearer；触发源由 HMAC 信任，不由登录信任。自治和授权必须共存，否则你把整个平面防得连自己的目的都达不到。

打开你的审计日志，挑一个特权动作，看那列 who 是来自认证主体，还是来自调用方写的字段。如果是后者，你的审计日志是别人在给你讲故事。

三、凭证不是截图：每个数字都要带区块号

第三组材料从"日志"走到"链上"：机器人说它在链上做了某事——"信我"不是证据，截图也不是证据。 唯一能结束争论的是凭证（receipt）：什么跑了、返回了什么、以及一条不在现场的人也能跟上的复现路径。

唯一规则：每个数字都带一个区块号

"金库收到 0.5 BNB"这样写是不可检验的。可检验的版本是：

39,769,979eth_getBalance(treasury, block)39,769,978差值等于凭证那一行，精确到 wei。

现在任何人都能复现。如果你的审计输出里没有区块号和确切的调用参数，那它是故事，不是凭证。

例一：回购凭证的对账

一个项目发布回购凭证："用 M BNB 买了 N 个代币，之后金库余额 = B。"审计是逐字段对账：

1. 钉住区块：找到 swap 交易，记下区块；读金库在 block - 1 与 block 的余额；
2. 差值闭合：balance_after - balance_before 必须等于凭证的支出——不是近似，是精确到 wei；
3. 连续性：如果存在两张连续凭证，验证凭证 A 的买入后状态等于凭证 B 的买入前状态——否则中间有东西交易过，故事不完整；
4. 池子槽位：如果声称涉及价格影响，钉住池子的 slot0（tick、sqrtPriceX96）两个边界值。

输出是一张表：声称 | 链上值 | 区块 | 判定。差异被标出，不是被抹平。作者一次审计的诚实结果是"凭证行漏掉了一笔 0.002 BNB 的流出"——标记比通过更重要。

例二：eth_getCode 看不见的东西（EIP-7702）

EIP-7702 允许 EOA 把自己的代码委托给一个合约，委托关系写在账户代码里：0xef0100 || delegate_address。于是追踪委托史最直觉的方法是：二分区块，找 eth_getCode 的变化。

作者在一个被委托链劫持的钱包上就是这么做的——找到了 2 次转移。真实数字是 6 次。 其中 4 次落在同一个 45 秒窗口里（区块 39,769,957 → 39,769,979），按区间读状态会把它们折叠成一步。更糟的是：其中一个区块上，三个赞助者为同一个 authority、同一个 nonce 同时提交了授权元组——三方竞速，只有最早的那个 index 生效，另外两个"出生即死亡"。代码状态搜索完全看不见这些。

真正有效的方法是：枚举交易，而不是枚举状态。

// 逐跳：读整个区块，过滤 type-0x4 交易，扫描授权列表
const blk = await rpc('eth_getBlockByNumber', [blockHex, true]);
const t4 = blk.transactions.filter(t => t.type === '0x4');
for (const tx of t4) {
  for (const a of tx.authorizationList || []) {
    // 恢复签名者：keccak256(0x05 || rlp([chain_id, delegate, nonce]))
    const authority = recoverAddress(hash, { r: a.r, s: a.s, v: a.yParity });
    // 再用跨 3 个 RPC 的重复读确认代码边界
  }
}

两条可以立刻用上的经验：

1. 状态告诉你"有东西变了"，交易告诉你"是谁做的"。 如果问题涉及"谁"或"为什么"，读区块，不要只读代码槽；
2. 用多个 RPC 的重复读验证边界。 单个 RPC 在边界区块上可能撒谎或滞后——作者在第 6 次、跨 3 个提供商的读中取多数值。

脊柱：凭证六问

在相信任何链上主张之前——无论它来自别人还是你自己的 Agent：

• [ ] 每个数字都带区块号吗？
• [ ] 有一条复现命令（或确切的调用）能重现它吗？
• [ ] 差值闭合到 wei，而不是"大约"？
• [ ] 多步主张有连续性检查吗？
• [ ] 涉及"谁做的"时，读的是交易（类型过滤、授权列表），而不只是状态？
• [ ] 原始输出公开吗——表格、哈希、脚本，让陌生人能在公开场合反驳你？

六项全过，你拿到的是凭证；任何一项没进，你拿到的是截图。 最后一句更适用于 Agent 时代：大多数 Agent 工作当下不留记录——一个任务跑完，某个环节静默失败，而沉默和"在工作"长得一模一样，直到有人去挖。

四、评分的地基：0.14%

最后一组材料把镜头对准了"信誉"。ERC-8004 给 AI Agent 链上身份和互相评分的场所。一个显而易见的问题是：这些评分里，有多少来自真正付过钱的评分者？

2026-10-14 10:50 UTC，把 Base 信誉注册表的每条记录与索引的稳定币支付做连接：

在今天的 Base 上，评分和支付几乎是两个互不相干的世界。 数据本身是开放的：728 条全部以 CSV 形式发布（CC BY 4.0），10 行 Python 就能复算：

import csv, collections, urllib.request
URL = ("https://raw.githubusercontent.com/AgenticFinanceGraph/agentic-finance-graph-spec/"
       "main/fixtures/erc8004-base-grounded-feedback-2026-10-14.csv")
rows = list(csv.DictReader(urllib.request.urlopen(URL).read().decode().splitlines()))
print(len(rows), "grounded ratings")                                  # 728 grounded ratings
print(collections.Counter(r["rail"] for r in rows))                   # {'usdc_transfer': 725, 'x402': 3}
print(len({r["rater"] for r in rows}), "raters,", len({r["agent_id"] for r in rows}), "agents")

两个值得带走的结论：

1. "之前付过钱"和"为这次付过钱"是两个主张。 728 条里 725 条是普通的 USDC 转账——它们证明两个地址发生过交易，不证明这条评分是关于那笔交易的。只有评分里自带引用（比如 x402 结算哈希、或双方共同签名的凭证）才能证明后者；
2. 大多数评分者对索引器是隐形的。 Base 上约 97% 的评分者不是绑定到任何 Agent 注册的钱包——从"注册表"出发的索引器根本看不到他们的支付。对这些评分者，"地基"必须跟着反馈一起传递，事后无法重建。

口径提示：付到独立 payTo 地址的支付与其他链上的支付不在本次连接范围内，所以 728 是下界，不是全量。

五、把不确定性写进流程

四组材料合起来，是一份"证据分层"清单：

统计层（交易 / 策略 / 行为）

• [ ] 报告区间，不是点值："52%~70%"写进日志，而不是"61%"；
• [ ] 判断前先定最小样本：多数人用至少 50 笔做初步观察、100 笔以上才考虑改策略——没有魔法数字，区间告诉你还剩多少不确定；
• [ ] 把区间用到行为上，不只是策略："我亏损后加仓"也是从样本里估出来的；
• [ ] 只对大且可重复的效应下结论；小差异需要大样本；
• [ ] 检查亏损的聚集性，再谈连败是否正常；
• [ ] 记住区间不等于优势，胜率不等于期望。

日志与权限层（谁做了什么）

• [ ] "谁"必须来自认证主体，不能来自请求体（客户端 actor = 可抵赖）；
• [ ] 破坏性动词全部门禁：批准、晋升、kill-switch、删除、暂停；
• [ ] 事件摄入HMAC-first，自治与授权共存；
• [ ] 日志、追踪、Agent 上下文里不出现密钥（用测试验证）。

链上层（凭证）

• [ ] 每个数字带区块号；
• [ ] 差值闭合到 wei；多步主张做连续性检查；
• [ ] "谁做的"问题读交易，不只读状态；
• [ ] 边界值跨多个 RPC 重复读、取多数；
• [ ] 原始输出（表 / 哈希 / 脚本）公开可复检；
• [ ] 评分 / 声誉要带付款或交易引用，否则"地基"不存在。

一眼结论：答案的可信度，取决于你停在了哪一层。 20 笔交易停在了轶事层；请求体里的 actor 停在了自述层；没有区块号的截图停在了叙事层；0.14% 则告诉我们——当"地基"不随数据一起传递时，看起来最像证据的那一列，可能什么都不支撑。

相关工具：要发币、做多链部署可以用 TokenDIY；检查并撤销不需要的链上授权用 Revoke（仅 http）。

相关阅读

• 链上核验清单：收据、钱包与授权，别只看表面
• AI 回测的"未来函数"：为什么回测很美、实盘就崩
• 交易的真实成本：四笔费用、Gas 假设与到手的价格
• 专题：量化交易 / 策略与市场结构完全指南
• 专题：链上数据 / 安全完全指南

本系列另两篇（三站相关系列 · 验证盲区）

• AI 测试与 bug 同谋：变异测试与 LLM 评委校准（同样的"检查通过≠正确"落到软件：88.00 的巧合、覆盖率证明不了 oracle、κ 0.80 的评委校准）
• 水密不等于能打印：AI 3D 资产的验收清单（落到 3D 资产：水密的网格可能法线全反、225 个隐藏壳体、软件默认 K 因子不是物理事实）

来源

• @holdylab, Why 20 Trades Prove Nothing: Sample Size for Trading Behavior (in 25 Lines of Python)（dev.to，2026-10-14，含 10-15 勘误；作者为 Holdy Lab，代码 MIT 开源，区间与概率可复现；非投资建议）：https://dev.to/holdylab/why-20-trades-prove-nothing-sample-size-for-trading-behavior-in-25-lines-of-python-m66
• @debashish_ghosal, No Bootstrap, No Principal: The Day My Audit Log Became Fiction（dev.to，2026-10-15；案例来自其自建项目 HivePlane 0.2.0 现场测试，作者自报 36/36 通过）：https://dev.to/debashish_ghosal/no-bootstrap-no-principal-the-day-my-audit-log-became-fiction-562n
• @kaminariresearch, Receipts, not screenshots: a practical guide to verifying on-chain claims（dev.to，2026-10-13；作者为自主研究 Agent，文中推广其 agent skills，核验均用公开链上数据）：https://dev.to/kaminariresearch/receipts-not-screenshots-a-practical-guide-to-verifying-on-chain-claims-20el
• @agenticfinancegraph, 0.14% of AI-agent ratings on Base follow a payment: an open fixture set for ERC-8004（dev.to，2026-10-14；数据采集时间 10:50 UTC，CSV 以 CC BY 4.0 公开，728 为下界；发布方运营 AI-agent 资金账本）：https://dev.to/agenticfinancegraph/014-of-ai-agent-ratings-on-base-follow-a-payment-an-open-fixture-set-for-erc-8004-l5l
• @axagen, I Let an AI Bot Trade Real Money for a Week – Results ($50 Live + $20k Paper)（dev.to，2026-10-13；单人单周实验日志，原文明确"不是策略推荐、不构成投资建议"）：https://dev.to/axagen/i-let-an-ai-bot-trade-real-money-for-a-week-results-50-live-20k-paper-3l2f

本文由 DefiPlot 翻译整理，转载请注明出处。

免责声明

本文仅用于学习与研究目的，不构成任何投资建议、财务建议或交易建议。文中胜率区间、连败概率与 $50 实盘/paper 结果来自原文作者的代码与自述口径，未做独立复测；链上数据标注了抓取时间与来源（Base 信誉注册表连接结果 2026-10-14 10:50 UTC，728 条为下界），审计日志案例来自作者自建项目的现场测试。加密资产交易与链上交互存在合约漏洞、统计偏差、网络拥堵、滑点与钓鱼风险；样本量不足的结论、过拟合的策略与无付款地基的评分都可能严重误导。请勿使用无法承受损失的资金参与，任何操作前请自行核对官方数据与链上记录并 DYOR（Do Your Own Research）。

本文属于「量化交易」专题。查看专题全部文章 →

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。