1
2

你的电脑遇到问题，需要重启。
终止代码：DPC_WATCHDOG_VIOLATION

从那天起，这台笔记本每天要这么死 1~4 次，整整 17 天没有一天例外。日志里 Kernel-Power 41 和 EventLog 6008 与每次死机一一对应。

排查前后持续了几个月，走了两次明显的弯路：先是在转储里扫字符串找驱动，然后是把 amdgpio2.sys 当成元凶。真正的转折点是 !blackboxpnp 这条几乎没人提的命令——它把六次崩溃里的六次，都指向了同一块硬件：Intel AX200 无线模块所在的 PCIe 根端口。

这篇文章按时间顺序把整个过程写下来：错在哪、怎么证伪、最后改了哪三样东西，以及为什么“5 天不崩”这一次能算数。

设备：机械革命 无界14X（MECHREVO WUJIE14XA）／AMD Ryzen 7 8845HS + Radeon 780M／Windows 11 25H2
故障：每天卡死 1~4 次，卡住几十秒后黑屏重启，终止代码恒为 0x00000133
结果：修复后 5 天零崩溃（统计显著性 P ≈ 3×10⁻⁷）

先说结论

一、症状：一天崩四次

这台机器从 7 月开始频繁“整机假死”：

• 鼠标、键盘、画面全部冻结，按什么都没反应；
• 卡住几十秒到几分钟后，屏幕黑掉，出现“你的电脑遇到问题，需要重启”，下面一行小字给出终止代码；
• 日志里 Kernel-Power 41（异常断电）和 EventLog 6008（意外关机）与每次死机一一对应；
• 最严重的时候一天崩 4 次，17 天里没有一天不崩。

终止代码始终是同一个：

1

0x00000133  DPC_WATCHDOG_VIOLATION

参数在不同崩溃间是两种形态：

二、先理解这个错误码在说什么

Windows 内核用 IRQL 给代码分级。在 DISPATCH_LEVEL 及以上，代码必须遵守三条铁律：

1. 不能被线程调度抢占（没有“时间片用完就切走”）；
2. 不能访问分页内存（触发缺页就要降回 PASSIVE_LEVEL）；
3. 不能做任何“等待”（只能自旋）。

这就是为什么“驱动卡住”的表现是整机卡死，而不是某个程序变慢——普通程序跑在 PASSIVE_LEVEL，卡了会被切走；而 ISR/DPC 卡住，同处理器上所有更低 IRQL 的工作全部排不上队，包括时钟、键鼠、显示、磁盘中断。

看门狗（nt!KiDpcWatchdog）在时钟中断里检查这个时间，超了就调 KeBugCheckEx(0x133)。

由此得到一个重要推论：蓝屏的调用栈顶部永远是“报信的处理器”，它只负责调用 KeBugCheckEx，不一定是闯祸的那个。真正的元凶要靠 Stack.Pointer 和归因桶去找。

三、第一步就走错了：字符串扫描转储

一开始我的思路很朴素：把 minidump 复制出来，扫描里面的字符串，提取崩溃时加载的驱动清单，然后比对不同时期的驱动差异。

这个方法是无效的。 一个内核转储里本来就有上百个已加载驱动，“当时在场的驱动”和“闯祸的驱动”完全是两件事。按这个思路，最后只能得到一张“所有第三方驱动都可疑”的清单，无法排序，也就无法收敛。

更糟的是，它容易得出看起来很有说服力、实际是错的结论。

四、一个把人带偏很远的假线索

分析日志时我发现：所有 P1=1 的崩溃，P3 参数都以 0x53C8 结尾。

1
2
3
4

0x133 (0x1, 0x1e00, 0xfffff805d53c53c8, 0x0)
0x133 (0x1, 0x1e00, 0xfffff803783c53c8, 0x0)
0x133 (0x1, 0x1e00, 0xfffff804b83c53c8, 0x0)
                              ^^^^^^ 都一样！

很容易得出“每次蓝屏参数完全一致 → 指向同一内核代码路径 → 某个驱动的固定缺陷”。

但这是错的。 当 P1=1 时，P3 并不是崩溃地址，而是：

1

P3 = nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK 的指针

这是 ntoskrnl 里一个固定偏移的数据结构（本例偏移 0x3c53c8）。每次开机内核基址被 KASLR 重新随机化，页对齐意味着低 12 位必然一模一样。它跟“哪条代码路径”毫无关系。

这个坑值得记下来：看 0x133 的参数时，不要用 P3 的低位去“聚类”。

五、正确的第一步：加载符号再分析

真正有效的工具是 WinDbg / kd.exe 加符号服务器。装好新版 WinDbg（MSIX 包内含 kd.exe，免管理员）之后：

1
2
3
4
5
6

$kd  = 'C:\Program Files\WindowsApps\Microsoft.WinDbg_<版本>_x64__8wekyb3d8bbwe\amd64\kd.exe'
$sym = 'srv*C:\Symbols*https://msdl.microsoft.com/download/symbols'

& $kd -z 'C:\Windows\Minidump\xxx.dmp' -y $sym `
      -logo 'C:\temp\out.log' `
      -c '!analyze -v; !blackboxpnp; q'

⚠️ 关键技巧：用 -logo 让调试器自己写文件，不要用管道重定向。
在某些受限环境下，把 kd 的标准输出重定向到管道会刷屏报 Could not write to pipe, 1450（ERROR_NO_SYSTEM_RESOURCES），分析永远跑不完。-logo 绕开管道，日志是完整的。

!analyze -v 的输出里，真正有用的是这几行：

1
2
3
4
5
6

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
Stack.Pointer:    ISR
SYMBOL_NAME:      amdgpio2+2935
MODULE_NAME:      amdgpio2
IMAGE_NAME:       amdgpio2.sys
FAILURE_BUCKET_ID: 0x133_ISR_amdgpio2!unknown_function

FAILURE_BUCKET_ID 才是归因结论，它由调试器算出来，不是字符串扫描能得到的。

一开始我锁定的就是它：AMD GPIO 控制器驱动（amdgpio2.sys）的中断服务例程执行超时。

当时的证据链看起来非常完整：

• 6 份转储里 2 份精确点名 amdgpio2+0x2935，同一偏移（不同 KASLR 基址、不同开机时长的两次崩溃能复现同一个“模块+偏移”，不可能是栈上垃圾）；
• 调用栈里能看到 nt!KiChainedDispatch → KiScanInterruptObjectList（链式共享中断：多个设备共用一条中断线，内核要按链表逐个调用 ISR，一个卡住后面全轮不到）；
• 系统日志里 21 次 ACPI 事件 13「嵌入式控制器 EC 未在超时时间内响应」，且集中在蓝屏前 1~2 分钟，每 5 秒刷一次；
• 8 次 UcmUcsiCx.sys（USB Type-C / UCSI）的 live dump，微软官方定义就是“固件未按时响应 UCSI 命令”。

链条看起来是：amdgpio2 的 ISR 卡死 → EC/Type-C 中断得不到服务 → 看门狗蓝屏。

于是我自然而然做了一件事：更新 amdgpio2.sys。

六、第一次实验：更新 GPIO 驱动，失败了

查到的版本差异确实很夸张：

也就是说，一个 2020 年构建的二进制，被装在 2026 年的 Windows 11 25H2 + Hawk Point 平台上跑了六年（文件日期显示 2022，那只是 AMD 打包的时间）。

更新过程很顺利，设备挂载版本确实换了：

1
2

AMD GPIO Controller   2.2.0.130 → 2.2.0.137
ImagePath → ...\DriverStore\FileRepository\amdgpio2.inf_amd64_xxx\amdgpio2.sys  ← 新路径

这里有个很实用的验收要点：不要用 C:\Windows\System32\drivers\amdgpio2.sys 判断生效版本，那个位置常常留着旧副本。要看设备实际挂载的版本：

1 2	Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceName -match 'AMD GPIO' | Select-Object DeviceName, DriverVersion, DriverDate, InfName | Format-List

结果：14 小时后再次崩。 之后半个月继续每天崩 1~4 次，转储依旧归因 amdgpio2。

两个版本都在同一个位置以同样方式超时，偏移随二进制重建而变化。 这推翻了“某个版本代码缺陷”的假设——

amdgpio2 是受害者/报信者，不是元凶。得去找“是什么把它的 ISR 拖住了”。

七、真正的突破口：!blackboxpnp

