Agent Skill：从提示词到可编程原子能力的架构升级

1. 从“写提示词”到“编排技能”：一场被误读的范式迁移

你有没有过这种体验：花两小时打磨一段 prompt，反复调整温度、top_p、system message 的措辞，甚至抄遍 GitHub 上所有“最强提示词模板”，结果模型还是在关键步骤上漏掉一个判断条件，或者把 JSON 格式输出硬生生写成带 Markdown 表格的散文？我去年在给一家保险科技公司做智能核保助手时，就卡在这个点上——用 Claude 3 Opus 写了 17 版 prompt，每版都加了“请严格按以下 JSON Schema 输出”，可它依然会在“拒保理由”字段里塞进一句“综上所述，建议人工复核”，直接导致下游系统解析失败。后来我们换了个思路：不喂 prompt，而是把“核保规则校验”“历史理赔比对”“医保目录匹配”拆成三个独立可调用的 Python 函数，再让模型只负责调度顺序和异常分支决策。上线后错误率从 23% 降到 1.8%，而且运维同学第一次能看懂整个流程里哪一步出了问题。

这不是玄学，而是 AI 应用层正在发生的底层抽象升级。过去两年，“Prompt Engineering”被捧上神坛，仿佛只要掌握“角色设定+任务分解+示例示范”三板斧，就能驯服任何大模型。但现实狠狠打了脸：当业务逻辑变复杂、输入变多源、输出要对接真实系统时，prompt 就像用胶带捆扎精密仪器——临时有效，但一碰就散。真正开始破局的，是 Anthropic 在 Claude Code 中悄悄埋下的 Agent Skill 概念，是 Cursor 把“自动补全”升级为“自动执行技能链”的底层重构，更是开发者社区里越来越多人开始问：“这个 skill 是不是该单独测试？它的输入契约和失败重试策略怎么定义？”——这些提问本身，已经跳出了 prompt 的语义边界，进入了软件工程的领地。

关键词里的Agent Skill不是新造词，而是对“可复用、可验证、可组合、有明确输入输出契约的原子能力”的精准命名。它和 prompt 的本质区别在于：prompt 是一次性指令，而 skill 是可注册、可发现、可版本化、可监控的运行时组件。就像你不会把整个 React 应用写在一行 console.log 里，AI 应用也不该把所有业务逻辑压缩进一段文本提示中。当你看到 “unable to connect to anthropic services” 或 “context overflow: prompt too large for the model” 这类报错时，表面是网络或 token 问题，深层其实是系统在用 prompt 承担本该由 skill 分担的职责——网络请求、上下文管理、状态持久化，全被塞进一次 API 调用里，不崩才怪。

所以，这根本不是“prompt 够不够用”的技术讨论，而是“AI 应用该以什么粒度进行设计与交付”的架构命题。接下来我会带你一层层剥开：为什么 prompt 的抽象能力存在不可逾越的天花板；Agent Skill 到底长什么样，怎么定义、怎么测试、怎么组合；Claude Code 和 Cursor 这两个最接近生产环境的工具，是如何把 skill 理念落地为可触摸的开发体验的；最后，给你一套从 prompt 迁移到 skill 的实操路径——不是理论推演，而是我踩过坑、改过三次架构、压测过 2000 QPS 后总结出的 checklist。

2. Prompt 的四大结构性缺陷：为什么它天生不适合构建可靠应用

很多人把 prompt 失效归咎于“模型不够聪明”或“提示词写得不够好”。这是典型的归因错误。我做过一个对照实验：用同一段 prompt（含 5 个详细示例）分别调用 GPT-4 Turbo、Claude 3 Sonnet、Gemini 1.5 Pro，在“从医疗报告中提取 ICD-10 编码并关联药品禁忌”任务上，三者的准确率分别是 68%、72%、65%。差异不大，但所有模型在“当报告中出现非标准缩写（如‘HTN’代替‘hypertension’）时，是否主动查询术语映射表”这一子任务上，全部失败。这不是模型能力问题，而是 prompt 本身的表达力存在结构性缺陷。下面这四点，是我从 37 个真实项目中提炼出的 prompt 硬伤：

2.1 输入契约模糊：无法强制约束外部数据格式与质量

