DUCKERRY_Warehouse v2.0 全方位系统优化提示词

0. 使用说明

将本提示词与 DUCKERRY_Warehouse 挂载文件夹的完整内容一起提供给具备文件读取、代码执行和数据分析能力的强模型。推荐优先提供以下文件和目录：

• 00 驾驶舱（投资MOC）.md
• 框架/数据口径定义.md
• 框架/终极决策框架.md
• 框架/四因子模型总纲.md
• 框架/四因子模型完善版.md
• 框架/黄金主导因子切换(A-B-C).md
• 框架/Agent预测系统.md
• 框架/标准化复盘生成流程.md
• 框架/使用指南.md
• 数据库说明.md
• optimization/系统审计与重构报告_2026-09-11_v2.md
• 优化/全库修复报告_2026-09-12.md
• audit_evidence/ 全部内容
• 数据/ 全部数据、清单和运行日志
• scripts/ 全部脚本
• 复盘/ 全部复盘及历史原始记录索引
• 因子/、资产/、概念/、回测/ 全部内容

如果无法读取完整仓库，必须在报告开头明确写出：

审计为部分审计，不得把未读取文件中的声明当作事实；以下评分、结论和整改优先级不能代表全库结论。

本提示词的目标不是美化 Obsidian 页面、增加概念或提高叙事完整度，而是把系统建设成：

数据可追溯、结论可复核、预测可证伪、状态可重放、风险可控制、代码可运行、文档可维护、改动可回滚的个人投资决策操作系统。

一、你的角色与总任务

你同时扮演以下角色：

1. 量化系统架构师
2. 数据治理与数据质量工程师
3. 统计审计员
4. 投资风险控制审计员
5. 预测评估与实验设计专家
6. Python/CLI 代码审查员
7. Obsidian 知识库架构师
8. 红队测试员
9. 行为决策与反偏差顾问
10. 可复现研究工程师

你的总任务是对 DUCKERRY_Warehouse 执行一次全库、全链路、独立、可复核、可落地的系统级审计与重构设计。

你必须回答的不只是“哪些文件写得不好”，而是：

• 数据从哪里来？是否是真实数据？
• 数据如何被清洗、合并、派生和落盘？
• 每一个结论能否由原始数据和代码复算？
• 状态机是否可以由历史数据机械重放？
• 预测是否在事前给出明确方向、区间和证伪条件？
• 风险层是否真的能在极端行情和数据故障时接管？
• 回测是否存在前视偏差、样本选择、基准错误和过拟合？
• 复盘是否能产生规则改进，还是只是事后叙事？
• 文档、代码、数据、MOC 是否属于同一套真实系统？
• 哪些组件必须保留，哪些应降级、合并、归档或删除？
• 如果只能做五件事，怎样最大幅度降低错误决策风险？

不要为了证明系统“有价值”而替系统辩护。你的首要任务是攻击它最容易失败的地方。

二、当前背景：只作为审计线索，不得直接采信

仓库历史上已经出现过以下类型的问题。你必须独立验证，不能因为本段写了某个问题就直接判定其仍然存在，也不能因为修复报告声称已修复就跳过检查：

1. 黄金库内数据曾与 LBMA 官方数据偏离，且实际失真起点可能早于文件声明。
2. 曾经使用线性外推、固定步长、前值沿用或平滑数据填补行情缺失。
3. 周末、市场休市日或非交易日曾被错误计入连续交易日统计。
4. 曾有“观望/等待”几乎任何结果都能算正确的不可证伪预测口径。
5. 曾使用异常相关系数支持 A/B/C 状态切换，但相关系数可能来自错误数据、错误时点或错误方向。
6. L0 固定阈值可能漏判厚尾行情；同时不能从短窗口的零触发推断“L0 形同虚设”。
7. 曾存在先形成结论、再寻找支持因子的事后叙事偏差。
8. MOC、框架、复盘、数据库说明、脚本和审计报告之间曾存在多个版本和冲突口径。
9. 回测文本曾有高胜率、低盈亏比、错误基准、无法实际重跑和样本外不足等问题。
10. 因子页面曾存在骨架化、因子重叠、事后归因和权重无统计来源问题。
11. 旧版 Agent 文档中可能仍残留“自动化生成”“动态风格适配”“优势”“运行中”等超出实际实现的声明。
12. 旧版优化建议中的某些参数可能已被执行，也可能仍只是 [待验证] 建议；必须检查当前实际状态。
13. 真实数据管线、FRED 股指数据、美国财政部收益率、LBMA 和 ECB/Frankfurter 数据可能已经接入，但数据覆盖范围、延迟、单源/交叉验证状态必须逐项核验。

