医疗健康 AI 应用里，Skill 库常被设计成“提示词模板集合”，上线初期看似灵活，迭代几轮后就会出现重复、不可追踪、权限混乱和效果不可复现等问题。本文从技术架构和工程流程角度，拆解一个医疗 Skill 库如何围绕复用、版本、权限和审计来建设。以下内容仅讨论系统设计示例，不提供诊断、治疗、分诊或用药建议；任何业务规则都应由医疗专业人员和机构规范确认。

问题背景：为什么 Skill 库容易变成提示词堆积

在医疗健康应用中，常见 Skill 可能包括文献摘要生成、术语解释、病历文本结构化、科研问答辅助、质控规则检查等。开发团队为了快速验证效果，往往直接把 prompt 写进代码、配置表或运营后台。

这种方式短期成本低，但会带来几个工程问题。

第一，复用粒度不清。一个“摘要 Skill”里可能同时包含角色设定、输入字段说明、输出格式、风险提示和后处理规则。其他场景想复用其中的输出格式，只能复制整段 prompt。

第二，版本不可追踪。某个 Skill 今天调整了约束条件，明天线上结果发生变化，很难回答“哪个版本影响了哪些调用方”。

第三，治理缺位。医疗健康场景对内容边界、敏感信息处理、可审计性要求更高。如果 Skill 没有权限、审批、灰度和日志机制，很难进入稳定生产流程。

技术目标：把 Skill 设计成基础能力，而不是文本片段

一个可治理的医疗 Skill 库，核心目标不是保存更多 prompt，而是让 Skill 具备工程资产属性。

建议至少满足以下要求：

• 可复用：公共输入规范、输出 schema、后处理器可以被组合使用
• 可版本化：每次变更都能关联版本、变更说明、发布状态和调用记录
• 可治理：不同角色只能操作授权范围内的 Skill
• 可审计：每次执行都能记录输入摘要、版本、操作者、输出状态和错误信息
• 可回滚：新版本效果不稳定时，可以快速切回稳定版本

这里的“医疗”只限定工程场景，例如医学文本处理、科研辅助、健康管理内容生成等。涉及风险分层、升级规则、提示语边界时，应写成可配置的示例规则，并交由机构规范确认。

架构拆解：Skill 不只是 Prompt

可以把 Skill 拆成四层：元数据层、编排层、执行层、治理层。

┌──────────────────────────────┐
│          Skill Portal         │
│  创建 / 审批 / 发布 / 回滚      │
└───────────────┬──────────────┘
                │
┌───────────────▼──────────────┐
│       Metadata Registry       │
│ Skill 定义 / 版本 / Schema / 标签 │
└───────────────┬──────────────┘
                │
┌───────────────▼──────────────┐
│        Workflow Engine        │
│ 输入校验 / 模板渲染 / 后处理 / 降级 │
└───────────────┬──────────────┘
                │
┌───────────────▼──────────────┐
│      Execution Runtime        │
│ LLM 调用 / 规则引擎 / 缓存 / 日志   │
└───────────────┬──────────────┘
                │
┌───────────────▼──────────────┐
│ RBAC / Audit Log / Observability│
└──────────────────────────────┘

元数据层负责定义“Skill 是什么”，而不是仅保存 prompt。一个 Skill 至少应包含名称、适用场景、输入 schema、输出 schema、版本、状态、责任人、风险等级和依赖组件。

编排层负责“Skill 怎么跑”。例如先做输入脱敏，再渲染模板，再调用模型，最后做 JSON 校验和规则检查。

治理层负责“谁能改、谁能发布、谁调用过”。在医疗健康系统里，审计日志不是附加功能，而是生产可用性的基础条件。

数据模型：先定义 Skill Contract

Skill Contract 是调用方和 Skill 库之间的契约。只要契约稳定，内部 prompt、模型、后处理规则都可以独立演进。

下面是一个简化的 Skill 元数据示例，用于“医学文献摘要辅助”场景。

skill_id: literature_summary
name: 医学文献摘要辅助
domain: medical_research
status: published
owner: ai-platform-team
risk_level: low
version: 1.3.0
input_schema:
  type: object
  required:
    - title
    - abstract
  properties:
    title:
      type: string
      maxLength: 500
    abstract:
      type: string
      maxLength: 5000
output_schema:
  type: object
  required:
    - background
    - method
    - conclusion
    - limitation
  properties:
    background:
      type: string
    method:
      type: string
    conclusion:
      type: string
    limitation:
      type: string
policy:
  allow_personal_data: false
  require_human_review: true
  note: 示例配置，真实项目需按机构规则确认

这里的重点是，Skill 被描述为一个可调用能力，而不是一段自然语言。调用方只依赖 skill_id、版本策略和输入输出结构，不需要关心底层 prompt 如何组织。

执行流程：用 Workflow Engine 固化可复用步骤

一个医疗 Skill 的执行通常不应直接进入模型调用。推荐把流程拆成多个可组合节点。

from dataclasses import dataclass
from typing import Dict, Any
import json
import time

@dataclass
class SkillVersion:
    skill_id: str
    version: str
    template: str
    output_keys: list

class AuditLogger:
    def write(self, event: Dict[str, Any]) -> None:
        print(json.dumps(event, ensure_ascii=False))