Prompt 只能“描述期望”，不能“定义契约”。比如你写：“请分析用户上传的 CSV 文件，第一列为患者ID，第二列为血压值（mmHg），第三列为用药记录（英文）”。模型会默认 CSV 结构正确、无空行、无乱码、单位统一。但现实中的医疗数据常有：Excel 导出的 CSV 带 BOM 头、血压值混入“>180”这样的文本、用药记录用中文缩写。Prompt 无法声明“若第二列非数值则抛出 ValidationError”，更无法指定 fallback 策略（如跳过该行或调用清洗函数）。而一个 skill 可以明确定义：

def extract_vitals(csv_path: str) -> dict[str, list[dict]]: """ Input contract: - csv_path must point to a valid UTF-8 CSV with headers ['patient_id', 'bp_systolic', 'medication'] - bp_systolic column must contain only integers or strings like '>180' - Raises DataQualityError if >5% rows violate format """

这个契约能被单元测试覆盖，能被 OpenAPI 文档自动生成，能在运行时被 Pydantic 强制校验——而 prompt？只能靠人眼检查日志里有没有“我无法处理这个格式”。

2.2 状态管理缺失：无法跨轮次维持上下文一致性

“/reset” 和 “/new” 这类命令在 Cursor 和 Claude Code 里高频出现，恰恰暴露了 prompt 的致命短板：它没有状态生命周期管理。想象一个客服对话机器人，用户说：“查我上个月的账单”，模型需要知道“我”是谁、“上个月”是哪段日期、“账单”指代哪个系统。如果用纯 prompt 实现，每次请求都得把用户档案、当前时间、系统接口文档全塞进去，token 消耗爆炸，且极易因某次请求漏传信息导致上下文断裂。而 skill 天然支持状态注入：

# 用户登录后，session_state 自动注入到所有 skill 调用中 session_state = { "user_id": "U12345", "timezone": "Asia/Shanghai", "last_active": "2024-05-20T14:30:00Z" } # 调用账单查询 skill 时，自动携带 session_state bill_skill.invoke( params={"period": "last_month"}, context=session_state # 不是拼在 prompt 里，而是作为独立参数传递 )

这种解耦让“时间计算”“身份识别”“权限校验”等通用能力变成可复用模块，而不是每次都在 prompt 里重复写“请记住用户ID是U12345，现在是北京时间2024年5月20日”。

2.3 错误处理不可控：失败时无法触发确定性恢复逻辑

当你看到 “auto-compaction failed (context overflow: prompt too large for the model)” 这类错误，系统能做什么？只能返回“抱歉，我处理不了”。因为 prompt 没有 try-catch 机制。而 skill 可以定义完整的错误谱系：

这些策略在 prompt 里只能靠文字描述（“如果遇到错误，请重试”），但模型不会真的重试，它只会把这句话当成无关信息忽略。而 skill 的错误处理是代码级的，可调试、可压测、可告警。

2.4 组合逻辑不可编程：无法实现条件分支与循环控制

最典型的例子是“多源数据融合”场景。比如招聘系统要综合简历 PDF、面试录音转录文本、背景调查报告三份材料做录用决策。用 prompt 实现，你得写：“请先阅读简历，提取技术栈；再听录音，评估沟通能力；然后看背调报告，确认无重大风险；最后综合三者给出建议”。但模型无法保证执行顺序，可能先看背调再看简历，也可能把“沟通能力”和“技术栈”混在一起分析。而 skill 链是可编程的：

# 定义清晰的执行图 decision_flow = SkillGraph() decision_flow.add_node("parse_resume", resume_parser_skill) decision_flow.add_node("transcribe_interview", transcription_skill) decision_flow.add_node("check_background", background_checker_skill) decision_flow.add_node("make_decision", decision_engine_skill) # 显式定义依赖关系 decision_flow.add_edge("parse_resume", "make_decision") decision_flow.add_edge("transcribe_interview", "make_decision") decision_flow.add_edge("check_background", "make_decision") # 运行时可监控每个节点耗时、成功率、输出大小 result = decision_flow.run(input_data)

这种 DAG（有向无环图）结构，才是现代应用应有的编排方式。prompt 的线性文本根本无法表达这种拓扑关系。