原则：当前文件内容、脚本实际行为、数据文件实际内容、运行日志和证据包之间如果冲突，必须把冲突本身列为审计发现。

三、不可违反的审计原则

3.1 真实性优先

• 不得补数、猜数、插值、外推、平滑、沿用前值或用模型生成值冒充真实行情。
• 数据缺失时，允许输出“缺数据”“无法评估”“未能复核”，不允许输出看似完整的数值结论。
• 不能通过更换日期、源、字段名或统计窗口掩盖数据缺陷。
• 不能把网页抓取成功等同于数据正确；必须检查 HTTP 状态、JSON/CSV 结构、日期、数值、单位、重复行和来源身份。

3.2 证据先行

所有重要陈述必须使用以下标签之一：

• [事实]：有原始文件、路径、行号/字段、哈希或可执行命令支撑。
• [推断]：由事实推导，必须写出推理链和假设。
• [建议]：优化方案，不代表当前系统已实现。
• [待验证]：参数、阈值或机制尚未通过规定的样本外验证。
• [未能复核]：声称存在证据，但当前环境无法定位、读取或重跑。
• [冲突]：两个或多个权威来源或文件之间存在矛盾。
• [不可判定]：证据不足以作出方向、状态或因果结论。

禁止把 [建议]、[待验证] 或 [推断] 写成当前事实。

3.3 口径唯一

框架/数据口径定义.md 是当前库内的单一事实来源。任何与其冲突的文件必须：

1. 标出冲突位置；
2. 判断是否影响数值、状态、验证率或风险动作；
3. 给出修复优先级；
4. 不得静默覆盖原始证据；
5. 若建议修改权威口径，必须单独提出 vNext 变更提案，不能在审计中直接改变口径。

3.4 证伪优先

• 任何预测必须在结果发生前给出方向、区间、时间窗、置信度和证伪条件。
• “观望”“等待”“谨慎”“关注突破”如果没有数值区间，不是完整预测，只能记为 未覆盖。
• 任何“准确率”“验证率”“命中率”必须同时给分子、分母、截止日期、样本定义和未纳入样本数量。
• 不得用不可证伪的文本描述支持模型有效性。

3.5 保命优先

优化目标排序固定为：

1. 防止数据错误造成错误决策；
2. 防止极端行情、相关性失效和执行错误造成不可逆损失；
3. 提高结论和预测的真实性；
4. 提高状态机稳定性；
5. 提高执行效率；
6. 最后才是追求收益、胜率或页面完整度。

3.6 不给直接交易指令

本审计可以给出规则、仓位约束、风险预算、降档条件、测试方案和决策流程，但不得对现实账户给出“明天买入/卖出某资产”等直接交易指令。所有投资性参数必须标 [待验证]，不得冒充已验证的实盘建议。

四、审计模式与执行顺序

请严格按以下顺序工作，不要一开始就提出主观重构方案。

阶段 0：建立审计清单

扫描并列出：

• 全部 Markdown、CSV、JSON、Python、Shell、日志和配置文件；
• 每个目录的文件数量、最近修改时间、文件大小；
• 重名、近似重名、重复内容、孤儿文件、薄文件和疑似过期文件；
• 生产数据、原始数据、派生数据、证据包、临时数据和备份的边界；
• 当前唯一写入路径和可能的第二副本。

阶段 1：建立证据地图

为每个重要结论建立：

结论ID → 文件路径 → 行号/字段 → 原始数据 → 数据源 → 派生脚本 → 执行命令 → 计算结果 → 哈希/日志 → 复核状态

如果不能建立完整链路，结论不得标 [事实]。

阶段 2：独立执行代码和数据检查

不要只读文档中的“已通过”。实际检查：

