1. 项目概述当“技能”成为降本增效的利器最近在折腾大模型应用时我反复被一个现实问题困扰Token消耗。无论是调用OpenAI的API还是使用Claude、DeepSeek等模型每一次交互都在“烧钱”或消耗宝贵的额度。尤其是在处理那些结构固定、逻辑重复的任务时看着Token数蹭蹭往上涨而实际产生的价值却有限这种感觉就像开着跑车在市区里堵车既浪费又心疼。“Skill”这个概念正是在这种背景下进入了我的视野。它不是什么神秘的新技术而是一种将重复性操作封装成可复用“技能”的工程化思路。简单来说就是把那些你需要反复向大模型解释的指令、固定的处理流程、标准的输出格式打包成一个“技能包”。下次遇到同类任务直接调用这个技能包而不是从头开始用自然语言描述一切。这听起来像是编程里的“函数”或“宏”但在大模型交互的语境下它的价值被放大了——因为它直接作用于成本的核心Token。我最近完成的一个编号为“36”的实际项目就是这种思路的典型落地。它不是一个炫酷的AI应用而是一个朴实无华的效率工具目标非常明确将某个高频、固定的数据清洗与格式化任务的Token消耗降低至少50%。结果比预想的还要好。通过Skill的合理设计与应用我们不仅大幅压降了成本还意外地收获了处理速度的提升和结果一致性的保证。这篇文章我就来拆解这个“项目36”的完整实现过程分享如何将Skill从概念变成实实在在的省钱工具。无论你是个人开发者、项目团队负责人还是对AI应用成本敏感的任何角色这些实战经验都可能为你打开一扇新的大门。2. Skill的核心设计思路从“聊天”到“执行指令”在深入项目细节之前我们必须统一对“Skill”在这类应用场景下的理解。它不同于某些平台如Codex定义的特定插件系统而是一种更广义的、面向大模型交互的“高效指令集”设计模式。2.1 为什么重复任务如此“吃”Token要理解Skill的价值先得明白钱是怎么“烧”掉的。以一个常见的场景为例你每天需要处理几十份来自不同渠道的客户反馈提取其中的产品名称、问题类型、严重等级和用户情绪并整理成结构化的表格。低效的做法每次消耗约 800-1200 Tokens每次你都给模型发送类似的提示“请从以下用户反馈中提取产品名称、问题类型选项功能故障、使用咨询、价格投诉、服务建议、严重等级1-5级、用户情绪正面、中性、负面。以JSON格式输出键名为 product, issue_type, severity, sentiment。” 即使你的指令已经比较清晰但模型每次都需要重新解析这段指令理解“提取”、“JSON格式”、“键名”等要求并结合当次提供的反馈内容进行思考。这段系统提示本身可能就占用了200-300 Tokens而且每次交互中模型“思考”如何解析你的指令这个过程也会产生Tokens。更糟糕的是上下文累积如果你在同一个会话中连续处理多个反馈历史消息会不断累积在上下文里。虽然最新的模型上下文窗口很大但为这些重复的指令和历史结果支付Token费用无疑是巨大的浪费。2.2 Skill的设计哲学预设、精简、复用Skill的思路就是对抗这种浪费。它的核心是将可变与不可变的部分分离。不可变部分固化到Skill中任务的目标、输出的格式、固定的逻辑规则、选项枚举。这部分被预先定义和“训练”或“注入”到Skill中。可变部分每次输入需要处理的具体内容。这部分是每次交互唯一需要传递的新信息。对于上面的客户反馈处理例子一个设计良好的Skill意味着对模型而言它内部已经“知道”自己的任务是“从文本中提取四类结构化信息”并输出指定格式的JSON。它不需要每次再听你复述一遍规则。对你而言你每次只需要说“使用‘客户反馈解析’技能处理内容[这里是具体的用户反馈文本]”。对Token消耗而言系统提示词可能被压缩到50个Tokens以内只是一个技能调用指令大部分Tokens都用于处理真正有价值的“可变部分”——用户反馈文本本身。项目36的起点正是源于我们内部一个类似的数据标注预处理流程。每天有数百条原始数据需要被分类、打标签、并转换成标准格式。最初用通用聊天方式处理单条成本居高不下。我们意识到这个流程的“骨架”是100%固定的变的只是“血肉”数据本身。这就是Skill的理想应用场景。3. 实战构建一个用于数据清洗的Skill“项目36”的具体任务是从非结构化的技术日志片段中提取出错误代码error_code、发生时间timestamp、影响的服务器模块module以及错误级别level: DEBUG, INFO, WARN, ERROR, FATAL。原始日志格式混乱时间格式不一模块名称缩写多样。3.1 技能定义与“训练”这里说的“训练”不是指重新训练一个大模型而是通过精心构建的少样本示例Few-Shot Examples和指令让模型在上下文中学会这个特定技能。我们为这个“日志解析技能”撰写的定义如下你是一个日志解析专家。请始终按照以下规则处理输入的技术日志文本 1. 提取错误代码寻找类似“ERR-XXXX”、“ErrorCode: XXXX”或方括号内的代码如[0x3F]的模式。 2. 提取时间戳识别并统一转换为ISO 8601格式YYYY-MM-DDTHH:MM:SS。可能遇到的格式有“Mar 12 10:23:11”、“2024/03/12 10:23:11”、“12-03-2024 10:23”。 3. 提取服务器模块通常出现在日志开头或错误信息前如“[AuthService]”、“Gateway - ”、“Module: Database”。将其规范化为首字母大写的完整英文单词如“AuthenticationService”, “Gateway”, “Database”。 4. 提取错误级别从日志中识别“DEBUG”、“INFO”、“WARNING”、“ERROR”、“FATAL”等关键词并映射到对应的标准级别。 5. 输出格式必须且仅输出一个合法的JSON对象包含且仅包含四个键error_code, timestamp, module, level。如果某个字段无法从输入中识别其值应为null。 示例 输入“[AuthService] ERROR [2024/03/12 10:23:11] User login failed with ERR-1001” 输出{error_code: ERR-1001, timestamp: 2024-03-12T10:23:11, module: AuthenticationService, level: ERROR} 输入“WARNING 12-03-2024 10:23 Gateway - High latency detected [Code: 0x5A]” 输出{error_code: 0x5A, timestamp: 2024-03-12T10:23:00, module: Gateway, level: WARN} 现在请处理新的日志输入。关键设计点解析规则明确用编号列表清晰界定任务范围避免模型自由发挥。格式统一强制规定输出格式省去了每次协商格式的Tokens。示例精准两个示例覆盖了常见格式变体展示了规则的应用。示例本身也是投资它们会占用上下文Tokens但这是一次性的、可复用的投资。容错处理明确规定了“无法识别则设为null”避免了模型因纠结于缺失信息而生成冗长解释或提问。这个技能定义文本就是我们构建的“Skill”。它大约有400个Tokens。在后续的每次调用中我们只需要在会话开始时将它作为系统消息或第一条用户消息发送一次取决于API使用方式然后就可以反复使用。3.2 实现模式会话复用与技能调用如何在实际API调用中应用这个Skill有两种主流模式模式一长会话复用推荐用于批量任务初始化一个会话第一条消息就发送完整的技能定义作为系统提示或第一条用户消息。这消耗了约400 Tokens。在此会话中后续的每一条用户消息都简化为“解析日志[具体的日志文本]”。模型会基于已经建立的上下文即它已经“掌握”了技能直接处理新输入。优势技能定义只需发送一次后续交互极其精简。处理100条日志技能定义的成本被摊薄到几乎可以忽略。注意事项需注意模型的总上下文长度限制。如果处理的日志文本非常长可能需要定期开启新会话并重新注入技能。模式二技能模板化更灵活适合低频或分布式调用将技能定义保存为一个模板字符串。每次调用时动态生成提示词技能定义 “\n\n输入” 实际日志文本。每次都是独立的API调用。优势无状态适合服务器less函数或异步任务队列。每次调用互不影响。劣势技能定义的Tokens会在每次调用时重复计算成本较高。仅适合调用频率不高的场景。在项目36中我们处理的是批量日志文件因此果断采用了模式一。我们编写了一个脚本读取日志文件每50条日志开启一个新的会话以防止上下文过长在每个会话中先“注入”技能然后循环处理这50条日志。3.3 Token消耗对比分析让我们用真实数据算一笔账。假设没有Skill处理一条日志的平均交互如下用户消息指令“请从以下日志中提取error_code, timestamp, module, level以JSON输出。时间转成ISO格式...” (约80 Tokens)模型回复结果JSON输出 (约40 Tokens)单条总消耗~120 Tokens使用Skill后在同一个复用会话中会话初始化发送技能定义 (400 Tokens)。这是固定成本。第1条日志用户消息“解析日志xxx” (约10 Tokens)第1条日志模型回复JSON输出 (约40 Tokens)第2条及以后日志用户消息“解析日志yyy” (约10 Tokens)第2条及以后模型回复JSON输出 (约40 Tokens)处理N条日志的总Token消耗公式为400 N * (10 40) 400 50N盈亏平衡点令120N 400 50N解得N ≈ 5.7。也就是说只要处理超过6条日志使用Skill就开始节省Tokens。处理100条日志时无Skill120 * 100 12,000 Tokens有Skill400 50 * 100 5,400 Tokens节省比例55%这完全符合甚至超过了我们最初设定“降低至少50%”的目标。在实际运行中由于我们批量处理每条日志的平均指令更短实际节省率接近60%。4. 高级技巧与避坑指南仅仅封装一个技能定义只是开始。要让Skill真正高效可靠还需要一些“踩坑”后总结的经验。4.1 技能描述的精确性与模糊性的平衡最初的技能描述中我们写道“识别时间戳”。结果模型有时会把日志中的“处理耗时120ms”这样的数字也误认为是时间戳。这就是描述过于模糊。改进后“提取表示事件发生时刻的时间戳字符串通常位于行首或错误级别附近格式可能为...列举常见格式。忽略表示时间间隔、耗时如‘120ms’、‘耗时2秒’的数字。”心得定义Skill时要像编写严谨的产品需求文档。不仅要告诉模型“做什么”更要明确“不做什么”并通过负例Negative Examples来强化边界。可以在技能定义的示例部分加入一个故意出错的例子并说明原因。4.2 处理边界情况与模型“臆想”即使规则再明确模型面对完全不符合预期的输入时也可能产生“臆想”Hallucination即编造数据。例如日志中根本没有错误代码但模型为了满足输出格式可能会生成一个“UNKNOWN”或虚构一个代码。我们的解决方案是在技能定义中强化指令“必须严格基于输入文本进行提取。如果输入文本中明确不存在某项信息则对应字段输出null。禁止推断或编造任何未被输入文本直接支持的信息。”同时在后续的校验脚本中我们增加了一条规则如果error_code为null但level为ERROR或FATAL则这条记录需要被标记出来进行人工复核。这样既利用了模型的提取能力又用规则兜底。4.3 技能组合与管道化复杂的任务往往由多个子任务构成。这时可以设计多个细粒度的Skill并将它们组合成工作流。在项目36的后期我们增加了一个“日志摘要”Skill。它接收之前“日志解析”Skill输出的JSON数组然后生成一段自然语言摘要例如“过去一小时内共发生12条ERROR级日志其中8条来自Database模块主要错误代码为ERR-1001。”实现方式第一个会话使用“解析技能”处理大量日志输出JSON列表。将JSON列表作为输入在第二个会话中调用“摘要技能”。这个“摘要技能”也有其独立的定义专注于总结JSON结构化的数据。这种管道化Pipeline的方式使得每个Skill都保持简单、专注易于维护和调试同时也更符合Token经济——每个步骤只为其特定的价值付费。4.4 模型选择与成本优化不同的模型其Token定价和能力不同。对于高度结构化、规则明确的Skill任务我们不一定需要能力最强、最贵的模型。复杂技能需要推理、判断可能适合使用GPT-4、Claude-3 Opus。简单提取与格式化技能如项目36完全可以使用更经济实惠的模型如GPT-3.5 Turbo、Claude-3 Haiku甚至是专门微调过的中小模型。它们的输出质量对于格式化任务通常足够而Token成本可能只有顶级模型的1/5甚至1/10。我们在项目36中尝试了从GPT-4切换到GPT-3.5 Turbo。在技能定义足够清晰的前提下对于标准格式的日志两者的提取准确率相差无几在98%以上但成本下降了80%。这是一个巨大的优化。核心原则是用合适的工具做合适的事不为过剩的能力付费。5. 效能提升与扩展思考通过项目36的实践Skill带来的收益远不止Token节省。5.1 处理速度的意外提升由于每次交互的提示词变得非常短模型需要处理的文本量大大减少这直接导致了端到端延迟的降低。批量处理100条日志总耗时减少了约30%。这对于需要近实时处理的场景是一个宝贵的副产品。5.2 输出一致性的保障在使用自由格式提示词时即使指令相同模型在不同时间、对不同输入的输出格式也可能有细微差别如JSON键名偶尔加个空格时间格式偶尔不一致。Skill将输出格式强制锁定使得下游程序如解析JSON的脚本可以完全依赖固定的格式消除了大量的数据清洗和后处理工作提高了整个流程的可靠性。5.3 Skill的管理与版本化当团队内拥有多个Skill时管理它们就变得重要。我们建立了一个简单的内部Wiki页面记录每个Skill的ID与名称如 “LOG_PARSER_V1”完整定义描述可直接复制粘贴的提示词文本。用途与示例什么情况下使用输入输出示例。创建者与日期便于追溯。关联模型建议在哪些模型上使用效果最好、成本最低。版本历史记录重要的变更例如为了处理新的日志格式而更新了规则。这避免了“技能黑盒”让团队协作成为可能。5.4 超越文本处理Skill的广义应用Skill的思路可以推广到许多领域客服自动化将“用户投诉分类”、“提取订单号”、“生成标准回复模板”等封装成技能。内容创作将“根据要点写小红书文案”、“将技术报告改写为公众号摘要”等风格化写作封装成技能。代码助手将“为函数添加Google风格注释”、“检查代码安全漏洞模式”等封装成技能比通用代码补全更精准。其核心思想始终如一识别流程中重复、固定的部分将其预置为模型的“上下文”或“预设指令”从而将每次昂贵的交互聚焦于真正需要创造力和灵活性的部分。回过头看项目36的成功并不依赖于高深的技术而是源于对成本结构的细致审视和一种“精益”的工程思维。在AI应用日益普及的今天如何更经济、更高效地利用大模型的能力将成为每个开发者和团队的核心竞争力之一。将常用操作封装成Skill就是一个简单而有效的起点。它提醒我们与AI协作有时我们需要做的不是让它更“智能”而是让它更“听话”、更“专业”地服务于我们特定的、重复的需求。 1. 项目概述当“技能”成为降本增效的利器最近在折腾大模型应用时我反复被一个现实问题困扰Token消耗。无论是调用OpenAI的API还是使用Claude、DeepSeek等模型每一次交互都在“烧钱”或消耗宝贵的额度。尤其是在处理那些结构固定、逻辑重复的任务时看着Token数蹭蹭往上涨而实际产生的价值却有限这种感觉就像开着跑车在市区里堵车既浪费又心疼。“Skill”这个概念正是在这种背景下进入了我的视野。它不是什么神秘的新技术而是一种将重复性操作封装成可复用“技能”的工程化思路。简单来说就是把那些你需要反复向大模型解释的指令、固定的处理流程、标准的输出格式打包成一个“技能包”。下次遇到同类任务直接调用这个技能包而不是从头开始用自然语言描述一切。这听起来像是编程里的“函数”或“宏”但在大模型交互的语境下它的价值被放大了——因为它直接作用于成本的核心Token。我最近完成的一个编号为“36”的实际项目就是这种思路的典型落地。它不是一个炫酷的AI应用而是一个朴实无华的效率工具目标非常明确将某个高频、固定的数据清洗与格式化任务的Token消耗降低至少50%。结果比预想的还要好。通过Skill的合理设计与应用我们不仅大幅压降了成本还意外地收获了处理速度的提升和结果一致性的保证。这篇文章我就来拆解这个“项目36”的完整实现过程分享如何将Skill从概念变成实实在在的省钱工具。无论你是个人开发者、项目团队负责人还是对AI应用成本敏感的任何角色这些实战经验都可能为你打开一扇新的大门。2. Skill的核心设计思路从“聊天”到“执行指令”在深入项目细节之前我们必须统一对“Skill”在这类应用场景下的理解。它不同于某些平台如Codex定义的特定插件系统而是一种更广义的、面向大模型交互的“高效指令集”设计模式。2.1 为什么重复任务如此“吃”Token要理解Skill的价值先得明白钱是怎么“烧”掉的。以一个常见的场景为例你每天需要处理几十份来自不同渠道的客户反馈提取其中的产品名称、问题类型、严重等级和用户情绪并整理成结构化的表格。低效的做法每次消耗约 800-1200 Tokens每次你都给模型发送类似的提示“请从以下用户反馈中提取产品名称、问题类型选项功能故障、使用咨询、价格投诉、服务建议、严重等级1-5级、用户情绪正面、中性、负面。以JSON格式输出键名为 product, issue_type, severity, sentiment。” 即使你的指令已经比较清晰但模型每次都需要重新解析这段指令理解“提取”、“JSON格式”、“键名”等要求并结合当次提供的反馈内容进行思考。这段系统提示本身可能就占用了200-300 Tokens而且每次交互中模型“思考”如何解析你的指令这个过程也会产生Tokens。更糟糕的是上下文累积如果你在同一个会话中连续处理多个反馈历史消息会不断累积在上下文里。虽然最新的模型上下文窗口很大但为这些重复的指令和历史结果支付Token费用无疑是巨大的浪费。2.2 Skill的设计哲学预设、精简、复用Skill的思路就是对抗这种浪费。它的核心是将可变与不可变的部分分离。不可变部分固化到Skill中任务的目标、输出的格式、固定的逻辑规则、选项枚举。这部分被预先定义和“训练”或“注入”到Skill中。可变部分每次输入需要处理的具体内容。这部分是每次交互唯一需要传递的新信息。对于上面的客户反馈处理例子一个设计良好的Skill意味着对模型而言它内部已经“知道”自己的任务是“从文本中提取四类结构化信息”并输出指定格式的JSON。它不需要每次再听你复述一遍规则。对你而言你每次只需要说“使用‘客户反馈解析’技能处理内容[这里是具体的用户反馈文本]”。对Token消耗而言系统提示词可能被压缩到50个Tokens以内只是一个技能调用指令大部分Tokens都用于处理真正有价值的“可变部分”——用户反馈文本本身。项目36的起点正是源于我们内部一个类似的数据标注预处理流程。每天有数百条原始数据需要被分类、打标签、并转换成标准格式。最初用通用聊天方式处理单条成本居高不下。我们意识到这个流程的“骨架”是100%固定的变的只是“血肉”数据本身。这就是Skill的理想应用场景。3. 实战构建一个用于数据清洗的Skill“项目36”的具体任务是从非结构化的技术日志片段中提取出错误代码error_code、发生时间timestamp、影响的服务器模块module以及错误级别level: DEBUG, INFO, WARN, ERROR, FATAL。原始日志格式混乱时间格式不一模块名称缩写多样。3.1 技能定义与“训练”这里说的“训练”不是指重新训练一个大模型而是通过精心构建的少样本示例Few-Shot Examples和指令让模型在上下文中学会这个特定技能。我们为这个“日志解析技能”撰写的定义如下你是一个日志解析专家。请始终按照以下规则处理输入的技术日志文本 1. 提取错误代码寻找类似“ERR-XXXX”、“ErrorCode: XXXX”或方括号内的代码如[0x3F]的模式。 2. 提取时间戳识别并统一转换为ISO 8601格式YYYY-MM-DDTHH:MM:SS。可能遇到的格式有“Mar 12 10:23:11”、“2024/03/12 10:23:11”、“12-03-2024 10:23”。 3. 提取服务器模块通常出现在日志开头或错误信息前如“[AuthService]”、“Gateway - ”、“Module: Database”。将其规范化为首字母大写的完整英文单词如“AuthenticationService”, “Gateway”, “Database”。 4. 提取错误级别从日志中识别“DEBUG”、“INFO”、“WARNING”、“ERROR”、“FATAL”等关键词并映射到对应的标准级别。 5. 输出格式必须且仅输出一个合法的JSON对象包含且仅包含四个键error_code, timestamp, module, level。如果某个字段无法从输入中识别其值应为null。 示例 输入“[AuthService] ERROR [2024/03/12 10:23:11] User login failed with ERR-1001” 输出{error_code: ERR-1001, timestamp: 2024-03-12T10:23:11, module: AuthenticationService, level: ERROR} 输入“WARNING 12-03-2024 10:23 Gateway - High latency detected [Code: 0x5A]” 输出{error_code: 0x5A, timestamp: 2024-03-12T10:23:00, module: Gateway, level: WARN} 现在请处理新的日志输入。关键设计点解析规则明确用编号列表清晰界定任务范围避免模型自由发挥。格式统一强制规定输出格式省去了每次协商格式的Tokens。示例精准两个示例覆盖了常见格式变体展示了规则的应用。示例本身也是投资它们会占用上下文Tokens但这是一次性的、可复用的投资。容错处理明确规定了“无法识别则设为null”避免了模型因纠结于缺失信息而生成冗长解释或提问。这个技能定义文本就是我们构建的“Skill”。它大约有400个Tokens。在后续的每次调用中我们只需要在会话开始时将它作为系统消息或第一条用户消息发送一次取决于API使用方式然后就可以反复使用。3.2 实现模式会话复用与技能调用如何在实际API调用中应用这个Skill有两种主流模式模式一长会话复用推荐用于批量任务初始化一个会话第一条消息就发送完整的技能定义作为系统提示或第一条用户消息。这消耗了约400 Tokens。在此会话中后续的每一条用户消息都简化为“解析日志[具体的日志文本]”。模型会基于已经建立的上下文即它已经“掌握”了技能直接处理新输入。优势技能定义只需发送一次后续交互极其精简。处理100条日志技能定义的成本被摊薄到几乎可以忽略。注意事项需注意模型的总上下文长度限制。如果处理的日志文本非常长可能需要定期开启新会话并重新注入技能。模式二技能模板化更灵活适合低频或分布式调用将技能定义保存为一个模板字符串。每次调用时动态生成提示词技能定义 “\n\n输入” 实际日志文本。每次都是独立的API调用。优势无状态适合服务器less函数或异步任务队列。每次调用互不影响。劣势技能定义的Tokens会在每次调用时重复计算成本较高。仅适合调用频率不高的场景。在项目36中我们处理的是批量日志文件因此果断采用了模式一。我们编写了一个脚本读取日志文件每50条日志开启一个新的会话以防止上下文过长在每个会话中先“注入”技能然后循环处理这50条日志。3.3 Token消耗对比分析让我们用真实数据算一笔账。假设没有Skill处理一条日志的平均交互如下用户消息指令“请从以下日志中提取error_code, timestamp, module, level以JSON输出。时间转成ISO格式...” (约80 Tokens)模型回复结果JSON输出 (约40 Tokens)单条总消耗~120 Tokens使用Skill后在同一个复用会话中会话初始化发送技能定义 (400 Tokens)。这是固定成本。第1条日志用户消息“解析日志xxx” (约10 Tokens)第1条日志模型回复JSON输出 (约40 Tokens)第2条及以后日志用户消息“解析日志yyy” (约10 Tokens)第2条及以后模型回复JSON输出 (约40 Tokens)处理N条日志的总Token消耗公式为400 N * (10 40) 400 50N盈亏平衡点令120N 400 50N解得N ≈ 5.7。也就是说只要处理超过6条日志使用Skill就开始节省Tokens。处理100条日志时无Skill120 * 100 12,000 Tokens有Skill400 50 * 100 5,400 Tokens节省比例55%这完全符合甚至超过了我们最初设定“降低至少50%”的目标。在实际运行中由于我们批量处理每条日志的平均指令更短实际节省率接近60%。4. 高级技巧与避坑指南仅仅封装一个技能定义只是开始。要让Skill真正高效可靠还需要一些“踩坑”后总结的经验。4.1 技能描述的精确性与模糊性的平衡最初的技能描述中我们写道“识别时间戳”。结果模型有时会把日志中的“处理耗时120ms”这样的数字也误认为是时间戳。这就是描述过于模糊。改进后“提取表示事件发生时刻的时间戳字符串通常位于行首或错误级别附近格式可能为...列举常见格式。忽略表示时间间隔、耗时如‘120ms’、‘耗时2秒’的数字。”心得定义Skill时要像编写严谨的产品需求文档。不仅要告诉模型“做什么”更要明确“不做什么”并通过负例Negative Examples来强化边界。可以在技能定义的示例部分加入一个故意出错的例子并说明原因。4.2 处理边界情况与模型“臆想”即使规则再明确模型面对完全不符合预期的输入时也可能产生“臆想”Hallucination即编造数据。例如日志中根本没有错误代码但模型为了满足输出格式可能会生成一个“UNKNOWN”或虚构一个代码。我们的解决方案是在技能定义中强化指令“必须严格基于输入文本进行提取。如果输入文本中明确不存在某项信息则对应字段输出null。禁止推断或编造任何未被输入文本直接支持的信息。”同时在后续的校验脚本中我们增加了一条规则如果error_code为null但level为ERROR或FATAL则这条记录需要被标记出来进行人工复核。这样既利用了模型的提取能力又用规则兜底。4.3 技能组合与管道化复杂的任务往往由多个子任务构成。这时可以设计多个细粒度的Skill并将它们组合成工作流。在项目36的后期我们增加了一个“日志摘要”Skill。它接收之前“日志解析”Skill输出的JSON数组然后生成一段自然语言摘要例如“过去一小时内共发生12条ERROR级日志其中8条来自Database模块主要错误代码为ERR-1001。”实现方式第一个会话使用“解析技能”处理大量日志输出JSON列表。将JSON列表作为输入在第二个会话中调用“摘要技能”。这个“摘要技能”也有其独立的定义专注于总结JSON结构化的数据。这种管道化Pipeline的方式使得每个Skill都保持简单、专注易于维护和调试同时也更符合Token经济——每个步骤只为其特定的价值付费。4.4 模型选择与成本优化不同的模型其Token定价和能力不同。对于高度结构化、规则明确的Skill任务我们不一定需要能力最强、最贵的模型。复杂技能需要推理、判断可能适合使用GPT-4、Claude-3 Opus。简单提取与格式化技能如项目36完全可以使用更经济实惠的模型如GPT-3.5 Turbo、Claude-3 Haiku甚至是专门微调过的中小模型。它们的输出质量对于格式化任务通常足够而Token成本可能只有顶级模型的1/5甚至1/10。我们在项目36中尝试了从GPT-4切换到GPT-3.5 Turbo。在技能定义足够清晰的前提下对于标准格式的日志两者的提取准确率相差无几在98%以上但成本下降了80%。这是一个巨大的优化。核心原则是用合适的工具做合适的事不为过剩的能力付费。5. 效能提升与扩展思考通过项目36的实践Skill带来的收益远不止Token节省。5.1 处理速度的意外提升由于每次交互的提示词变得非常短模型需要处理的文本量大大减少这直接导致了端到端延迟的降低。批量处理100条日志总耗时减少了约30%。这对于需要近实时处理的场景是一个宝贵的副产品。5.2 输出一致性的保障在使用自由格式提示词时即使指令相同模型在不同时间、对不同输入的输出格式也可能有细微差别如JSON键名偶尔加个空格时间格式偶尔不一致。Skill将输出格式强制锁定使得下游程序如解析JSON的脚本可以完全依赖固定的格式消除了大量的数据清洗和后处理工作提高了整个流程的可靠性。5.3 Skill的管理与版本化当团队内拥有多个Skill时管理它们就变得重要。我们建立了一个简单的内部Wiki页面记录每个Skill的ID与名称如 “LOG_PARSER_V1”完整定义描述可直接复制粘贴的提示词文本。用途与示例什么情况下使用输入输出示例。创建者与日期便于追溯。关联模型建议在哪些模型上使用效果最好、成本最低。版本历史记录重要的变更例如为了处理新的日志格式而更新了规则。这避免了“技能黑盒”让团队协作成为可能。5.4 超越文本处理Skill的广义应用Skill的思路可以推广到许多领域客服自动化将“用户投诉分类”、“提取订单号”、“生成标准回复模板”等封装成技能。内容创作将“根据要点写小红书文案”、“将技术报告改写为公众号摘要”等风格化写作封装成技能。代码助手将“为函数添加Google风格注释”、“检查代码安全漏洞模式”等封装成技能比通用代码补全更精准。其核心思想始终如一识别流程中重复、固定的部分将其预置为模型的“上下文”或“预设指令”从而将每次昂贵的交互聚焦于真正需要创造力和灵活性的部分。回过头看项目36的成功并不依赖于高深的技术而是源于对成本结构的细致审视和一种“精益”的工程思维。在AI应用日益普及的今天如何更经济、更高效地利用大模型的能力将成为每个开发者和团队的核心竞争力之一。将常用操作封装成Skill就是一个简单而有效的起点。它提醒我们与AI协作有时我们需要做的不是让它更“智能”而是让它更“听话”、更“专业”地服务于我们特定的、重复的需求。 
