前几天折腾了一堆 Codex Skills。

这东西怎么理解呢？大概就是给 Codex 塞一堆小抄。你不可能每次都从头教它“帮我检查 NSFC 标书时要先看科学问题”“读论文不要只看摘要”“改代码前先找根因”“写我的博客不要写成公众号腔”。于是就把这些稳定的工作习惯写成 skill，下次直接点名调用。

当然，装多了也挺吓人。现在一看，已经不是三五个小工具了，而是一整个工具箱。工具箱这种东西有个问题：工具越多，不代表干活越快。有时候你只是站在工具箱前面发呆，想半天到底该拿螺丝刀还是扳手。

所以我给已经安装的 skills 写了一个使用手册，把它们分了几类。

第一类是科研和 NSFC。这类对我最有用。

比如 bibliography-deep-research，适合读一个主题文件夹里的所有 PDF，写综述，整理研究方向。这个对我很关键，因为我经常不是缺论文，而是缺一个人帮我把一堆论文串起来。

NSFC 这一组就更像标书流水线了。nsfc-qc 做质量检查，nsfc-ref-alignment 查正文引用和参考文献是否对得上，nsfc-justification-writer 改立项依据，nsfc-reviewers 模拟专家评审。以前这些事情都要靠自己憋，憋到后来脑子都糊了。现在至少可以让 Codex 先当一个不太客气的同事，把问题指出来。

不过这类 skill 也不能当神仙。它可以提醒我逻辑不顺、引用不稳、篇幅不对，但真正的科学问题还是得自己想。AI 能帮你打磨刀，但不能替你决定砍哪棵树。

第二类是 Obsidian 和知识库。

这里有 obsidian-markdown、obsidian-cli、obsidian-bases、json-canvas、defuddle、canghe-url-to-markdown 这些。它们的目标很明确：把资料变成能放进 vault 的东西。

以前我收藏网页，经常是收藏完就等于没有收藏。因为网页在浏览器里，笔记在 Obsidian 里，想法在脑子里，三者互相看不见。现在比较理想的流程是，看到网页先用 defuddle 或 canghe-url-to-markdown 抓成 Markdown，再用 obsidian-markdown 整理成笔记，需要关系图就丢给 json-canvas。

这样至少不会出现“我记得我看过，但是我完全不知道放哪了”的经典惨案。

第三类是调研、学习和思考。

这里有 huashu-research、hv-analysis、ljg-read、ljg-learn、ljg-think、ljg-plain。名字看起来有点玄，但用途其实很清楚。

huashu-research 是联网调研，适合查最新东西。hv-analysis 是横纵分析，适合看一个产品、公司、技术到底怎么来的，现在和别人比又处在什么位置。ljg-read 是陪读，ljg-plain 是说人话，ljg-think 是往下追问。

这几个我觉得适合在“我大概知道问题，但还没有想清楚”的时候用。比如看到一个新工具，先别急着安装，先让它横向纵向分析一下。否则很容易见一个爱一个，最后电脑里全是工具，人还是那个手忙脚乱的人。

第四类是写作、内容生产和可视化。

这类包括 qiaomu-info-card-designer、guizang-ppt-skill、canghe-infographic、canghe-format-markdown、ljg-present，还有我刚做的 seisamuse-blog-writer。

seisamuse-blog-writer 是给我自己写博客用的。它读了我 200 多篇博客，总结出我的写法：别写得像公众号，别太端着，问题先摆出来，技术就给步骤，想法就慢慢绕，最后不用强行升华。听起来有点羞耻，但确实有用。因为 AI 默认会把文章写得太圆滑，太像“在当今快速发展的时代”。这种句子一出来，我就想把网页关了。

所以以后如果要写博客，我大概就直接说：

用 seisamuse-blog-writer 帮我写一篇关于 XXX 的博客。

它至少会记得，不要把我写成一个培训机构讲师。

第五类是代码开发。

这里就多了。diagnose、debugging-and-error-recovery、source-driven-development、code-review-and-quality、tdd、prototype、playwright、performance-optimization、security-and-hardening，还有一堆 git 和项目管理相关的。

这类 skill 的意义不是让 Codex 更会写代码，而是让它少犯“上来就改”的毛病。比如出了 bug，先用 diagnose 查根因；涉及新库，先用 source-driven-development 查官方文档；改完了再用 code-review-and-quality 过一遍；前端页面就用 playwright 真的打开看看。

说到底，代码这种东西不是写出来就完了。能跑、能测、能维护、下次还能看懂，这才算完。否则现在爽了，未来的自己就要还债。

还有一类是多代理和 skill 维护，比如 awesome-code、parallel-vibe、auto-test-project、better-prompt、compact-bensz-skills。这些不太适合天天用。小任务用它们就像切一颗葱还要召集一个项目组开会，阵仗太大。

我现在觉得最常用的大概就十来个：

  • bibliography-deep-research
  • nsfc-qc
  • nsfc-ref-alignment
  • nsfc-justification-writer
  • obsidian-markdown
  • huashu-research
  • hv-analysis
  • diagnose
  • source-driven-development
  • code-review-and-quality
  • qiaomu-info-card-designer
  • guizang-ppt-skill

以后调用也不要说得太虚。最稳的格式应该是这样：

帮我用 <skill-name> 做 <任务>。
输入是：<文件/目录/网页/目标>。
重点关注：<最多三个重点>。
输出到：<路径或格式>。
限制：<不要改文件/不要联网/不要 push/先给报告>。

这其实也不是给 AI 看的，是给自己看的。你把需求说清楚了，AI 才不会到处乱跑。你自己都没想清楚，skill 再多也没用。

总之，Codex Skills 这事很像给实验室整理工具柜。以前锤子、胶带、螺丝、万用表全堆在抽屉里，找得到算运气好。现在终于贴上了标签：这个用来读论文，这个用来查标书，这个用来写笔记，这个用来查 bug。

但是工具柜再整齐，也不会自己做实验。

该想的问题，还是得自己想。该做的判断，还是得自己做。Skills 最好的用法，大概不是让 AI 替我干所有事，而是让我少在重复的小事里打转，把脑子留给真正麻烦的地方。