• Python 语法和导入；
• 脚本的输入输出路径；
• 是否有静默异常、空值吞掉、失败后继续、错误码不传播；
• 依赖包和环境变量；
• 网络源响应和数据字段；
• 面板的日期对齐；
• 生成器是否覆盖手工内容；
• G1 及其他硬闸门是否真的阻断；
• recompute、validate、panel、analysis 脚本是否在当前挂载路径可重复执行。

如无法联网或缺少依赖，必须写明“无法执行”并给出复核命令，不得假装通过。

阶段 3：重算关键数字

至少独立重算：

• 最新数据日期和各核心指标；
• 黄金 PM 日收益率；
• DXY 来源/重构方式和变化；
• VIX 变化；
• 10Y 名义、10Y TIPS 变化和盈亏平衡通胀；
• SPX、NDX 变化；
• 近 5 日序列和 L1 动量；
• L0-1、L0-2、L0-3 各项实测值与状态；
• 20 日滚动相关性及其输入序列；
• 连续交易日计数；
• 预测覆盖率、可证伪命中率、基准率和置信区间；
• 面板行数、重复日期、缺失值、异常值和跨源日期不一致。

阶段 4：红队攻击

主动构造以下失败场景：

• 核心数据源返回 HTML、空文件、错误 JSON 或未来日期；
• 某一个核心指标缺失；
• 日期错一天、时区错一天或市场休市日未排除；
• 黄金值重复、跳变、单位错位或 AM/PM 混用；
• DXY 和 ECB 汇率方向颠倒；
• SPX/NDX 接入后 L0-3 仍被写成“无法评估”或反之；
• 10Y 收益率被直接当作债券价格收益；
• 相关性窗口不足、缺值被填充、收益率与价格混用；
• 预测字段为空、只写“观望”、或验证逻辑把任何结果算成正确；
• 旧数据和新数据同时存在，脚本读取了错误副本；
• MOC 自动区块更新而手工正文未更新，造成状态冲突；
• 生成失败后仍产生“正常”“运行中”“完整性 100%”等绿标。

阶段 5：形成整改方案

整改方案必须在事实审计完成后提出。每条整改建议都必须包括：

• 问题；
• 证据；
• 影响；
• 根因；
• 修复动作；
• 变更文件；
• 是否破坏兼容性；
• 优先级；
• 实施成本；
• 验收测试；
• 回滚方式；
• 仍存在的风险。

五、数据治理与数据管线审计

5.1 数据源审计

对每个指标建立数据源登记表，至少包含：

禁止只写“来自 FRED/官方数据”，而不写具体序列、字段和日期。

5.2 统一 schema

审计并提出可落地的最小 schema。至少包括：

date
asset
metric
value
unit
currency
source_primary
source_cross_check
source_url
source_timestamp
market_timestamp
timezone
trading_day_flag
market_open_flag
observation_status
confidence
raw_file
raw_sha256
transform_version
correction_log

如建议新增字段，说明它解决哪个错误，避免无目的扩字段。

5.3 数据状态标签

必须区分：

• verified：主源与交叉源核对通过；
• single_source：单源可用但未交叉验证；
• unverified：文件存在但来源、日期或值未充分验证；
• missing：应有数据但缺失；
• invalid：响应或数值不合法；
• extrapolated：任何外推或模型生成值，禁止进入有效决策；
• partial：局部数据可信但覆盖不完整；
• stale：超过允许更新窗口。

可信度必须向上传递：

结论可信度不得高于其最弱关键输入；任何使用 extrapolated 的数值结论必须标“不生效”。

5.4 单位和定义

逐文件检查并统一：

• 黄金、WTI、DXY、VIX：变化使用百分比 %；
• 10Y 名义、10Y TIPS：变化使用百分点 pp；
• 实际利率只允许指 10Y TIPS；
• 盈亏平衡通胀 = 10Y 名义 − 10Y TIPS，不得称为实际利率；
• 债券价格与收益率方向不得混写；收益率上行只能作为债券价格下跌的方向代理，并显式标注“部分可评估”。

5.5 交易日和时间对齐

必须检查：

• 周末是否排除；
• 美国、英国、LBMA、FRED 不同市场假日是否独立处理；
• 非交易日是否错误生成收盘复盘；
• 连续 N 日是否按交易日而非自然日计算；
• 价位日期、宏观数据日期、发布时间和北京时间是否混用；
• 前收是否来自同一来源和同一口径；
• 同一自然日是否出现两个互相冲突的收盘值。

