Skills：大模型精确化的声明式解决方案

大家好，我是人月聊IT，今天继续聊Claude Skills方面的一些思考。

大模型的崛起带来了令人振奋的能力提升，但同时也暴露出一个核心矛盾：如何让具有概率性质的生成模型产出精确、可靠的结果？这个问题困扰着每一个试图将大模型应用于生产环境的团队。业界为此探索了多种路径，但我们发现，一个来自云原生领域的思想——声明式设计——可能为这个问题提供了最优雅的解决方案。

本文将深入探讨大模型精确化的三种主要路径，重点阐述Skills技能定义如何借鉴声明式设计思想，通过将核心经验显性化、结构化，实现大模型能力的精确定义和可靠应用。

大模型精确化的核心挑战

在讨论解决方案之前，我们需要明确问题的本质。大模型基于概率分布进行文本生成，这使得它们在创造性任务中表现出色，但在需要精确性的场景中却面临挑战。首先是输出的不确定性，相同的输入可能产生不同的输出，这在生产环境中带来了不可预测性。其次是幻觉问题，模型可能生成看似合理但实际错误的内容，这在关键业务场景中是不可接受的。第三是领域知识的泛化性问题，通用模型往往缺乏特定领域的深度精确性。最后是复杂任务的可控性挑战，多步骤任务难以保证每一步都准确执行。

这些挑战的根源在于大模型本质上是一个基于海量数据训练的模式识别和生成系统，而非精确的逻辑执行引擎。因此，解决精确化问题不能简单地期望模型"更聪明"，而需要在架构和方法论层面寻找突破。

三种精确化路径的探索

业界对大模型精确化问题的探索，主要形成了三条技术路径，每条路径都有其独特的思想和适用场景。

路径一：生成精确代码

这是最直观的解决方案：让大模型生成可执行的代码，由代码的确定性执行来保证结果的精确性。核心思路是将自然语言需求转化为编程语言，利用代码的逻辑严密性和执行确定性来实现精确控制。这种方法在数据分析和处理任务、API调用和系统集成、算法实现和计算任务等场景中表现出色。

代码生成路径的优势在于执行结果完全确定且可重复，能够调用外部工具和库从而大幅扩展能力边界，同时代码本身具有可审查、可测试、可维护的特性。然而这种方法也存在明显的局限性。它对模型的代码生成能力要求极高，复杂逻辑的代码生成容易出错，Debug过程困难且错误定位成本高。此外，灵活性受编程语言和环境限制，不适合需要创造性或判断性的任务。

代码生成路径本质上是用确定性系统（代码）替代概率性系统（模型生成），这种方式在特定场景下非常有效，但并非所有问题都适合用代码表达。

路径二：Agent + Workflow编排

图片

随着Agent技术的发展，另一种思路逐渐流行：通过Agent来处理复杂任务的规划和执行，通过Workflow编排来管理多步骤流程。这种方法的核心思路是将复杂任务分解为多个步骤，每个步骤由Agent决策执行，通过工作流引擎编排整体流程。典型应用场景包括复杂的业务流程自动化、需要多轮决策的任务以及涉及多个工具和系统的集成场景。

Agent+Workflow路径的优势在于可以处理复杂的多步骤任务，支持条件分支和循环逻辑，能够整合多种工具和能力，同时状态可追踪、流程可视化。但这种方法也面临挑战：过程式思维使得编排复杂度随任务增长而快速上升，状态管理困难（特别是长流程和并行场景），调试和优化成本高，Agent决策的可靠性仍依赖模型能力，流程固化后缺乏灵活性。

Agent+Workflow路径试图通过流程控制来约束模型行为，这在处理明确的多步骤任务时效果显著，但过程式的编排方式容易陷入复杂性陷阱。

路径三：Skills声明式定义

图片

第三条路径借鉴了云原生领域的声明式设计思想，通过定义Skills来实现大模型能力的精确化。这是一种更为优雅和符合大模型特性的解决方案。核心思路是不告诉模型"怎么做"（How），而是声明"要什么样的能力和约束"（What），让模型在理解意图后自主匹配和应用相应的技能。

这个思路的本质是将核心经验显性化为声明式的知识结构，让大模型在这个结构的引导下实现精确能力。不同于前两种方法试图用确定性流程或代码来"控制"模型，Skills方法是为模型提供一个知识框架，在这个框架内发挥其理解和生成能力。

三种路径的对比分析

Skills：声明式设计在大模型中的实践

什么是声明式设计

在深入Skills之前，让我们回顾云原生领域的声明式设计。以Kubernetes为例，当你想部署一个应用时，不需要告诉系统如何创建容器、如何调度、如何监控，只需要声明"我要3个nginx副本"，系统会自动实现并维持这个状态。你描述的是期望的目标状态，而不是达到目标的具体步骤。