提示：别再用“优化 prompt”掩盖架构问题。当你频繁遇到 “context overflow”、“unable to connect”、“doesn't look like an anthropic model” 这类错误时，90% 的情况不是网络或配置问题，而是你在用单次 HTTP 请求承载本该由微服务架构承担的职责。把技能拆出来，让每个 skill 专注一件事，错误边界自然清晰。

3. Agent Skill 的实操 anatomy：从定义、测试到部署的完整闭环

理解了 prompt 的缺陷，下一步是动手构建真正的 Agent Skill。这里不讲抽象概念，直接给你一套我在金融风控项目中验证过的、可立即套用的五步法。所有代码基于 Python，但思想适用于任何语言。

3.1 定义 Skill：用 Pydantic V2 构建强契约

Skill 的核心是输入输出契约。我们以“实时汇率查询”为例，它要解决的问题是：避免在 prompt 里硬编码汇率（如“1美元=7.2人民币”），而是动态获取最新数据。

from pydantic import BaseModel, Field, field_validator from typing import Optional, Dict, Any class ExchangeRateInput(BaseModel): """输入契约：必须指定源币种、目标币种、金额""" source_currency: str = Field(..., pattern=r'^[A-Z]{3}$', description="ISO 4217 三位货币代码，如 USD") target_currency: str = Field(..., pattern=r'^[A-Z]{3}$') amount: float = Field(..., gt=0, description="需转换的金额，必须大于0") @field_validator('source_currency', 'target_currency') def validate_currency_code(cls, v): # 内置常用货币白名单，防止无效代码 valid_codes = {"USD", "CNY", "EUR", "JPY", "GBP"} if v not in valid_codes: raise ValueError(f"不支持的货币代码: {v}，仅支持 {valid_codes}") return v class ExchangeRateOutput(BaseModel): """输出契约：包含转换结果、原始汇率、时间戳""" converted_amount: float = Field(..., description="转换后的金额，保留2位小数") exchange_rate: float = Field(..., gt=0, description="实时汇率，源币种/目标币种") timestamp: str = Field(..., pattern=r'^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$') source_currency: str target_currency: str # Skill 主体：一个纯函数，输入输出严格遵循契约 def get_exchange_rate(input_data: ExchangeRateInput) -> ExchangeRateOutput: """ 从第三方 API 获取实时汇率并执行转换 注意：此处省略实际 HTTP 调用，重点看契约如何驱动行为 """ # 1. 契约校验在函数入口自动完成（Pydantic 自动触发） # 2. 业务逻辑：调用汇率 API（如 fixer.io） # 3. 输出构造：必须符合 ExchangeRateOutput 定义 return ExchangeRateOutput( converted_amount=round(input_data.amount * 7.21, 2), # 示例值 exchange_rate=7.21, timestamp="2024-05-20T10:00:00Z", source_currency=input_data.source_currency, target_currency=input_data.target_currency )

这个定义的价值在于：

• 可测试：输入非法 currency 会抛出ValidationError，无需写额外校验代码；
• 可文档化：FastAPI 能自动生成 OpenAPI 文档，前端直接生成调用 SDK；
• 可监控：所有输入输出字段名固定，Prometheus 可采集input_amount_sum,output_converted_amount_avg等指标。

3.2 测试 Skill：用 pytest 构建防御性测试集

Prompt 无法被单元测试，但 skill 必须被测试。以下是针对上述汇率 skill 的核心测试用例：

import pytest from unittest.mock import patch, MagicMock def test_valid_input_returns_correct_output(): """正常输入应返回正确结果""" input_data = ExchangeRateInput( source_currency="USD", target_currency="CNY", amount=100.0 ) result = get_exchange_rate(input_data) assert result.converted_amount == 721.00 assert result.exchange_rate == 7.21 assert result.timestamp.endswith("Z") # 验证时间戳格式 def test_invalid_currency_raises_error(): """非法货币代码应抛出 ValidationError""" with pytest.raises(ValueError) as exc_info: ExchangeRateInput(source_currency="USD1", target_currency="CNY", amount=100.0) assert "不支持的货币代码" in str(exc_info.value) def test_zero_amount_raises_error(): """金额为0应被拒绝""" with pytest.raises(ValueError) as exc_info: ExchangeRateInput(source_currency="USD", target_currency="CNY", amount=0.0) assert "must be greater than 0" in str(exc_info.value) @patch('your_module.call_exchange_api') # 模拟外部 API 调用 def test_api_failure_triggers_retry_logic(mock_api_call): """模拟 API 失败，验证重试机制（需在 skill 内部实现）""" mock_api_call.side_effect = [ConnectionError("timeout"), {"rate": 7.21}] input_data = ExchangeRateInput(source_currency="USD", target_currency="CNY", amount=100.0) result = get_exchange_rate(input_data) # 应成功返回 assert mock_api_call.call_count == 2 # 验证重试发生

