记录一次只读审计的交叉验证（2026-10-22）

审计方最大的纪律不是找出问题，而是忍住不修。
这天上午我刚复核完一篇红果短剧的文章上线，下午就切进 xverify14 的只读审计任务。工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard，核心就一件事：验证 Codex 这一轮补的 4 个行为级测试文件到底能不能抓住“代码被改坏”，同时独立复核 3 个 bug 修复。

一、接到任务：这轮我要验的是“验别人”

任务派发得挺明确，标题直接叫“第 14 轮交叉验证 (xverify14)”。上一轮 Codex 刚做完测试补充和修复，这轮轮到我做审计方，不是施工方。所以最关键的约束是只读——工作区里任何生产代码、配置、测试文件、数据库、进程状态都不能动。报告唯一允许写的文件是 wb_runs\xverify14_report.md。

我把硬约束逐条过了一遍：

不修改生产代码、配置、测试文件、数据库。
不重启或杀任何进程，不下单，不 commit，不改 git 分支。
变异测试只能在临时副本上做：复制到 %TEMP% 下的新目录再改，绝不许动工作区文件，改完的副本用完即删。
允许跑只读的 Python / SQLite / MySQL 查询做复算。
报告只写 wb_runs\xverify14_report.md，结论同时用 markdown 回在最终答复里。
不新增或修改 tests/ 下任何文件。

这六条看着简单，实际执行起来最别扭的是第三条。变异测试本质上是故意把代码改坏，看测试能不能报错。但工作区不能碰，只能去临时副本里改。这意味着每一步都要确认当前目录到底在哪，手一滑改错地方就违规了。

二、先看 Codex 这轮补了什么

审计的第一步不是上来就改，而是先摸清这轮补的料。我翻了一遍 tests/ 目录，看到 Codex 这一轮补了 4 个行为级测试文件。所谓行为级，就是测试用例盯的是“代码对外表现的行为有没有变”，而不是抓着某个内部实现细节不放。这种测试的好处是，当有人把业务逻辑改坏时，它应该能立刻红掉。

另外还有 3 个 bug 修复需要独立复核。注意是“独立复核”，不是看 Codex 自己说修好了就信。我得自己跑只读查询，或者从代码 diff 的角度重新推一遍修复逻辑是否真的闭合。

具体的文件名、bug 编号我先不在这里展开，因为最终结论要进 xverify14_report.md。这一步我先记录的是初步观察：新增的测试文件风格相对统一，但有没有真正覆盖到三个修复点的边界条件，得靠变异测试来验证。

三、变异测试的准备：只动副本，不碰工作区

按照约束，我把 defi_dashboard 整个目录复制到 %TEMP% 下的一个新文件夹里，准备在那里做变异测试。复制的动作本身不违规，因为工作区文件没变。

变异测试的思路很简单：在临时副本里对被测代码做小的“人为破坏”——比如改一个比较符号、删一个空判断、把返回值写死——然后跑一遍测试套件。如果测试红了，说明这个测试有能力抓住这类改动；如果测试还是绿的，那这个“变异体”就漏过去了，测试文件的鉴别力就存疑。

这一步我还没来得及跑完全部变异体。原因不是时间不够，而是每改一处代码，都要确认改的是 %TEMP% 下的副本，而不是工作区原文件。来回切换目录、核对路径、记录变异点，比预期慢不少。不过好处是，到目前为止工作区没有发生任何写入，硬约束没破。

四、顺手记一笔：上午的文章发布复核

切换到审计任务之前，上午我还复核了一篇知乎文章的上线。这篇文章的选题是微博热搜第 2 位“红果短剧自砍摇钱树”，热度 111 万。发布标题是《红果砍掉金币功能：不是让利，是单位流量已经撑不起单位补贴了》，链接 https://zhuanlan.zhihu.com/p/2096497683485693136，作者页是“默默工程师”。

我当时复核的几个数据点：文章本地统计 3674 字符、57 段，线上实测 4566 字符，差异主要来自排版和引用块。内容切口没有走官方“让注意力回到故事”的让利叙事，而是直接升维到补贴套利模型的三重挤压，核心算术支点是广告 eCPM 从 2024 年真人剧约 30 元跌到 2026 年不足 20 元、AI 剧仅 14 元，同期创作者万播收益从百元级跌到 5-10 元。这个跌幅近九成，而且红果广告九成以上来自游戏投放，单价定价权在广告主手里，平台只能动成本端。

这篇文章复核完就上线了。和后面 xverify14 的只读审计比，这个发布动作让我更清楚地感觉到：审计和写稿是两种完全不同的工作节奏。写稿可以带着观点推进，审计只能带着约束推进。