声明式设计具有几个核心特征。首先是关注目标而非过程，描述想要什么而不是如何得到。其次是系统自主决策，具体实现路径由系统根据当前状态和约束条件自行选择。第三是幂等性和收敛性，多次应用相同的声明会产生相同的结果。最后是可组合性，多个声明可以组合形成更复杂的系统。

这种设计思想在云原生领域取得了巨大成功，因为它将"意图"和"实现"解耦，让系统具备了自适应和自愈能力。当我们将这个思想引入大模型领域，会产生什么样的化学反应呢？

Skills如何体现声明式思想

Skills将声明式设计思想引入大模型领域。一个Skills包不是一个固定的执行流程，而是一个经验知识的声明式封装。它通过多个维度来定义一种能力，让模型能够理解、识别并应用这种能力。

首先是Steps，即步骤框架。这不是强制执行的步骤序列，而是建议的思考框架。它提供问题分解的指导性结构，但模型可以根据具体情况灵活调整。就像一个经验丰富的专家在处理问题时，会有一个大致的思维框架，但不会机械地遵循固定步骤。

其次是代码片段（Code Snippets），这些是可复用的实现单元。它们不是完整的程序，而是可组合的知识模块，类似于设计模式中的可复用方案。当遇到特定的子问题时，这些代码片段提供了经过验证的解决方案。

第三个要素是规则（Rules），它们定义了约束和边界条件，明确什么可以做、什么不能做，为模型的决策提供判断依据。规则不是硬编码的逻辑，而是声明式的约束，模型需要在理解这些约束的基础上做出符合规则的决策。

第四个要素是案例（Examples），即具体的问题-解决方案对照。这些案例为模型提供了模式识别的锚点，支持Few-shot学习机制。通过学习这些案例，模型能够理解在什么样的情况下应该如何应用这个Skill。

最后是模板（Templates），即结构化的输出格式定义。模板确保输出的一致性和规范性，降低后处理的复杂度。它不限制内容的创造性，但规范了内容的组织形式。

Skills的工作机制

Skills的工作流程体现了声明式设计的精髓。当用户提出一个需求时，系统首先进行Skills匹配，识别哪些Skills与当前任务相关。然后进行上下文组装，将相关Skills的各个要素（Steps、规则、案例、模板等）组织成一个完整的上下文。模型在理解这个丰富的上下文后，灵活应用相关知识来生成精确的输出。

关键在于理解这个过程中发生了什么：不是执行Skills中的步骤，而是让模型理解Skills所代表的经验模式；不是替代模型思考，而是为模型提供思考的框架和约束；不是固定流程，而是声明式的知识引导。

这个过程类似于一个经验丰富的专家处理问题的方式。专家不需要每次都从零开始思考，而是能够快速识别问题类型，调用大脑中相应的经验模式，然后在这个框架下灵活应对具体情况。专家的经验不是死板的流程图，而是一种结构化的知识和直觉的结合。Skills正是试图将这种专家经验以声明式的方式显性化，让大模型能够"学习"和"应用"这些经验。

Skills相比其他路径的优势

符合大模型的工作原理

大模型的核心能力是模式识别、语义理解和基于上下文的生成。它不是一个逻辑执行引擎，也不是一个状态机，而是一个能够理解语言、识别模式、生成内容的智能系统。Skills通过声明式定义，直接为模型提供了丰富的上下文线索、明确的模式参考和结构化的知识框架。

这种方式充分发挥了大模型的优势，而不是试图让它做不擅长的事情。代码生成要求模型像编译器一样精确，Workflow编排要求模型像状态机一样严格，而Skills则是在模型擅长的"理解和生成"层面上工作，通过提供更好的上下文来引导更精确的输出。

经验的显性化与复用

Skills最大的价值在于将隐性知识显性化。在传统的工作方式中，专家的经验往往存在于个人的大脑中，难以传承和复用。通过Skills，专家的解题思路被结构化为Steps，最佳实践被总结为Rules，成功案例被提取为Examples，输出规范被定义为Templates。

这些显性化的知识具有多重价值。首先它们可以持续积累和迭代，每次实践都可以反馈到Skills的优化中。其次它们可以在团队间共享和传承，新人可以快速学习和掌握最佳实践。第三它们可以进行版本管理和回溯，当出现问题时可以追溯到具体的Skills版本。最重要的是，这些知识形成了可持续增长的知识资产，随着时间推移而不断增值。

灵活性与精确性的平衡

这是Skills最优雅的地方，它实现了看似矛盾的两个目标：精确性和灵活性。通过规则、模板、案例，Skills提供了精确性的约束，确保输出符合预期的标准和规范。但同时，模型仍然可以根据具体情况灵活调整，在框架内进行创造性的思考和生成。Skills明确了边界和约束，但在这个边界内给予了充分的自由度。