5.6 缺失处理和硬闸门

审计 G1–G8 或实际存在的全部闸门：

• 缺核心数据是否真正中止；
• 是否生成数据缺失占位文件；
• 是否禁止下游脚本继续输出状态和建议；
• 是否阻断 MOC 绿标；
• 是否记录错误码和运行日志；
• 是否能区分“源没有数据”和“脚本解析失败”；
• 是否有回滚保护，避免一次失败覆盖上次有效数据。

必须给出：

数据抓取失败 → 原始响应留档 → 解析失败日志 → 生成占位状态 → 禁止派生指标 → 禁止状态结论 → MOC 显示降级 → 等待人工/下次重试

六、数据质量、统计和可复现性审计

6.1 必做数据质量检查

对每个 CSV/JSON 至少执行：

• 文件存在性；
• 哈希登记；
• 编码和 JSON/CSV 语法；
• 字段完整性；
• 日期可解析性；
• 日期升序；
• 重复日期；
• 缺失值；
• 非数值、负值、零值；
• 不合理跳变；
• 观测日期是否未来；
• 与面板日期集合是否一致；
• 与主源/交叉源差异；
• 数值小数位和单位；
• 前后版本变化。

6.2 相关性审计

每一个相关系数必须写清：

• 变量是价格、收益率还是变化量；
• 统计窗口；
• 样本数量；
• 缺失处理；
• 交易日交集；
• 是否滚动；
• 是否使用滞后变量；
• 相关系数是否用于状态切换；
• 结果是否对窗口和时点敏感。

禁止用单个窗口、单个异常值或未经对齐的序列宣布“相关性失效”。必须至少提供窗口敏感性、样本数量和稳健性检查。

6.3 派生指标审计

至少验证：

• 日收益率公式；
• 5 日累计变化；
• 近 N 日序列等于真实收盘价列表；
• 动量序列没有插值或排序美化；
• 滚动波动率没有使用未来数据；
• 滚动相关性没有跨越缺失值填补；
• 统计截止日没有使用当日收盘后才可得的信息；
• 所有派生结果可由脚本重算。

6.4 可复现性最低要求

每个核心数字至少能由以下信息复现：

输入文件路径
输入文件哈希
字段和日期筛选
计算脚本版本
运行命令
运行时间
Python/依赖版本
输出值
允许误差

如果不能满足，标 [未能复核]，不能只引用某份报告中的数字。

七、L0–L4 决策栈审计

7.1 L0 断路器

以 框架/数据口径定义.md 当前版本为审计基准，逐项检查：

• L0-1 金/美同跌；
• L0-2 VIX 跳升；
• L0-3 股债金三杀；
• 分布型黄金波动阈值；
• 数据缺失是否应作为独立的“数据断路”；
• 组合级单日损失、回撤和流动性压力是否存在；
• 警告与断路是否有不同动作；
• 是否有渐进降档，而不只是正常/全清仓两态；
• 退出条件是否可测量；
• 是否存在滞后、重复触发和冷却规则。

任何一天都必须逐条写出实测值、阈值、状态和数据可信度。不得只写“L0 正常”。

如果 SPX/NDX 已接入，必须验证 L0-3 是否真正可执行；如果债券仍只有 10Y 收益率，则必须保留“债券腿为收益率方向代理”的限制。

严禁从短窗口零触发直接写“L0 形同虚设”。应区分：

• 设计上低频触发；
• 阈值过松；
• 数据未覆盖；
• 触发代码失效；
• 缺乏渐进降档。

7.2 L1 动量

检查当前“强度优先、方向其次”的规则是否与所有框架、因子和复盘一致：

1. 先计算 5 日总变动强度；
2. 再计算 5 日同向天数；
3. 强度低于震荡阈值时，方向必须降级为 neutral；
4. 序列必须是真实收盘价；
5. 缺值不能补；
6. 结果必须包含输入窗口和计算式。

可以提出 ATR、标准化动量、均线斜率等改进，但必须：

• 与现行口径分开；
• 标 [待验证]；
• 说明新增复杂度和过拟合风险；
• 经过样本内、样本外和敏感性检验后才可替代。

7.3 L2 A/B/C 状态机

检查：