class SkillRunner:
    def __init__(self, audit_logger: AuditLogger):
        self.audit_logger = audit_logger

    def validate_input(self, payload: Dict[str, Any]) -> None:
        if not payload.get("title") or not payload.get("abstract"):
            raise ValueError("title 和 abstract 为必填字段")
        if len(payload["abstract"]) > 5000:
            raise ValueError("abstract 超出示例长度限制，真实限制应按业务配置")

    def render_prompt(self, skill: SkillVersion, payload: Dict[str, Any]) -> str:
        return skill.template.format(
            title=payload["title"],
            abstract=payload["abstract"]
        )

    def call_model(self, prompt: str) -> Dict[str, str]:
        return {
            "background": "研究背景摘要示例",
            "method": "研究方法摘要示例",
            "conclusion": "结论摘要示例",
            "limitation": "局限性摘要示例"
        }

    def run(self, skill: SkillVersion, payload: Dict[str, Any], user_id: str) -> Dict[str, Any]:
        start = time.time()
        status = "success"
        try:
            self.validate_input(payload)
            prompt = self.render_prompt(skill, payload)
            result = self.call_model(prompt)

            for key in skill.output_keys:
                if key not in result:
                    raise ValueError(f"模型输出缺少字段: {key}")

            return result
        except Exception as exc:
            status = "failed"
            raise exc
        finally:
            self.audit_logger.write({
                "skill_id": skill.skill_id,
                "version": skill.version,
                "user_id": user_id,
                "status": status,
                "latency_ms": int((time.time() - start) * 1000),
                "payload_keys": list(payload.keys())
            })

skill = SkillVersion(
    skill_id="literature_summary",
    version="1.3.0",
    template="请基于题名和摘要生成结构化科研摘要。题名：{title}\n摘要：{abstract}",
    output_keys=["background", "method", "conclusion", "limitation"]
)

runner = SkillRunner(AuditLogger())
print(runner.run(skill, {
    "title": "A clinical research article title",
    "abstract": "This is an example abstract for engineering workflow testing."
}, user_id="developer_001"))

这段代码没有追求完整平台化，而是表达三个关键点：输入校验、执行编排、审计日志必须在 Skill 执行链路中出现。后续可以把 call_model 替换为具体模型服务，把 AuditLogger 替换为 Kafka、数据库或日志平台。

版本治理：不要只给 Prompt 加时间戳

Skill 版本建议采用语义化策略，例如 major.minor.patch。

• major：输入输出契约发生不兼容变化
• minor：能力增强，但兼容旧调用方
• patch：修复模板措辞、错误处理或小范围规则

发布状态也要明确区分：draft、reviewing、published、deprecated、archived。调用方默认只允许使用 published 版本，灰度测试可通过白名单或流量比例控制。

一个常见实践是“双轨发布”：稳定版本服务生产流量，新版本只对测试用户、内部账号或指定业务线开放。对医疗健康内容相关 Skill，如果涉及风险提示、升级建议、敏感字段处理等规则，发布前应经过业务、合规和医疗专业人员确认。

权限与审计：RBAC 要覆盖创建、发布和调用

Skill 库至少需要三类权限。

开发者可以创建草稿、调试流程、查看自己负责的执行日志。审核者可以查看变更 diff、审批发布、要求回退。调用方系统只能按授权调用指定 Skill 和版本范围。

审计日志建议记录以下字段：

• skill_id、version、调用方应用
• user_id 或 service_account
• 输入字段摘要，不保存不必要的原文
• 执行状态、耗时、错误码
• 模型版本、后处理版本
• 发布人、审批人、发布时间

注意，日志设计要遵守最小化原则。若系统处理敏感信息，应进行脱敏、访问控制和保留周期管理，具体要求需按机构安全规范确认。

复用机制：把公共能力拆成组件

为了避免重复建设，可以把 Skill 拆成可复用组件。

例如输入校验器、术语标准化器、输出 JSON 校验器、敏感信息检查器、引用格式检查器都可以独立注册。一个新 Skill 只需要组合已有组件，再补充自己的模板和策略。

Skill = InputSchema
      + PreProcessor[]
      + PromptTemplate
      + ModelProfile
      + PostProcessor[]
      + Policy
      + AuditConfig

这种设计能降低维护成本。修改公共输出校验器时，所有依赖它的 Skill 都能受益；但也要通过依赖图确认影响范围，避免公共组件变更引发连锁问题。

落地建议：从一个高频低风险 Skill 开始

医疗 Skill 库不建议一开始就覆盖所有场景。更稳妥的方式是选择高频、低风险、输出结构明确的场景，例如科研文本摘要辅助或术语解释辅助，先跑通注册、执行、审计和发布流程。

第一阶段关注契约稳定和日志完整。第二阶段补齐版本 diff、灰度发布、回滚和调用统计。第三阶段再考虑组件市场、自动评测、成本分析和跨团队复用。

如果系统未来要支持更高风险的业务流程，必须把示例规则升级为机构确认的正式规则，并纳入权限、审批、人工复核和异常升级机制。

总结

医疗 Skill 库的核心不是收集 prompt，而是把 AI 能力做成可复用、可版本化、可审计的工程资产。设计时应优先定义 Skill Contract，再通过 Workflow Engine 固化执行链路，并用 RBAC、审计日志和发布流程保证治理能力。

对开发团队来说，最小可行路径是：选一个低风险场景，定义输入输出 schema，接入执行日志，建立版本状态机，再逐步沉淀公共组件。这样建设出来的 Skill 库，才有机会从“提示词仓库”变成医疗健康 AI 应用的基础能力层。

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