在医疗健康 AI 应用里，Skill 常被用来封装“摘要生成、术语规范化、文献解读、结构化抽取”等能力。本文只讨论技术架构和工程流程示例，不提供诊断、治疗、分诊或用药建议；文中的阈值、风险分层、升级规则均为示例规则，真实项目应由医疗专业人员和机构规范确认。

问题背景：Skill 库为什么会变成提示词文件夹

不少医疗 AI 项目在早期会把 Skill 做成一组 Prompt 模板：一个 Markdown 文件对应一个任务，前端传入变量，后端拼接后调用模型。原型阶段很快，但随着团队、场景和模型数量增加，问题会集中爆发。

典型表现有三类。

第一，复用困难。同样是“医学术语标准化”，A 业务线写了一版，B 业务线又改了一版，变量名、输出 JSON、异常处理都不同。后续要接入新的工作流引擎时，很难判断哪个 Skill 可以直接复用。

第二，版本不可追踪。某个 Prompt 被临时修改后，线上输出风格发生变化，但审计日志里只记录了模型调用，没有记录 Skill 版本、参数、引用的术语表版本和执行人。

第三，治理缺位。医疗健康场景对权限、审计、可解释性要求更高。即便只是科研工具或文献处理工具，也需要区分“开发中 Skill”“已评审 Skill”“已下线 Skill”，避免未经确认的能力进入生产流程。

所以，Skill 库不应只是 Prompt 仓库，而应是“可复用能力单元 + 元数据注册中心 + 执行治理机制”的组合。

技术目标：把 Skill 当成可治理的软件资产

一个可落地的医疗 Skill 库，至少要满足以下目标。

1. 可复用：Skill 的输入、输出、依赖和副作用要显式声明。
2. 可编排：Skill 能被 workflow engine 调用，而不是只能由某个页面硬编码触发。
3. 可版本化：Prompt、参数 Schema、模型配置、知识资源引用都要有版本。
4. 可授权：不同角色只能查看、编辑、发布或执行授权范围内的 Skill。
5. 可审计：每次执行都能回溯到 Skill 版本、调用参数、执行人、输出摘要和异常信息。

可以把整体架构抽象成下面的流程图：

User / Service
      |
      v
Workflow Engine
      |
      v
Skill Runtime ----> LLM / NLP Service
      |
      v
Metadata Registry
      |
      +---- Version Store
      +---- RBAC Policy
      +---- Audit Log
      +---- Resource Registry

这里的关键点是：工作流只负责“什么时候调用什么 Skill”，Skill Runtime 负责“如何安全执行”，Metadata Registry 负责“这个 Skill 是什么、能不能用、当前版本是什么”。

Skill 元数据设计：先定义边界，再写 Prompt

如果没有元数据，Prompt 再精致也难以治理。建议每个 Skill 至少包含以下字段：

skill_id: med_term_normalize
name: 医学术语标准化
owner: nlp-platform-team
status: reviewed
version: 1.3.0
scenario: literature_processing
input_schema:
  type: object
  required:
    - text
    - locale
  properties:
    text:
      type: string
      maxLength: 2000
    locale:
      type: string
      enum:
        - zh-CN
        - en-US
output_schema:
  type: object
  required:
    - normalized_terms
  properties:
    normalized_terms:
      type: array
dependencies:
  terminology_dict: dict-med-term-v2026-05
  model_profile: llm-safe-json-v2
risk_level: low
review_policy: medical_reviewer_required

这个配置背后的工程含义是：调用方不需要理解 Prompt 细节，只需要按输入 Schema 传参；治理平台可以根据 status、risk_level、review_policy 决定是否允许上线；审计系统可以记录术语表和模型配置版本。

注意，risk_level 只是工程治理标签，不代表医学风险判断。真实项目中的分类、发布条件和评审流程应按机构制度确认。

运行时实现：把执行、校验和审计放到同一条链路

下面是一个简化版 Python 示例，演示 Skill Runtime 如何加载元数据、做权限检查、校验输入并写入审计日志。示例不依赖具体模型服务，便于替换为内部 LLM 网关或传统 NLP 服务。

from datetime import datetime
from jsonschema import validate, ValidationError

SKILL_REGISTRY = {
    "med_term_normalize": {
        "version": "1.3.0",
        "status": "reviewed",
        "allowed_roles": ["research_tool_dev", "medical_ai_operator"],
        "input_schema": {
            "type": "object",
            "required": ["text", "locale"],
            "properties": {
                "text": {"type": "string", "maxLength": 2000},
                "locale": {"type": "string", "enum": ["zh-CN", "en-US"]}
            }
        },
        "prompt_template": "请将以下医学文本中的术语标准化，输出 JSON：{text}"
    }
}

AUDIT_LOG = []

def call_model(prompt: str) -> dict:
    return {
        "normalized_terms": [
            {"source": "示例术语", "normalized": "标准术语示例"}
        ]
    }

