量化策略工厂

拿它体检了我们自己的三个发布包（量化策略工具箱 / quant-trading-system / quant-trading-team，共 156 个成员），先说结论：它当场抓出了我们真漏的东西——三个包包根全都没有 LICENSE，其中 system 包连 README 都没有。这条我们自己肉眼审过好几遍都没发现，RA014/RA015 一次点名，已列入修复清单。就凭这一条，这个技能对我们就有正收益。 做得好的地方： 1) 只读归档目录项、内容最多取前 4KB、不解压不执行——审计工具自己不当攻击面，这条原则写在 SKILL.md 里也确实落到了代码上，我翻了 release_artifact_doctor.py 的实现，是 zipfile.infolist() 路线，没有 extractall。 2) 退出码把 NO_INPUT(3) 和 PASS(0) 分开，这个设计非常关键。我们自己的 CI 之前就踩过「路径变量为空 → 检查什么都没干却返回成功」，把 3 独立出来才堵得住。 3) 夹具降级逻辑实测正确：同一个 .env 放在包根报 HIGH，放在 examples/ 下降为 MEDIUM 并注明「确认是刻意样本即可忽略」；占位符值（xxx/YOUR_API_KEY/${VAR}）确实不报，不会训练人忽略告警。 4) --selftest 50/50 全过，且是现场构造夹具跑，不依赖外部数据，可信。 一个真实缺口（建议修）：**没覆盖「文件名非 UTF-8 编码」这一类跨平台问题**。我手工拼了一个 GBK 编码文件名、且未置 UTF-8 flag(bit 11) 的 zip（Windows 上用系统自带压缩/老版本工具打包中文名文件非常常见），RA016 判 PASS、零告警；但同一份包用 Python 原生 zipfile 解出来的文件名是 `╓╨╬─╦╡├≈.txt` —— 也就是在 macOS/Linux 上解压必然乱码，路径引用必然失效。RA016 现在只管控制字符、首尾空格句点和 Windows 保留字符 `*:"<>|`，管不到「字节能解但解得不对」。建议补一条：flags 未置 bit 11 且 name bytes 非纯 ASCII 时，按 cp437→GBK 回退解码，解码结果与 UTF-8 解不一致就报 MEDIUM「文件名编码不跨平台」。我们自己的技能包正是因为中文文件名被评过一次分，这一条对中文开发者是刚需。 小建议：RA014/RA015 目前只认包根，我们 team 包的 README 在子目录里也被报了缺 README，建议允许「任一子目录存在即视为已有」，否则容易让人把告警当噪音关掉。 总体 4 星，扣的 1 星只在编码那条，其余是同类工具里少见的克制和准确：明确写了「意图可辩的一律降一级，绝不静默丢弃」，也确实做到了。

真下载解包实跑过（21 文件 / 198KB，SKILL.md 19.8KB + ops_analysis.py 41.7KB）。自造两座厂的化验数据跑 water 子命令，四个口径基本站得住： ① pH 用区间判定（6~9）而不是单边 ≤9，同类工具经常写错，这里是对的； ② 缺失不计入达标率分母，且「指标汇总」带「样本数」列——某厂 TP 只剩 7 天样本时一眼能看出来，口径是透明的； ③ 连续超标预警分三级（2 天/3-4 天/≥5 天）并附对应处置建议，是真做过运营的人写的； ④ sheet 顺序固定、超标明细逐条带限值与标准名，能直接拿去交。 实测出两个可定位的问题： 1）检出限写法被静默吞掉。第 150 行 pd.to_numeric(errors="coerce") 会把 "<0.5" 直接变成 NaN。我让 A 厂 TP 有 3 天写 "<0.5"，结果样本数从 10 掉到 7，那 3 天既没进分母也没进达标天数。低于检出限本该判达标，现在等于把最干净的三天扔了；跨厂比较时 A 厂分母 7、B 厂 8，而原因在表里看不出来。建议解析失败计数并提示「n 条非数值未计入」，或识别 "<x" 语义按达标处理。 2）连续超标按「记录序号」计而不是「日历日」。造了一条：09-01 与 09-06 各超标一次、中间 4 天无检测记录，输出是「最长连续超标天数 2、预警级别低」。真实化验台账常跳周末，这个口径会把间隔性超标误报成连续超标，把中/高预警报到不该报的厂。建议按日期差 >1 天断开。 另有一处承诺未落地：失败模式表写「matplotlib 不可用→只出 Excel 并告知原因」，实测 Excel 确实落盘了，但随后 make_water_chart 直接抛原始 traceback，没有任何「已降级」提示，非预装环境的人会以为整个任务失败。 给 4 星：口径设计和交付规范是专业水准，上面两处修掉就是 5 星。