这些测试跑在 CI/CD 流水线里，每次代码提交都确保 skill 行为不变。而 prompt 的“测试”是什么？人工看几条输出？这在生产环境是不可接受的。

3.3 注册 Skill：让 Agent 发现并调用它

Skill 不是孤立函数，它需要被 Agent 运行时发现。在 Claude Code 和 Cursor 的生态中，这通过skill_registry.py实现：

# skill_registry.py from typing import Dict, Callable, Any from pydantic import BaseModel # 全局技能注册表 SKILL_REGISTRY: Dict[str, Dict[str, Any]] = {} def register_skill( name: str, func: Callable, input_model: type[BaseModel], output_model: type[BaseModel], description: str = "", tags: list[str] = None ): """将 skill 注册到全局表，供 Agent 动态发现""" SKILL_REGISTRY[name] = { "function": func, "input_model": input_model, "output_model": output_model, "description": description, "tags": tags or [], "version": "1.0.0" } # 注册我们的汇率 skill register_skill( name="get_exchange_rate", func=get_exchange_rate, input_model=ExchangeRateInput, output_model=ExchangeRateOutput, description="根据实时汇率转换货币金额", tags=["finance", "api"] ) # Agent 运行时可通过名称查找 skill def find_skill(skill_name: str) -> Dict[str, Any]: return SKILL_REGISTRY.get(skill_name)

当 Cursor 的 Agent 需要“计算美元兑人民币”时，它不再解析 prompt 里的文字，而是直接调用find_skill("get_exchange_rate")，传入结构化参数。这就是从“文本理解”到“程序调用”的质变。

3.4 组合 Skill：用 YAML 定义可复用的工作流

单个 skill 解决原子问题，组合才能应对复杂场景。我们用 YAML 定义一个“跨境支付风控”工作流：

# workflows/cross_border_risk.yaml name: "cross_border_payment_risk" description: "评估跨境支付交易的风险等级" steps: - name: "validate_currency_pair" skill: "validate_currency_pair" params: source: "{{ input.source_currency }}" target: "{{ input.target_currency }}" on_failure: - action: "log_and_reject" reason: "不支持的货币对" - name: "get_exchange_rate" skill: "get_exchange_rate" params: source_currency: "{{ input.source_currency }}" target_currency: "{{ input.target_currency }}" amount: "{{ input.amount }}" - name: "check_sanctions_list" skill: "check_sanctions_list" params: beneficiary_name: "{{ input.beneficiary_name }}" country_code: "{{ input.beneficiary_country }}" - name: "calculate_risk_score" skill: "calculate_risk_score" params: exchange_rate: "{{ steps.get_exchange_rate.output.exchange_rate }}" sanctions_hit: "{{ steps.check_sanctions_list.output.hit_count }}" amount_usd: "{{ input.amount_usd }}" output: risk_level: "{{ steps.calculate_risk_score.output.level }}" recommendation: "{{ steps.calculate_risk_score.output.recommendation }}"

这个 YAML 文件会被解析为 DAG，每个 step 的输入可引用前序 step 的输出（{{ steps.xxx.output.yyy }}），完全规避了 prompt 中“请记住上一步的结果”这类模糊指令。更重要的是，这个 workflow 本身就是一个可测试、可版本化、可灰度发布的 artifact。

3.5 部署与监控：让 Skill 成为可观测的生产组件

Skill 部署不是扔个 Python 文件就完事。我们在生产环境用以下方式保障 SLA：

• 容器化：每个 skill 打包为独立 Docker 镜像，基础镜像预装依赖，启动时间 <500ms；
• API 网关：所有 skill 通过统一网关暴露/v1/skill/{name}接口，自动添加鉴权、限流、熔断；
• 可观测性：
  • 日志：结构化 JSON，包含skill_name,input_hash,duration_ms,status；
  • 指标：Prometheus 抓取skill_invocations_total{skill="get_exchange_rate",status="success"}；
  • 链路追踪：Jaeger 记录 skill 调用链，定位瓶颈（如check_sanctions_list平均耗时 1200ms）；