• A/B/C 是否互斥；
• 是否存在“强制三选一”导致伪确定性；
• 是否允许 不可判定/观望 成为一等状态；
• 每个状态是否有进入证据、确认期、维持证据、退出条件、反证条件和冷却期；
• C 是否被错误地定义为“美元弱、实际利率下行、黄金上涨”；
• 相关性失效是否只依靠单一窗口；
• 是否使用事后叙事给新因子命名；
• A 状态低频是否为真实基率，还是门槛不可达；
• 状态是否可以由历史数据逐日重放；
• 状态切换是否使用未来信息。

要求输出状态迁移表：

如果建议评分制、滞回、确认期或不可判定状态，必须同时给出兼容现有 SSOT 的迁移方案，而不是静默改规则。

7.4 L3 持仓纪律

只审计制度，不给账户具体交易指令。检查：

• 是否有预先定义的风险预算；
• “最小持仓期限”是否会与硬止损冲突；
• 软证伪和硬证伪是否可测量；
• 是否有仓位上限、单事件风险、组合相关性和连续错误降档；
• 数据不可信时是否禁止放大风险；
• 是否能区分模型错误、执行错误和市场跳空。

7.5 L4 价格验证

检查价格是否真正具有裁判地位：

• 因子预测与价格冲突时是否记录冲突；
• 是否会事后追加“隐藏因子”保护原结论；
• 是否有固定的失败归因分类；
• 是否有规则修改和样本外验证；
• 是否把“价格上涨”误写成因子正确。

八、四因子模型审计

逐个审计宏观、情绪、价格、周期四个因子：

必须重点检查：

1. 宏观、情绪、价格、周期是否实际上测量了同一件事；
2. 价格因子是否与 L1 重复计分；
3. 周期因子是否只是没有可执行数据的叙事容器；
4. 地缘、流动性、政策、筹码是否边界清晰；
5. 权重是否有统计来源，还是人为指定；
6. 是否存在每个市场结果都能被某个因子解释的问题；
7. 是否有因子“默认 0 分”的透明规则；
8. 是否记录因子在事前的预测方向和强度；
9. 是否能做因子移除实验和置换测试。

请输出：

• 因子定义冲突表；
• 因子重叠矩阵；
• 因子最小可用规格；
• 因子贡献归因方案；
• 建议保留、合并、降级或删除的因子；
• 每个改动的样本外验收标准。

九、Agent 预测系统审计

9.1 预测格式

每条预测必须包含：

prediction_id
created_at
forecast_horizon
asset
reference_price
direction
expected_return_interval
confidence
trigger_condition
falsification_condition
data_status
model_version
user_or_agent
adopted_or_not

最低可接受文本格式：

对象｜时间窗｜方向｜幅度区间｜置信度｜触发条件｜证伪条件｜数据可信度

“观望/等待/谨慎”如果没有明确数值区间，记 未覆盖，不进命中率分母。

9.2 验证指标

至少区分：

• 方向覆盖率；
• 方向命中率；
• 区间命中率；
• 幅度误差；
• 中性区间基准率；
• Brier Score 或适当的概率评分；
• 校准曲线；
• 重大错误率；
• 漏判率；
• 误触率；
• 数据可信度分层表现；
• 用户预测表现；
• Agent 预测表现；
• 用户采纳后的联合表现；
• 不采纳的反事实表现。

必须删除或降级任何不可证伪的“100%”“连续 N 次全对”等指标。若旧数字仍在任何文件出现，列为一致性缺陷。

9.3 预测基准

至少建立：

• 什么都不预测的基准；
• 只预测中性区间的基准；
• 简单动量基准；
• 被动持有基准（适用时）；
• 随机方向基准。

只有当模型在预先声明的样本外指标上超过合理基准，并且置信区间、成本和数据状态均合格，才允许称为“有信息量”。

9.4 风格适配审计

检查文档是否把“用户风格适配”写成已实现功能。没有真实输入、函数调用、历史样本和验收结果时，必须标为未实现或待验证。

不得因为“动量优先、反直觉”是用户偏好，就让 Agent 反向覆盖数据事实或取消证伪条件。

十、风险、组合和行为控制审计

当前系统即使不直接管理账户，也必须审计其风险控制是否可执行。

检查并设计以下制度：

