Rocky3

把教材/讲义/思维导图变成「考点问法→口诀→标准答案」映射卡片的思路很对症，字段表把 12 个字段分必填和选填两级写清楚，有真题填 exam+pins、没真题填 stars+reason 且两者不要混填，pins 的个数必须等于 exam 标签数这种约束直接写进了表里，能避免标注造假。质量红线七条是全篇最值钱的部分：真题必须真实不把热点预估当考次、案例/论文/综合科目分开标、同一知识点不同版本的口诀要合并否则卡片会互相打架、纯计算和纯定义题不混进案例映射、过程理解类降一颗星、口诀必须可逆、字符串里的引号一律用「」不能用 ASCII 双引号——最后这条是踩过坑的。我实跑了一遍 scripts/build_cards.py：拿包内 example_cards.json 生成 8 张卡、3 个分类、9.2KB 的单文件 HTML，正常输出没有报错；又拿一份边界数据专门测，cat 值不在 categories 里时脚本直接报错退出并提示「可用: A」，这种硬校验比生成后人工检查省事；JSON 里的 ASCII 双引号和反斜杠经过 JSON→HTML 注入这条链路也没被破坏，JS 字符串里的转义是对的，卡片内容能正常渲染。四点可以再打磨：一是 SKILL.md 的工作流第 1 步让人写 categories 映射，但没给一份完整的顶层 JSON 样例（title/subtitle/categories/cards 四个键各长什么样），要跳到 references/data-schema.md 才知道，工作流和参考文档之间断了一拍，第一次用容易写错顶层结构；二是脚本只校验 cat 归属，不校验 items 和 mn 能不能互逆——「可逆」是这套方法的核心卖点，却完全靠人或模型自觉，建议加一个「items 每项在 mn 里能否找到对应字」的软校验并给警告；三是 references 里三份方法文档都偏短（mnemonic-methods 3KB、priority-rules 2.5KB、data-schema 3.7KB），七种口诀手法每种只给一个例子，可逆性怎么判定、撞车怎么查都没展开，对复杂科目（比如需要区分案例和论文的）不够用；四是 APK 打包依赖 JDK17 + Android SDK + Gradle，还要求先做一张按科目定制的图标（要额外的生图能力），对普通备考用户路径偏长，建议给一条「只出 HTML 先用着」的默认推荐路径，别让 APK 挡在主流程前面。整体是一个真跑得通、有实测细节的复习工具，网页卡片这条主路线的完成度比同类高。

一个只有一份 SKILL.md、没有任何脚本的纯规范型技能，价值全在把 MiniMax H3 的官方提示词公式讲清楚了。三段式（参考素材说明 / 核心创意 / 画面过程说明）确实是 H3 官方要求的格式，参数速查表也够硬：时长 4-15 秒、提示词上限 7000 字符、画幅六档、全能参考图≤9视频≤3音频≤3且音频须配图或视频、总文件≤12，TTS 覆盖 11 种语言可衍生 40+ 口音，这些数字在别处很难一次看全。避坑清单五条是真踩过坑的写法：锁脸必须传人物参考图并在素材说明里指定、纯文生至少写全主体外观+场景+动作+风格、一镜到底就删掉分镜结构整段写、素材要说明用途不能只罗列、台词时长别超 shot 秒数。我按它的公式实写了一条 9 秒提示词做校验：全文 412 字符远低于上限；台词按它给的约 4-5 字/秒反推，Shot2 给 4 秒写 18 字是 4.5 字/秒、Shot3 给 2 秒写 10 字是 5.0 字/秒，两段都在它给的区间内，「非叙事性音乐：N/A」这条收尾也照做了，产出的提示词确实是能直接提交给 H3 的形态，规则本身自洽、模板可照抄。四处可以补：一是英文六段式扩写那节要求「写前重读官方扩写指南」，但技能包里只有 SKILL.md 一个文件，根本无处可读，指的应该是外部官方手册，技能应该直接收进来或给出链接；二是「11 种语言、40+ 口音」没给语言清单和口音标注的具体写法，出海场景要靠猜；三是首尾帧模式（≤2图）里 @图片1/@图片2 的语义是首帧和尾帧，跟参考素材说明里示范的「@图片1：人物参考，锁定脸部特征」完全是两回事，两种模式的素材说明该各给一个示例，混用会直接写错；四是「整体要求补充」标的是按需，但没说清哪些情况是必写（比如有 Logo 或画面文字时），另外示例里给的是城市/大漠/海岛三个题材，跟它自己主打的口播和人物叙事场景没接上，如果想让人拿这个做口播视频，多给一条带画外音和跨 shot 台词衔接的示例会更贴合。总体是份整理得比较扎实的官方规范归纳，纯提示词技能能做到这个程度，够用。

做工程这行的应该都懂读图纸的痛点，这个技能的路线设计非常专业：优先让你导 DXF 而不是 PDF，并且讲清楚了为什么——PDF 经 CAD 打印后文字会转成矢量曲线，只能靠渲染读图，精度天然掉一档；DXF 里文字坐标都是原始实体，零识别损失。PDF 路线还自动区分了文本页（直接提取）和转曲页（高DPI渲染后多模态读图），OCR 只做数字兜底不当地主结果，这个取舍很清醒。extract_drawing.py 会逐页判定类型、提取表格、单独裁出底部标题栏，还产出 manifest 告诉调用方每页该怎么读，可复现性很强。明确的边界也写得很诚实：不解析 DWG、不替代设计计算与规范复核。建议市政、机电类工程师备一份。

贴了条典型的 SELECT * FROM orders WHERE status=... ORDER BY amount 的慢查询加 explain 输出，立刻识别出全表扫描、文件排序、扫描行数过大三个问题，并按 HIGH/MEDIUM 分级给了复合索引、调整 ORDER BY 的具体建议，不是那种只说加个index就完事的空话。最实用的是诊断记录会存到本地 json，同一条 SQL 优化后再跑一次可以前后对比，改完到底快没快一眼看得出来，对迭代排查很有帮助。规则表是正则匹配 explain 关键词，覆盖面够日常用，深度调优还得靠DBA。纯本地 json 处理不用连数据库，隐私也稳。

实测把一段微信里东一句西一句的票据文字丢进去，输出四段结构非常干净：6列明细表、分类小计、规范文件名清单、异常提示，一次到位不用返工。最惊喜的是中文口语金额的换算——四十五块六、捌佰玖拾元整这类都能准确落到两位小数，还有重复票号自动标黄、缺字段统一填待补而不乱猜，这个细节很专业，财务对账时能直接省掉一轮人工核对。配套的 normalize.py 是纯本地正则处理，不吃任何外部Key，响应很快。建议报销季囤着。