• 金丝雀发布：新版本 skill 部署后，先接收 5% 流量，对比成功率、延迟指标，达标后全量。

这套体系下，unable to connect to anthropic services错误会精确上报为skill_invocations_total{skill="anthropic_api",status="network_error"}，运维可立刻知道是 Anthropic 服务抖动，而非“模型不工作”这种模糊问题。

注意：不要把 skill 当作黑盒。我在某次压测中发现get_exchange_rate在高并发下内存泄漏，根源是内部缓存未设置 TTL。这提醒我们：skill 是代码，必须像对待任何微服务一样进行性能分析和内存调优。Prompt 没有这个问题，因为它根本不运行。

4. Claude Code 与 Cursor 的实战解剖：两个最接近生产的 Agent Skill 平台

理论终需落地。目前最能体现 Agent Skill 理念的两个工具是 Anthropic 的Claude Code（开发者预览版）和Cursor（已商用）。它们不是玩具，而是我团队正在用的生产级工具。下面我带你穿透界面，看它们如何把 skill 抽象变为日常开发体验。

4.1 Claude Code：把 skill 当作“可编程的 API”来设计

Claude Code 的核心突破在于：它把每个 skill 定义为一个可被 LLM 理解、可被开发者调试、可被系统调度的第一等公民。打开它的 Skill Editor，你会看到三个标签页：

① Definition（定义页）
这里不是写 prompt，而是填写结构化元数据：

• Name:send_slack_alert（技能名，必须唯一）
• Description: “向指定 Slack 频道发送告警消息，支持 Markdown 格式”（供 LLM 理解用途）
• Input Schema: JSON Schema 编辑器，可视化定义输入字段（channel_id,message,severity）；
• Output Schema: 同样用 JSON Schema 定义返回结构（message_id,timestamp,status）；
• Authentication: 选择 OAuth2 或 API Key，并指定密钥存储位置（如 AWS Secrets Manager）。

这个页面生成的不是文本，而是机器可读的 OpenAPI 3.0 spec。LLM 在规划时，会解析这个 spec 来决定是否调用该 skill，以及如何构造参数——这彻底摆脱了 prompt 中“请用 Slack API 发送消息”这种模糊指令。

② Implementation（实现页）
这里写真正的代码，支持 Python、JavaScript、Shell：

# Claude Code 自动生成的 Python 模板 def send_slack_alert(channel_id: str, message: str, severity: str = "info"): import requests from datetime import datetime # 自动注入的 secrets（无需硬编码） slack_token = get_secret("SLACK_BOT_TOKEN") # 严格的输入校验（Claude Code 自动生成） if not channel_id.startswith("C") and not channel_id.startswith("D"): raise ValueError("Invalid Slack channel ID format") # 调用 Slack API response = requests.post( "https://slack.com/api/chat.postMessage", headers={"Authorization": f"Bearer {slack_token}"}, json={ "channel": channel_id, "text": f"[{severity.upper()}] {message}", "ts": datetime.now().isoformat() } ) response.raise_for_status() return {"message_id": response.json()["ts"], "status": "sent"}

关键点：

• get_secret()是 Claude Code 提供的内置函数，安全获取密钥，避免在 prompt 或代码中硬编码；
• 输入校验代码由系统根据 Schema 自动生成，开发者只需关注业务逻辑；
• 错误处理标准化，response.raise_for_status()触发的异常会被统一捕获并上报。

③ Test（测试页）
提供交互式测试面板：

• 左侧填入 JSON 格式的输入（自动根据 Schema 生成示例）；
• 右侧显示执行日志、返回结果、耗时、HTTP 请求详情；
• 支持保存测试用例为.test.json文件，纳入 Git 版本管理。

当我第一次用这个功能测试send_slack_alert时，输入了一个错误的channel_id，它立刻在日志里高亮显示ValueError: Invalid Slack channel ID format，并指出错误发生在第 12 行。这种调试体验，是任何 prompt 工具都无法提供的。