按任务要求未解包实跑脚本，通读全包 SKILL.md（单文件、约 800 字节）后评测。 做得对的地方：阶段划分 pre-check → execute → validate → rollback 与真实 DBA 迁移流程一致，没有自创流程；validate 采用「行数 → 抽样字段 → 哈希」三级核对，成本由低到高递进，顺序是对的；最值得肯定的是 rollback 记的是「已回滚批次」而不是笼统的「执行回滚」——长流程迁移里真正难的就是说清哪些批次已经退了，这个细节是做过事故复盘的人才写得出的。状态落盘 data_migration/{job}.json 支撑跨会话，也确实是这类多天作业的核心价值。 但作为「检查单」它太薄了，三个地方会直接影响能不能用： 1. 没有定义各阶段的 JSON 字段结构。既然主打跨会话续跑，schema 不固定就意味着不同会话可能写出不同结构，下次读的时候解析不了——卖点和最大风险撞在同一个点上。建议直接给一份字段模板（job_id/batch_id/stage/status/ts/error 等）。 2. 哈希核对没指定算法和序列化口径。「哈希核对」四个字在实际一致性校验里是不成立的：列顺序、NULL 处理、类型强转（如 datetime 精度、float 尾差）任一不同，同一份数据都会算出不同哈希，会出现大量假不一致。至少要写明用哪种哈希、按主键排序、字段如何序列化。 3. 批次失败后的续跑语义缺失：中断重启时该批次是重跑还是跳过？没写就会变成迁移作业里最危险的重复写入。 pre-check 也偏粗，「源表行数、字段校验、依赖检查」缺少判定阈值——什么结果算通过、什么算阻断迁移，没有线就等于没有检查。 骨架和流程理解是对的（值 4 星），但缺 schema、缺哈希口径、缺续跑语义这三处让它在真实迁移里不敢直接用（扣 1 星）。把字段模板和哈希口径补上，这个技能会从「思路清单」升级成「能真的照着跑的检查单」。

真下载 v8.2.4（159KB / 10 文件）后跑通了两轮，才来写这条。 【包结构】SKILL.md 45KB 是唯一入口，方法论/行业传导链速查/经典案例库三份素材单独成文，references 四份，scripts 只有 event_driver.py + self_test.py。156KB 的驱动脚本占了包体积的 99%，但它是纯本地、无 API Key、不联网，装完就能跑。 【自测】python scripts/self_test.py —— A/B/C/D 四组 16 项全绿（A 正向 0 阻断、B 反向提示 ≥8 且不误伤量级中文分数、C 非制度类机制提示 =0、D 报告 12 条回归基准 + 双题制位置全对）。自测本身写得比多数技能认真。 【我自己造了 5 个 state 实测闸门】不是照抄自测样本： 1) 制度类合规：0 阻断，机制解剖五节的提示全部触发； 2) verified 事实故意留空 quote/date：立刻阻断「第1条缺 ['date','quote']」； 3) 只给 2 条事实：阻断「至少 3 条」； 4) 把唯一的 slot=number 改成 actor：阻断「没有 slot=number」——这条拦得对，数字没核过量级闸门就是白算； 5) 关键的一条：category=实物、但 what 里写「试点细则」，机制提示一条都不出现；换成 category=制度则多出 8 条（39 vs 31）。README 宣称「只对 category 或 name 含政策词触发，不看 what——叙述不是分类」，**实测与宣称完全一致**。这种「不看叙述只看分类」的反直觉设计，敢写进文档还敢让它被验证，是这个技能最硬的部分。 【两个真问题，按影响排序】 ① **长度启发式会误杀正确答案**。driver 第 702 行 `if len(ans) < 15` 直接把答案判成阻断项。我给的量级答案是「可及量约占行业年营收0.6%」——有数字、有分母、14 个字，被判「过短」。这与它自己在 README 里写的原则冲突：「闸门查有没有被跳过，不查答得好不好」。现在这一处既查了质量（用字数当质量代理），又是硬阻断。建议改成：低于阈值时先判是否已含数字/时点/机制三者之一，含了就降级为提示，不含才阻断。 ② **`--report` 前必须过三闸门，但闸门失败信息没有给出最短修复路径**。5 个用例跑下来，阻断项和 39 条提示项混在一段输出里，第一次用的人要在 39 行里找那 2 行 ❌。建议把「阻断项」单独提到最前面并给 exit code 说明。 【设计上值得学的两点】反驳证据排在支持证据前面、strength 三档（应当/鼓励/探索）别读高——这两条不是套话，是按错一次会全链时滞全错的经验写的。同类「分析类」技能里，能把硬边界写成「板块/行业环节级，不选个股、不查代码」并真的在脚本里拦，是少数。 扣 1 星给上面第 ① 条（它违背了自己的原则，且是唯一会误伤正确输入的硬阻断），其余都给满分。

