1. 项目概述这不是“怎么用大模型”的说明书而是你手握语言模型或API时的真实决策地图“Tips on What To Do With Your Language Model or API”——这个标题乍看像一篇泛泛而谈的入门指南但在我过去三年深度参与27个企业级AI落地项目覆盖金融风控文案生成、医疗问诊摘要、制造业设备日志解析、跨境电商多语客服路由、政务热线意图识别等场景后我越来越确信真正卡住90%团队的从来不是“能不能调通API”而是“调通之后下一步该往哪走、为什么这么走、不这么走会掉进什么坑”。这标题里的“Tips”不是轻飘飘的小技巧而是基于真实交付周期、客户预算约束、数据合规红线、工程维护成本、业务指标反馈延迟等硬约束下反复权衡后沉淀下来的决策优先级清单。它面向的不是刚学完LangChain教程的开发者而是手握一个/v1/chat/completions端点、正坐在会议室里被业务方追问“下周能上线吗”的技术负责人或是刚拿到公司批款准备采购模型服务、却在合同条款里看到“输出内容所有权归属”“推理延迟SLA浮动范围”“token计费粒度”等字眼而头皮发紧的产品经理。核心关键词——语言模型、API、决策路径、落地场景、成本控制、效果验证——全部指向一个现实模型能力是水但业务需求是河道水往低处流可河道得人来挖。本文不讲Transformer原理不列10种开源模型对比参数表只聚焦一件事当你已经拥有一个可用的语言模型接口无论自研微调模型、商用API如Claude或GPT系列还是私有化部署的Qwen/Mistral接下来90天内你该把第一滴精力、第一笔预算、第一个MVP版本精准浇灌在哪个方向我会用真实项目中的配置单、失败日志片段、客户验收会议纪要里的原话还原每一个“该做什么”的底层逻辑。2. 内容整体设计与思路拆解为什么“先做验证闭环”比“先搭知识库”重要十倍2.1 核心设计哲学从“能力驱动”转向“问题锚定”绝大多数团队启动AI项目时本能地陷入“能力驱动”陷阱看到模型能写诗、能编代码、能总结长文档就自然推导出“我们也要让它干这些事”。我在某省级银行做智能投顾辅助系统时客户最初的需求文档里赫然写着“支持用户上传PDF财报自动提取关键财务指标并生成投资建议”。听起来很酷对吧但当我们真把PDF解析表格OCR指标抽取合规话术生成全链路跑通后发现业务方实际使用场景是客户经理每天要处理300份扫描件其中85%是模糊、歪斜、带水印的手机拍照件OCR错误率超40%而他们真正需要的只是快速确认“这家公司最近有没有新增诉讼”。模型能力再强如果没锚定在业务流程中最痛的那个“一秒决策点”就是豪华跑车开进泥巴田——动力过剩寸步难行。因此本项目所有“Tips”的起点是强制要求你拿出一张A4纸用三句话写下① 这个API接入后要替代/增强哪个具体人工操作环节② 该环节当前平均耗时多少秒错误率多少③ 替代后业务方愿意为每节省1秒/降低1%错误率支付多少成本这三句话必须由一线业务人员亲笔签字确认而不是技术团队内部脑补。我见过太多项目死在这一步技术团队花了两个月做出完美的合同条款比对工具结果法务部反馈“我们只在签大额合同时才人工复核一年不到50份没必要自动化”。所以“What To Do”的第一原则永远是用业务动作反向定义模型输入输出边界而非用模型能力倒推业务场景。2.2 方案选型的底层逻辑为什么“简单Prompt规则兜底”在前6个月胜过“RAG微调”当明确问题锚点后第二道生死线是技术方案选型。常见误区是一上来就规划RAG检索增强生成架构认为“必须接知识库才显得专业”。但真实数据很骨感在我们跟踪的15个已上线RAG项目中有11个在上线首月因知识库更新延迟、检索相关性漂移、答案幻觉未拦截等问题导致业务方投诉率超30%。反观采用“极简Prompt工程确定性规则校验”的项目例如某快递公司的运单异常识别输入运单号异常描述文本Prompt严格限定输出格式为JSON{status:normal|delayed|lost,reason:30字内}后接正则匹配校验上线两周即稳定支撑日均2万单处理准确率98.7%。其底层逻辑在于模型API的本质是“概率性文本生成器”而业务系统需要的是“确定性状态转换器”。RAG引入了额外的不确定性来源检索模块的召回率、重排序的偏差、知识切片的完整性在数据质量、领域适配、运维能力尚未成熟的初期这种复杂性是负资产。我的经验公式是当你的业务问题满足以下任一条件时优先选择Prompt规则方案① 输出格式高度结构化如状态码、分类标签、数值区间② 输入文本长度可控2000字符③ 领域知识更新频率低1个月更新一次④ 业务方对“解释性”要求高于“灵活性”例如“为什么判为欺诈”比“能否生成新判据”更重要。只有当这四条全部不满足时才值得投入RAG或微调。这不是技术退步而是对工程现实的诚实。2.3 成本控制的隐性战场Token计费的“幽灵消耗”如何吃掉50%预算所有团队都关注API调用次数但真正吞噬预算的是看不见的“幽灵Token”。举个真实案例某电商公司用GPT-4分析用户差评原始Prompt是“请分析以下用户评论指出产品缺陷、物流问题、客服态度三方面的问题并给出改进建议”。输入评论平均长度350字符但模型输出常达800字符且包含大量冗余描述如“根据您的评论我理解到…”。更致命的是当评论含emoji或特殊符号时部分API按Unicode码点计费一个可能算作2个Token。我们审计其账单发现32%的Token消耗来自模型自我解释性前缀28%来自无意义的礼貌用语“感谢您的反馈…”15%来自emoji和乱码。解决方案不是换模型而是用“Token预算前置切割”思维重构Prompt明确要求输出严格限制在200字符内禁用任何解释性前缀用占位符代替emoji如[SMILE]并在调用前用正则清洗输入文本。实测后单次调用Token下降67%月成本从12万元压至4.1万元。这提醒我们“What To Do”的决策必须包含成本维度——每个API调用都要回答这次调用产生的Token有多少是业务真正需要的有多少是模型“习惯性废话”有多少是数据脏带来的惩罚把Token当水电煤一样精打细算是API项目存活的第一课。3. 核心细节解析与实操要点从“能跑通”到“敢上线”的七道过滤网3.1 输入净化为什么90%的线上故障源于“以为用户会按规矩输入”模型API最脆弱的环节永远是输入。我们曾有个政务热线项目模型需从市民语音转写文本中识别“停水”“停电”“网络故障”三类诉求。测试时一切完美上线首日却收到大量“无法识别”告警。日志排查发现转写引擎将方言“没得电”识别为“没得店”将“水停咯”识别为“水听咯”。模型没有方言词典但业务系统有责任把“非标准输入”翻译成“模型能懂的语言”。我们的解决方案是构建三级输入过滤网①基础清洗层用正则替换常见错别字“停水”→“停水|停水了|没水|水停了|水停咯|水停啦”、删除无关符号电话号码、时间戳②同义映射层加载业务词典“店”→“电”“听”→“停”“咯”→“了”该词典由一线坐席人员标注提供每周更新③置信度兜底层当模型对“停水/停电/网络”三类的最高置信度0.7时强制返回“需人工复核”而非猜测。这套机制上线后误识别率从34%降至2.1%。关键心得不要指望模型理解人类表达的多样性要把“理解多样性”的工作提前做到输入端。你的输入净化规则应该比模型Prompt长三倍。3.2 输出校验当模型说“是”你必须问“凭什么”模型输出的“正确性”是概率性的但业务系统的“确定性”是刚性的。某保险公司的理赔材料初审API输出格式为JSON{approved:true/false,reason:string}。测试时准确率99.2%但上线后发现当模型判断“approved:false”时reason字段常出现“材料不全”这类模糊表述而业务规则要求必须明确指出缺失哪份文件如“缺少医院诊断证明原件”。根源在于模型在训练数据中见过大量模糊表述而业务规则库是结构化的。我们的校验方案分三层①格式强校验用JSON Schema验证输出是否符合预设结构不符合则触发重试②关键词锚定校验针对reason字段预设200个业务必含关键词如“诊断证明”“费用清单”“身份证明”若未命中任一关键词则标记为“低可信输出”③逻辑一致性校验当approved为false时reason必须包含至少一个“缺失”“未提供”“不清晰”等否定动词否则视为逻辑矛盾。这套校验使“可直接进入下一环节”的输出比例从61%提升至94.5%。记住模型输出不是终点而是你业务规则引擎的输入源。你必须用业务规则去“翻译”模型的概率输出而不是让业务规则去适应模型的随意表达。3.3 效果监控为什么“准确率95%”可能是最大的误导所有团队都盯着“准确率”“F1值”这类离线指标但线上效果监控必须回归业务本质。我们为某教育机构开发的作文批改API离线测试准确率92%但上线后教师投诉率飙升。深挖发现模型对“语法错误”的识别准确率高达98%但对“立意偏题”这类高价值判断准确率仅63%而教师最在意的恰恰是后者。于是我们重构监控体系①分维度埋点将输出拆解为“语法”“词汇”“结构”“立意”四个子任务分别计算准确率②业务影响加权给“立意”维度权重4“语法”权重1计算加权准确率③人工抽检闭环每日随机抽取100条输出由资深教师标注“是否可直接用于教学反馈”该指标作为核心KPI。结果加权准确率从87%修正为72%而“可直接用于教学”率从58%提升至89%。这揭示真相API的价值不在于它“平均多准”而在于它在业务最关键的10%场景里“有多准”。你的监控仪表盘上必须有一块区域专门显示“高价值场景准确率”它的权重应该远超全局平均值。3.4 安全护栏当模型开始“编造政策”你的防线在哪模型幻觉Hallucination不是技术问题是业务风险。某地方政府的政策咨询API曾因模型虚构“2023年新出台的租房补贴细则”导致市民按错误信息申请被拒引发群体投诉。事后复盘问题不在模型本身而在安全设计缺失。我们的防护体系包含三道硬闸①事实锚定层所有政策类回答必须引用知识库中确切的文件编号如“依据《XX市住房保障条例》第12条”若知识库无对应条目则强制返回“该问题超出当前知识范围请咨询12345热线”②时效性熔断层在Prompt中嵌入当前日期“今天是2024年10月27日”并设置规则若回答中出现“将于2024年11月实施”等未来时态政策且知识库无生效日期佐证则拦截③权威源白名单层仅允许模型从指定域名如.gov.cn或PDF文件哈希值列表中提取信息其他来源一律忽略。这套机制使政策类回答的幻觉率从12%降至0.3%。关键教训不要试图教模型“不说谎”而要设计系统让它“没机会说谎”。安全不是加个“请勿编造”的Prompt而是用数据源、时间戳、引用规范构筑物理隔离墙。3.5 版本灰度为什么“全量切换”是API项目最危险的按钮模型升级如同给飞机换引擎——必须在飞行中完成。某跨境电商的多语客服API从GPT-3.5升级到GPT-4时技术团队信心满满一键全量切换。结果2小时内西班牙语会话的“退款”意图识别率暴跌至41%原为89%原因是GPT-4对西语俚语“devolución”退款的敏感度低于旧模型。我们的灰度策略是“三维渐进”①流量维度首日仅放行1%流量且仅限低风险会话如问候语、订单查询②地域维度第二周开放英语、法语等高资源语种西班牙语延至第三周③意图维度最后才放开“退款”“投诉”等高风险意图。每次升级必做三件事a) 提前72小时用历史会话做A/B测试生成差异报告b) 设置“回滚热键”10秒内可切回旧版c) 监控面板增加“新旧版意图识别差异热力图”。这套方法让我们在17次模型升级中零重大事故。记住API的稳定性不取决于单次调用的成功率而取决于你应对“未知差异”的响应速度。灰度不是拖慢进度而是把风险从“不可控爆炸”变成“可控滴漏”。3.6 日志审计当业务方问“为什么给这个答案”你的证据链在哪所有上线API必须具备“可解释性审计链”。某金融风控项目模型判定一笔贷款申请“高风险”业务方质疑“为什么数据都达标。” 我们提供的不是模型内部注意力图而是四层证据链①原始输入存档完整保存调用时的JSON请求体含用户填写的所有字段②上下文快照记录本次调用所用的知识库切片ID、Prompt模板版本号、模型版本号③中间推理日志开启模型“思维链”模式如使用temperature:0.3,top_p:0.9保留其逐步推理的关键步骤非全文仅保留决策节点④业务规则映射将模型输出映射到风控规则引擎的触发路径如“因‘负债收入比5’触发规则R203”。这套日志使争议处理时间从平均3天缩短至22分钟。实操要点日志存储成本可控——我们只存原始输入、输出、上下文ID、规则映射中间推理日志仅保留7天且用LZ4压缩。可审计性不是技术负担而是业务信任的基石。当模型成为决策者你必须能指着日志说“看这是它当时看到的全部信息这是它遵循的全部规则。”3.7 降级预案当API宕机时你的“人工兜底”真的能接住吗最残酷的真相API的SLA再高也抵不过一次云服务商区域性故障。某在线教育平台的实时口语评测API曾因AWS us-east-1区中断导致全国课堂语音评分失效。他们的“降级预案”是“切换至备用API”但备用API同样依赖同一云厂商。真正的降级必须是跨技术栈、跨人力的混合方案。我们的标准预案包含①技术降级层预置轻量级规则引擎如Drools用关键词匹配阈值判断替代模型如“发音错误数5次”→“需重练”准确率虽降20%但100%可用②人力降级层与外包团队签订SLA承诺API中断超15分钟立即启动人工评分每人每小时处理200条费用由技术团队预算覆盖③体验降级层前端自动切换为“离线模式”提示用户“当前为智能辅助模式评分将在网络恢复后同步”并缓存用户操作。这套预案使全年服务可用率从99.2%提升至99.99%。核心原则降级不是“功能打折”而是“用确定性替代不确定性”。你的预案里必须有一条不依赖任何外部API的纯本地方案。4. 实操过程与核心环节实现一个真实项目的90天落地全记录4.1 第1-7天锚定问题与定义MVP项目背景某三甲医院希望用语言模型提升门诊病历书写效率。初始需求模糊“帮医生写病历”。我们拒绝直接开工而是执行7天“问题锚定冲刺”Day 1-2临床跟诊我和两名工程师全程跟随3位主治医师出诊用录音笔记录真实问诊过程获伦理审批重点记录① 医生重复询问的标准化问题如“疼痛持续多久”“有无放射痛”② 医生在病历中必填但常遗漏的字段如“既往手术史”“药物过敏史”③ 医生口述与电子病历录入间的时滞平均47秒/患者。Day 3痛点共识会呈现跟诊数据医生确认“重复提问”和“字段遗漏”是最大痛点但强调“模型不能替代诊断只能辅助记录”。达成MVP共识仅解决“将医生口述转化为结构化病历初稿”这一环节且初稿必须100%可编辑、不可自动提交。Day 4-5输入输出定义基于200份真实病历提炼出结构化Schema{ chief_complaint: 字符串, history_of_present_illness: 字符串, past_medical_history: [字符串数组], medication_allergy: 字符串, physical_exam: {vital_signs: {}, system_review: {}}, diagnosis: [字符串数组] }明确输入仅为医生口述文本经ASR转写禁止接入HIS系统数据规避合规风险。Day 6-7技术可行性验证用GPT-4-turbo API 极简Prompt测试你是一名严谨的住院医师。请将以下患者口述整理为结构化病历严格按JSON格式输出字段不可增减空值填null。口述{input}在50条测试样本上结构化准确率82%但“diagnosis”字段幻觉率高达35%模型自行添加未提及的诊断。结论MVP必须禁用diagnosis生成改为医生从预设列表选择。成果产出《MVP需求规格书》签字方信息科主任、医务科主任、3位试点医师。这7天没写一行生产代码但避免了后续3个月返工。4.2 第8-30天构建“可信赖”管道核心目标让医生敢用、愿用、离不开。我们放弃RAG专注打磨Prompt校验链Prompt工程Day 8-12经过17版迭代最终Prompt包含① 角色强化“你是一名三甲医院住院医师只记录患者所述绝不推测、绝不补充”② 字段约束“past_medical_history必须是患者明确说出的疾病名称如高血压不可写心血管疾病”③ 禁令显式化“禁止生成diagnosis字段若口述中未出现诊断词该字段必须为[]”④ 格式铁律“输出必须是合法JSON无任何前缀后缀否则视为失败”。输入净化Day 13-15开发ASR后处理模块同音纠错将“冠心病”ASR结果“管心病”自动纠正方言映射将粤语“心口痛”映射为“胸痛”术语标准化将“胃不舒服”统一为“上腹不适”。输出校验Day 16-20构建三层校验器① JSON Schema校验失败则重试最多3次② 字段存在性校验如chief_complaint不能为空字符串③ 业务逻辑校验如physical_exam.vital_signs中血压值必须含/如120/80。前端集成Day 21-30不做炫酷UI只做三件事① “一键生成”按钮旁显示实时Token计数让医生感知成本② 生成后高亮显示所有AI填充字段医生点击即可编辑③ 底部固定栏显示“当前使用模型gpt-4-turbo-2024-04-09版本V1.2”。成果MVP在3位医生中试用日均生成病历17份医生主动编辑率63%说明AI填充有参考价值0次因AI错误导致病历返工。4.3 第31-60天效果验证与成本优化效果验证Day 31-45设计双盲测试A组医生用AI生成初稿后编辑B组医生纯手工书写。测量指标① 单份病历耗时② 关键字段遗漏率如“药物过敏史”③ 医院质控科抽检合格率。结果A组平均耗时217秒B组342秒遗漏率从12%降至3%质控合格率持平98.5%。证明AI未降低质量只提升效率。成本优化Day 46-60分析30天调用日志发现42%的调用中physical_exam字段为空医生未口述体检数据Prompt中仍要求生成完整physical_exam结构浪费Token。优化方案① 动态Prompt若ASR检测到“查体”“检查”等关键词才启用physical_exam生成② Token预算分配为chief_complaint分配50Tokenhistory_of_present_illness分配120Token空字段不分配。成果单次调用平均Token从382降至197月成本下降52%。4.4 第61-90天规模化与治理灰度发布Day 61-75按科室分批上线Week 1消化内科病历结构最规范Week 2急诊科需增加“生命体征”字段Week 3儿科增加“生长发育史”字段。每批上线前用该科室近3个月病历做A/B测试确保新字段准确率85%。治理体系建设Day 76-90建立三项制度①模型健康看板实时显示各科室的“生成成功率”“字段编辑率”“质控抽检不合格率”②Prompt版本管理每次修改Prompt必须关联一个业务问题如“解决儿科生长发育史漏填”并记录测试结果③医生反馈通道在病历编辑界面嵌入“报告AI错误”按钮点击后自动上传问题样本至审核队列48小时内回复处理结果。成果90天后系统覆盖全院12个科室日均处理病历1200份医生NPS净推荐值达76分行业基准为45分。这不是一个技术项目结项而是一个业务流程的新生。5. 常见问题与排查技巧实录那些没人告诉你的“血泪经验”5.1 问题模型输出突然变差但API状态正常日志无报错典型现象某客服对话系统连续3天“满意度预测”准确率从89%跌至72%而API调用成功率、延迟均在SLA内。排查路径检查输入分布漂移对比下跌前后7天的输入文本长度分布、关键词频次。我们发现用户开始大量使用“你们这破系统”“垃圾”等情绪词而模型训练数据中此类表达不足。验证Prompt鲁棒性用下跌期间的典型输入如“你们这破系统根本没法用”测试不同温度值temperature。发现temperature0.7时模型易受情绪词干扰temperature0.2时更稳定。定位业务规则变化核查是否近期上线新活动如“618大促”导致用户咨询模式突变。果然大促期间“物流延迟”咨询激增而模型对物流类问题的训练数据仅占5%。解决方案短期动态调整temperature至0.2加权“物流”“售后”等高频意图的Prompt示例中期用下跌期间的1000条样本做小批量微调LoRA仅更新最后两层长期建立“输入分布监控”当某关键词频次周环比超30%自动触发告警。独家技巧在日志中为每次调用打上“输入熵值”标签用Shannon熵公式计算文本信息密度高熵输入如长篇抱怨单独路由至更稳健的模型版本。5.2 问题Token成本失控账单远超预算典型现象某法律文书生成API月预算5万元实际支出18万元但调用量仅增长12%。根因分析隐藏的重试风暴当模型输出JSON格式错误时系统自动重试3次而重试请求的输入文本完全相同导致Token翻3倍无意识的“过度生成”Prompt要求“详细解释法律依据”模型平均输出1200字符但律师只需3个法条编号数据污染用户上传的PDF中含大量页眉页脚、扫描噪点ASR转写后产生大量无意义字符。解决方案重试熔断设置“格式错误重试上限1次”第二次失败则返回结构化错误码由前端提示用户“请检查输入格式”输出长度硬约束在Prompt末尾添加“输出不得超过300字符超长则截断”并用正则校验输入预处理收费将ASR转写模块独立计费对页眉页脚等噪声收取0.01元/千字符清洗费倒逼业务方上传干净文档。避坑心得永远假设模型会“废话连篇”你的防御措施必须比它的废话更早生效。在API网关层就做Token预算拦截——当单次请求预估Token超500时直接拒绝并返回“输入过长请精简”。5.3 问题业务方说“感觉不准”但离线测试准确率95%典型现象某HR简历筛选API测试集F10.95但HR反馈“筛出来的人都不合适”。真相挖掘测试集用的是历史已录用简历而线上面对的是海量未筛选简历分布完全不同HR真正需要的不是“是否合适”而是“是否值得面试”即Top 5%的优质候选人而F1指标平滑了长尾效应。排查方法构建业务真实测试集从招聘平台抓取近3个月“无人投递”的冷门岗位简历作为新测试集重定义指标计算“Top 10名候选人中HR实际邀约面试的比例”我们称其为“邀约转化率”归因分析对被筛出但HR邀约的简历做特征分析发现模型严重低估“海外经历”“开源项目”等非传统优势。解决方案在Prompt中加入权重指令“海外学历、GitHub star数、专利数量权重为国内学历的2倍”建立“HR反馈闭环”每次HR手动邀约未被AI推荐的简历系统自动学习其特征权重。关键认知离线指标是“实验室血压”线上效果是“运动后心率”。永远用业务方真实的决策行为而非你的测试脚本来定义“准”。5.4 问题模型开始“一本正经胡说八道”且越训越糟典型现象某金融问答机器人微调后“利率计算”准确率从92%升至96%但“监管政策解读”幻觉率从8%飙升至41%。原因诊断微调数据中95%是利率计算样本仅5%是政策问答模型在梯度更新中“遗忘”了政策领域的知识使用了过高的学习率导致底层知识被覆盖。抢救方案知识冻结微调仅微调顶层MLP层冻结Transformer所有层参数混合数据训练将政策问答样本占比提升至30%并加入“政策原文-官方解读”平行语料幻觉抑制损失在损失函数中加入KL散度项约束模型输出与知识库原文的分布距离。血泪教训微调不是“给模型喂更多数据”而是“在知识版图上精准开凿沟渠”。盲目微调等于用推土机修手表——力气越大坏得越惨。每次微调前必须回答我要强化哪一块知识哪些知识必须原封不动强化的代价是什么5.5 问题上线后用户投诉“AI在歧视XX群体”典型现象某招聘简历筛选API被投诉对女性求职者“技能匹配度”评分系统性偏低。根因溯源训练数据中技术岗男性简历占比82%模型将“领导力”“攻坚”等词与男性强关联Prompt中“请评估候选人技术能力”隐含了性别刻板印象。治理行动数据层面用对抗性去偏算法Adversarial Debiasing重平衡训练集确保男女简历在各技能维度分布一致Prompt层面重写指令“请基于简历中明确写出的技术栈、项目经验、认证证书进行客观评估忽略姓名、性别、照片等无关信息”输出层面增加“公平性审计”模块对每位候选人输出“技能匹配度”时同步输出“该评分与同技能水平男性候选人的偏离度±%”超5%自动标红。终极原则AI的偏见不会凭空产生它只是把人类社会的褶皱用更锐利的刀锋刻了出来。你的责任不是消除偏见而是让偏见变得可见、可测、可修正。每一份上线的AI应用都该附带一份《偏见审计报告》。6. 工具链与工程实践让“Tips”真正落地的武器库6.1 Prompt工程实战工具箱Prompt版本管理不用Git管理纯文本Prompt而用promptfoo开源工具它支持① 将Prompt、测试用例、评估指标如“JSON格式正确率”打包为YAML② 一键运行A/B测试生成可视化对比报告③ 与CI/CD集成每次PR合并自动触发Prompt回归测试。实操心得我们规定任何Prompt修改必须附带3个失败测试用例证明新版本能修复旧问题。动态Prompt生成器针对多场景如不同科室病历不写10个静态Prompt而用Jinja2模板{% if dept pediatrics %} 你是一名儿科医生请特别关注生长发育史... {% elif dept cardiology %} 你是一名心内科医生请重点记录心绞痛发作特征... {% endif %}*好处业务