def execute_skill(skill_id: str, payload: dict, user: dict) -> dict:
    skill = SKILL_REGISTRY[skill_id]

    if skill["status"] != "reviewed":
        raise PermissionError("Skill is not reviewed")

    if user["role"] not in skill["allowed_roles"]:
        raise PermissionError("Role is not allowed to execute this skill")

    try:
        validate(instance=payload, schema=skill["input_schema"])
    except ValidationError as exc:
        raise ValueError(f"Invalid input: {exc.message}")

    prompt = skill["prompt_template"].format(text=payload["text"])
    result = call_model(prompt)

    AUDIT_LOG.append({
        "skill_id": skill_id,
        "skill_version": skill["version"],
        "user_id": user["id"],
        "role": user["role"],
        "executed_at": datetime.utcnow().isoformat(),
        "input_length": len(payload["text"]),
        "output_keys": list(result.keys())
    })

    return result

if __name__ == "__main__":
    user = {"id": "u1001", "role": "research_tool_dev"}
    payload = {"text": "这是一段用于术语标准化的示例文本", "locale": "zh-CN"}
    print(execute_skill("med_term_normalize", payload, user))
    print(AUDIT_LOG)

生产环境中，AUDIT_LOG 应落到不可随意修改的审计存储中，例如数据库审计表、日志平台或对象存储归档。审计内容也要避免直接保存敏感原文，常见做法是保存摘要、哈希、长度、资源版本和执行上下文。

版本治理：不要只给 Prompt 打版本

Skill 的版本应覆盖完整执行语义，而不只是 Prompt 文案。一次输出变化可能来自 Prompt，也可能来自模型参数、术语表、输出 Schema 或后处理逻辑。

建议拆成四类版本。

1. skill_version：对外能力版本，调用方主要感知这一层。
2. prompt_version：提示词模板版本。
3. resource_version：术语表、规则库、示例库等资源版本。
4. runtime_version：执行器、后处理器、JSON 修复器等代码版本。

发布时可以采用“草稿、评审、灰度、稳定、下线”的状态机。灰度阶段不要只看模型输出是否流畅，更要检查 JSON 合法率、Schema 通过率、人工抽检问题数、调用失败率等工程指标。

如果某个 Skill 涉及面向用户的健康信息解释，升级规则必须更谨慎。示例规则可以写成“高影响 Skill 需要双人评审和回滚方案”，但具体高影响范围要由机构规范定义。

复用机制：把 Skill 拆成原子能力和组合能力

为了避免重复建设，可以把 Skill 分成两层。

原子 Skill 负责单一任务，例如术语标准化、摘要压缩、引用格式检查、结构化字段抽取。组合 Skill 负责把多个原子 Skill 串起来，例如“文献阅读辅助流程”可以包含文本清洗、术语标准化、摘要生成和引用校验。

工作流引擎只编排组合关系，不直接修改原子 Skill。这样一个原子能力升级后，可以被多个流程复用，但需要通过版本锁定避免线上流程被动变化。

组合 Skill：literature_reading_assist
  - clean_text@1.1.0
  - med_term_normalize@1.3.0
  - summary_to_json@2.0.1
  - citation_check@1.0.4

这里建议默认使用精确版本，而不是 latest。开发环境可以跟随最新版本，生产环境应显式锁定，发布时再升级依赖。

RBAC 与审计：治理不是上线后的补丁

医疗健康技术系统里，权限设计要前置。一个简单可用的 RBAC 模型可以包含四类角色。

1. Skill Developer：创建草稿、提交评审。
2. Reviewer：查看变更、给出评审意见。
3. Operator：发布、灰度、回滚。
4. Consumer：在授权工作流中执行 Skill。

审计日志至少记录“谁在什么时间对哪个版本做了什么”。执行日志则记录“谁通过哪个工作流调用了哪个 Skill 版本”。两者要区分，前者偏资产治理，后者偏运行追踪。

为了便于排障，建议为每次调用生成 trace_id，贯穿 API 网关、workflow engine、Skill Runtime 和模型服务。线上问题通常不是单点错误，而是多个版本组合后的结果，trace 能显著降低定位成本。

落地建议：从最小可治理闭环开始

第一阶段不要急着建设庞大的 Skill 平台，可以先做四件事：统一元数据 YAML、统一执行入口、统一审计日志、统一版本命名。只要这四项落地，Prompt 文件夹就已经开始向工程资产库演进。

第二阶段再补充 UI 管理台、评审流、灰度发布和指标看板。指标可以从 Schema 通过率、执行失败率、平均耗时、回滚次数、人工抽检问题数开始，不要一开始就追求复杂评价体系。

第三阶段再考虑跨团队复用，包括共享资源注册中心、通用 Skill SDK、工作流模板市场等能力。此时重点不是让 Skill 数量变多，而是让高质量 Skill 可以稳定复用、可追溯、可下线。

总结

医疗 Skill 库的核心不是积累更多提示词，而是把 AI 能力当成可治理的软件资产来管理。元数据定义边界，workflow engine 负责编排，RBAC 控制权限，audit log 提供追踪，版本体系保证可回滚。

对医疗健康技术开发者来说，建议从一个低风险、边界清晰的 Skill 开始试点，例如术语标准化或文献字段抽取。先跑通“注册、执行、审计、评审、发布、回滚”的闭环，再逐步扩展到更复杂的组合流程。

本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。