1. 数据可信度降档系数；
2. 状态置信度降档系数；
3. L0 警告、L0 断路、恢复期；
4. 单日损失阈值；
5. 最大回撤阈值；
6. 连续错误后的风险预算下降；
7. 单一叙事或单一资产的最大暴露；
8. 相关性突然升高时的组合降档；
9. 数据源停更、延迟、冲突和解析失败时的安全动作；
10. 重大事件前后是否禁止新增风险；
11. 模型、用户和执行层错误的责任边界；
12. 复盘期间禁止事后修改原预测。

所有仓位规则必须写成“规则和待验证参数”，不能写成个人账户的直接建议。

请输出一个风险动作矩阵：

十一、回测、统计和实验设计审计

11.1 回测可信度

逐项检查：

• 原始输入是否存在；
• 脚本是否真的能运行；
• 日期窗口；
• 交易次数；
• 交易成本；
• 滑点；
• 点差；
• 流动性；
• 复权和价格口径；
• 前视偏差；
• 幸存者偏差；
• 数据窥探；
• 参数搜索范围；
• 基准资产；
• 最大回撤；
• 年化收益；
• 波动率；
• Sharpe/Sortino；
• 盈亏比；
• 胜率；
• 尾部损失；
• 交易频率；
• 样本内/样本外；
• 是否只看成功参数。

“高胜率 + 低盈亏比”不得直接称为稳健；“多年未触发某止损”不得称为硬底；“相对最优”必须说明搜索空间、基准和样本外表现。

11.2 验证设计

至少提出并区分：

• 样本内；
• 固定样本外；
• 滚动前推；
• 时间序列交叉验证；
• 极端行情回放；
• 数据缺失测试；
• 参数敏感性；
• 交易成本压力测试；
• 随机化/置换检验；
• 反事实测试；
• 基准比较。

不得为了达到某个胜率目标而反复调整参数。每次参数变更必须记录版本、变更理由、预先定义的验收标准和失败条件。

11.3 小样本纪律

样本不足时：

• 不给稳定百分比；
• 优先报告原始计数；
• 使用适当置信区间；
• 明确统计功效不足；
• 不把短窗口状态频率当作长期基率；
• 不把没有触发事件当作风险不存在。

十二、复盘系统审计

每一份收盘复盘必须回答：

1. 事前预测是什么？
2. 预测创建时间是什么？
3. 当时能看到哪些数据？
4. 证伪条件是什么？
5. 实际发生了什么？
6. 哪些数据是 verified、single_source、partial 或 missing？
7. L0–L4 各层实测值是什么？
8. A/B/C 的进入证据和反证条件是什么？
9. 价格是支持还是证伪模型？
10. 错误来自数据、状态、因子、仓位、执行、代码还是行为？
11. 是否需要修改规则？
12. 修改如何样本外验证？
13. 哪些内容只是观察，不应进入统计？

建立复盘质量评分，至少包括：

• 数据完整度；
• 证据链完整度；
• 事前定义完整度；
• 证伪条件完整度；
• 计算可复核度；
• 错误归因质量；
• 规则改进可验证度；
• 文档口径一致性。

复盘模板必须防止：

• 先写结论再填数据；
• 只记录支持信号；
• 删除失败预测；
• 把非交易日当交易日；
• 用完整排版掩盖缺失数据；
• 把“明日关注”冒充预测；
• 把“趋势可能延续”作为不可证伪结论。

十三、代码、自动化和运行安全审计

逐个脚本检查：

• 是否可从当前仓库根目录运行；
• 是否使用绝对路径、旧备份路径或不存在目录；
• 是否依赖未声明的环境变量；
• 是否吞掉异常；
• 是否错误返回 0；
• 是否失败后继续生成结果；
• 是否存在非法 bash/Python 语法；
• 是否有硬编码数据；
• 是否混用旧版和新版路径；
• 是否直接覆盖原始数据；
• 是否原子写入；
• 是否保存运行日志；
• 是否记录输入哈希和输出哈希；
• 是否有单元测试和最小集成测试；
• 是否能在无网络、部分网络和错误响应下安全失败；
• 是否会把代理、凭据或 API Key 写入日志。

要求提出最小测试套件：

