Stock_Analysis_For_Quant / 回测审计
一条收益曲线能不能信：先过 12 项检查，再看它属于哪一级
仓库里有大量结果图：组合 notebook 算净值、指标 notebook 画叠加图、预测 notebook 画拟合线。但没有一处说明这些图是怎么算出来的——没有成本假设、没有样本外、没有参数敏感性，也没有一行文字交代复权方式与信号成交时点。这不是这个仓库独有的问题，而是绝大多数示例代码的共同缺口。
所以这一页不给结论，只给尺子：12 项检查表告诉你每一项怎么查、查不到时该得出什么结论；四级分级告诉你这条曲线目前只到哪一档；最后一节列出 Stock_Analysis_For_Quant 里那些能直接查证的失败事实（失效链接、停更、无依赖清单、超大 notebook），它们本身就是「能不能复用」的判断依据。
先看这条曲线属于哪一级
12 项检查：每一项都写清「怎么查」与「查不到时怎么判」
下表按「先查什么」的顺序排列。前四项在别的语言里也一样通用，与 Stock_Analysis_For_Quant 用哪种工具无关。
先说清楚这套检查表是干什么用的：它不负责判断「策略好不好」，只负责判断「这条曲线能不能作为证据被引用」。在 Stock_Analysis_For_Quant 这类示例集合里，曲线往往是顺手画出来的中间产物，作者并没有打算让它承担绩效证明的责任——所以你会看到大量漂亮的结果图，却没有一行成本或样本外说明。
| 检查项 | 怎么查 | 查不到时的结论 | 适用场景 |
|---|---|---|---|
| 1 未来函数 | 在 notebook 里搜 shift(-、iloc[-1]、.max() 与 .min() 在时间轴上的用法，看信号是否用到了当日或未来的收盘价 | 无法排除未来函数 → 这条曲线的收益不可采信，只能当绘图练习 | 所有含信号与回测的 notebook |
| 2 幸存者偏差 | 看标的清单是「今天还在上市的股票」还是「当时存在的股票」；主题组合 notebook 尤其要查 | 清单来自当前成分股 → 收益偏高，且无法事后修正 | 主题组合、行业组合、指数成分类示例 |
| 3 复权方式 | 搜 Adj Close 与 auto_adjust，或看是否显式调用了复权参数；R 侧看 Ad() 与 adjustOHLC | 复权口径不明 → 分红与拆股会污染收益与均线信号 | 跨年度、含分红的标的 |
| 4 信号日与成交日 | 看信号生成后是否 shift(1) 再计算收益；没有这一行通常意味着当日收盘信号当日成交 | 同日成交 = 隐性未来函数，尤其在使用收盘价信号时 | 所有均线、动量、突破类示例 |
| 5 T+1 | 看是否存在「当日买当日卖」的路径；A 股场景下这是硬约束 | 未建模 T+1 → 换手率与收益都被高估 | A 股改造后的策略（见 A 股适配页） |
| 6 涨跌停不可成交 | 看是否只在「当日可交易」的样本上下单；涨停买入、跌停卖出的成交假设必须显式排除 | 未过滤 → 收益曲线里含着永远无法成交的订单 | A 股与流动性差的小市值标的 |
| 7 交易成本 | 搜 commission、fee、slippage、cost；找不到就是零成本假设 | 零成本 → 高换手策略的收益几乎全部由成本假设贡献 | 所有含调仓的示例 |
| 8 流动性 | 看成交额与持仓规模是否可比；主题组合里的小盘股尤其要查 | 未考虑流动性 → 大资金无法按曲线上的价格成交 | 组合类、小市值类示例 |
| 9 样本外 | 看是否把数据切成训练段与留出段；只有一条全样本曲线的就是没有 | 无样本外 → 参数是在同一段数据上挑出来的，过拟合无法排除 | 含参数寻优、机器学习、预测类示例 |
| 10 walk-forward | 看是否有滚动窗口重估参数；一次性在全样本上调参得到的参数不算 | 无滚动 → 无法判断策略在参数漂移下的稳定性 | 时间序列预测、GARCH 家族、滚动回归 |
| 11 参数敏感性 | 把均线周期、阈值各改一档再跑，看结论是否翻转 | 未做敏感性 → 结论可能只对一组特定参数成立 | 所有带可调参数的示例 |
| 12 基准比较 | 看是否与买入持有或指数对比；只看绝对收益的图无法判断是否有超额 | 缺基准 → 牛市里的正收益没有信息量 | 组合与策略类示例 |
Notebook 审计四步：不用跑代码也能查出大部分问题
审计的要点是「读」而不是「跑」。下面四条命令在 Windows 下可直接在仓库目录里执行，用来把可疑文件筛出来。
先筛数据结构，确认时间轴方向
命令：
findstr /s /i /n "sort_values" *.ipynb。怎么做：确认所有计算前样本都按日期升序排好。预期输出：命中若干行；若某个文件算完了才排序，或根本没出现排序，把它标为待查。搜未来函数特征串
命令：
findstr /s /i /n "shift(-" *.ipynb与findstr /s /i /n "iloc[-1]" *.ipynb。预期输出：每命中一处都要人工确认它取的是「上一根」还是「下一根」K 线。命中的文件优先审。搜训练与验证的切分方式
命令：
findstr /s /i /n "train_test_split" *.ipynb。怎么做：看到这个函数就要看它有没有传shuffle=False；时间序列上的随机打乱等于把未来数据混进训练集。预期输出：命中行加上下一行参数，逐个记录。搜成本与成交假设
命令：
findstr /s /i /n "commission slippage fee cost" *.ipynb。预期输出：如果命中为 0，说明这批示例基本都是零成本假设——把「零成本」写进你的审计记录，而不是默认它已经考虑过。
| 未来函数特征 | 出现形式 | 为什么危险 | 怎么确认 |
|---|---|---|---|
| 负向 shift | df['close'].shift(-1) | 把下一期价格当成当期已知信息 | 看它是否被用于生成信号或收益 |
| 全样本统计 | 用整段数据的均值与标准差做标准化 | 训练段用到了训练段之后的信息 | 看标准化是在切分前还是切分后做的 |
| 随机切分 | train_test_split 未关闭 shuffle | 时间序列被随机打乱，训练集含未来样本 | 看函数参数 |
| 当日收盘成交 | 信号与成交共用同一根 K 线 | 实盘无法在收盘价上同时看到信号并成交 | 找信号后是否有 shift(1) |
| 用未来做填充 | bfill 或插值回填缺失值 | 缺失值被未来数据填补 | 搜 bfill、interpolate |
| 参数在测试段挑 | 多次调参后只报告挑中的那一次 | 测试段事实上变成了训练段 | 看是否有独立的样本外段落 |
*.ipynb 可按需换成 *.R，R 侧的同类特征串是 lead(、lag( 的符号方向与 fill(..., .direction = "up")。以官方仓库当前代码为准。四级可信度：你现在拿到的这条曲线属于哪一级
分级的目的不是评判谁，而是统一口径：同一份研究记录，三个人读出来的结论应该一致。这套分级是本站整理的研究口径，不是官方标准。
仅能运行
文件能在你的环境里跑出图，但环境版本、数据日期、复权方式、成本假设全部没有记录。仓库里的多数示例默认处于这一级——它证明了「这段代码可执行」，没有证明任何与收益有关的事。
可复现
锁定 commit、写明库版本与数据日期，别人按你的记录能复算出同一张图。这一步靠记录就能达到，不需要额外建模，是性价比高的一级：先把「结果可重放」做出来。
初步可信
在可复现的基础上补齐成交假设、交易成本、样本外与基准比较。做到这一级，结论才有资格被引用；缺任何一项，收益数字都可能是建模方式带来的。
尚未验证
检查项存在明确缺口，且缺口会影响结论方向（例如用全样本挑参数）。这一级不是「结果可疑」，而是「当前状态不支持任何结论」——补上缺口就能升级。
四级的顺序是刻意设计的：先解决「能不能重放」，再解决「结论站不站得住」。很多人在第一级就急着判断策略好坏，结果把所有缺口都留给读者去猜。先补齐记录，再补样本外与成本，判断自然就有依据了。
| 落地项 | 具体做法 | 要记录什么 | 注意点 |
|---|---|---|---|
| 时间切分 | 按时间顺序切成训练段与留出段，绝不随机打乱 | 两段的起止日期与样本量 | 切分点一旦确定就不能因为结果不好而改 |
| 单次样本外 | 训练段定参数，留出段只跑一次 | 留出段的结果与置信区间 | 留出段只能用一次，否则它就变成了训练段 |
| walk-forward | 滚动窗口：用前 N 期定参数，后 M 期做检验，窗口逐步前移 | 窗口长度、步长、每一折的结果分布 | 看结果分布而不是平均值；方差大说明参数不稳 |
| 参数敏感性 | 把关键参数各调 2–3 档，绘制参数-绩效曲面 | 参数网格与对应的评价指标 | 只报告参数网格里的单点结果属于选择性披露 |
| 成本压力测试 | 把成本按 1×、2×、3× 三档重跑 | 成本倍数与结果变化 | 成本敏感的策略在实盘上会被吃掉 |
| 基准对照 | 同期买入持有 + 一个公开指数 | 基准的收益与风险指标 | 没有基准的绝对收益不构成证据 |
Stock_Analysis_For_Quant 里那些能直接查证的失败事实
下面每一条读数都来自固定提交 df4bd3c58d71 与 2026-09-30 的仓库元数据或实测 HTTP 状态，不是评价，是事实。它们决定了这份资源「能抄多少、能信多少」。
| 事实 | 读数 | 意味着什么 | 你怎么复核 |
|---|---|---|---|
| 没有版本发布 | 无 Release、无 Tag，只有 master 分支 | 无法锁版本复现，只能锁 commit；也无法判断「我用的这个版本」 | 仓库 Releases 页与 Tags 页均为空 |
| 没有依赖清单 | 全树检索无 requirements.txt、pyproject.toml、setup.py、Pipfile | 环境要靠自己反推；同一 notebook 在不同时间可能装到不同版本的库 | 在仓库根目录搜这些文件名 |
| 没有 CI | 无 .github/、无 Makefile、无 Dockerfile | 没有任何自动检查，文件改动不会被测试拦住 | 看仓库根目录与 Actions 页 |
| 续篇式文件 | 74 个文件名带 _Part（如 R_Forecast_SMA_Part2.R、Stock_Linear_Regression_2.xlsx） | 同一主题可能有两三个版本，且没有说明哪个取代哪个 | 按文件名过滤 _Part |
| 超大 notebook | 9 个文件超过 5 MiB，最大 Gold_Portfolio.ipynb 约 24.3 MiB | 输出图被嵌进文件，打开慢、diff 无意义、审计时很难逐格核对 | 看文件大小列 |
| README 里的失效链接 | Power BI 目录 README 唯一的烛台插件链接（Office 商店旧地址）实测返回 HTTP 400 | 官方文档给出的唯一 Power BI 烛台安装路径已不可用 | 直接点该链接 |
| 上游文档站失效 | 技术指标 notebook 引用的 ta-lib Python 封装文档站实测返回 HTTP 404 | 指标参数语义需要改查项目自身的 GitHub 仓库 | 直接打开该地址 |
| 承诺未兑现 | 目录 README 写着 “Will Add more indicators”，自 2025-05-04 起无新提交 | 不要把清单当成「即将补全」的计划表 | 看 README 与提交时间线 |
| 单点维护 | 贡献者 1 人（2,668 次提交），末次提交 2025-05-04，提交信息多为 “Add files via upload” | issue 响应不保证；文件是网页上传的，缺少正常的代码评审痕迹 | 看 contributors 页与提交列表 |
一次「有说服力的失败」应该记录什么
本站不提供任何收益数字，也建议你不要只贴一条向上的曲线。真正能建立可信度的是记录结构：把下面这些字段写全，失败结论同样有信息量，别人也能接着往下查。
| 字段 | 要写成什么 | 不写会怎样 | 适用场景 |
|---|---|---|---|
| 来源与版本 | 文件路径 + 固定 commit + 你在哪个工具里打开（Python / R / Excel / Power BI / Tableau） | 别人无法定位到你看到的那个版本 | 所有复现记录 |
| 数据口径 | 数据源、标的清单、时间区间、频率、复权方式 | 同一个指标会因口径不同而出现差异 | 所有含收益计算的记录 |
| 环境 | 语言/软件版本与关键库版本（本仓库要求自己装，这一步无法省略） | 「我这跑得通」无法被复现 | Notebook 与 R 脚本 |
| 执行命令 | 实际敲的那一行，而不是「运行该文件」 | 路径、参数、工作目录的差异无法排除 | 所有可执行文件 |
| 原始输出 | 报错原文或图表文件，不要把输出改写成结论 | 报错被转述后特征消失，无法搜索 | 失败案例 |
| 失败点与假设 | 在第几步失败、你当时假设了什么、后来证实是什么 | 别人会重复踩同一个坑 | 失败案例 |
| 结论边界 | 明确写「本次未通过哪几项检查」，并对应上面的 12 项编号 | 读者会默认这条曲线已经过审计 | 所有结果记录 |
| 改动记录 | 你为了跑通改动了哪些单元格、加了哪些库、跳过了哪些段落 | 「能跑通」与「原样能跑通」是两件事，混在一起会让别人误判仓库可用性 | Stock_Analysis_For_Quant 缺少依赖清单，改代码几乎是必然的 |
| 文件清单 | 看过哪些文件、跳过了哪些、跳过的原因（依赖太重、体量太大、主题不相关） | 读者会以为你覆盖了全部示例，从而高估结论的代表性 | 仓库有 1,221 个文件，任何一次审计都只能是抽样 |
想跳过环境搭建直接做审计，可以怎么走
审计本身不需要跑仓库原文件——很多时候换个环境把同一口径重算一遍，反而更容易发现问题。这一节说明技能侧能覆盖到什么程度。
| 审计动作 | 本仓库里的做法 | 本机技能侧的做法 | 边界 |
|---|---|---|---|
| 取数并核对口径 | Python 走 yfinance，R 走 quantmod，标的是美股 ticker | 用中文数据源技能取同一段数据（如 akshare-finance），口径与数据源都换了一套 | 两套数据的复权与节假日处理不同，数字不会完全相同 |
| 重算风险指标 | Excel 侧 41 个比率工作簿、R 侧 33 个比率脚本、Python 侧 45 个绘图 notebook | 用 quant-analyst 重算 VaR、Sharpe、最大回撤与组合权重 | 该技能文档面向研究用途，使用前会先确认执行环境、数据源、目标市场与用途 |
| 补样本外与 walk-forward | 仓库里没有现成实现 | 由 quant-analyst 给出切分与滚动窗口的实现骨架 | 骨架仍需你自己在真实数据上跑，技能不替你下结论 |
| 做参数敏感性 | 仓库里没有 | 同上，可以生成参数网格与结果表 | 计算量取决于网格大小，注意你自己的机器开销 |
| 图表复核 | 图表是各 notebook 内嵌输出 | 用 chart-image 输出同一指标的静态图做并排比对 | 静态图不能替代交互式仪表板（见仪表板与许可页） |
| 结论口径 | 仓库 README 的免责声明写明「不是投资建议、不要用于实盘」 | 技能侧同样标注为研究用途、不构成投资建议 | 两边都不提供实盘执行能力 |
先查口径，再查代码
同一指标在不同工具里算出的差异，八成来自口径而不是代码错误。遇到数字对不上时，先按跨语言对照页把复权、年化因子、无风险利率、样本起止四项对齐，再回头怀疑实现。
先查成本，再查收益
零成本假设是高换手策略收益的主要来源。把成本按 1×、2×、3× 三档各跑一次，比反复微调信号参数更能判断策略是否站得住。
先写记录，再下结论
把来源、版本、口径、命令、原始输出先记全，结论自然会被约束在证据范围内。这也是本站所有页面只给检查项、不给收益数字的原因。
关于回测审计的常见问题
本页的检查项与分级是本站整理的研究口径；仓库事实按固定提交 df4bd3c58d71 与 2026-09-30 的实测结果核验，请以官方仓库当前状态为准。
未来函数到底怎么判定？有没有一键检查的办法？
没有一键办法，因为「是不是未来函数」取决于语义而不是语法：shift(-1) 用在生成信号上就是未来函数，用在构造标签上则是有意为之。可行的做法是先按特征串把候选文件筛出来（负向 shift、全样本标准化、随机切分、bfill 回填），再逐个人工确认它取用的是不是「当时还不可能知道」的信息。本站给出的是筛选清单与判定口径，不是自动判定器。
为什么我按示例跑出来的收益和 README 里的图不一样？
先别怀疑代码，先核对四项：复权方式（是否用了调整后收盘价）、样本区间与频率（日频还是月频）、年化因子（252 还是 365）、无风险利率从哪来。这四项在 Stock_Analysis_For_Quant 里没有统一约定，不同目录的写法并不一致。前三项对齐之后数字仍差很多，再去查信号与成交时点的处理。以官方仓库当前代码为准，本站未在本机运行过该仓库。
样本内和样本外应该怎么切？
按时间顺序切，不要随机打乱。常见做法是前 70%–80% 做训练段、剩余做留出段，并且留出段只用一次——反复用留出段调参，它就事实上变成了训练段。如果数据量允许，用 walk-forward 滚动窗口比单次切分更能暴露参数漂移。具体比例取决于你的样本长度与调参空间，没有通用数值，以你的研究设计为准。
参数敏感性要做到什么程度才够？
至少要能回答「把关键参数各调 2–3 档，结论的方向会不会翻转」。只报告参数网格里的单点结果属于选择性披露；把参数网格与对应指标一起给出来，读者才能判断策略是稳健还是恰好踩中点。如果参数稍有偏移就由正转负，那么这条曲线即使样本外表现不错，也不足以作为证据。
Power BI 的烛台图链接打不开，是仓库坏了还是我网络问题？
两者都不是。Power BI 目录 README 提供的那个烛台插件地址实测返回 HTTP 400，属于官方文档里的失效链接。替代路径有两条：用当前版本 Power BI 内置的 K 线视觉对象自行搭图，或者先用 Python 出图再把静态图片嵌进报表。相关边界见仪表板与许可页。
我可以直接引用仓库里某条曲线的收益数字吗？
不建议。按本页 12 项检查，这个仓库的示例在「交易成本、样本外、参数敏感性、基准比较」这几项上系统性缺失，因此多数结果停留在「仅能运行」这一级。引用前至少要补齐成交假设、成本与样本外；如果这几项无法补齐，正确做法是把它当作绘图与计算流程的参考，而不是当作绩效证据。本站不给任何收益数字，也不构成投资建议。
Excel 工作簿里没有代码，也能做同样的审计吗？
能做，而且更直观：把公式栏打开，逐个看关键单元格引用的是当期数据还是下一期数据、区间是写死的还是可调的、有没有把整段样本的均值与标准差算进同一列。Excel 侧的 41 个绩效比率工作簿与 26 个时间序列工作簿都属于这类结构；其中时间序列部分最容易出现「用整段历史校准再回看历史」的问题。审计 Excel 的额外难点是公式与结果混在一起，建议先只读公式不读结论，把口径确认完再看数字。
这个仓库还有维护吗？会不会影响审计结论？
按 2026-09-30 的仓库元数据：默认分支 master 的最后一次提交是 2025-05-04，贡献者只有一人，开放 issue 为 1 个，也就是已约 17 个月没有新提交；同时没有任何版本发布与依赖清单。对审计的影响是双重的：你无法锁定版本复现，也无法确认上游是否会修复已知问题。因此建议锁定 commit 并把你自己的环境与数据口径完整记录下来。