医疗 Skill 库怎么建才不会沦为提示词堆积，关键在可复用和可治理

在医疗健康应用里Skill 常被用来封装一段可执行能力例如文献摘要、术语标准化、随访文本结构化、质控提醒生成等。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中所有规则、阈值和升级逻辑均为示例真实项目应由医疗专业人员和机构规范确认。问题背景为什么 Skill 库会变成提示词仓库医疗 AI 项目早期通常会把一个需求拆成多个 Prompt摘要一个、改写一个、质控一个、结构化一个。短期看上线很快长期会出现几个典型问题。第一复用困难。同样是“生成患者教育文本”不同业务线复制出多个相似 Prompt参数、禁用词、输出格式各不相同后续改动无法同步。第二责任不清。某个 Skill 输出异常时很难回答“当前线上用的是哪个版本”“谁审批过”“输入数据来自哪里”“有没有触发人工复核”。第三评估断裂。Prompt 文本改了但测试集、指标、灰度记录没有绑定导致效果回退只能靠用户反馈发现。所以医疗 Skill 库的核心不是“存放提示词”而是把可执行能力做成一个具备契约、版本、权限和审计的工程资产。目标把 Skill 定义成可治理的执行单元一个可治理的 Skill 至少应包含四层信息。Skill Prompt Template Input / Output Schema Runtime Config Governance Metadata更具体一些Prompt Template任务描述、角色约束、输出要求。Schema输入字段、必填项、输出 JSON 结构、字段类型。Runtime Config模型、温度、超时、重试、工具调用权限。Governance Metadata负责人、版本、适用场景、审批状态、风险等级、审计策略。可以用下面的架构理解 Skill 库在系统中的位置。业务系统Workflow EngineSkill RegistryPrompt TemplateSchema ValidatorPolicy / RBACLLM GatewayAudit Log评估与回放这里的关键点是业务系统不直接拼 Prompt而是调用工作流引擎工作流引擎根据 Skill Registry 取版本、校验输入、检查权限、执行模型调用并记录审计日志。Skill 元数据怎么设计下面是一个简化的 Skill 元数据示例。它不绑定具体模型厂商便于后续迁移。skill_id:patient_education_summaryname:患者教育文本摘要domain:medical_healthrisk_level:mediumowner:clinical_ai_teamstatus:approvedversion:1.2.0description:将经过授权的健康教育材料压缩为结构化摘要input_schema:type:objectrequired:-source_text-target_audienceproperties:source_text:type:stringmax_length:6000target_audience:type:stringenum:-general_public-caregiveroutput_schema:type:objectrequired:-summary-key_points-limitationsproperties:summary:type:stringkey_points:type:arrayitems:type:stringlimitations:type:stringruntime:model:configurabletemperature:0.2timeout_ms:15000retry:1governance:reviewer_role:medical_revieweraudit_required:truehuman_review_required:truenotes:真实项目需按机构规范确认适用范围这个结构解决了几个问题调用方知道该传什么评估系统知道该验证什么运维知道异常时查哪里合规与安全团队知道谁负责审批。用 Registry 管住版本而不是靠文件名Skill 版本不能只靠prompt_v3_final_final.txt。建议采用语义化版本并把变更类型写清楚。patch修正文案、补充少量约束不改变输入输出。minor新增可选字段、扩展输出内容保持向后兼容。major输入输出结构或任务边界发生变化。Registry 可以用数据库实现核心表不复杂。CREATETABLEskill_registry(skill_idVARCHAR(128)NOTNULL,versionVARCHAR(32)NOTNULL,statusVARCHAR(32)NOTNULL,ownerVARCHAR(128)NOTNULL,risk_levelVARCHAR(32)NOTNULL,metadata_json JSONNOTNULL,prompt_templateTEXTNOTNULL,created_atTIMESTAMPNOTNULL,approved_atTIMESTAMPNULL,PRIMARYKEY(skill_id,version));CREATETABLEskill_release_channel(skill_idVARCHAR(128)NOTNULL,channelVARCHAR(32)NOTNULL,active_versionVARCHAR(32)NOTNULL,updated_atTIMESTAMPNOTNULL,PRIMARYKEY(skill_id,channel));skill_release_channel用来支持 dev、staging、prod 等环境。业务方调用prod渠道而不是写死版本号灰度发布时只需要调整渠道映射。工作流引擎负责组合不让 Skill 互相硬编码医疗健康场景里的任务往往不是单步。例如“健康教育内容生成”可能包含文本清洗、术语规范化、摘要生成、风险提示检查、人工复核派单。每一步都可以是 Skill但 Skill 之间不应直接调用彼此否则依赖关系会失控。更好的方式是由 workflow engine 编排。fromtypingimportDict,AnyimporttimeimportuuidclassSkillRuntime:def__init__(self,registry,policy,llm_gateway,audit):self.registryregistry self.policypolicy self.llm_gatewayllm_gateway self.auditauditdefrun(self,skill_id:str,channel:str,user:Dict[str,Any],payload:Dict[str,Any]):trace_idstr(uuid.uuid4())skillself.registry.load_active(skill_id,channel)self.policy.check_permission(user_roleuser[role],skill_idskill_id,risk_levelskill[risk_level])self.registry.validate_input(skill[input_schema],payload)startedtime.time()try:resultself.llm_gateway.invoke(prompt_templateskill[prompt_template],payloadpayload,runtimeskill[runtime])self.registry.validate_output(skill[output_schema],result)statussuccessreturnresultexceptExceptionasexc:statusfailedraiseexcfinally:self.audit.write({trace_id:trace_id,skill_id:skill_id,version:skill[version],channel:channel,user_id:user[id],status:status,latency_ms:int((time.time()-started)*1000)})这段代码体现了几个边界权限检查在执行前完成Schema 校验在模型调用前后都做审计日志不依赖业务方自觉记录。RBAC不要让所有人都能改线上 Skill医疗 Skill 的治理重点之一是权限分离。推荐至少拆成四类角色。developer创建草稿、提交测试版本。reviewer审核医学表达、适用范围和风险提示。operator发布、回滚、配置灰度比例。auditor查看调用记录和变更记录但不能修改内容。需要注意reviewer不等于系统管理员。医学内容审核和系统发布权限应分离避免一个账号既能改 Prompt 又能直接上线。对于中高风险 Skill可以增加双人审批或人工复核节点。这里的“风险等级”只是工程治理标签不代表任何医学风险分层结论真实项目必须由机构规则确认。审计日志记录什么才有用审计不是简单写一行“调用成功”。排查线上问题时最有价值的是可回放、可定位、可追责。建议记录以下字段trace_id串联一次工作流。skill_id、version、channel定位执行版本。caller、user_role定位调用来源和权限。input_hash、output_hash避免直接存敏感原文同时支持一致性排查。policy_result记录权限与策略判断。latency、token_usage、error_code用于性能与成本分析。review_required、review_status记录是否进入人工复核。涉及个人敏感信息时应按项目合规要求做脱敏、加密和访问控制。不要把完整原文无差别写入普通日志系统。复用机制从“复制 Prompt”改成“组合能力”可复用的 Skill 应该保持单一职责。比如不要把“术语规范化、摘要生成、风险提示、格式转换”写进一个超长 Prompt。更好的方式是拆成小粒度 Skill再由工作流组合。示例拆法text_normalize统一标点、单位、缩写。term_standardize术语映射输出候选与置信度。education_summary生成结构化摘要。safety_check检查是否包含禁止表达或超出适用范围的内容。review_ticket_create创建人工复核任务。这样做还有一个工程收益评估可以按节点进行。摘要质量下降时不必怀疑整条链路可以先回放education_summary的固定测试集。常见坑治理系统做了但没人愿意用第一个坑是元数据太重。创建一个 Skill 要填几十个字段开发者会绕过平台。建议先强制最小集合输入输出 Schema、owner、版本、状态、审计开关。第二个坑是审批流程没有自动化。审核通过后还要手工复制 Prompt 到生产环境必然出错。Registry、发布渠道和工作流引擎要打通。第三个坑是评估集没有版本。Skill 变更时应绑定测试集版本和评估结果。即使只是示例规则也要保存当时的配置和输出方便回滚时比较。第四个坑是把模型参数藏在代码里。温度、超时、重试、模型路由都应属于 runtime config否则不同环境的行为会不一致。结论Skill 库是工程资产不是文案仓库医疗 Skill 库要避免沦为提示词堆积关键是把 Skill 当作可执行、可复用、可版本化、可审计的基础能力来建设。Prompt 只是其中一部分围绕它还需要 Schema、Registry、Workflow、RBAC、Audit Log 和评估回放。落地时可以从一个低风险、边界清晰的 Skill 开始先跑通元数据注册、版本发布、权限校验和审计闭环。等流程稳定后再扩展到更复杂的工作流编排和多角色治理。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。