WinDbg 有个很不显眼但极有价值的命令：!blackboxpnp。它读取崩溃时保存的 BlackBox PnP 记录——“崩溃前最后一次即插即用活动”。

1
2
3
4
5
6

0: kd> !blackboxpnp
        PnpActivityTime    : 134376450726760352
        PnpEventInformation: 3
        PnpEventInProgress : 0
        PnpProblemCode     : 24
        DeviceId           : SWD\RADIO\Bluetooth_...

把 6 份能读出这条记录的转储排在一起，结果惊人地一致：

6/6 全部落在一块硬件上：Intel AX200 无线模块（Wi-Fi + 蓝牙二合一）。

前 5 次指的是它的蓝牙无线电设备，第 6 次指的是承载它的那条 PCIe 根端口，而且那次 PnP 操作正在执行中。

八、把 PCIe 拓扑画出来

知道 DEV_14EE 是 AMD 的 PCIe 根端口还不够，得知道它下面挂的是谁。用一段脚本遍历父子关系即可：

1
2
3
4
5
6
7
8

$pci = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^PCI\\' }
foreach ($d in $pci) {
    $parent = (Get-PnpDeviceProperty -InstanceId $d.InstanceId `
                 -KeyName 'DEVPKEY_Device_Parent').Data
    if ($parent -match 'DEV_14EE|DEV_14EB') {
        "{0,-42} <- {1}" -f $d.FriendlyName, ($parent -replace '.*\\','')
    }
}

输出直接给出了答案：

1
2
3
4

AMD PCIe 根端口 DEV_14EE
  ├─ &0&11  → Motorcomm YT6801 千兆有线网卡
  ├─ &0&12  → Intel(R) Wi-Fi 6 AX200 160MHz   ← 崩溃瞬间正在被 PnP 操作
  └─ &0&14  → Standard NVM Express Controller（NVMe SSD）

崩溃发生时，Windows 正在对“承载 AX200 无线网卡的那条 PCIe 根端口”执行 PnP 操作。

回头再看系统日志，所有碎片瞬间对上了：

• NDIS 10317「Wi-Fi 虚拟网卡电源转换失败」83 次；
• Netwtw10（Intel 无线驱动）内部错误 / 固件重置 30 次、微端口重置看门狗 8 次；
• 而当时的无线驱动是 2023-11-29 的 23.20.0.4，跑在 2026 年的系统上。

修正后的因果链：

1
2
3
4
5
6
7
8

Intel AX200 的电源管理 / PCIe 链路行为异常
        ↓
Windows 反复给它做电源切换 / 重新枚举
        ↓  触发其所在 PCIe 根端口的 PnP 操作与链路状态变化
        ↓  每次变化都伴随中断与 ACPI/GPIO 交互
AMD GPIO 控制器（amdgpio2）的 ISR 被反复重入 / 长时间占据
        ↓
DPC 看门狗判定超时 → 0x133；或整机硬死（连转储都写不出）

这也解释了两件此前想不通的事：

1. 为什么换 amdgpio2 驱动没用——它是被动方；
2. 为什么下游症状那么杂——EC 超时、UCSI 超时、TPM 初始化失败、NVMe 控制器重置、AMD 自家看门狗 dump 全都在报，因为它们共享同一片中断/电源生态。

九、顺手证伪了两个“硬件直觉”

到这一步，很多人（包括我自己）会怀疑硬件：全金属机身，卡死前风扇狂转，是不是静电或过热？

过热：证据不支持

如果是真正的过热保护，应该表现为直接断电或 WHEA 记录，而不是一个能被判定、还能写出完整转储的看门狗蓝屏。

而且后面还有一条反证：修复后的观察期里，ACPI 热区曾读到 76.1 °C 依然没有崩。

关于“卡死前风扇狂转”，有个反直觉的解释：这可能是结果而非原因——EC 停止响应或 CPU 被 ISR 空转占满时，风扇会失去正常调节被拉到最大。本机有直接的「EC 未响应」证据，所以更像结果。

静电：基本可以排除

不过要留个口子：统计里有一批“连转储都没写出来”的硬死机（60 天内 41 事件 67 次 vs 蓝屏 34 次，差约 33 次），这一类确实符合断电/静电/过热关机的特征，不能完全排除。

十、最终修复：三件事

定位到“无线模块的电源/链路行为”后，动作就很明确了。用 Intel 官方工具和系统设置，一共三件：

1. 更新两套驱动（Wi-Fi / 蓝牙）

AX200 是同一模块上的两个独立设备：Wi-Fi 是 PCIe 设备（PCI\VEN_8086&DEV_2723），蓝牙是独立的 USB 设备（USB\VID_8087&PID_0029）——两套完全不同的驱动，必须分别更新。

装之前务必核对数字签名：

1 2	Get-AuthenticodeSignature '.\WiFi-xx.x-Driver64-Win10-Win11.exe' | Select-Object Status, SignerCertificate

蓝牙驱动其实 Windows Update 的可选更新里就有更新的版本，不一定需要额外下载。

2. 禁止系统把网卡断电

设备属性里的「电源管理」标签——注意它是独立标签页，不是「高级」列表里的一项——很多 OEM 驱动 INF 并不注册这个页，所以你会找不到。等价开关是注册表：

1
2

HKLM\SYSTEM\CurrentControlSet\Enum\<设备实例ID>\Device Parameters
    PnPCapabilities  (DWORD) = 0x18

0x18 同时禁止“允许计算机关闭此设备以节省电源”和“允许此设备唤醒计算机”。Wi-Fi 和蓝牙两块都要设，改完需要重启或禁用/启用设备才生效。

同时在「高级」标签里关掉省电/唤醒项（不同驱动版本条目名不同）：

1
2
3

唤醒幻数据包     → 停用
唤醒模式匹配     → 停用
数据包合并       → 停用   ← 这项最能减少网卡进入低功耗态

3. 关掉 PCIe 链路状态电源管理（ASPM）

这是最关键的一项：它直接决定 PCIe 链路会不会频繁进 L1/L2。当前如果是“最大电源节省”，改成“关闭”或“中等”：

1
2
3
4

# 0=关闭  1=中等电源节省  2=最大电源节省
powercfg /setacvalueindex SCHEME_CURRENT SUB_PCIEXPRESS ASPM 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_PCIEXPRESS ASPM 0
powercfg /setactive SCHEME_CURRENT

顺便把无线适配器的节能模式也拉到最高性能（尤其电池档，默认常是“中等节能”）：

1
2
3

powercfg /setdcvalueindex SCHEME_CURRENT `
  19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 `
  12bbebe6-58d6-4636-95bb-3217ef867c1a 0

再关掉快速启动（HiberbootEnabled = 0），让每次开关机都是完整电源循环。

十一、验证结果：5 天零崩溃

最有力的指标是最后一行。 那些 AMD_WATCHDOG、UcmUcsiCx、DripsWatchdog 的 live dump 是不产生蓝屏的隐性故障，此前每几天就冒一份。观察期内一份都没有——说明不只是“侥幸没崩”，而是平台级停顿本身消失了。

另外还有一次连续运行 52.7 小时无异常（而此前 17 天里没有任何一天不崩）。

统计意义：修复前基率 3.0 次/天，5 天预期 15 次，实际 0 次——泊松估计 P ≈ e⁻¹⁵ ≈ 3×10⁻⁷。

归因必须诚实说

这次同时改了 7 项，所以不能说“就是某一项修好的”。但有两点是确定的：

• 单独更新 amdgpio2.sys 无效（换完驱动后仍每天崩 1~4 次，转储照样点名它）；
• 有效的变化发生在「AX200 驱动 + 无线/PCIe 电源管理」这一层，与前面的机制推导一致。

十二、可复用的排查清单

如果哪天你也遇到 0x133 / 频繁整机假死，按这个顺序走。

第一步：拿到正确的归因（别做字符串扫描）

1
2
3
4

# 1) 转储需要管理员权限才能复制
# 2) 用 kd + 符号服务器分析，务必用 -logo 而非管道重定向
kd -z <dump> -y "srv*C:\Symbols*https://msdl.microsoft.com/download/symbols" `
   -logo out.log -c "!analyze -v; !blackboxpnp; !dpcs; q"

重点看三个字段：FAILURE_BUCKET_ID（归因）、DPC_TIMEOUT_TYPE（超时类型）、Stack.Pointer（谁在超时）。

第二步：别把“被点名的驱动”直接当元凶

问一句：它是主动作恶，还是被动挨打？

判断方法：换掉它的版本再观察。如果换版本后仍然崩在它身上（只是偏移变了），那它是受害者，要去找“谁在踩它”。

第三步：用 !blackboxpnp 找设备

这是被严重低估的线索——它直接告诉你崩溃前最后一次 PnP 活动涉及哪个设备。落在某个设备上 6/6 次，就不是巧合。

第四步：把 PCIe 拓扑和设备对应起来

1
2
3
4
5
6
7
8

$pci = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^PCI\\' }
foreach ($d in $pci) {
    $parent = (Get-PnpDeviceProperty -InstanceId $d.InstanceId `
                 -KeyName 'DEVPKEY_Device_Parent').Data
    if ($parent -match 'DEV_') {
        "{0,-42} <- {1}" -f $d.FriendlyName, ($parent -replace '.*\\','')
    }
}

第五步：三个“电源管理”必查项

第六步：看驱动的“代际”

查驱动的 PE 链接时间戳，而不只是文件日期：

1
2
3
4

$b = [IO.File]::ReadAllBytes('C:\Windows\System32\drivers\xxx.sys')
$peOff = [BitConverter]::ToInt32($b,0x3C)
$ts    = [BitConverter]::ToUInt32($b,$peOff+8)
[DateTimeOffset]::FromUnixTimeSeconds($ts).ToLocalTime()   # 这才是真正的构建时间

第七步：验证要算基率

“改完之后不崩了”只有在对照基率下才有意义。本例基率 3 次/天，5 天 0 次就是 P≈3×10⁻⁷；如果基率是 0.1 次/天，5 天 0 次就几乎没有说服力。

十三、几个随手记下的小坑

1. P3 低 12 位相同 ≠ 同一代码路径（那是 DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK 的固定偏移，KASLR 的必然结果）。
2. triage minidump 不含驱动代码页，所以别指望在转储里反汇编出错的那几条指令（会报 Memory access error）。
3. C:\Windows\System32\drivers\xxx.sys 可能是陈旧副本，PnP 驱动实际从 DriverStore 加载，验收要看设备挂载版本。
4. kd 的输出别走管道，用 -logo。
5. PowerShell 5.1 读无 BOM 的 UTF-8 脚本会按 GBK 解析，中文全变乱码、还可能吃掉引号花括号导致语法错误。写 .ps1 给 5.1 用，要么带 BOM，要么纯 ASCII。
6. Windows Update 的“可选更新 → 驱动程序更新”里常藏着比 OEM 官网更新的驱动，本例的蓝牙驱动就是从那里装的，比官网方便。
7. 5 天不崩不等于彻底好了，覆盖高发场景（高负载、视频会议、合盖唤醒、插拔外接显示器）才能算验证充分。

结语

这个案子最值得记的不是“哪个驱动坏了”，而是两个方法论上的教训：

• 归因要用调试器算出来的 FAILURE_BUCKET_ID，不是靠肉眼在转储里找字符串；
• 0x133 点名的驱动，很可能只是最后一个被压垮的人，而不是开枪的人。

从“怀疑所有驱动”，到锁定 amdgpio2，再到发现它其实是被踩的，最后落到“无线网卡的 PCIe 电源行为”——每一步都在缩小范围，而每一次“看起来很有说服力的结论”都需要一次对照实验去证伪。

但真正决定“要不要认输”的不是这条简报。那是另一层：一组确定性规则先把“值得看一眼”的仓位挑出来，再让 DeepSeek 回答一个问题——这一仓开仓时的逻辑，是不是已经被破坏了。它输出 hold / trim / exit，附置信度、风险分和一句理由；至于要不要真的执行，还得过一道确定性门槛。

两层都是只读的。这篇文章讲这条链：规则怎么看见，模型怎么裁决，以及为什么最后一步必须由代码而不是模型来扣扳机。

图 1｜分析层每天 10:00 的多品种看板。标题行写着“未来 4h 环境读数，非交易信号”

一、四个角色，各管一段

四条边界里最硬的是第二行：模型只能“建议”，执行权在策略和门槛手里。所以这套东西最坏的情况是“给你一个错的建议”，而不是“替你做了一个错的决定”。

这条边界不是为了保守，而是为了可归因。模型说错了，你能翻出它当时看到的数据、给出的理由和失效条件；如果它还能直接下单，这些记录就都变成了事后解释。

二、两层怎么接

1
2
3
4
5
6
7
8

币安 REST ─┐
11 个新闻源 ├─→ market_intel（确定性）─→ 简报 / 详细卡 / 四张账本
恐慌贪婪 ─┘        │
                   └─ 4h 区间 · 健康分 · 拥挤度（给人看，也给模型当上下文）

freqtrade API（只读）─→ sentinel 候选规则 ─→ DeepSeek ─→ signals.sqlite
                                                              │ 只读
                                                     策略 custom_exit

一句话分工：分析层负责“把市场说清楚”，裁决层负责“这一仓还成不成立”。

前者可复算，同一个输入永远同一个输出；后者是定性的，同样的事实，不同的人可能给出不同结论。把两者混在一起，出错时你就永远分不清是数据错了还是判断错了。

三、模型看到什么

候选：先把绝大多数时刻排除掉

为什么不把所有仓位直接丢给模型？成本和信噪比。8 个仓位、每 60 秒扫一次，一天 11520 次判断，其中绝大多数是“没事”；模型的价值不在这些时候，而真正需要判断的时刻，一天可能只有一两次。

所以顺序是反的：规则先做减法，把候选压到个位数，模型只在候选上做加法。

上下文：一次给全，但不给它编造的机会

• 持仓侧：开仓价、当前价、杠杆、浮亏、持仓时长、DCA 层数、历史最大浮盈；
• 市场侧：4h / 1d 的 EMA 结构、RSI、ATR、资金费率、OI；
• 拥挤度：多空账户比、大户持仓比、主动买卖比、费率趋势、基差、24h 量能，5 个免费端点，15 分钟缓存，单个接口挂了只是缺字段；
• 组合层：同因子且同方向的保证金占比、整本净敞口、平均相关性。

组合层有个例外要单独处理：同板块反向腿是对冲，不该算成集中风险，所以只统计“同因子 + 同方向”。

Prompt 里写死三条规则：不准编造；必须区分事实与推断；必须给出“失效条件”。数据缺失就写“数据缺失”，宁可 hold + low，也不要为了“做点什么”而减仓。

“失效条件”那条值得单说：它不是给模型自己看的，是给 20 小时后的复盘看的。模型说“跌破 342 就说明这次判断错了”，复盘时就能直接检验这句话——判断从一句形容词变成了一个可验证的命题。

契约：严格 JSON，温度 0

1
2

{"action":"hold|trim|exit","size_fraction":0.0,"confidence":"low|medium|high",
 "risk_score":0,"rationale":"...","invalidation":"..."}

校验是逐字段的、确定性的：action / confidence 只能是枚举值，risk_score 必须是 0–5 的整数（布尔值不算），trim 的 size_fraction 必须落在 (0, 0.9] 并吸附到预设档位，rationale 不能为空。任何一条不合规，直接记 llm_failed，不猜、不修、不重试到行为漂移。

temperature: 0，超时 15–20 秒。一个具体的坑：max_tokens 一开始设 256，中文理由经常在句子中间被截断，JSON 直接失效；调到 512 才稳定。

四、模型说 exit，不等于真的平仓

模型输出之后，还有一道 gate：

第一版的门槛是二值的：exit + high + risk≥4 才全平，其余一律不动。上线后拉了 28 小时统计，exit+high 只出现 2 次，而 exit+medium+risk4 出现 42 次、全部被丢掉——其中一笔 XRP 多单就那样一路亏到 −6.6%。

这不是模型不准，是门槛的“分辨率”错了。把确信度当开关（信 / 不信），等于把 42 次中等确信的警告全扔了。改成分级之后，同样的输出变成“先减一半”，风险留在中间地带，既不装死，也不一刀切。

一次真实的裁决长这样：

1
2
3

{"action":"exit","size_fraction":0.0,"confidence":"medium","risk_score":4,
 "rationale":"持仓 14h、浮亏 -4.8%，4h 结构转空、费率由正转负，多头逻辑已破",
 "invalidation":"4h 收盘重新站回 EMA200 上方则本次判断作废"}

过 gate 时，medium + risk 4 不会全平，而是被改写成 action=trim, size_fraction=0.5，并写入一条 gate_note。策略看到的只是“减一半”，账本里留的却是“模型原本想全平、被门槛折中”——两条信息都得留着，否则事后分不清是模型太激进，还是门槛太保守。

状态机只有五个状态：

1
2
3
4
5
6

pending ─┬─ hard_stop ──────────────→ exit_recommended
         ├─ exit/high/risk>=4 ──────→ exit_recommended
         ├─ medium/risk>=4 ─────────→ trim 50%
         ├─ hold 或低置信 ──────────→ no_exit
         ├─ 超时 / 非法 JSON ───────→ llm_failed
         └─ 超过 45 分钟 ───────────→ expired

策略侧只认三件事：status == exit_recommended、未过期、trade_id 匹配。退出原因写成 llm_exit_<signal_id> 或 watchdog_local_hard_stop，事后能追到是哪条判断、哪次调用。

还有两个不起眼但很值的工程细节：同一仓位 15 分钟内不重复送模型（去重），信号 45 分钟过期（防止拿旧判断做新决定）。

五、供数层为什么必须确定性

裁决层再聪明，也得有人先把事实摆对。分析层做的就是这件事，而且它一行 LLM 都没有——判断必须可复算，否则账本没有意义。

三周期投票：15m / 6h / 1d 各投五票，加权成 −1~+1 的方向分；4h 区间用 15m 历史上“恰好 4 小时”的窗口算 P10–P90。

这里最贵的坑是 RSI 和布林读反了：线性上涨的样本里 RSI 打到 100、价格贴着上轨，三个投票项同时给出“超买→看跌”，结果是系统性地做空每一次突破。修正只有一条：突破中顺势，震荡中才反向。

4h 区间还有个更隐蔽的坑：滚动窗口一旦跨过周末缺口，区间宽度会虚胖到 ±2.5%，等于什么都覆盖了。只保留时间严格连续（间隔正好 4h）的窗口后，XAG 收到 ±0.9%。卡片上那行「样本 2984（独立 = 186）」就是它的痕迹——2984 是 15m 的滚动窗口数，按 4h 视界折算，真正独立的只有 186 个：分位数看起来有三千个样本，其实只有一百八十几个。

新闻面：11 个源，金额 ≥ $100M 判重大。第一版 161 条里判出 60 条“重大”，基本是噪声——Rp114 Trillion 被当成 114 万亿美金、$19.5B net income 被当事件、$171B customer assets 盖住了标题里的 $5.8B outflow。修正后同一天只剩 19 条，最大 $6.3B。

衍生品：XAU / CL / XAG 是 4 小时结算，BTC / TSLA / AAPL 是 8 小时，不折算就会得出“黄金比比特币便宜”的反向结论（XAG 那次 0.0298%/4h 折出来是 0.0596%/8h、年化 65.3%，一看就知道是拥挤而不是便宜）；全市场多空比是账户比，大户是持仓比，两者不能相减，只能各自比自己的 20 日分位。

健康度：六个分项可加，方向 ±35、区间 ±20、拥挤 ±25、大户 ±10、新闻 −25~0、浮盈 ±10，正向封顶压低、负向给重。同日同方向的持仓能差出 78 分（ADA −54 对 AVAX +25）——如果所有仓位分数都差不多，这个模型就没有存在价值。

这套东西的价值不在“猜得准”，而在“说得清”：任何一个分数都能拆回分项，任何一个分项都能拆回原始数据。

六、三重滤网：把数字换成一句人话

1d = 潮、6h = 浪、15m = 涟，三层组合映射成一句结论，无量突破一律降级为“存疑”。简报因此从 2975 字符压到 2119 字符——不删信息，只删数值。

图 2｜/detail AAPL 的完整卡，下半截是 /status

拿这张卡读一遍：结论行 潮 无潮（区间） ｜ 浪 区间震荡 ｜ 涟 区间偏弱 → 无潮·区间交易，三层独立判定，1d 和 6h 的 vote 刚好相互抵消在 +0.00，15m 的 −0.60 是全卡最明确的一项。

健康分 −15（中性）方向 −16 区间 −3 拥挤 +4 可以手算：价格 344.50，4h 区间 343.41–345.98，位置 42%，对多单而言贴边程度 1 − 0.42 = 0.576，代入 (0.5 − 0.576) × 40 得 −3——和中位差的那一点，就是这 −3 分。

吃单 0.65（>1 主动买占优） 括号里是口径说明不是结论，0.65 意味着主动卖占优；R_squeeze_15m 是标记不是结论，波动压缩本身不告诉你往哪边开。整张卡最后一句是给自己看的：非交易信号；不下单、不改杠杆、不改 DCA。

下半截的 /status 是另一条线索：running · FFTAdaptiveCycle · 8 仓 · 权益 391.64 USDT · dry_run=False。策略在跑，分析层在旁路看着它——两者之间只有一条 127.0.0.1 的只读 REST，没有别的耦合。

七、账本：模型也要被记账

判断不能被证伪，就只是噪声的另一种写法。所以两层都有自己的账本。

分析层四张表：scores 记 4h 方向命中，band_scores 记区间覆盖（期望 80%），reviews 记逐仓 4h / 24h 走势与“对持仓有利度”，macro_scores 记 2–5 日宏观判断。

裁决层记的是另一样东西：每条信号保存 snapshot、prompt、模型原始输出、状态、gate 备注和时间。模型说错了，你能翻出它当时看到的是哪几根 K 线、哪一档费率、哪个组合敞口。

一个反直觉的数据点：早期版本上线 8 小时，signals 表 0 条、LLM 调用 0 次。不是程序没跑，是当时的候选规则要求价格偏离 EMA20 达到 2%，而那一夜 BTC/ETH 浮亏扩大到 −20% 以上，价格相对 EMA20 最大只偏离 **−0.88%**——缓跌 + EMA 跟随，规则永远等不到。

“模型一次都没被叫”本身就是一个结论：不是模型没用，是候选规则没覆盖到这种行情。后来候选改成了以浮亏、时长、逆势为主的组合，才有了可用的样本。

八、工程约束

部署在一台 Ubuntu 上，本机只写代码跑单测。原因很实际：本机到币安和英文 RSS 超时，服务器到中文站 403 / 404，只有 ChainCatcher 两边都通。

依赖只有标准库：urllib 而不是 requests，xml.etree 自己解 RSS 和 Atom，数据库用内置 sqlite3。代价是超时、重试、退避要自己写；好处是部署就是 tar 加解包，没有依赖漂移。

调度是“一个心跳”而不是“一排定时器”：mi-tick.timer 每小时 :05 唤醒，decide() 决定跑 daily 还是 hourly，job_state 记“今天跑没跑”，停机错过只补一次。sentinel 是独立进程，60 秒轮询一次，挂了也不影响 bot。

九、边界与风险

• 模型看不到的东西：链上数据、期权偏斜、新闻原文。Prompt 要求“缺失就说缺失”，不会编造，但这也意味着它的结论有盲区；
• 股票类标的：AAPL / TSLA 在闭市时段取不到完整的 5m K 线；
• 阈值仍是先验：所有分数只看相对排序，别看绝对值；n ≥ 20 之前不给调参建议；
• gate 不是保险：它只把“高确信”放行，不保证放行的一定对；
• 执行层也会坑你：有一次 adjust_trade_position 返回 -current_amount * current_rate，在 Freqtrade 2025.10 的负 stake 语义下换算出的数量超过持仓，日志里刷了 21,841 条 Remaining amount of -...，减仓全部被拒。AI 判对了，也不代表能执行——这条链路上一共有三个可能出错的地方：数据、判断、执行。

结语

这套系统的分工可以用一句话说完：规则负责看见，模型负责裁决，账本负责证伪。

规则把市场说清楚、把候选压到个位数，让每次模型调用都值得看；模型只回答“逻辑还在不在”，并且必须给出置信度、风险分和失效条件；最后一道门槛决定这份建议是变成一个动作，还是只留一条记录。

它不预测行情。它做的是三件更朴素的事：把判断摊开（可归因）、把判断写死（可复算）、把判断记下来（可证伪）。如果三个月后账本证明 4h 方向确实没有增量、或者 DeepSeek 的裁决并不比“一律持有”更好，那就把它降级成“只展示”——那也是一个结论。

量化交易的本质，是在不确定的市场中寻找统计意义上的优势。然而，单一指标或简单规则往往难以适应多变的市场环境。本文解析的 newstrategy5_1 策略，展示了一个成熟量化策略应有的复杂性与自适应性——它融合了十余种买入信号、动态 DCA 加仓、多级止盈止损以及基于市场状态的仓位过滤。下面我们将深入其核心逻辑与亮点实现，源码放在文末。

一、策略概览

策略的核心哲学：不依赖单一“圣杯”信号，而是构建多个独立、互补的入场条件，每个条件在特定市场状态下具备正期望；同时通过严谨的仓位管理（DCA）与动态出场，控制回撤、放大利润。

二、指标工程：多维度的市场画像

策略在 populate_indicators 中计算了超过 30 种衍生指标，涵盖趋势、动量、波动率、成交量、形态等维度。以下列举几个关键的自定义函数：

1. EWO（Elliott Wave Oscillator）

1
2
3
4
5

def EWO(dataframe, ema_length=5, ema2_length=3):
    ema1 = ta.EMA(df, timeperiod=ema_length)
    ema2 = ta.EMA(df, timeperiod=ema2_length)
    emadif = (ema1 - ema2) / df['close'] * 100
    return emadif

两条快速 EMA 的差值归一化，用于捕捉短期动能爆发。当 EWO 很大且为负时，可能代表超跌反弹机会。

2. Chaikin Money Flow (CMF)

1
2
3
4
5

def chaikin_money_flow(dataframe, n=20):
    mfv = ((close - low) - (high - close)) / (high - low)
    mfv *= volume
    cmf = mfv.rolling(n).sum() / volume.rolling(n).sum()
    return cmf

衡量资金流向，正值表示吸筹，负值表示派发。策略在卖出条件中加入了 cmf < 0 的判断，用于识别“死鱼”行情。

3. 自定义 Pmax（SuperTrend 风格）

1
2
3

def pmax(df, period, multiplier, length, MAtype, src):
    # 计算基于 ATR 的动态上下轨，并生成方向信号
    # 返回 pm（价格序列）和 pmx（'up'/'down'）

这是一个类似 SuperTrend 但更灵活的自适应通道，用于判断主要趋势方向。策略在 NFINext37 条件中使用 pm > pmax_thresh 来确认上升趋势。

三、买入信号：多个独立的“专家委员会”

策略没有使用单一的买入条件，而是定义了十余个独立的 enter_tag，每个代表一种市场模式。这种设计的好处：

• 分散风险：不同条件在不同市态下表现，避免过拟合单一模式。
• 可解释性：每个信号都可追踪其触发逻辑。
• 便于优化：可单独调整每个信号的参数。

以下是几个典型信号及其背后的逻辑：

1. DIP / Break 信号（均值回归）

1
2
3
4
5
6
7
8
9
10
11

dataframe.loc[
    ((dataframe[f'rmi_length_{self.buy_rmi_length.value}'] < self.buy_rmi.value) &
     (dataframe[f'cci_length_{self.buy_cci_length.value}'] <= self.buy_cci.value) &
     (dataframe['srsi_fk'] < self.buy_srsi_fk.value) &
     (dataframe['bb_delta'] > self.buy_bb_delta.value) &
     (dataframe['bb_width'] > self.buy_bb_width.value) &
     (dataframe['closedelta'] > dataframe['close'] * self.buy_closedelta.value / 1000) &
     (dataframe['close'] < dataframe['bb_lowerband3'] * self.buy_bb_factor.value) &
     (dataframe['roc_1h'] < self.buy_roc_1h.value) &
     (dataframe['bb_width_1h'] < self.buy_bb_width_1h.value)
), ['enter_long', 'enter_tag']] = (1, 'DIP signal')

多个超卖指标共振（RMI、CCI、Stoch RSI、布林带下轨），并辅以 1 小时级别趋势过滤（ROC 与 BB 宽度）。这是一种经典的左侧抄底模型。

2. cluc_HA（Heikin-Ashi 形态突破）

1
2
3
4
5
6
7
8
9
10

dataframe.loc[                    
    ((dataframe['rocr_1h'] > self.buy_clucha_rocr_1h.value) &
     (dataframe['bb_lowerband2_40'].shift() > 0) &
     (dataframe['bb_delta_cluc'] > dataframe['ha_close'] * self.buy_clucha_bbdelta_close.value) &
     (dataframe['ha_closedelta'] > dataframe['ha_close'] * self.buy_clucha_closedelta_close.value) &
     (dataframe['tail'] < dataframe['bb_delta_cluc'] * self.buy_clucha_bbdelta_tail.value) &
     (dataframe['ha_close'] < dataframe['bb_lowerband2_40'].shift()) &
     (dataframe['close'] > (dataframe['sup_level_1h'] * 0.88)) &
     (dataframe['ha_close'] < dataframe['ha_close'].shift()) 
), ['enter_long', 'enter_tag']] = (1, 'cluc_HA')

基于 Heikin-Ashi 平滑后的价格计算 bb_delta_cluc（布林带宽度）和 tail（下影线长度），捕捉下跌末端的小实体阴线后的反转。同时引入 sup_level_1h（小时线支撑位）进行价格确认。

3. vwap（基于成交量加权平均价的超卖）

1
2
3
4
5
6
7
8
9

dataframe.loc[
    ((dataframe['close'] < dataframe['vwap_low']) &
     (dataframe['tcp_percent_4'] > 0.053) &
     (dataframe['cti'] < -0.8) &
     (dataframe['rsi'] < 35) &
     (dataframe['rsi_84'] < 60) &
     (dataframe['rsi_112'] < 60) &
     (dataframe['volume'] > 0)
), ['enter_long', 'enter_tag']] = (1, 'vwap')

价格跌破 VWAP 下轨，同时短、中、长周期 RSI 均处于低位，tcp_percent_4（4 周期开盘价最高点到收盘价跌幅）超过 5.3%，表明短期急跌。此信号适合流动性较好的币种。

4. NFINext 系列（趋势+动量组合）

例如 NFINext44：

1
2
3
4
5
6
7

dataframe.loc[
    ((dataframe['close'] < (dataframe['ema_16'] * self.buy_44_ma_offset)) &
     (dataframe['ewo'] < self.buy_44_ewo) &
     (dataframe['cti'] < self.buy_44_cti) &
     (dataframe['r_480_1h'] < self.buy_44_r_1h) &
     (dataframe['volume'] > 0)
), ['enter_long', 'enter_tag']] = (1, 'NFINext44')

价格远低于 16EMA，EWO 极度为负（超卖），CTI（C-Trend Indicator）显示强下降趋势，同时 1 小时 Williams %R（480 周期）处于极低位置。这是大周期与小周期共振的超卖信号。

四、卖出信号与动态出场

出场同样不单一，分为三个层级：

1. 基于 Fisher 指标的固定出场

1
2
3
4
5
6
7
8
9

dataframe.loc[
    (dataframe['fisher'] > self.sell_fisher.value) &
    (dataframe['ha_high'].le(dataframe['ha_high'].shift(1))) &
    (dataframe['ha_high'].shift(1).le(dataframe['ha_high'].shift(2))) &
    (dataframe['ha_close'].le(dataframe['ha_close'].shift(1))) &
    (dataframe['ema_fast'] > dataframe['ha_close']) &
    ((dataframe['ha_close'] * self.sell_bbmiddle_close.value) > dataframe['bb_middleband']) &
    (dataframe['volume'] > 0)
] = (1, 'fisher_sell_signal')

Fisher 变换将价格转换为高斯分布，数值过高代表极端超买，配合 Heikin-Ashi 高点降低、价格低于快速 EMA 等条件，确认反转。

2. 自定义 exit 中的动态跟踪止盈

custom_exit 函数中实现了两个跟踪止盈区间：

1
2
3

if (current_profit > self.sell_trail_profit_min_1.value) & (current_profit < self.sell_trail_profit_max_1.value) & 
   (((trade.max_rate - trade.open_rate) / 100) > (current_profit + self.sell_trail_down_1.value)):
    return 'trail_target_1'

其逻辑是：当利润处于 [min1, max1] 区间内，且最高价回撤幅度超过当前利润加上一个阈值时，触发止盈。这是一种基于价格回撤的跟踪止损，比简单的移动止损更敏感。

3. “死鱼”止损

当持仓已亏损（current_profit < sell_deadfish_profit.value），且市场波动收缩（布林带宽度很小）、价格被中轨压制、成交量萎缩、CMF 为负，认定为“死鱼”行情，强制止损离场，避免资金被长期占用。

五、亮点代码深度解析

亮点1：top_percent_change_dca —— 创新性的下跌幅度度量

1
2
3
4
5

def top_percent_change_dca(dataframe: DataFrame, length: int) -> float:
    if length == 0:
        return (dataframe['open'] - dataframe['close']) / dataframe['close']
    else:
        return (dataframe['open'].rolling(length).max() - dataframe['close']) / dataframe['close']

通常我们用 (high - close)/close 或 (open - close)/close 来衡量单根 K 线的下跌。但这里 top_percent_change_dca 度量的是：从过去 N 根 K 线的开盘价最大值到当前收盘价的跌幅。这能够捕捉到“开盘后持续走低”的连续下跌形态，是 DCA 决策中的重要过滤条件。例如在 adjust_trade_position 中，若 tpct_change_0 > 1.8% 且收阴，则放弃加仓，避免在急跌中接飞刀。

亮点2：adjust_trade_position 的条件加仓限制

策略允许多达 8 次 DCA，但并非无条件。每个加仓层级都有一组前置条件：

1
2
3
4
5
6
7
8

if count_of_entries == 1 and (last_candle['tpct_change_0'] > 0.018) and (last_candle['close'] < last_candle['open']):
    return None
elif count_of_entries == 2 and (last_candle['tpct_change_0'] > 0.018) and (last_candle['close'] < last_candle['open']) and (last_candle['ema_vwap_diff_50'] < 0.215):
    return None
...
elif count_of_entries == 5 and (last_candle['cmf_1h'] < 0.00) and (last_candle['rsi_14_1h'] < 30):
    logger.info(f"DCA for {trade.pair} waiting for cmf_1h to rise above 0...")
    return None

这种设计防止了在极端恶劣的环境下继续加仓。第 1 次加仓要求当前 K 线不是急跌大阴线；第 2 次要求 EMA-VWAP 偏离不过大；第 5 次开始要求 1 小时 CMF 为正且 RSI >30。加仓不是盲目的摊平成本，而是基于市场状态的条件触发。

亮点3：几何级数增长的安全订单步长与数量

1
2

if self.safety_order_step_scale > 1:
    safety_order_trigger = abs(self.initial_safety_order_trigger) + (abs(self.initial_safety_order_trigger) * self.safety_order_step_scale * (math.pow(self.safety_order_step_scale, (count_of_entries - 1)) - 1) / (self.safety_order_step_scale - 1))

安全订单的触发间距并非等距，而是按 step_scale=1.2 指数级扩大。这意味着：

• 首次加仓在 -1.8% 触发
• 第二次在 -1.8 - 2.16 ≈ -3.96% 触发
• 第三次在 -1.8 - 2.16 - 2.592 ≈ -6.55% 触发

配合 volume_scale=1.4（每次加仓金额增加 40%），形成一个金字塔式加仓，越跌买得越多，但间距越来越大，避免过度暴露。

六、总结与启示

newstrategy5_1 策略是一个典型的生产级量化策略，其价值不仅在于回测收益，更在于其设计模式：

1. 信号冗余与互补：用多个独立条件替代单一规则，增强鲁棒性。
2. DCA 有条件执行：每次加仓都需满足市场过滤，而非机械执行。
3. 多级出场机制：固定止盈、移动回撤止盈、死鱼止损、趋势破坏止损，各司其职。
4. 参数可优化空间：大量 IntParameter、DecimalParameter 与 optimize 开关，便于超参调优。

补充：策略回测数据稳健，但仅仅作为参考，详细源码来源：https://strat.ninja/overview.php?strategy=newstrategy5_1

我们从小听着”大丈夫宁死不屈”长大，也被教导”识时务者为俊杰”；被告知”狭路相逢勇者胜”，又听说”退一步海阔天空”；有人劝你”三思而后行”，也有人警告”当断不断，反受其乱”。

这些相互矛盾的人生格言，哪一句是对的？

答案是：都对，也都不对。关键不在于格言本身，而在于”时”与”度”——这正是中庸之道的核心。

交易的世界里，同样的悖论比比皆是。

交易的双面镜像

如果你对身边的人说自己在做股票交易，大概率会收到两种反应。

一种人皱着眉头说：”那不就是赌博吗？”在他们的认知里，股市就是个大赌场，所有公开的策略都是骗人的把戏。你跟他们讲技术分析，他们说这是迷信；你谈价值投资，他们说这是运气。

另一种人则会眼睛一亮：”听说巴菲特、芒格又分享新的投资理念了！”他们能如数家珍地背诵那些投资大师的金句，相信成功可以复制，策略可以学习。

这两种看法看似对立，却同时存在于真实的世界里。

事实是什么？绝大多数人确实在亏损，但每年也确实有人盈利。市场上确实充斥着骗人的”战法”和”秘籍”，但那些持续盈利的大师们，也确实在真诚地分享他们的思考框架。

这就像那个古老的盲人摸象寓言——每个人摸到的都是真实的一部分，但都不是全部。

为何交易中的道理总在打架？

打开任何一本交易书籍，你会发现矛盾俯拾皆是。

“趋势是你的朋友” vs “高抛低吸，落袋为安”
“截断亏损，让利润奔跑” vs “见好就收，别让盈利变亏损”
“市场永远正确” vs “市场总是错的”

这些说法不是谁在骗人。它们像那两句矛盾的俗语一样，各自对应着不同的市场状态和交易者处境。

牛市初期，趋势跟踪有效；震荡行情里，高抛低吸更优。左侧交易者认为市场总会犯错，右侧交易者坚信趋势才是真理。

问题不在于道理错了，而在于人们总想用一个道理解释所有情况。

中庸：第三种视角

“中庸”被误解了很久。它不是和稀泥，不是”差不多就行”，也不是在两个极端中间取一个平均值。

《中庸》开篇说：”中也者，天下之大本也；和也者，天下之达道也。””中”是事物的本然状态，”庸”是用。中庸是在动态变化中把握那个恰到好处的”度”。

用在交易上，中庸意味着：

第一，接受矛盾的存在。 交易领域没有放之四海而皆准的真理。你的盈利单可能是别人止损的理由，你的入场信号可能是别人的出场依据。承认这一点，就不会执着于寻找”圣杯”。

第二，因时制宜，因地制宜。 趋势策略和震荡策略哪个好？取决于当下的市场环境。重仓和轻仓哪个对？取决于你的资金管理和风险承受能力。中庸思维训练的是”判断当下该用哪种道理”的能力，而不是背诵道理本身。

第三，在极端之间寻找平衡。 过度自信和过度怀疑之间，有健康的谨慎；频繁交易和完全不动之间，有适度的参与；追逐热点和固守己见之间，有灵活的坚持。

量化认知：让中庸可执行

中庸听起来很玄，但如果结合量化思维，它可以变得很具体。

量化交易的核心不是复杂的数学模型，而是”用数据代替感觉，用规则代替冲动”。把中庸之道量化，可以这样做：

设定边界，而非固定值。 不是规定”仓位永远50%”，而是设定”仓位在20%-80%之间动态调整，根据市场波动率决定具体数值”。这是一种有弹性的约束。

用概率思维替代二元判断。 不问”这个策略行不行”，而是问”这个策略在什么条件下胜率更高，赔率如何”。这不是放弃判断，而是让判断更精细。

建立反馈和调整机制。 每个季度复盘一次，检查自己在”过度”和”不及”之间是否偏向了某一端。量化不是为了消灭主观，而是让主观有据可依。

接受亏损，如同接受盈

最后，中庸之道带给交易者最重要的认知是：盈亏同源。

导致你亏损的那个特质，往往也是你盈利的来源。谨慎让你躲过大跌，也会让你错过大涨；激进让你抓住主升浪，也会让你在山顶站岗。

大多数人亏损，不是因为技术不好，而是因为他们无法接受这个事实——他们总想消除亏损，结果反而消除了盈利的可能。

中庸的交易观，是在长期的时间尺度上，接受短期的不确定。是在知道自己不知道什么的前提下，做自己能做的事。

俗语云：”尽人事，听天命。”

交易亦然：定规则，守边界，剩下的，交给市场。

1. 幸存者偏差与“低门槛”陷阱
   低准入门槛 vs. 高竞争门槛： 交易是世界上门槛最低的行业之一（只要开户），但它是竞争最激烈的行业之一（对手是顶尖机构）。

“新手保护期”与过度自信： 很多人初学阶段恰逢市场红利，误将行情归功于能力，导致在环境切换时迅速溃败。

网络噪音的真相： 网络上“量化无用论”盛行，是因为大多数人未曾建立科学的交易体系，而真正获利的 5% 往往保持沉默。

2. 指标的本质：从“迷信”到“工具化”
   指标不是预言机： 否定指标是因为试图用它预测未来。其实指标只是历史数据的统计规律化，其核心作用是降维（将复杂的行情简化为可决策的信号）。

消息面的伪命题： 相比于滞后、零散且极易被操纵的消息面，量化指标具有客观性、可回测性和唯一性。

构建组合逻辑： 失败者依赖单一指标，成功者构建多因子体系。通过不同维度（动量、波动、估值等）的指标对冲单一逻辑失效的风险。

3. 动态博弈：寻找“非平稳”市场中的确定性
   策略的半衰期： 市场是一个进化的有机体。当一个策略被大多数人获知时，其超额收益（Alpha）就会被摊薄甚至消失。

动态调整的维度：

参数自适应： 市场从震荡转为趋势时，参数需自动调节。

风控优先： 在策略失效（回撤达到阈值）时，必须具备强制离场的底层逻辑。

有些时候，想得太多而做的太少了，先做一个小事情，就是B站发图文，那么多量化书籍，讲好一个策略，如果一开始就要打

如果说有一个副业能够持之以恒，可能非量化莫属，天然适合发挥计算机的优势，也不用和各种人打交道。

5090显卡好贵，跑AI以后还得换设备。

课程简介

本课程基于Freqtrade 2025.8 stable版本，从零开始讲解加密货币量化交易框架的使用，涵盖环境搭建、策略开发、回测优化到实盘交易的全流程。参考《零基础Python量化教程》和《量化从入门到精通》的经典结构，结合实战案例帮助新手快速掌握量化交易技能。

学习目标

• 掌握Python基础语法及量化交易常用库（Pandas、TA-Lib）
• 熟练配置Freqtrade开发环境（Docker/原生两种方式）
• 能够独立编写、测试和优化量化交易策略
• 理解量化回测原理及实盘风险控制方法
• 掌握FreqAI人工智能策略开发基础

第一部分：量化交易基础（入门篇）

第1章：量化交易概念入门

1.1 什么是量化交易？

• 量化交易的定义与优势
• 加密货币市场特点及量化适用性
• 常见量化策略类型（趋势跟踪、均值回归等）

1.2 量化交易必备知识

• 金融市场基本概念（K线、指标、订单类型）
• 回测与实盘的区别
• 风险控制基础（止损、仓位管理）

第2章：Python量化基础

2.1 Python环境搭建

• Anaconda安装与环境配置
• Jupyter Notebook使用指南
• 常用库安装（Pandas、NumPy、TA-Lib）

2.2 Python核心语法

• 数据类型与控制流
• 函数与类的定义
• 量化交易常用数据结构

2.3 金融数据处理实战

• Pandas读取与处理K线数据
• 技术指标计算（RSI、MACD、布林带）
• 数据可视化（Matplotlib/Plotly）

1
2
3
4
5
6
7

# 示例：计算RSI指标
import talib as ta
import pandas as pd

df = pd.read_csv('BTC-USDT-1h.csv')
df['rsi'] = ta.RSI(df['close'], timeperiod=14)
print(df[['datetime', 'close', 'rsi']].tail())

第二部分：Freqtrade框架核心（进阶篇）

第3章：Freqtrade环境搭建

3.1 系统要求与依赖

• 硬件配置：2GB RAM/1GB磁盘/2vCPU
• 软件要求：Python 3.11+、Docker（推荐）、Git
• 常见问题解决（TA-Lib安装失败、权限问题）

3.2 Docker安装方式

1
2
3
4
5
6
7
8

# 拉取最新镜像
docker compose pull

# 启动并后台运行
docker compose up -d

# 查看日志
docker compose logs -f

3.3 原生Python安装方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 克隆仓库
git clone https://github.com/freqtrade/freqtrade.git
cd freqtrade

# 创建虚拟环境
virtualenv -p python3 .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# 安装依赖
pip install -U -r requirements.txt
pip install -e .

# 安装FreqUI
freqtrade install-ui

3.4 初始配置与目录结构

• 配置文件详解（config.json）
• 用户目录结构（策略/数据/日志存放位置）
• 交易所API密钥安全配置

第4章：策略开发基础（V3版本）

4.1 策略基本结构

• IStrategy接口核心方法
• 策略配置参数（时间框架、止损、ROI）
• 最小策略示例（RSI策略）

4.2 V3版本API重大变更

4.3 技术指标应用

• 内置指标库使用（TA-Lib、Pandas TA）
• 自定义指标编写方法
• 策略逻辑调试技巧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# V3版本RSI策略示例
class RSIStrategy(IStrategy):
    INTERFACE_VERSION = 3
    timeframe = '1h'
    minimal_roi = {"0": 0.1, "30": 0.05, "60": 0}
    stoploss = -0.05

    def populate_entry_trend(self, dataframe: pd.DataFrame, metadata: dict) -> pd.DataFrame:
        dataframe.loc[
            (
                ta.RSI(dataframe) < 30  # RSI低于30
                & (dataframe['volume'] > 0)  # 排除零交易量
            ),
            ['enter_long', 'enter_tag']] = (1, 'rsi_buy')
        return dataframe

    def populate_exit_trend(self, dataframe: pd.DataFrame, metadata: dict) -> pd.DataFrame:
        dataframe.loc[
            (
                ta.RSI(dataframe) > 70  # RSI高于70
                & (dataframe['volume'] > 0)  # 排除零交易量
            ),
            ['exit_long', 'exit_tag']] = (1, 'rsi_sell')
        return dataframe

第5章：多空交易策略

5.1 空头交易基础

• 做空逻辑与信号定义
• enter_short/exit_short信号列使用
• 多空策略示例代码

5.2 仓位管理

• 固定仓位与动态仓位设置
• 杠杆交易风险控制
• 策略参数优化思路

第三部分：实战操作指南（实战篇）

第6章：数据获取与回测

6.1 历史数据下载

1
2

# 下载比特币1小时数据（近30天）
freqtrade download-data --timeframes 1h --pairs BTC/USDT --exchange binance --timerange 20250801-20250830

6.2 回测功能详解

• 基本回测命令

  1	freqtrade backtesting --strategy RSIStrategy --timerange 20250801-20250830

• 回测结果分析（收益、胜率、最大回撤）
• 可视化回测结果（生成HTML报告）

6.3 策略优化（Hyperopt）

• 超参数优化原理
• 目标函数选择（夏普比率、利润因子）
• 优化命令示例

  1	freqtrade hyperopt --strategy RSIStrategy --hyperopt-loss SharpeHyperOptLoss --epochs 50

第7章：实盘交易与监控

7.1 模拟交易（Dry Run）

1

freqtrade trade --strategy RSIStrategy --dry-run --config user_data/config.json

7.2 实盘交易启动

1
2
3
4
5

# 原生方式
freqtrade trade --strategy RSIStrategy --config user_data/config.json

# Docker方式
docker compose up -d

7.3 交易监控工具

• FreqUI网页界面使用
• 关键指标监控（交易量、盈亏、策略性能）
• 日志分析与问题排查

7.4 实盘风险控制

• 仓位大小动态调整
• 连续亏损应急预案
• 市场极端行情应对策略

第8章：FreqAI人工智能策略（进阶）

8.1 FreqAI基础配置

• 启用AI功能的策略设置
• 训练周期与数据量选择
• 常用模型类型（XGBoost、LightGBM）

8.2 特征工程

• 技术指标特征构建
• 特征扩展与时间序列处理
• 自动特征生成示例

8.3 目标函数定义

• 价格预测目标设置
• 多目标优化方法
• 风险调整后的收益目标

1
2
3
4
5
6
7
8

# FreqAI策略示例片段
def feature_engineering_expand_all(self, dataframe: pd.DataFrame, period: int) -> pd.DataFrame:
    dataframe["%-rsi-period"] = ta.RSI(dataframe, timeperiod=period)
    dataframe["%-macd-period"] = ta.MACD(dataframe)["macd"]
    dataframe["%-bb-width-period"] = (
        (dataframe["bb_upperband"] - dataframe["bb_lowerband"]) / dataframe["bb_middleband"]
    )
    return dataframe

第三部分：综合实战项目（实战篇）

第9章：完整策略开发实战

9.1 项目需求：双指标趋势策略

• 策略逻辑设计（RSI+布林带组合）
• 入场/出场条件定义
• 风险控制参数设置

9.2 策略编写与调试

• 代码实现步骤
• 常见错误排查
• 策略回测验证

9.3 优化与性能提升

• Hyperopt参数优化
• 策略鲁棒性测试
• 不同市场条件下的表现评估

第10章：实盘部署与运维

10.1 服务器部署方案

• 云服务器选择（AWS/阿里云/腾讯云）
• 开机自启动配置
• 远程访问安全设置

10.2 数据备份与策略更新

• 自动备份策略文件
• 平滑更新策略方法
• 版本控制（Git）集成

10.3 长期运行监控

• 性能指标长期跟踪
• 策略衰减预警
• 定期再训练计划

附录

附录A：常见问题解决

• 安装问题（依赖缺失、权限错误）
• 策略错误（语法问题、逻辑缺陷）
• 回测异常（数据质量、参数设置）
• 实盘故障（API连接、订单执行失败）

附录B：学习资源推荐

• 官方文档：Freqtrade官方指南
• 策略库：Freqtrade社区策略
• 进阶书籍：《量化交易》《Python金融大数据分析》
• 社区支持：Discord群组、GitHub Issues

附录C：工具与资源清单

• 开发工具（VS Code配置）
• 数据获取工具
• 性能分析工具
• 安全最佳实践

课程总结与后续学习路径

• 知识体系回顾
• 进阶学习方向（高频交易、套利策略）
• 量化交易伦理与合规
• 持续学习资源推荐

services:
tensorboard:
image: freqtradeorg/freqtrade:stable
volumes:
- “./user_data:/freqtrade/user_data”
ports:
- “6006:6006”
command: >
tensorboard –logdir user_data/models/unique-id2 –host 0.0.0.0 –port 6006
docker-compose up tensorboard

#不太会使用tensorbaord进行调试啊

freqtrade官方链接：

https://www.freqtrade.io/en/stable/

一、准备工作

1、一台正常使用windows电脑
如果是linux系统，则参考freqtrade官方文档上的其他安装方案
确保你的系统已安装 Docker 及其相关组件。对于 Docker 的安装，可以参考官方文档。
最好安装docker desktop，链接：
https://www.docker.com/products/docker-desktop/

二、安装步骤

1. 创建工作目录

创建一个目录用于保存 Freqtrade 的配置文件和用户数据：

1
2

mkdir ft_userdata
cd ft_userdata/

这里我选择了在D盘创建，完成后打开电脑文件目录，可以正常看到多了一个文件夹

2. 下载 docker-compose.yml 文件

从 Freqtrade 的 GitHub 仓库下载 docker-compose.yml 文件：

1

curl https://raw.githubusercontent.com/freqtrade/freqtrade/stable/docker-compose.yml -o docker-compose.yml

注意，这里部分情况下会遇见网络问题，建议提前准备一个科学上网的代理

3. 拉取 Freqtrade Docker 镜像

使用以下命令拉取 Freqtrade 的 Docker 镜像：

1

docker compose pull

4. 创建用户目录结构

运行以下命令创建用户目录结构：

1

docker compose run --rm freqtrade create-userdir --userdir user_data

5. 创建配置文件

运行以下命令创建配置文件：

1

docker compose run --rm freqtrade new-config --config user_data/config.json

此命令会启动一个交互式向导，提示你输入相关配置信息，例如交易货币、交易所等。

6. 启动 Freqtrade 容器

启动 Freqtrade 容器：

1

docker compose up -d

在docker desktop里面可以清楚的看到运行的状态

打开浏览器，输入127.0.0.1：8080

三、网络问题导致镜像拉取失败的解决办法

1. 检查 DNS 配置

确保你的系统 DNS 配置正确。可以将 DNS 设置为 Google 或 Cloudflare 的公共 DNS：

• Google DNS: 8.8.8.8 和 8.8.4.4
• Cloudflare DNS: 1.1.1.1 和 1.0.0.1

2. 修改 Docker 镜像源

如果默认的 Docker Hub 镜像源无法访问，可以配置国内的镜像加速器。编辑 /etc/docker/daemon.json 文件，添加以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "registry-mirrors": [
        "https://docker.m.daocloud.io",
        "https://dockerproxy.com",
        "https://docker.mirrors.ustc.edu.cn",
        "https://docker.nju.edu.cn",
        "https://iju9kaj2.mirror.aliyuncs.com",
        "http://hub-mirror.c.163.com",
        "https://cr.console.aliyun.com",
        "https://hub.docker.com",
        "http://mirrors.ustc.edu.cn"
    ]
}

保存后，重启 Docker 服务：

1
2

sudo systemctl daemon-reload
sudo systemctl restart docker

3. 使用代理

如果需要代理，可以配置 Docker 的代理设置。编辑 /etc/systemd/system/docker.service.d/proxy.conf 文件，添加以下内容：

1
2
3
4

[Service]
Environment="HTTP_PROXY=http://xxx.xxx.xxx.xxx:xxxx/"
Environment="HTTPS_PROXY=http://xxx.xxx.xxx.xxx:xxxx/"
Environment="NO_PROXY=localhost,127.0.0.1,xxx.xxx.xxx.xxx"

保存后，重启 Docker 服务：

1
2

sudo systemctl daemon-reload
sudo systemctl restart docker

四、其他注意事项

• 如果需要使用 WebUI，可以在 docker-compose.yml 文件中添加 WebUI 的配置。
• 确保配置文件 config.json 中的设置符合你的需求。
• 如果遇到容器时间不一致的问题，可以调整容器内的时区设置。

以上是使用 Docker 安装 Freqtrade 的简要教程，希望对你有所帮助。如果遇到问题，可以参考 Freqtrade 的官方文档。

暂时记录最开始的部分，后面有空慢慢更新配置文件和策略的解读

2025年11月13日更新，补充关于ubuntu系统上的安装

• 我们采取的是conda安装

环境激活命令：

source ./.venv/bin/activate

前几天看到有人用Midjourney生成的数字绘画作品获得了比赛一等奖，恍然惊醒，原来AI已经成长到这种地步了，一种见证AI崛起于这个时代厚重历史感，

作者用的是Discord频道下Midjourney，输入提示词，然后等待GPU燃烧就可以生成画作。这个过程说起来简单，但实际上还是有难度。这个过程叫做Prompt Engineering

直接翻译为提示工程，可能不是太准确，网友甚至预测以后会有提示工程师这种全新职业。毕竟利用AI作画，一小时抵的上原来一星期的量，这让人明明白白的感受到什么是降维打击啊。

关于AI是否杀死了艺术，个人认为虎嗅这篇文章分析的有点道理。
《美术行业，正在被AI作画杀死？》
https://www.huxiu.com/article/651324.html

整理几个AI画画工具

discord.gg/midjourney（公测）

labs.openai.com/waitlist（内测）

https://beta.dreamstudio.ai/dream（公测）

对于我而言，并不是很关心艺术将来究竟如何，只关心AI作画可能的变现渠道。

一、抖音的壁纸号，目前已经有不少人在做这个，通过精美的壁纸吸引流量，然后广告变现，但是这个由于护城河很低，也是卷的不行。需要坚持。
二、对于原本的美术设计，游戏设计来说，运用得当可能会是职场杀器，缺陷在于很可能调试出来给提示词直接被公司继承，然后就直接毕业了。
三、对于画家来说确实不是一个好消息，继续坚持可能会更加困难，转型则意味之前的学习成本投入几乎浪费。还是顺势拥抱吧。
四、整理相关知识，卖教程，做知识星球。这个是比较可行的路子。至少可以在这一波冲击中收获一些。

最后，

很幸运生在这个伟大的时代，
但同时面对这个时代的飞速发展，
又感到很无力。
网上有个段子说的很好：长城非常壮观雄伟，但是我是修长城的人。