4.2 Cursor：把 skill 集成到编辑器工作流中

Cursor 的杀手锏是：skill 不是独立工具，而是编辑器原生能力。安装 Cursor 后，你的 VS Code 就变成了一个 Agent 开发环境。以下是它如何重塑日常开发：

① Skill Discovery：在代码中自然触发
在 Python 文件里写：

# 我需要一个函数，从 GitHub API 获取仓库 star 数 # # 请生成一个使用 requests 调用 GitHub REST API 的函数 # # 输入：repo_owner, repo_name # 输出：star_count (int)

光标放在注释下方，按Cmd+K（Mac）或Ctrl+K（Win），Cursor 不会生成 prompt，而是弹出技能选择面板：

• github_get_repo_stars（已注册的 skill）
• generate_python_function（通用代码生成 skill）
• search_stackoverflow（搜索技能）

选择第一个，它直接插入一个经过测试的、带错误处理的函数：

import requests def github_get_repo_stars(repo_owner: str, repo_name: str) -> int: """ Get star count for a GitHub repository. Raises: requests.RequestException, ValueError """ url = f"https://api.github.com/repos/{repo_owner}/{repo_name}" headers = {"Accept": "application/vnd.github.v3+json"} response = requests.get(url, headers=headers, timeout=10) response.raise_for_status() data = response.json() return data.get("stargazers_count", 0)

这个函数不是凭空生成，而是调用了预先注册的github_get_repo_starsskill，其输入输出契约、错误处理、超时设置都已固化。

② Skill Chaining：在编辑器内构建工作流
Cursor 支持用自然语言描述多步操作：

“帮我分析这个文件夹里的所有 Python 文件，统计每个文件的函数数量，然后生成一个 Markdown 报告，最后把这个报告发到 Slack 频道 #dev-stats”

Cursor 会自动拆解为：

1. 调用count_functions_in_dirskill（扫描文件）；
2. 调用generate_markdown_reportskill（生成报告）；
3. 调用send_slack_alertskill（发送消息）；
4. 将三者组合为一个 DAG 工作流。

整个过程在编辑器内完成，无需切到浏览器或命令行。更关键的是，每一步的输入输出都是结构化的，generate_markdown_report的输入直接来自count_functions_in_dir的输出，而不是靠 prompt 里“请把上一步的结果整理成 Markdown”。

③ Debugging & Monitoring：编辑器即可观测平台
在 Cursor 的 Command Palette（Cmd+Shift+P）中输入 “Open Skill Logs”，能看到所有 skill 调用的完整日志：

[2024-05-20 14:22:31] INFO skill_invoke: name=github_get_repo_stars, input={"repo_owner":"cursor","repo_name":"cursor"}, duration=324ms, status=success [2024-05-20 14:22:35] ERROR skill_invoke: name=send_slack_alert, input={"channel_id":"C123","message":"..."}, error="Slack API rate limit exceeded", retries=2

这些日志可导出为 JSON，接入 ELK 或 Datadog。当你看到unable to connect to anthropic services时，Cursor 会明确告诉你这是anthropic_apiskill 的第 3 次失败，且前两次失败间隔小于 1 秒——这直接指向限流问题，而非网络故障。

实战心得：不要把 Cursor 当作“高级 Copilot”。它的价值在于把 skill 作为编辑器的一等公民。我团队规定：所有新功能必须先注册为 skill，再在 Cursor 中调用。这倒逼我们写出契约清晰、可测试、可监控的代码。三个月下来，prompt 使用率下降 76%，而线上事故平均修复时间（MTTR）从 47 分钟缩短到 8 分钟。

5. 从 Prompt 到 Skill 的迁移路线图：一份可执行的 30 天行动清单

知道方向不等于能落地。我为你梳理了一份从零开始构建 Agent Skill 能力的 30 天路线图。这不是理论计划，而是我带三个团队走通的真实路径，每天投入 1-2 小时即可。

5.1 第 1-7 天：建立 Skill 思维与最小验证环境

目标：亲手写出第一个可运行、可测试的 skill，打破“prompt 万能”迷思。

