判断一份资料值不值得做成 Skill，有个简单标准：它是不是“反复查、有固定要求、每次回答都要讲同一套规则”。客服 FAQ、产品说明、内部流程、标准操作手册都符合；偶尔才查一次的文件，直接上传问一次就够了，不必专门做 Skill。

做 Skill 的思路可以概括为四步：

第一步，准备一份干净的源资料。把 FAQ、说明或流程文档整理成一份文件上传。资料里的规则要明确：适用条件、限制、例外情况都要写清楚，含糊的条款在做 Skill 之前先修订，否则模型只能靠猜来补。

第二步，生成 Skill 时把“回答规则”写进要求里，而不只是把资料原文塞进去。要求里要包括：回答用口语化表达、形成可直接发给客户的回复；保留适用条件、限制与例外，不为精简而省略关键前提；引用的信息要能对应到源资料的条目，方便核对；资料没写或前后冲突的地方要明确指出、不自行补全；不承诺资料未写明的信息。生成完成后，记下 Skill 的位置与调用方式，并确认还需手动完成哪些启用步骤。

第三步，做对照测试。同一批问题分别用两种方式问一遍：一是直接上传资料现问现答，二是调用已生成的 Skill 回答。对比的不只是速度与消耗，还有答复质量：能不能直接发给客户、有没有把内部表述原样抛给客户、有没有让客户再去找别人确认本该由你回答的事。发现这类问题时，要把修正规则补充进 Skill，让下一次回答自动按新规则来，而不是每次手动改一遍。

第四步，跨会话验证。换一个新会话再问：资料里明确写过的问题能不能答对、必要条件有没有遗漏、会不会主动追问缺失的关键信息；资料里没有的问题，会不会诚实表示不清楚、需要核实，而不是编一个数字或承诺出来。两类问题都通过，这个 Skill 才算可用。

Skill 与知识库怎么分工？资料多、主要用途是“查信息、找答案”时，优先用知识库；想把“怎么处理、怎么回答”的要求也固定下来时，用 Skill。两者也可以配合：知识库管资料，Skill 规定处理与回答方式。先从那份“每次都要重复交代同样要求”的文档开始做，收益最明显。

观点：Skill 的价值不在于生成那一次有多快，而在于此后每一次回答都不用重新讲规则、重新纠话术。把高频回答固定下来，人才有时间去处理那些真正需要判断的新问题。