skill创作学习笔记

参加讯飞AI开发者大赛Skill类赛题的这段时间，最大的收获是理解了"提交一个Skill"和"交付一个合规可用的Skill"之间的鸿沟。一开始以为核心脚本能跑通就算完事了，直到第一版被驳回才发现，审核关注的点远比功能正确更细：SKILL.md的元数据格式、ZIP包的目录结构、动态字段的注入防护、输出内容的转义处理，每一项都是一道隐形的门槛。 以表格异常检测助手为例，功能上五类异常检测从一开始就是完整的，但前后经历了至少三轮驳回打磨。第一轮是Markdown净化的公式前缀检测只判了首字符，没处理前导空格和制表符，导致 ` =SUM(1,1)` 这种载荷可以绕过防护直接写入报告。修复方式是把检测逻辑从 `s[0]` 改为 `lstrip()` 后再判断，单引号精准插在有效字符前而非简单前置。第二轮报的是一样的问题但出在Excel/CSV输出路径，`sanitize_csv_cell` 也得同步升级。第三轮又因为ZIP包嵌套了一层子目录、usage.md里残留了不存在的命令行参数被拒。这些问题在自测时完全不会被发现，因为功能本身运行正常，但站在审核视角，每个出口都必须严丝合缝。 另一个深刻的体会是"写代码"和"写工程"的区别。比赛要求的是生产级交付，不是demo。sanitize_cell里处理的不只是 `=`，还包括 `+ - @` 三个前缀、`javascript:` / `vbscript:` / `data:` 协议过滤、HTML实体转义、Markdown管道符转义、链接语法脱敏——每一步都对应一个真实的攻击面。写完这些再写测试，36个用例一行行验证，才敢说这里没问题了。 最有价值的副产品是积累了一套可复用的安全防护模板。HTML转义、公式注入防护、Markdown净化这三段逻辑现在可以直接搬到其他Skill的脚本里，不用每次从头造轮子。回头看，比赛真正的训练不是做出一个能用的工具，而是养成"上线前从审核视角把自己审一遍"的肌肉记忆。