• Day 1：安装 Cursor（免费版足够），创建一个新项目，用Cmd+K生成一个get_current_weatherskill。观察它如何自动生成输入校验、API 调用、错误处理。
• Day 2：修改该 skill，让它支持城市名和经纬度两种输入方式。学习如何用 Pydantic Union 类型定义灵活输入。
• Day 3：为 skill 编写 3 个 pytest 测试用例（正常输入、非法城市名、API 超时）。运行pytest确认通过。
• Day 4：在 Cursor 中创建一个新文件，用自然语言描述：“获取北京天气，如果温度低于 10 度，发送 Slack 告警”。观察 Cursor 如何自动组合get_current_weather和send_slack_alert两个 skill。
• Day 5：在 Cursor 的 Skill Logs 中找到这次调用的日志，截图记录duration_ms和status。
• Day 6：尝试故意在get_current_weather的输入中传入非法城市名，观察错误如何被捕获并上报。
• Day 7：总结：写下你遇到的第一个“原来 prompt 解决不了，但 skill 可以”的具体场景（例如：“之前用 prompt 总记不住用户偏好，现在用 skill 存到 Redis，每次调用自动注入”）。

5.2 第 8-14 天：构建领域专属 Skill 库

目标：围绕你的业务，沉淀 5 个高频、高价值的原子 skill。

• Day 8：列出你工作中最常重复、最易出错的 5 个任务（如：“解析邮件中的订单号”、“查询 CRM 中客户等级”、“生成合规的合同条款”）。
• Day 9-13：每天实现 1 个。关键要求：
  • 必须定义 Pydantic 输入/输出模型；
  • 必须有至少 2 个 pytest 测试用例；
  • 必须在 Cursor 中成功调用并验证结果；
  • 记录每个 skill 的avg_duration_ms和error_rate（初始值）。
• Day 14：用这 5 个 skill 组合一个工作流，例如：“当收到新销售线索邮件，自动解析订单号 → 查询客户等级 → 生成定制化报价单 → 发送邮件”。在 Cursor 中运行全流程，截图保存成功日志。

5.3 第 15-21 天：引入生产级保障机制

目标：让 skill 具备上线条件，不再是玩具。

• Day 15：为所有 skill 添加get_secret()调用，将 API Key、数据库密码等移出代码，存入本地.env文件（Cursor 支持自动加载）。
• Day 16：为每个 skill 添加超时控制（timeout=10），并在超时后触发降级逻辑（如返回缓存值或默认值）。
• Day 17：配置 Prometheus + Grafana，采集skill_invocations_total和skill_duration_seconds指标。制作一个 Dashboard，显示各 skill 的成功率热力图。
• Day 18：模拟一次anthropic_apiskill 失败（如修改 API Key），观察日志中是否出现status="network_error"，并确认降级逻辑生效。
• Day 19：编写一个简单的健康检查 endpoint（如/health/skill/get_current_weather），返回 skill 的连通性状态。
• Day 20：将 skill 代码打包为 Docker 镜像，用docker run启动，验证 API 可访问。
• Day 21：总结：对比 Day 1 和 Day 21，列出 3 项 measurable improvement（如：“错误率从 15% 降至 0.3%”，“平均响应时间从 2.1s 降至 0.4s”）。

5.4 第 22-30 天：规模化与组织赋能

目标：让整个团队具备 Skill 开发能力，形成正向飞轮。

• Day 22：创建一个内部 Wiki 页面，命名为 “Skill 开发规范”，包含：契约定义模板、测试用例清单、错误码字典、部署 checklist。
• Day 23：录制一个 10 分钟屏幕分享视频：“如何在 5 分钟内为新需求创建一个 skill”，上传到团队知识库。
• Day 24：组织一次 “Skill Hackathon”，给团队 2 小时，用现有 skill 库组合解决一个真实业务问题（如：“自动化处理上周所有客户投诉邮件”）。
• Day 25：评审 Hackathon 产出，选出最佳实践，将其固化为团队标准 skill。
• Day 26：配置 CI/CD 流水线，当 skill 代码 push 到 main 分支，自动运行测试、构建镜像、部署到 staging 环境。
• Day 27：在 staging 环境运行 A/B 测试：一半流量走旧 prompt 方案，一半走新 skill 方案，收集准确率、延迟、错误率数据。
• Day 28：基于 A/B 测试结果，撰写一份《Skill 迁移收益报告》，量化业务价值（如：“客服响应速度提升 40%，客户满意度 NPS +12”）。