这种"柔性的精确"是Skills独特的价值。不同于代码的刚性约束，一旦写死了逻辑就难以适应变化；也不同于Workflow的流程固化，一旦设计好了步骤就难以调整。Skills提供的是一个框架，一个经验的骨架，但具体的血肉由模型根据实际情况来填充。

人机协作的最佳模式

Skills明确了人与模型的分工，形成了一种优雅的协作模式。人类负责的是经验总结、知识结构设计、规则定义，这些是需要专业判断和领域知识的工作。模型负责的是理解意图、匹配技能、灵活应用，这些是AI擅长的大规模模式识别和生成工作。协作方式是声明式交互，而非指令式控制。

人不需要告诉模型每一步怎么做，只需要声明"这类问题需要这样的能力框架"。模型也不是被动地执行指令，而是主动理解和应用知识。这种协作模式既保留了人类的专业判断力，又充分发挥了AI的规模化能力和泛化能力。

Skills的实践挑战与应对策略

尽管Skills思路优雅，但在实际应用中仍面临一些需要解决的挑战。这些挑战不是理论上的问题，而是落地实践中必然会遇到的具体困难。

这些挑战的存在并不意味着Skills方法有根本性缺陷，而是任何新方法在落地过程中都需要建立配套的工程实践和管理机制。随着实践的深入，这些挑战的解决方案会逐渐成熟，形成一套完整的Skills工程方法论。

展望：声明式AI的未来

Skills代表的声明式设计思路，可能不仅仅是解决大模型精确化的一个方案，而是指向了一个更广阔的方向：声明式AI。这是一个值得想象的未来图景。

我们可能会看到Skills市场的出现，就像云原生领域的Helm Charts和Docker Hub一样，形成一个Skills的共享生态系统。各个领域的专家可以将自己的经验封装成Skills并分享，其他人可以直接使用或在此基础上改进。这将极大地加速AI能力的积累和传播。

更高层次的Skills编排能力也会出现。单个Skill解决特定问题，但通过声明式的组合，可以构建更复杂的AI能力。这种组合不是简单的串联，而是声明式地定义Skills之间的协作关系，让系统自动协调多个Skills的配合。

随着技术的发展，我们甚至可能看到AI通过学习自动提炼和生成Skills。系统可以从大量的交互数据中发现模式，自动总结出有效的Skills定义，然后人类专家进行审查和优化。这将形成一个人机协同进化的良性循环。

跨模型的Skills标准也是一个重要方向。理想情况下，同一套Skills定义应该能够适配不同的大模型，就像声明式的配置可以在不同的云平台上运行一样。这需要建立Skills的标准格式和语义规范，但一旦实现，将大大降低切换模型的成本。

这个方向的核心是将人类的经验和AI的能力通过声明式接口优雅地连接起来，形成可持续演进的智能系统。人类负责经验的提炼和知识的组织，AI负责理解和应用，两者通过声明式的Skills定义进行协作。

结语

大模型的精确化问题本质上是如何约束概率系统的问题。代码生成路径用确定性替代概率性，试图绕过模型的不确定性；Agent+Workflow路径用流程控制约束行为，试图用过程控制来限制模型的自由度；而Skills声明式路径则是用知识结构引导智能，在保留模型灵活性的同时实现精确性。

Skills借鉴云原生的声明式设计，将核心经验显性化为Steps、代码片段、规则、案例和模板的组合，形成一个既精确又灵活的能力定义框架。它不是让大模型执行固定流程，而是为其提供思考的框架和知识的锚点，让模型在理解的基础上实现精确应用。

这种思路最符合大模型的工作原理，因为它发挥了模型在理解、匹配、生成方面的优势。它实现了灵活性与精确性的优雅平衡，在约束和自由之间找到了最佳平衡点。它为人机协作提供了最自然的接口，明确了分工又促进了协同。最重要的是，它能够将经验转化为可积累、可复用、可演进的知识资产，这是一个可持续发展的方向。

声明式设计在云原生领域的成功已经证明了这一思想的强大生命力。当我们将它引入AI领域，通过Skills来定义和管理大模型的能力时，我们不仅解决了精确化这个具体问题，更开启了通往声明式AI的大门。这是一条值得深入探索的道路，它可能将重新定义我们与AI协作的方式，让AI真正成为可以依赖的生产力工具。

大模型时代才刚刚开始，我们需要更多像Skills这样的方法论创新，将工程实践的智慧与AI技术的能力结合起来。声明式设计为我们提供了一个优雅的思路，接下来需要的是更多的实践探索和经验积累。让我们拭目以待，看声明式AI如何改变未来的智能系统构建方式。