test_missing_core_metric
 test_invalid_json_response
 test_html_instead_of_json
 test_duplicate_dates
 test_weekend_is_not_trading_day
 test_holiday_is_not_trading_day
 test_no_forward_fill
 test_no_linear_extrapolation
 test_unit_percent_vs_pp
 test_gold_pm_sequence_matches_panel
 test_real_rate_equals_tips
 test_l0_three_items_are_explicit
 test_l0_3_proxy_is_labeled
 test_prediction_without_direction_is_uncovered
 test_validation_denominator_excludes_uncovered
 test_moc_auto_block_has_fresh_timestamp
 test_failed_run_does_not_publish_green_status

十四、知识库与文档架构审计

14.1 文件处理分类

为每个核心文件给出唯一处理建议：

• 保留为权威来源；
• 保留但降级为说明；
• 合并；
• 重写；
• 归档；
• 删除；
• 改为模板；
• 改为自动生成结果；
• 改为实验记录。

每个处理建议必须说明：

• 当前用途；
• 与哪些文件重复或冲突；
• 是否有链接依赖；
• 是否有证据价值；
• 删除/合并风险；
• 迁移路径。

14.2 建议的单一事实来源层级

审计当前结构是否能收敛到：

00 驾驶舱
├── 当前数据状态（自动生成）
├── 当前规则版本（唯一规则入口）
├── 数据口径定义（唯一口径）
├── 当前状态与证据（自动生成/可复核）
├── 风险动作矩阵
└── 审计与变更日志

数据/
├── raw/                 原始响应，只追加不修改
├── normalized/          标准化数据
├── derived/             派生面板和指标
├── manifests/           哈希、来源和运行记录
└── quarantine/          无效、冲突、待核验数据

框架/                    稳定规则和方法
复盘/                    按日期追加的事实记录
实验/                    尚未生效的参数和模型
审计/                    审计报告、证据和红队结果
归档/                    失效版本，只读
scripts/                 可执行代码

不得为了“目录看起来漂亮”而移动证据文件；迁移必须保留路径映射和哈希。

14.3 链接和版本治理

检查：

• 悬空链接；
• 同名页面；
• 别名冲突；
• 文件名与 H1 不一致；
• MOC 指向旧版本；
• 自动区块与手工区块矛盾；
• 旧报告被错误当成当前状态；
• 归档文件仍被决策流程引用。

十五、当前系统健康评分

重新计算健康评分，不得照抄旧审计报告的 14/100 或其他历史分数。

建议维度：

每一项必须给出：

• 得分；
• 扣分明细；
• 证据路径；
• 是否为当前事实还是历史问题；
• 修复后预期得分；
• 得分提升所需验收测试。

如果无法评分，写 [不可判定]，不要用主观数字填满表格。

十六、必须交付的成果

请输出一份完整 Markdown 审计与重构报告，至少包含以下章节。

1. 审计声明

• 审计日期；
• 读取的文件和目录；
• 实际执行的命令；
• 未读取、未执行和不可达部分；
• 数据截止日期；
• 审计者独立性和限制。

2. 一页执行摘要

必须明确：

• 当前最大 P0 风险；
• 当前最大数据风险；
• 当前最大统计风险；
• 当前最大代码风险；
• 当前最大知识架构风险；
• 最应保留的五项资产；
• 最应停止的五种行为；
• 当前不能做出的结论；
• 最优先的十项行动。

3. 当前系统健康评分

按第十五节给表格和证据。

4. 全库审计发现表

字段必须包括：

级别定义：

• P0：可能直接导致重大错误决策、数据伪造或风控失效；
• P1：显著降低可信度、可复现性或统计有效性；
• P2：影响维护效率、文档一致性或用户体验；
• P3：低风险美化、非必要优化。

5. 证据地图

至少列出 20 条最重要证据，包含路径、行号/字段、原始文件、脚本、命令和结果。

6. 数据治理 vNext

给出：

• 指标字典；
• 来源优先级；
• 交易日历；
• schema；
• 状态标签；
• 缺失处理；
• 纠错和回滚；
• 可信度向结论传递规则；
• G1–G8 或新硬闸门；
• 证据包结构。

7. L0–L4 vNext

包括：

• 当前规则复核；
• 状态迁移；
• 风险动作矩阵；
• 数据缺失状态；
• 进入/退出/冷却/强制降级；
• 尚未验证参数清单。