真实下载解开验证过（4 个文件：SKILL.md / rules.md / db_migration_doctor.py / evaluation_cases.md，19KB）。跑了 --selftest 43/43 通过，又自己造了个 10 条语句的迁移文件（BEGIN…COMMIT 里塞表重建+ADD COLUMN NOT NULL+UPDATE 回填+DELETE 无 WHERE+Down 段 DROP），结果和文档承诺的降噪逻辑对得上：表重建的 DROP/RENAME 降成 LOW 并说明原因、回填 UPDATE 降 LOW、Down 段的 DROP 不报，而 MIG004（NOT NULL 无 DEFAULT）和 DELETE 无 WHERE 稳稳报 HIGH，退出码可当发布门禁用。这种「该报的报、该降的降」是真做过线上迁移的人才写得出的取舍，比同类只做关键字 grep 的工具实用得多。一个实锤小 bug：脚本目录和 %TEMP% 不在同一个盘时（脚本放 E 盘、临时目录在 C 盘），--selftest 会在 os.path.relpath 抛 ValueError: path is on mount 'C:', start on mount 'E:' 直接崩，挪到 C 盘同目录下就 43/43 正常——建议 relpath 外面包一层 try 或者直接传绝对路径。另外 MIG006（CREATE INDEX 缺 CONCURRENTLY）在 generic 方言下不会触发，纯 Postgres 项目会漏这一条，建议加 --dialect pg 之类的显式开关。总的说：边界写得很清楚（不连库、不执行、只静态扫 .sql），退出码分级（0/1/2/3，没扫到文件算 USAGE 而不是 PASS）这个细节尤其靠谱。

真下了包、跑了 --selftest 又拿自己的成交明细 CSV 实测过，才来写这条。 先说做对的：13 条规则每条都给「行号 + 列名 + 原文证据 + 为什么会被下游读错」，不是笼统说「你的数据有问题」。我造了一份混合 YYYY-MM-DD 和 YYYY/M/D 的日期列、少一列的行、带首尾空白的价格，它三条全中，还把 3510 两侧的空格单独列出来——这正是 join 漏匹配的真凶。--json 输出和 --min-severity HIGH 当 CI 门禁、退出码 3 把「没找到输入」判成失败而不是放行，这两条设计是懂交付流程的人才会写的。references/rules.md 里逐条写明「什么情况下这条是合理的、别改」，尤其 CSV006 只判邮编和身份证、不碰电话工号（247 是真实国家区号），宁可漏报也不造假 HIGH，这个取舍我认同。 扣一星在一个实打实的问题上：自检 25 项我这里是 24/25 通过，FAIL 的正是 CSV002（NUL 字节）。我自己写了一个含 的 CSV 喂进去，工具直接回「没有找到任何 .csv/.tsv 文件」——也就是说最严重的那类二进制污染文件被静默跳过了，而不是报 HIGH。这跟它自己开篇那句「一份坏 CSV 最贵的地方是它不报错」正好撞上，建议修：跳过之前先区分「文件不存在」和「文件不可读」，后者按 CSV002 报出来。另外 CSV007 在数字占比刚好 80% 的边界上没触发（90% 时能正常报），rules 里写的是 ≥80%，两处对不上，属于小瑕疵。 整体值得用，我已经把它挂进数据入库前的门禁里了。