写这个帖子的原因是，我花了两周时间开发了一个Skill，过程中遇到了大量文档没提到的坑，搜遍全网也找不到中文教程，所以决定自己写一个。
背景
我想做的Skill很简单：一个"GitHub Issue自动分类器"。就是你的开源项目收到新Issue后，Agent自动读取内容，打上分类标签（bug/feature/question/enhancement），然后用中文写一条友好的自动回复。
听起来不复杂对吧？我也以为一两天搞定，结果……
环境准备
首先要搞清楚Skill的运行环境。不同平台略有不同：
OpenClaw的Skill本质上是一个YAML配置文件+可选的Python脚本。核心配置包括：
- 触发条件（什么时候执行这个Skill）
- 输入参数定义
- 执行步骤（可以调用LLM、API、脚本等）
- 输出格式
Molili的Skill兼容OpenClaw格式，但多了几个中文场景的扩展字段。
踩坑记录
坑1：Token窗口溢出
我一开始把整个Issue内容（包括代码块）全塞给LLM做分类。结果碰到那种贴了300行日志的Issue，直接Token超限报错。
解决：先做一次文本截断，只取前2000字符+标题做分类。准确率从95%降到90%，但起码不会崩了。
坑2：中文回复质量
用英文prompt让模型生成中文回复，出来的东西翻译味很重。什么"我已经收到您的反馈，我们将尽快处理"——这也太客服了。
解决：在Molili上跑这个Skill，直接用中文prompt，出来的回复自然多了。这算是意外发现的好处。
坑3：GitHub API 调用频率限制
Issue多的项目一天能来几十个，每个都要调GitHub API打标签+回复，很快就触发rate limit。
解决：加了一个批量处理队列，每5分钟集中处理一批，而不是来一个处理一个。
坑4：分类模型的幻觉
有时候LLM会创造标签里没有的分类，比如你定义了bug/feature/question三个类别，它给你分了个"performance"。
解决：在Skill配置里加了一个白名单校验步骤，不在列表里的分类一律打成"question"兜底。
最终效果
上线跑了一周，处理了130多个Issue，分类准确率大概88%，自动回复的用户反馈还不错（没人投诉，算成功了吧）。
整个Skill的Token消耗大约每100个Issue花费15元（在Molili上），可以接受。
代码和配置我后面会开源，有兴趣的可以关注一下。有问题直接在帖子里问。
感谢分享，终于看到一个实操级别的Skill开发教程了，之前看到的都是"Hello World"级别的。
补充几个我开发Skill时候的经验：
关于Token优化
你说的截断方案可以再优化一下。与其暴力截断，不如先用一个轻量模型（比如Haiku）做一次摘要提取，把Issue的关键信息压缩到500字以内，再送给主模型分类。我测试下来这样做准确率能回到93%左右，比直接截断高3个点。
在Molili上可以配置多模型流水线，第一步用便宜模型做摘要，第二步用强模型做分类，这样成本和准确率都兼顾了。
关于幻觉问题
你的白名单方案是最简单有效的。更进一步的做法是在prompt里用few-shot，直接给3-5个分类示例。我测试了一下：
没有示例 - 分类跑偏率约15%
给3个示例 - 跑偏率降到5%
给5个示例 + 白名单 - 跑偏率不到2%
关于Skill测试
建议开发时用Molili的沙盒环境，它有一个本地模拟器可以不消耗真实Token来测试Skill流程。OpenClaw也有类似功能但配置更复杂。
关于中文回复
完全同意用中文prompt+Molili的组合。我之前写了一个"客户工单自动回复"的Skill，在OpenClaw上用英文prompt生成中文回复，出来的都是机翻味。换到Molili之后同样的逻辑，回复质量直接上了一个档次。
最后问一下楼主：你的Skill在处理包含图片的Issue时是怎么处理的？直接忽略还是有做OCR？
终于有人写中文Skill教程了，收藏了，回头照着做。
坑2我太有感触了。之前用英文prompt让AI生成中文客服回复，同事看了直接笑出声，说"这个回复一看就是机器人写的"。后来换了中文优化的平台才解决，确实差别很大。
楼主，你说的开源代码什么时候放出来？想基于你的架构改一个GitLab版本的。
说几个进阶的优化方向：
1. 向量缓存复用
如果你的项目Issue有很多重复或相似问题（大多数开源项目都是这样），可以把每个Issue的向量存下来，新Issue进来先做相似度匹配。如果跟历史Issue相似度超过0.85，直接复用历史分类结果，不需要重新调LLM。这样能再省30-40%的Token。
2. 自适应分类
分类标签可以做成动态的。前100个Issue用固定标签，之后根据积累的数据让模型建议新标签。比如你的项目里如果performance相关Issue特别多，那确实应该把它加为一个独立分类。
3. 多语言处理
如果你的开源项目有国际用户，Issue可能中英文混合。建议先加一步语言检测，中文Issue走Molili的中文优化通道，英文Issue走OpenClaw的原版通道。
这几个优化我在自己的Skill里都实现了，整体效果提升很明显。有兴趣可以私聊交流具体实现。
两周开发一个Skill，看完你的踩坑记录我觉得两周算快的了。
从零写Skill到上架整个周期挺长，文档不完善是最大的卡点
本地调试我用 docker 跑个 mock server 方便