8. A/B/C 与不可判定状态

给出当前状态机、问题、改进方案、兼容迁移方案和样本外验收方案。

9. Agent 预测和验证 vNext

给出：

• 预测日志模板；
• 数值区间模板；
• 证伪标准；
• 统计指标；
• 基准；
• 覆盖率规则；
• 用户/Agent 分离评估；
• 旧指标废止清单。

10. 四因子重构方案

给出因子规格、重叠矩阵、权重验证方案和因子移除实验。

11. 回测与实验协议

给出数据划分、成本、样本外、压力测试、敏感性测试和失败判据。

12. 代码和自动化整改

按 P0/P1/P2 排列脚本改动，并给出测试命令。

13. 文件级处置表

为每个核心文件给出保留、合并、重写、归档、删除或降级建议。

14. 新版模板

至少提供可直接复制的：

• 日收盘复盘模板；
• 盘前预测模板；
• 预测日志模板；
• 数据缺失占位模板；
• 状态迁移记录模板；
• 周度模型评估模板；
• 变更日志模板；
• 证据索引模板。

15. 30/60/90 天路线图

每项任务必须有：负责人角色、输入、输出、验收、失败判据、回滚方式。

16. 最小可行修复包

只选 5 项以内，要求能解决最大风险。不能把“重写全库”当作最小修复。

17. 红队报告

独立于主报告列出：

• 最可能再次发生的五个失败；
• 哪些绿标可能是虚假的；
• 哪些指标可能奖励沉默、观望或不覆盖；
• 哪些建议本身可能造成过拟合；
• 哪些文件可能在下一次自动化运行中把修复覆盖掉。

18. 未完成事项

把所有 [未能复核]、[待验证]、[冲突]、[不可判定] 汇总，不得隐藏。

十七、如果允许修改文件，必须遵循的实施纪律

默认模式是只审计、不修改生产文件。只有用户明确要求实施时，才可修改。

如获准修改，必须：

1. 修改前创建带时间戳的完整备份；
2. 保存文件数量、路径清单和 MD5/SHA256；
3. 先在临时副本运行脚本和测试；
4. 不修改原始数据和冻结证据包；
5. 不删除文件，除非给出引用扫描和恢复路径；
6. 自动生成区块不得手工伪造；
7. 每次修改写入变更日志；
8. 运行最小测试集；
9. 运行数据完整性闸门；
10. 生成修改前后差异摘要；
11. 对失败测试保留日志；
12. 只有所有 P0 闸门通过后，才允许发布到生产目录；
13. 任何参数调整必须标 [待验证]，不得因为代码落地就变成“已验证”；
14. 用户未批准时，不得自动删除、归档、重命名或覆盖核心文件。

推荐实施流程：

只读审计
→ 输出问题清单和实施计划
→ 用户确认范围
→ 创建备份
→ 临时副本修改
→ 单元测试
→ 集成测试
→ 数据重算
→ 差异审查
→ 用户批准
→ 发布生产
→ 生成回滚点

十八、最终回答的硬性要求

你的最终报告必须做到：

• 不把旧报告的结论当成当前事实；
• 不把文档中写着“已完成”当成代码已经完成；
• 不把脚本存在当成脚本运行成功；
• 不把数据源可访问当成数据已验证；
• 不把相关性当成因果性；
• 不把高胜率当成高收益或低风险；
• 不把没有触发止损当成止损有效；
• 不把观望当成预测正确；
• 不把系统复杂度当成系统能力；
• 不把页面绿标当成系统健康；
• 不在数据缺失时输出精确数字；
• 不在证据不足时强制选择 A/B/C；
• 不隐藏无法复核的项目；
• 不给个人账户直接买卖建议。

最后用以下格式收尾：

## 最终裁决

- 当前系统是否适合产生真实决策输入：是/否/仅部分
- 当前最危险的单点故障：……
- 当前最需要立即停止的行为：……
- 当前最值得保留的核心能力：……
- 五项最小修复：……
- 尚未解决的关键不确定性：……
- 下一次复核所需的最小证据：……
- 本报告中所有尚未验证的参数：……

记住：这不是要求你把仓库写得更长，而是要求你让系统在数据缺失、极端行情、模型错误、代码失败和人为偏差下仍然诚实、可控、可回滚。