尧图网站建设 
你是不是也遇到过这样的场景团队里每个人都在用大模型每个人也都有自己的“独门提示词”。张三写了一个能精准分析日志的Prompt李四调出了一个能生成高质量SQL的Prompt王五甚至搞定了复杂的代码重构提示词。大家各自为战效率看似很高直到有一天产品经理提了个新需求需要把日志分析、SQL生成和代码检查串联成一个自动化流程。这时问题来了张三的Prompt在他本地文档里李四的在他个人笔记里王五的甚至只存在于某次聊天记录中。你想复用得一个个去要还得理解他们那套“黑话”般的上下文设定。更可怕的是当基础模型升级或者业务逻辑变化需要统一优化某个Prompt时你不得不通知所有人“请大家更新一下自己本地那个叫‘终极分析V2’的文档”。结果可想而知版本混乱、步调不一所谓的“知识沉淀”成了一盘散沙。这就是标题里那个经典面试题的残酷现实把Prompt存个文档根本不是工程化而是埋下了协作的灾难。当团队规模超过一个人当应用场景从单点尝试走向系统集成Prompt的管理问题就会指数级放大。那么真正的解决方案是什么最近技术圈高频出现的“Skill”概念或许给出了答案。但Skill究竟是什么是高级版的Prompt吗还是又一个炒作的概念本文将为你彻底厘清Prompt与Skill的本质区别并提供一个从零开始将散落的Prompt工程经验沉淀为团队可复用、可协作、可迭代的Skill体系的完整实战方案。这不是纸上谈兵而是涉及版本管理、测试验证和集成部署的完整工程实践。1. 核心问题为什么“存文档”是Prompt工程化的死胡同在深入Skill之前我们必须先诊断“存文档”模式为何失败。这不仅仅是管理问题更是技术债问题。1.1 协作之痛合并冲突与上下文丢失想象一下团队10个人维护同一个Word文档里的Prompt。A同学优化了角色设定B同学调整了输出格式C同学补充了新的示例。当他们同时编辑并保存时要么互相覆盖要么需要手动进行繁琐的合并。更关键的是Prompt往往不是孤立的文本它包含系统指令System Role模型的初始人设和约束。用户输入模板包含占位符如{user_input},{table_schema}的结构。少量示例Few-shot Examples直接影响模型输出的关键样本。外部知识/工具调用说明何时以及如何调用检索API、计算器等。这些元素在纯文本文档中难以结构化地管理和标注。当新人接手时他需要从一大段文字中自行脑补出这些隐式的结构和依赖关系。1.2 迭代之困无法测试与效果回溯你今天修改了Prompt中的一个形容词模型的输出从“不错”变成了“优秀”。这真的是你这个修改带来的吗还是因为模型本身的不确定性没有测试套件和版本对照Prompt的迭代就像闭着眼睛调整参数全凭感觉。你无法回答这个Prompt在100个历史用例上的平均表现如何相比上一版准确率/满意度提升了多少修改是否引入了新的错误模式如过度格式化1.3 集成之难难以被程序调用一个成熟的AI应用Agent其工作流往往由多个步骤串联而成。例如“分析需求 - 查询数据库 - 生成报告”。每个步骤都可能对应一个优化过的Prompt。如果这些Prompt都躺在文档里开发者在构建应用时就需要手动复制粘贴这些文本到代码中硬编码成字符串变量。这导致代码与Prompt耦合改Prompt需要改代码并重新部署。缺乏动态配置无法根据运行环境开发/测试/生产或用户偏好切换不同的Prompt版本。无法中心化管理无法统计各个Prompt的使用频率和效果。因此Prompt工程化的目标不是找一个更好的文档工具如Notion或飞书而是将Prompt提升为一种可版本化、可测试、可配置、可编程的软件资产。这就是Skill要解决的问题。2. 概念厘清Prompt、Skill与Agent到底是什么关系网络热词中充斥着“Skill是不是高级版的Prompt”的疑问。这里必须正本清源。2.1 Prompt提示词最基础的交互指令Prompt是与大模型进行一次对话的完整输入文本。它包含了让模型完成特定任务所需的全部信息。其核心是“一次性”的。# 一个简单的Prompt示例Python字符串 customer_service_prompt 你是一个专业的客服助手。请用友好、耐心的语气回答用户问题。 用户问题{user_query} 请根据以上知识库回答问题 {knowledge_base} 2.2 Skill技能可复用的Prompt执行单元Skill是对一个或多个相关Prompt的封装、增强和工程化。它不仅仅是一个文本模板而是一个包含以下要素的可执行模块核心Prompt模板带有参数占位符。输入/输出模式Schema明确定义输入参数的类型、格式和约束以及输出结果的格式如JSON。前置/后置处理逻辑可能在调用模型前对输入进行加工如检索知识或在得到输出后进行清洗、验证。版本与元数据作者、描述、测试用例、性能指标。依赖声明可能依赖其他Skill或外部工具如计算器、搜索引擎。简单类比Prompt像是一段写在纸上的“菜谱”Recipe。Skill则像是封装好的“预制菜”或“烹饪工具包”里面有按比例配好的食材参数化Prompt、标准的操作流程处理逻辑、以及确保成品质量的说明书Schema和测试。2.3 Agent智能体Skill的编排与调度者Agent是更高层次的抽象它是一个能够自主或半自主地使用多个Skill和工具来完成复杂目标的系统。Agent的核心能力是规划Planning和工具调用Tool Use。规划将复杂目标拆解为一系列子任务对应到不同的Skill。工具调用根据当前状态决定调用哪个Skill或外部API并处理它们之间的数据传递。关系总结Prompt是原材料Skill是标准化、封装好的功能组件Agent是组装和调度这些组件来完成复杂任务的“大脑”或“工作流引擎”。开发Skill就是为Agent制造可靠、可复用的乐高积木。3. 环境准备从零搭建Skill开发与管理的基础设施理论讲完我们进入实战。要管理Skill首先需要合适的“工具箱”。我们不依赖任何特定商业平台而是用开源和标准化的方式搭建。3.1 核心工具选型版本控制系统 (VCS)Git。这是基石用于管理Skill的源代码Prompt模板、配置文件、测试用例。包管理器/仓库可选但推荐考虑到Skill可能被多个项目复用可以借鉴软件包的管理思想。简单起步可以用文件系统Git子模块进阶可使用支持任意文件类型的包仓库如AWS S3索引文件或自建简单HTTP服务。对于Python生态甚至可以将Skill打包成pip包。测试框架pytest。我们需要自动化测试来验证Skill的效果。开发框架选择一个大模型应用开发框架它们通常提供了Skill/ Tool的抽象。主流选择有LangChain生态最丰富Tool和Runnable的概念与Skill高度契合。LlamaIndex长于数据连接和检索其QueryEngine可视为一种Skill。Semantic Kernel(微软)强于规划和技能编排。DSPy强调通过编程来优化Prompt其Module很适合构建可训练的Skill。 本文将以LangChain为例因为它受众最广抽象层次适中。3.2 初始化项目结构创建一个标准的Python项目这是所有Skill的家。mkdir ai-skill-repo cd ai-skill-repo python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install langchain langchain-openai pytest python-dotenv创建项目目录结构ai-skill-repo/ ├── skills/ # 所有Skill存放于此 │ ├── __init__.py │ ├── data_analysis/ # 按领域或功能分组 │ │ ├── __init__.py │ │ ├── skill_log_analyzer.py │ │ └── test_log_analyzer.py │ └── code_generation/ │ ├── __init__.py │ ├── skill_sql_generator.py │ └── test_sql_generator.py ├── shared/ # 共享资源 │ ├── prompts/ # 存放纯Prompt模板文件(.txt, .yaml) │ ├── schemas/ # 输入输出数据模型定义 │ └── utils.py # 通用工具函数 ├── .env # 环境变量如API密钥 ├── .gitignore ├── requirements.txt └── README.md关键点将Skill实现Python类、Prompt模板文本文件、测试用例分离符合关注点分离原则。3.3 配置大模型连接在.env文件中配置你的大模型密钥以OpenAI为例OPENAI_API_KEYsk-你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 # 或你的代理地址 MODEL_NAMEgpt-4o-mini # 根据实际情况选择模型创建一个基础配置模块shared/config.py# shared/config.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() def get_llm(model_name: str None, temperature: float 0.1): 获取配置好的LLM实例。 model model_name or os.getenv(MODEL_NAME, gpt-4o-mini) return ChatOpenAI( modelmodel, temperaturetemperature, api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), )安全提醒永远不要将API密钥硬编码在代码中或提交到Git仓库。.env文件必须列入.gitignore。4. 实战将你的第一个Prompt工程化为Skill我们以一个具体的场景为例将一段分析服务器日志错误原因的Prompt改造成一个可复用的Skill。4.1 原始Prompt文档中的样子你是一个资深的运维专家。请分析以下服务器错误日志找出最可能的根本原因并提供解决步骤。 日志内容 [ERROR] 2023-10-27 14:32:01.234 Database connection pool exhausted. Active: 100, Max: 100, WaitCount: 15. [WARN] 2023-10-27 14:31:58.123 High memory usage detected: 95%. [ERROR] 2023-10-27 14:32:05.678 Query timeout after 300s. 请按以下格式回答 根本原因 1. ... 2. ... 解决步骤 1. ... 2. ...这个Prompt很有效但它被“写死”了。日志内容是硬编码的。4.2 第一步抽象与参数化将可变的“日志内容”提取为参数。我们创建一个Prompt模板文件。# shared/prompts/log_analysis.txt 你是一个资深的运维专家。请分析以下服务器错误日志找出最可能的根本原因并提供解决步骤。 日志内容 {log_text} 请按以下格式回答 根本原因 1. ... 2. ... 解决步骤 1. ... 2. ...4.3 第二步定义严格的输入输出契约Schema使用Pydantic模型来定义Skill的“接口”。这能确保调用者传入正确的数据并对模型输出进行结构化解析。# shared/schemas/log_analysis.py from pydantic import BaseModel, Field from typing import List class LogAnalysisInput(BaseModel): 日志分析Skill的输入参数。 log_text: str Field(description需要分析的原始日志文本) severity_filter: str Field(defaultERROR,WARN, description关注的日志级别逗号分隔) class LogAnalysisOutput(BaseModel): 日志分析Skill的结构化输出。 root_causes: List[str] Field(description分析出的根本原因列表) solution_steps: List[str] Field(description建议的解决步骤) confidence: float Field(description分析结果的置信度0-1之间, ge0, le1)为什么需要Schema它强制了接口规范方便自动化测试并且能配合LangChain的with_structured_output功能让模型直接输出JSON对象极大简化后续处理。4.4 第三步实现Skill类现在我们创建真正的Skill类它封装了Prompt、LLM调用和输入输出处理。# skills/data_analysis/skill_log_analyzer.py import os from typing import Dict, Any from langchain.prompts import PromptTemplate from langchain_core.runnables import RunnablePassthrough from shared.schemas.log_analysis import LogAnalysisInput, LogAnalysisOutput from shared.config import get_llm class LogAnalysisSkill: 服务器日志分析技能。 name log_analyzer version 1.0.0 description 分析服务器错误日志定位根本原因并提供解决步骤。 def __init__(self): # 1. 加载Prompt模板 prompt_path os.path.join(os.path.dirname(__file__), ../../shared/prompts/log_analysis.txt) with open(prompt_path, r, encodingutf-8) as f: template f.read() self.prompt_template PromptTemplate.from_template(template) # 2. 初始化LLM并绑定输出结构 self.llm get_llm(temperature0.1) # 关键让LLM按照我们定义的Pydantic模型输出 self.structured_llm self.llm.with_structured_output(LogAnalysisOutput) # 3. 构建可执行链 self.chain ( RunnablePassthrough() # 传递输入 | self.prompt_template # 应用Prompt模板 | self.structured_llm # 调用LLM并解析为结构化对象 ) def invoke(self, input_data: Dict[str, Any]) - LogAnalysisOutput: 执行技能。 # 验证输入可选LangChain链本身会处理 # 这里可以加入前置处理比如根据severity_filter过滤日志行 processed_input self._preprocess(input_data) # 执行链 result: LogAnalysisOutput self.chain.invoke(processed_input) # 后置处理可选 result self._postprocess(result) return result def _preprocess(self, input_data: Dict[str, Any]) - Dict[str, str]: 输入预处理。例如过滤日志级别。 # 这里实现具体的过滤逻辑为简化示例直接返回 return {log_text: input_data.get(log_text, )} def _postprocess(self, output: LogAnalysisOutput) - LogAnalysisOutput: 输出后处理。例如对置信度进行校准。 # 这里可以添加业务逻辑 return output # 提供一个方便的工厂函数 def create_skill(): return LogAnalysisSkill()代码解读__init__方法初始化时加载外部Prompt文件、创建LLM、并将它们组合成一个可执行的chain。使用with_structured_output是关键它确保了输出的规范性。invoke方法对外的统一接口。接收字典输入返回结构化的LogAnalysisOutput对象。预留了_preprocess和_postprocess钩子这是Skill比纯Prompt强大的地方——可以嵌入任何业务逻辑。4.5 第四步编写自动化测试一个没有测试的Skill是不可靠的。我们为它编写单元测试。# skills/data_analysis/test_log_analyzer.py import pytest from .skill_log_analyzer import LogAnalysisSkill class TestLogAnalysisSkill: pytest.fixture def skill(self): 创建Skill实例的Fixture。 return LogAnalysisSkill() def test_skill_invocation(self, skill): 测试Skill基本调用。 test_log [ERROR] Database connection pool exhausted. Active: 100, Max: 100. [WARN] High memory usage detected: 95%. input_data {log_text: test_log} result skill.invoke(input_data) # 断言输出符合Schema assert hasattr(result, root_causes) assert hasattr(result, solution_steps) assert hasattr(result, confidence) assert isinstance(result.root_causes, list) assert isinstance(result.solution_steps, list) assert 0 result.confidence 1 # 可以添加更具体的断言例如检查结果是否包含关键词 assert len(result.root_causes) 0 assert connection in .join(result.root_causes).lower() or memory in .join(result.root_causes).lower() def test_skill_with_empty_log(self, skill): 测试边界情况空日志。 input_data {log_text: } result skill.invoke(input_data) # 检查Skill是否能妥善处理空输入 assert isinstance(result.root_causes, list) # 可能输出“未发现明显错误”之类的根因运行测试pytest skills/data_analysis/test_log_analyzer.py -v5. Skill的进阶版本管理、依赖与组合单个Skill解决了复用问题但要应对复杂场景我们还需要管理Skill的版本、依赖和组合。5.1 版本管理Git 语义化版本每个Skill目录下可以有一个skill_manifest.yaml文件记录元数据。# skills/data_analysis/skill_manifest.yaml name: log_analyzer version: 1.0.1 description: 分析服务器错误日志定位根本原因并提供解决步骤。 author: DevTeam created_date: 2023-10-27 input_schema: shared/schemas/log_analysis.py::LogAnalysisInput output_schema: shared/schemas/log_analysis.py::LogAnalysisOutput prompt_template: ../../shared/prompts/log_analysis.txt dependencies: - name: shared_utils version: ^1.2.0 changelog: - version: 1.0.1 date: 2023-10-28 changes: 优化了空日志的处理逻辑。 - version: 1.0.0 date: 2023-10-27 changes: 初始版本。版本控制策略主分支main存放稳定、经过测试的Skill版本。特性分支feature/*开发新Skill或修改现有Skill。发布标签v1.0.0为每个正式版本打上Git Tag。 当需要升级Prompt或逻辑时修改代码和模板更新version提交并创建Pull Request通过测试后合并。团队所有成员都通过Git拉取最新版本。5.2 Skill依赖构建技能图谱复杂的Skill可以依赖其他基础Skill。例如一个“事故报告生成Skill”可能依赖“日志分析Skill”和“指标查询Skill”。# skills/incident_report/skill_incident_reporter.py from skills.data_analysis.skill_log_analyzer import LogAnalysisSkill from skills.metrics.skill_metric_fetcher import MetricFetcherSkill class IncidentReporterSkill: def __init__(self): self.log_analyzer LogAnalysisSkill() self.metric_fetcher MetricFetcherSkill() # ... 自己的Prompt和LLM链 def invoke(self, incident_data): # 1. 调用依赖Skill log_analysis_result self.log_analyzer.invoke({log_text: incident_data[logs]}) metric_result self.metric_fetcher.invoke({query: incident_data[metric_query]}) # 2. 组合结果生成最终报告 combined_input f 日志分析结果{log_analysis_result.root_causes} 系统指标{metric_result.values} 请生成一份给管理层的简要事故报告。 # ... 调用自己的LLM链处理combined_input这要求Skill的接口输入输出必须稳定。一旦修改了LogAnalysisSkill的输出Schema所有依赖它的Skill都可能需要调整。这恰恰体现了工程化的必要性——通过接口契约和版本号来管理变更。5.3 在Agent中编排Skill最终我们的Skill会被Agent调用。以下是一个使用LangChain的简单Agent示例它根据用户问题自动选择并调用合适的Skill。# agent/simple_router_agent.py from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from skills.data_analysis.skill_log_analyzer import create_skill as create_log_skill from skills.code_generation.skill_sql_generator import create_skill as create_sql_skill from shared.config import get_llm # 1. 将Skill包装成LangChain Tool from langchain.tools import Tool log_skill create_log_skill() sql_skill create_sql_skill() tools [ Tool( namelog_skill.name, descriptionlog_skill.description, funclambda q: log_skill.invoke({log_text: q}).dict(), # 注意适配输入格式 ), Tool( namesql_skill.name, descriptionsql_skill.description, funclambda q: sql_skill.invoke({natural_language_query: q}).dict(), ), ] # 2. 创建Agent提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以调用工具来帮助用户。请根据用户问题决定是否调用工具以及调用哪个工具。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 3. 创建Agent和Executor llm get_llm(temperature0) agent create_tool_calling_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 4. 运行Agent result agent_executor.invoke({ input: 帮我分析一下这段日志数据库连接失败错误码1045, }) print(result[output])在这个架构中Agent是协调者Skill/Tool是执行者。每个Skill都通过标准的invoke方法提供服务实现了彻底的解耦。6. 运行验证与效果评估部署Skill后如何验证它工作正常并持续监控效果6.1 构建验收测试集为每个Skill维护一个validation_set.json包含典型输入和期望输出的关键特征。[ { input: {log_text: [ERROR] Disk full on /var/log}, expected_output_features: { root_causes_contain: [disk, space], solution_steps_contain: [cleanup, expand] } }, { input: {log_text: [ERROR] Syntax error in SQL at line 1}, expected_output_features: { root_causes_contain: [sql, syntax], solution_steps_contain: [check, query] } } ]编写一个自动化脚本定期如每日运行这些测试用例对比实际输出和期望特征计算通过率。6.2 集成评估框架对于更严肃的场景可以使用专门的LLM评估框架如RAGAS、LlamaIndex的Evaluation模块或LangSmith。它们可以自动化评估忠实度Faithfulness输出是否基于给定输入日志相关性Relevance分析的原因和步骤是否与日志相关有帮助性Helpfulness人类评分者认为结果是否有用6.3 线上监控与反馈闭环在生产环境中记录每次Skill调用的输入参数脱敏后输出结果耗时用户反馈如果有 这些数据可用于发现Bad Case定位Skill失效的场景。效果分析统计不同版本Skill的指标如平均置信度、用户满意率。数据驱动迭代基于高频Bad Case构造新的测试用例和训练数据反向优化Prompt。7. 常见问题与排查思路在Skill化过程中你会遇到一些典型问题。问题现象可能原因排查方式解决方案Skill调用返回非结构化文本而非Pydantic对象。1. LLM未成功绑定with_structured_output。2. Prompt未引导模型输出正确JSON。3. 输出格式过于复杂模型无法理解。1. 检查Skill初始化代码确认structured_llm配置正确。2. 打印出发送给模型的完整Prompt检查指令是否清晰。3. 简化输出Schema或提供更详细的示例。1. 确保使用支持结构化输出的模型如gpt-4系列。2. 在Prompt中明确要求输出JSON并给出示例。3. 使用response_format参数如果API支持。多个Skill组合时数据传递出错。1. 上游Skill的输出Schema与下游Skill的输入Schema不匹配。2. 数据预处理/后处理逻辑有误。1. 打印每个Skill的输入和输出对比数据类型和结构。2. 编写集成测试模拟完整数据流。1. 明确定义团队内部的“通用数据契约”。2. 在Skill的invoke方法入口和出口添加数据验证如使用Pydantic的validate_call装饰器。版本更新后依赖该Skill的其他服务报错。发生了破坏性变更Breaking Change如修改了输出字段名或类型。1. 查看Git提交历史和Changelog。2. 回滚到上一个可用版本确认问题。1.严格遵守语义化版本修改接口时升级主版本号。2.建立集成测试流水线在合并前自动测试所有依赖该Skill的服务。3. 考虑版本共存新版本Skill部署为新端点旧版本暂时保留。Prompt效果不稳定时好时坏。1. 模型温度temperature设置过高。2. Prompt中存在歧义或过于开放的指令。3. 输入数据差异过大。1. 固定随机种子如果API支持进行测试。2. 进行A/B测试对比不同Prompt版本在相同测试集上的表现。3. 分析Bad Case寻找输入数据的共同模式。1. 将temperature调低如0.1以获得更确定性的输出。2. 使用更具体、更详细的指令并提供更多Few-shot示例。3. 对输入进行归一化或分类对不同类型的输入使用不同的子Skill。Skill执行速度慢。1. LLM API调用延迟高。2. 前置处理如检索耗时过长。3. 网络问题。1. 使用监控工具记录每个环节的耗时。2. 检查是否有不必要的串行调用。1. 考虑缓存Cache常见输入的结果。2. 对于可并行操作使用异步调用。3. 优化前置处理逻辑或设置超时。8. 最佳实践与工程建议将Prompt工程沉淀为Skill是一个系统工程以下最佳实践能帮你少走弯路。8.1 设计原则单一职责一个Skill只做好一件事。不要设计一个既能分析日志又能生成SQL的“巨无霸”Skill。明确契约使用Pydantic等工具严格定义输入输出Schema这是Skill之间协作的基石。无状态设计Skill本身不应维护会话状态。状态应由上层的Agent或应用来管理。配置外置将Prompt模板、模型参数、温度等配置放在外部文件如YAML中便于动态调整。8.2 开发流程设计阶段明确Skill的输入、输出、功能边界。编写接口文档Schema。实现阶段创建Skill类编写核心Prompt和逻辑。同时编写单元测试。测试阶段在多样化测试集上验证效果包括边界用例和对抗性输入。评审阶段代码评审Code Review和Prompt评审Prompt Review同样重要。关注Prompt的清晰度、安全性和潜在偏见。发布阶段更新版本号提交Git打上标签。更新Skill目录的清单Manifest文件。监控阶段上线后收集使用数据和反馈为下一次迭代做准备。8.3 团队协作规范中心化仓库所有Skill代码和Prompt模板必须存放在唯一的Git仓库中禁止本地私有副本。Pull Request流程任何修改必须通过PR并至少需要一名其他成员评审。变更日志每次版本更新必须在CHANGELOG.md或Skill清单中记录修改内容、影响范围和升级指南。文档即代码Skill的描述、接口、示例用法应作为代码注释或Markdown文件一并提交。8.4 安全与合规输入净化对用户输入进行必要的清洗和检查防止Prompt注入攻击。输出过滤对模型的输出进行安全检查过滤不当内容。权限控制在Skill调用层实现权限校验确保只有授权用户或服务能调用敏感Skill如数据库操作。审计日志记录所有Skill的调用记录便于溯源和合规审查。从“存文档”到“建Skill”本质上是将AI能力从个人手工作坊式的技巧转变为团队工业化生产的组件。它初期会带来一些学习成本和工程开销但当你需要维护数十个Prompt、需要它们稳定协作、需要新成员快速上手时这套体系的价值将无可替代。它解决的不仅是同步问题更是质量、效率和规模化的问题。下一步你可以尝试将团队现有的核心Prompt逐步迁移到Skill架构并探索更高级的特性如Skill的自动发现与注册、基于向量数据库的Skill语义检索、以及利用LLM自动生成和优化Skill的Prompt。真正的AI工程化才刚刚开始。 从Prompt到Skill：构建可复用、可测试的AI技能工程化实战指南
你是不是也遇到过这样的场景团队里每个人都在用大模型每个人也都有自己的“独门提示词”。张三写了一个能精准分析日志的Prompt李四调出了一个能生成高质量SQL的Prompt王五甚至搞定了复杂的代码重构提示词。大家各自为战效率看似很高直到有一天产品经理提了个新需求需要把日志分析、SQL生成和代码检查串联成一个自动化流程。这时问题来了张三的Prompt在他本地文档里李四的在他个人笔记里王五的甚至只存在于某次聊天记录中。你想复用得一个个去要还得理解他们那套“黑话”般的上下文设定。更可怕的是当基础模型升级或者业务逻辑变化需要统一优化某个Prompt时你不得不通知所有人“请大家更新一下自己本地那个叫‘终极分析V2’的文档”。结果可想而知版本混乱、步调不一所谓的“知识沉淀”成了一盘散沙。这就是标题里那个经典面试题的残酷现实把Prompt存个文档根本不是工程化而是埋下了协作的灾难。当团队规模超过一个人当应用场景从单点尝试走向系统集成Prompt的管理问题就会指数级放大。那么真正的解决方案是什么最近技术圈高频出现的“Skill”概念或许给出了答案。但Skill究竟是什么是高级版的Prompt吗还是又一个炒作的概念本文将为你彻底厘清Prompt与Skill的本质区别并提供一个从零开始将散落的Prompt工程经验沉淀为团队可复用、可协作、可迭代的Skill体系的完整实战方案。这不是纸上谈兵而是涉及版本管理、测试验证和集成部署的完整工程实践。1. 核心问题为什么“存文档”是Prompt工程化的死胡同在深入Skill之前我们必须先诊断“存文档”模式为何失败。这不仅仅是管理问题更是技术债问题。1.1 协作之痛合并冲突与上下文丢失想象一下团队10个人维护同一个Word文档里的Prompt。A同学优化了角色设定B同学调整了输出格式C同学补充了新的示例。当他们同时编辑并保存时要么互相覆盖要么需要手动进行繁琐的合并。更关键的是Prompt往往不是孤立的文本它包含系统指令System Role模型的初始人设和约束。用户输入模板包含占位符如{user_input},{table_schema}的结构。少量示例Few-shot Examples直接影响模型输出的关键样本。外部知识/工具调用说明何时以及如何调用检索API、计算器等。这些元素在纯文本文档中难以结构化地管理和标注。当新人接手时他需要从一大段文字中自行脑补出这些隐式的结构和依赖关系。1.2 迭代之困无法测试与效果回溯你今天修改了Prompt中的一个形容词模型的输出从“不错”变成了“优秀”。这真的是你这个修改带来的吗还是因为模型本身的不确定性没有测试套件和版本对照Prompt的迭代就像闭着眼睛调整参数全凭感觉。你无法回答这个Prompt在100个历史用例上的平均表现如何相比上一版准确率/满意度提升了多少修改是否引入了新的错误模式如过度格式化1.3 集成之难难以被程序调用一个成熟的AI应用Agent其工作流往往由多个步骤串联而成。例如“分析需求 - 查询数据库 - 生成报告”。每个步骤都可能对应一个优化过的Prompt。如果这些Prompt都躺在文档里开发者在构建应用时就需要手动复制粘贴这些文本到代码中硬编码成字符串变量。这导致代码与Prompt耦合改Prompt需要改代码并重新部署。缺乏动态配置无法根据运行环境开发/测试/生产或用户偏好切换不同的Prompt版本。无法中心化管理无法统计各个Prompt的使用频率和效果。因此Prompt工程化的目标不是找一个更好的文档工具如Notion或飞书而是将Prompt提升为一种可版本化、可测试、可配置、可编程的软件资产。这就是Skill要解决的问题。2. 概念厘清Prompt、Skill与Agent到底是什么关系网络热词中充斥着“Skill是不是高级版的Prompt”的疑问。这里必须正本清源。2.1 Prompt提示词最基础的交互指令Prompt是与大模型进行一次对话的完整输入文本。它包含了让模型完成特定任务所需的全部信息。其核心是“一次性”的。# 一个简单的Prompt示例Python字符串 customer_service_prompt 你是一个专业的客服助手。请用友好、耐心的语气回答用户问题。 用户问题{user_query} 请根据以上知识库回答问题 {knowledge_base} 2.2 Skill技能可复用的Prompt执行单元Skill是对一个或多个相关Prompt的封装、增强和工程化。它不仅仅是一个文本模板而是一个包含以下要素的可执行模块核心Prompt模板带有参数占位符。输入/输出模式Schema明确定义输入参数的类型、格式和约束以及输出结果的格式如JSON。前置/后置处理逻辑可能在调用模型前对输入进行加工如检索知识或在得到输出后进行清洗、验证。版本与元数据作者、描述、测试用例、性能指标。依赖声明可能依赖其他Skill或外部工具如计算器、搜索引擎。简单类比Prompt像是一段写在纸上的“菜谱”Recipe。Skill则像是封装好的“预制菜”或“烹饪工具包”里面有按比例配好的食材参数化Prompt、标准的操作流程处理逻辑、以及确保成品质量的说明书Schema和测试。2.3 Agent智能体Skill的编排与调度者Agent是更高层次的抽象它是一个能够自主或半自主地使用多个Skill和工具来完成复杂目标的系统。Agent的核心能力是规划Planning和工具调用Tool Use。规划将复杂目标拆解为一系列子任务对应到不同的Skill。工具调用根据当前状态决定调用哪个Skill或外部API并处理它们之间的数据传递。关系总结Prompt是原材料Skill是标准化、封装好的功能组件Agent是组装和调度这些组件来完成复杂任务的“大脑”或“工作流引擎”。开发Skill就是为Agent制造可靠、可复用的乐高积木。3. 环境准备从零搭建Skill开发与管理的基础设施理论讲完我们进入实战。要管理Skill首先需要合适的“工具箱”。我们不依赖任何特定商业平台而是用开源和标准化的方式搭建。3.1 核心工具选型版本控制系统 (VCS)Git。这是基石用于管理Skill的源代码Prompt模板、配置文件、测试用例。包管理器/仓库可选但推荐考虑到Skill可能被多个项目复用可以借鉴软件包的管理思想。简单起步可以用文件系统Git子模块进阶可使用支持任意文件类型的包仓库如AWS S3索引文件或自建简单HTTP服务。对于Python生态甚至可以将Skill打包成pip包。测试框架pytest。我们需要自动化测试来验证Skill的效果。开发框架选择一个大模型应用开发框架它们通常提供了Skill/ Tool的抽象。主流选择有LangChain生态最丰富Tool和Runnable的概念与Skill高度契合。LlamaIndex长于数据连接和检索其QueryEngine可视为一种Skill。Semantic Kernel(微软)强于规划和技能编排。DSPy强调通过编程来优化Prompt其Module很适合构建可训练的Skill。 本文将以LangChain为例因为它受众最广抽象层次适中。3.2 初始化项目结构创建一个标准的Python项目这是所有Skill的家。mkdir ai-skill-repo cd ai-skill-repo python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install langchain langchain-openai pytest python-dotenv创建项目目录结构ai-skill-repo/ ├── skills/ # 所有Skill存放于此 │ ├── __init__.py │ ├── data_analysis/ # 按领域或功能分组 │ │ ├── __init__.py │ │ ├── skill_log_analyzer.py │ │ └── test_log_analyzer.py │ └── code_generation/ │ ├── __init__.py │ ├── skill_sql_generator.py │ └── test_sql_generator.py ├── shared/ # 共享资源 │ ├── prompts/ # 存放纯Prompt模板文件(.txt, .yaml) │ ├── schemas/ # 输入输出数据模型定义 │ └── utils.py # 通用工具函数 ├── .env # 环境变量如API密钥 ├── .gitignore ├── requirements.txt └── README.md关键点将Skill实现Python类、Prompt模板文本文件、测试用例分离符合关注点分离原则。3.3 配置大模型连接在.env文件中配置你的大模型密钥以OpenAI为例OPENAI_API_KEYsk-你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 # 或你的代理地址 MODEL_NAMEgpt-4o-mini # 根据实际情况选择模型创建一个基础配置模块shared/config.py# shared/config.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() def get_llm(model_name: str None, temperature: float 0.1): 获取配置好的LLM实例。 model model_name or os.getenv(MODEL_NAME, gpt-4o-mini) return ChatOpenAI( modelmodel, temperaturetemperature, api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), )安全提醒永远不要将API密钥硬编码在代码中或提交到Git仓库。.env文件必须列入.gitignore。4. 实战将你的第一个Prompt工程化为Skill我们以一个具体的场景为例将一段分析服务器日志错误原因的Prompt改造成一个可复用的Skill。4.1 原始Prompt文档中的样子你是一个资深的运维专家。请分析以下服务器错误日志找出最可能的根本原因并提供解决步骤。 日志内容 [ERROR] 2023-10-27 14:32:01.234 Database connection pool exhausted. Active: 100, Max: 100, WaitCount: 15. [WARN] 2023-10-27 14:31:58.123 High memory usage detected: 95%. [ERROR] 2023-10-27 14:32:05.678 Query timeout after 300s. 请按以下格式回答 根本原因 1. ... 2. ... 解决步骤 1. ... 2. ...这个Prompt很有效但它被“写死”了。日志内容是硬编码的。4.2 第一步抽象与参数化将可变的“日志内容”提取为参数。我们创建一个Prompt模板文件。# shared/prompts/log_analysis.txt 你是一个资深的运维专家。请分析以下服务器错误日志找出最可能的根本原因并提供解决步骤。 日志内容 {log_text} 请按以下格式回答 根本原因 1. ... 2. ... 解决步骤 1. ... 2. ...4.3 第二步定义严格的输入输出契约Schema使用Pydantic模型来定义Skill的“接口”。这能确保调用者传入正确的数据并对模型输出进行结构化解析。# shared/schemas/log_analysis.py from pydantic import BaseModel, Field from typing import List class LogAnalysisInput(BaseModel): 日志分析Skill的输入参数。 log_text: str Field(description需要分析的原始日志文本) severity_filter: str Field(defaultERROR,WARN, description关注的日志级别逗号分隔) class LogAnalysisOutput(BaseModel): 日志分析Skill的结构化输出。 root_causes: List[str] Field(description分析出的根本原因列表) solution_steps: List[str] Field(description建议的解决步骤) confidence: float Field(description分析结果的置信度0-1之间, ge0, le1)为什么需要Schema它强制了接口规范方便自动化测试并且能配合LangChain的with_structured_output功能让模型直接输出JSON对象极大简化后续处理。4.4 第三步实现Skill类现在我们创建真正的Skill类它封装了Prompt、LLM调用和输入输出处理。# skills/data_analysis/skill_log_analyzer.py import os from typing import Dict, Any from langchain.prompts import PromptTemplate from langchain_core.runnables import RunnablePassthrough from shared.schemas.log_analysis import LogAnalysisInput, LogAnalysisOutput from shared.config import get_llm class LogAnalysisSkill: 服务器日志分析技能。 name log_analyzer version 1.0.0 description 分析服务器错误日志定位根本原因并提供解决步骤。 def __init__(self): # 1. 加载Prompt模板 prompt_path os.path.join(os.path.dirname(__file__), ../../shared/prompts/log_analysis.txt) with open(prompt_path, r, encodingutf-8) as f: template f.read() self.prompt_template PromptTemplate.from_template(template) # 2. 初始化LLM并绑定输出结构 self.llm get_llm(temperature0.1) # 关键让LLM按照我们定义的Pydantic模型输出 self.structured_llm self.llm.with_structured_output(LogAnalysisOutput) # 3. 构建可执行链 self.chain ( RunnablePassthrough() # 传递输入 | self.prompt_template # 应用Prompt模板 | self.structured_llm # 调用LLM并解析为结构化对象 ) def invoke(self, input_data: Dict[str, Any]) - LogAnalysisOutput: 执行技能。 # 验证输入可选LangChain链本身会处理 # 这里可以加入前置处理比如根据severity_filter过滤日志行 processed_input self._preprocess(input_data) # 执行链 result: LogAnalysisOutput self.chain.invoke(processed_input) # 后置处理可选 result self._postprocess(result) return result def _preprocess(self, input_data: Dict[str, Any]) - Dict[str, str]: 输入预处理。例如过滤日志级别。 # 这里实现具体的过滤逻辑为简化示例直接返回 return {log_text: input_data.get(log_text, )} def _postprocess(self, output: LogAnalysisOutput) - LogAnalysisOutput: 输出后处理。例如对置信度进行校准。 # 这里可以添加业务逻辑 return output # 提供一个方便的工厂函数 def create_skill(): return LogAnalysisSkill()代码解读__init__方法初始化时加载外部Prompt文件、创建LLM、并将它们组合成一个可执行的chain。使用with_structured_output是关键它确保了输出的规范性。invoke方法对外的统一接口。接收字典输入返回结构化的LogAnalysisOutput对象。预留了_preprocess和_postprocess钩子这是Skill比纯Prompt强大的地方——可以嵌入任何业务逻辑。4.5 第四步编写自动化测试一个没有测试的Skill是不可靠的。我们为它编写单元测试。# skills/data_analysis/test_log_analyzer.py import pytest from .skill_log_analyzer import LogAnalysisSkill class TestLogAnalysisSkill: pytest.fixture def skill(self): 创建Skill实例的Fixture。 return LogAnalysisSkill() def test_skill_invocation(self, skill): 测试Skill基本调用。 test_log [ERROR] Database connection pool exhausted. Active: 100, Max: 100. [WARN] High memory usage detected: 95%. input_data {log_text: test_log} result skill.invoke(input_data) # 断言输出符合Schema assert hasattr(result, root_causes) assert hasattr(result, solution_steps) assert hasattr(result, confidence) assert isinstance(result.root_causes, list) assert isinstance(result.solution_steps, list) assert 0 result.confidence 1 # 可以添加更具体的断言例如检查结果是否包含关键词 assert len(result.root_causes) 0 assert connection in .join(result.root_causes).lower() or memory in .join(result.root_causes).lower() def test_skill_with_empty_log(self, skill): 测试边界情况空日志。 input_data {log_text: } result skill.invoke(input_data) # 检查Skill是否能妥善处理空输入 assert isinstance(result.root_causes, list) # 可能输出“未发现明显错误”之类的根因运行测试pytest skills/data_analysis/test_log_analyzer.py -v5. Skill的进阶版本管理、依赖与组合单个Skill解决了复用问题但要应对复杂场景我们还需要管理Skill的版本、依赖和组合。5.1 版本管理Git 语义化版本每个Skill目录下可以有一个skill_manifest.yaml文件记录元数据。# skills/data_analysis/skill_manifest.yaml name: log_analyzer version: 1.0.1 description: 分析服务器错误日志定位根本原因并提供解决步骤。 author: DevTeam created_date: 2023-10-27 input_schema: shared/schemas/log_analysis.py::LogAnalysisInput output_schema: shared/schemas/log_analysis.py::LogAnalysisOutput prompt_template: ../../shared/prompts/log_analysis.txt dependencies: - name: shared_utils version: ^1.2.0 changelog: - version: 1.0.1 date: 2023-10-28 changes: 优化了空日志的处理逻辑。 - version: 1.0.0 date: 2023-10-27 changes: 初始版本。版本控制策略主分支main存放稳定、经过测试的Skill版本。特性分支feature/*开发新Skill或修改现有Skill。发布标签v1.0.0为每个正式版本打上Git Tag。 当需要升级Prompt或逻辑时修改代码和模板更新version提交并创建Pull Request通过测试后合并。团队所有成员都通过Git拉取最新版本。5.2 Skill依赖构建技能图谱复杂的Skill可以依赖其他基础Skill。例如一个“事故报告生成Skill”可能依赖“日志分析Skill”和“指标查询Skill”。# skills/incident_report/skill_incident_reporter.py from skills.data_analysis.skill_log_analyzer import LogAnalysisSkill from skills.metrics.skill_metric_fetcher import MetricFetcherSkill class IncidentReporterSkill: def __init__(self): self.log_analyzer LogAnalysisSkill() self.metric_fetcher MetricFetcherSkill() # ... 自己的Prompt和LLM链 def invoke(self, incident_data): # 1. 调用依赖Skill log_analysis_result self.log_analyzer.invoke({log_text: incident_data[logs]}) metric_result self.metric_fetcher.invoke({query: incident_data[metric_query]}) # 2. 组合结果生成最终报告 combined_input f 日志分析结果{log_analysis_result.root_causes} 系统指标{metric_result.values} 请生成一份给管理层的简要事故报告。 # ... 调用自己的LLM链处理combined_input这要求Skill的接口输入输出必须稳定。一旦修改了LogAnalysisSkill的输出Schema所有依赖它的Skill都可能需要调整。这恰恰体现了工程化的必要性——通过接口契约和版本号来管理变更。5.3 在Agent中编排Skill最终我们的Skill会被Agent调用。以下是一个使用LangChain的简单Agent示例它根据用户问题自动选择并调用合适的Skill。# agent/simple_router_agent.py from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from skills.data_analysis.skill_log_analyzer import create_skill as create_log_skill from skills.code_generation.skill_sql_generator import create_skill as create_sql_skill from shared.config import get_llm # 1. 将Skill包装成LangChain Tool from langchain.tools import Tool log_skill create_log_skill() sql_skill create_sql_skill() tools [ Tool( namelog_skill.name, descriptionlog_skill.description, funclambda q: log_skill.invoke({log_text: q}).dict(), # 注意适配输入格式 ), Tool( namesql_skill.name, descriptionsql_skill.description, funclambda q: sql_skill.invoke({natural_language_query: q}).dict(), ), ] # 2. 创建Agent提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以调用工具来帮助用户。请根据用户问题决定是否调用工具以及调用哪个工具。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 3. 创建Agent和Executor llm get_llm(temperature0) agent create_tool_calling_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 4. 运行Agent result agent_executor.invoke({ input: 帮我分析一下这段日志数据库连接失败错误码1045, }) print(result[output])在这个架构中Agent是协调者Skill/Tool是执行者。每个Skill都通过标准的invoke方法提供服务实现了彻底的解耦。6. 运行验证与效果评估部署Skill后如何验证它工作正常并持续监控效果6.1 构建验收测试集为每个Skill维护一个validation_set.json包含典型输入和期望输出的关键特征。[ { input: {log_text: [ERROR] Disk full on /var/log}, expected_output_features: { root_causes_contain: [disk, space], solution_steps_contain: [cleanup, expand] } }, { input: {log_text: [ERROR] Syntax error in SQL at line 1}, expected_output_features: { root_causes_contain: [sql, syntax], solution_steps_contain: [check, query] } } ]编写一个自动化脚本定期如每日运行这些测试用例对比实际输出和期望特征计算通过率。6.2 集成评估框架对于更严肃的场景可以使用专门的LLM评估框架如RAGAS、LlamaIndex的Evaluation模块或LangSmith。它们可以自动化评估忠实度Faithfulness输出是否基于给定输入日志相关性Relevance分析的原因和步骤是否与日志相关有帮助性Helpfulness人类评分者认为结果是否有用6.3 线上监控与反馈闭环在生产环境中记录每次Skill调用的输入参数脱敏后输出结果耗时用户反馈如果有 这些数据可用于发现Bad Case定位Skill失效的场景。效果分析统计不同版本Skill的指标如平均置信度、用户满意率。数据驱动迭代基于高频Bad Case构造新的测试用例和训练数据反向优化Prompt。7. 常见问题与排查思路在Skill化过程中你会遇到一些典型问题。问题现象可能原因排查方式解决方案Skill调用返回非结构化文本而非Pydantic对象。1. LLM未成功绑定with_structured_output。2. Prompt未引导模型输出正确JSON。3. 输出格式过于复杂模型无法理解。1. 检查Skill初始化代码确认structured_llm配置正确。2. 打印出发送给模型的完整Prompt检查指令是否清晰。3. 简化输出Schema或提供更详细的示例。1. 确保使用支持结构化输出的模型如gpt-4系列。2. 在Prompt中明确要求输出JSON并给出示例。3. 使用response_format参数如果API支持。多个Skill组合时数据传递出错。1. 上游Skill的输出Schema与下游Skill的输入Schema不匹配。2. 数据预处理/后处理逻辑有误。1. 打印每个Skill的输入和输出对比数据类型和结构。2. 编写集成测试模拟完整数据流。1. 明确定义团队内部的“通用数据契约”。2. 在Skill的invoke方法入口和出口添加数据验证如使用Pydantic的validate_call装饰器。版本更新后依赖该Skill的其他服务报错。发生了破坏性变更Breaking Change如修改了输出字段名或类型。1. 查看Git提交历史和Changelog。2. 回滚到上一个可用版本确认问题。1.严格遵守语义化版本修改接口时升级主版本号。2.建立集成测试流水线在合并前自动测试所有依赖该Skill的服务。3. 考虑版本共存新版本Skill部署为新端点旧版本暂时保留。Prompt效果不稳定时好时坏。1. 模型温度temperature设置过高。2. Prompt中存在歧义或过于开放的指令。3. 输入数据差异过大。1. 固定随机种子如果API支持进行测试。2. 进行A/B测试对比不同Prompt版本在相同测试集上的表现。3. 分析Bad Case寻找输入数据的共同模式。1. 将temperature调低如0.1以获得更确定性的输出。2. 使用更具体、更详细的指令并提供更多Few-shot示例。3. 对输入进行归一化或分类对不同类型的输入使用不同的子Skill。Skill执行速度慢。1. LLM API调用延迟高。2. 前置处理如检索耗时过长。3. 网络问题。1. 使用监控工具记录每个环节的耗时。2. 检查是否有不必要的串行调用。1. 考虑缓存Cache常见输入的结果。2. 对于可并行操作使用异步调用。3. 优化前置处理逻辑或设置超时。8. 最佳实践与工程建议将Prompt工程沉淀为Skill是一个系统工程以下最佳实践能帮你少走弯路。8.1 设计原则单一职责一个Skill只做好一件事。不要设计一个既能分析日志又能生成SQL的“巨无霸”Skill。明确契约使用Pydantic等工具严格定义输入输出Schema这是Skill之间协作的基石。无状态设计Skill本身不应维护会话状态。状态应由上层的Agent或应用来管理。配置外置将Prompt模板、模型参数、温度等配置放在外部文件如YAML中便于动态调整。8.2 开发流程设计阶段明确Skill的输入、输出、功能边界。编写接口文档Schema。实现阶段创建Skill类编写核心Prompt和逻辑。同时编写单元测试。测试阶段在多样化测试集上验证效果包括边界用例和对抗性输入。评审阶段代码评审Code Review和Prompt评审Prompt Review同样重要。关注Prompt的清晰度、安全性和潜在偏见。发布阶段更新版本号提交Git打上标签。更新Skill目录的清单Manifest文件。监控阶段上线后收集使用数据和反馈为下一次迭代做准备。8.3 团队协作规范中心化仓库所有Skill代码和Prompt模板必须存放在唯一的Git仓库中禁止本地私有副本。Pull Request流程任何修改必须通过PR并至少需要一名其他成员评审。变更日志每次版本更新必须在CHANGELOG.md或Skill清单中记录修改内容、影响范围和升级指南。文档即代码Skill的描述、接口、示例用法应作为代码注释或Markdown文件一并提交。8.4 安全与合规输入净化对用户输入进行必要的清洗和检查防止Prompt注入攻击。输出过滤对模型的输出进行安全检查过滤不当内容。权限控制在Skill调用层实现权限校验确保只有授权用户或服务能调用敏感Skill如数据库操作。审计日志记录所有Skill的调用记录便于溯源和合规审查。从“存文档”到“建Skill”本质上是将AI能力从个人手工作坊式的技巧转变为团队工业化生产的组件。它初期会带来一些学习成本和工程开销但当你需要维护数十个Prompt、需要它们稳定协作、需要新成员快速上手时这套体系的价值将无可替代。它解决的不仅是同步问题更是质量、效率和规模化的问题。下一步你可以尝试将团队现有的核心Prompt逐步迁移到Skill架构并探索更高级的特性如Skill的自动发现与注册、基于向量数据库的Skill语义检索、以及利用LLM自动生成和优化Skill的Prompt。真正的AI工程化才刚刚开始。