咱们直接聊个扎心的话题过去一年多我见过太多团队拿着大模型一头扎进金融场景结果被现实狠狠教育了一顿。有的做智能客服回答得倒是流畅但客户一句这钱还能拿回来吗模型就开始发挥想象力了有的做研报分析摘要做得挺漂亮关键数据却张冠李戴。问题出在哪不是模型不够强而是大家把写提示词想得太简单了。真正的提示工程在金融这种监管严、容错率低、数据敏感的行业里是一门需要体系化架构的硬功夫。今天这篇东西就结合我自己的项目经验聊聊提示工程在金融科技里到底是怎么落地的以及提示工程架构师这个角色究竟在解决什么问题。如果你正打算在公司里推大模型应用或者已经在做但效果不稳定又或者单纯对这个新岗位好奇——这篇文章应该能给你不少拿得走的东西。我先说个结论金融科技里的提示工程核心不是让模型变聪明而是让模型变听话。而让模型听话这件事从提示词设计到评估体系再到模型选型与部署是一条完整的链路。1. 金融科技场景下提示工程为什么不是写个prompt那么简单1.1 金融行业的特殊性决定了提示工程的边界金融科技场景跟一般的内容生成、代码辅助场景有个极其明显的区别错不起。写个营销文案AI多写两句夸张话术顶多是改稿子的事在银行或者持牌金融机构里AI的回答如果踩了合规红线、算错了利息、编造了一个不存在的产品条款那就不只是尴尬了而是实实在在的客诉、监管风险和资金损失。所以金融行业的提示工程从一开始就要回答三个普通场景不太会深究的问题第一幻觉能不能被结构性地压制泛化场景里幻觉是个尽量改善的问题金融场景里幻觉是个必须堵死的问题。靠什么堵靠提示词里的强约束、知识库/工具的强制优先调用、以及输出格式的硬性限定。这三个手段全部是提示工程架构师的工作范畴。第二同一个问题面对不同身份的提问者答案边界完全不同。客户问收益要讲清楚业绩比较基准和预期收益之间的区别内部投资经理问同样的问题就可以说得更直接、更专业。这种按身份分流的应答策略不是模型自带的而是要设计进提示词里的场景规则。第三可解释性与可审计性怎么保证金融行业做事得留痕。模型输出了一句话监管或者内审问你凭什么这么回答你得能追溯得回去——当时用了哪个版本的prompt、召回了哪些知识片段、置信度是多少。这已经不是提示词层面的问题了而是整个系统架构层面要为可追溯预留能力。1.2 提示工程架构师一个翻译官风控官实验员的综合角色这两年业内开始出现提示工程架构师这个岗位。我见过不少做算法、做产品的朋友说自己兼任了这个角色但真正干得漂亮的很少。为什么因为它其实是三类工作的复合体。首先是翻译官。业务方说的往往是让AI帮客户推荐合适的理财产品但这句话距离一个可运行、可评估、可维护的提示方案中间隔着大量的需求拆解工作你面向的客户是谁KYC客户尽调信息从哪里来推荐策略里的风险等级怎么映射合规允许你说到什么程度把这些问题一一落成明确指令和约束条件才算完成了第一层翻译。其次是风控官。提示工程架构师要在每一版提示词上线之前从业务意图安全边界表述规范三个维度做审核。光有业务能力不够还得懂一点监管上的红线思路知道哪些话术是绝对不能出现的。在金融行业提示词不是代码代码上线有测试和Review提示词同样需要有这套发布阀。最后是实验员。真正好的提示词不是拍脑袋写出来的是拿数据试出来的。同一个任务你可能要设计提示的结构、约束的方式、示例的组合然后再用几十个评估样本跑一遍看哪版通过率高。这个过程要求你养成记录比例的习惯而不仅仅是感觉这版好像效果好了。一个人的精力是有限的但如果一个团队想要系统性地推进大模型在金融场景的落地提示工程架构师这个角色甚至比算法工程师更前置。因为算法工程师解决的是模型能不能学会提示工程架构师解决的是模型现在能不能按我们的规矩干活。2. 提示工程架构师的核心工作流从业务需求到可复用的提示方案2.1 场景梳理与提示模板抽象做过几个真实项目之后我对提示工程最大的体会是模板比提示词重要而方法论比模板更重要。因为金融场景里的每个业务线都在提需求如果每个需求都从零开始设计提示团队会累死而且质量参差不齐。所以第一步永远是抽象模板。以文本分类任务为例我常用的模板骨架是这样拆的[系统设定] 你是[某金融领域]的资深分析专家坐标在[某机构]的[某业务部门]。 [任务指令] 请对用户提供的文本做[具体分类/提取/总结]任务。 [输入数据] 文本内容如下{input} [知识约束] 仅依据以上输入及[已提供的参考资料]作答不得补充未经验证的金融知识。 [输出要求] 输出格式为JSON包含字段{result}。杜绝包含任何主观倾向。这个系统设定-任务指令-输入数据-知识约束-输出要求的结构我称之为提示词五段式。它看上去简单但能在金融场景里兜住绝大部分基础任务。原因在于系统设定解决了模型的角色边界和知识范围避免泛化输出。任务指令把决策规则前置让模型知道自己该干什么。输入数据和知识约束共同压制幻觉——模型只能基于给定材料说话。输出要求是后期自动化解析和校验的基础结构化输出在金融系统里几乎必须。2.2 提示参数与模型选择的联动提示词写完之后还有一堆和模型交互的参数需要调而这部分经常被忽略。我见过不少人用的模型默认参数生成效果飘得很。拿temperature温度来说它控制模型输出的随机性。在金融场景里面向客户的生成任务客服回复、理财建议、合规话术我会把temperature调到0.1~0.3有的保守场景甚至调到0。目的只有一个让模型怎么说都尽量一样别给客户搞惊喜。面向投研的探索性任务行业逻辑梳理、新闻异动归因可以稍微放开到0.4~0.6给模型一点多样性空间但也不会超过0.7——金融分析要的是有约束的发散不是天马行空。再说top_p。这个参数和temperature经常一起出现控制的是候选词概率分布的截断。它在金融场景里我一般固定用0.85~0.95很少往下降。有过一次做策略生成提示把top_p降到0.7结果输出倒是稳定了但回答特别干瘪很多合理的分析维度都没覆盖到。后来想明白了金融文本生成任务里模型需要的是足够大的候选空间来组合出专业的表述过度截断反而让内容贫瘠。两个参数的关系网上的说法很多核心记住一点它们是配合使用的不是替代关系。我自己的习惯是先用一个评测集固定top_p在0.9然后只调temperature找出业务可接受范围内的最优值。至于模型选型目前在金融科技中比较常见的是两条路线一条是直接用大型通用模型的API需要联网、能力强、开发快另一条是私有化部署的开源模型比如中杯参数量的那种约70亿到130亿参数级别数据不出域可控性更强。提示工程架构师在这儿的职责是评估业务的实时性要求和敏感程度决定哪个任务可以走API、哪个任务必须走私有化。如果两个模型都参与提示词还要做差异化的适配。2.3 提示版本管理与上下文化代码有Git做版本管理提示词也应该有。金融行业尤其如此因为监管审计很可能要追溯当时线上跑的到底是哪一版提示词。我在项目里的做法是把提示词模板放在专门的版本仓库里和代码一起提交、一起打标签。每次修改都要写清楚变更记录改了哪个字段、解决了什么问题、评测指标提升了多少。这里分享一个实践细节提示词的版本号和模型的版本号要分开记录但映射关系要有对照表。有一次我们临时切换了底层模型结果所有用旧提示词的接口响应质量显著下降。一查才发现原提示词针对旧模型的话痨倾向做了很强的抑制表述但新模型本身就很克制加上抑制词反而让它回答变得过于简短。对照表让我们快速定位了问题并在适配后加了一版新提示词。这个案例给团队的教训是给模型升级也预留提示工程回归的流程。上下文管理也是同样重要的事。金融场景下多轮对话的窗口是有限的但用户的原始输入往往很长。比如客户发来一份三页的产品说明问这个能买吗如果你把三页全文塞进上下文对话轮数稍多信息就要被挤出窗口了。架构师需要设计一套上下文压缩策略首轮完整解析提取关键信息产品类型、期限、风险等级、适用人群存入结构化记忆后续轮次只携带结构化摘要和最近两轮原始对话一旦对话超过N轮触发强制总结把所有关键结论写进摘要替换掉旧对话。这套策略写进提示词本身再配合外部短记忆模块实际效果比硬顶上下文效果好很多。3. 金融科技高频场景的提示设计实操3.1 智能客服与理财投顾场景智能客服基本是每家公司做金融AI第一站。它的提示设计相对成熟但仍有几个坑值得展开。坑一把客服和投顾的角色混在一个提示里。客服的核心是准确、礼貌、解决问题流程清晰投顾的核心是基于客户信息做匹配分析。如果都让模型扮演全能顾问很容易在合规表述上出问题。我在做方案时会把提示拆成两层先做意图识别区分办业务还是咨询投资再根据意图加载对应的角色提示。这样做的好处是投资类回答可以明确加一句以上信息仅供参考不构成任何投资建议而业务办理类不会被这句合规话术干扰到办事效率。坑二多轮对话的约束很容易被绕过。客户可能先问你们银行有什么存款产品然后又补一句帮我比较一下。如果提示词里没有明确的状态追踪设计模型搞不清楚这是同一个客户在追问还是新开了一轮。在实际项目中我习惯在每个系统提示的末尾加一行对话状态字段把当前已确认的信息结构化地列一遍这样模型每次回答前都能回看自己掌握的情况。理财投顾场景涉及到一个提示词之外的敏感点推荐的适当性。模型可以推荐产品但不能脱离客户的KYC画像更不能把高风险的推给稳健型客户。这个约束光靠提示不牢靠我在架构里会把它做两层保险第一层业务系统先判读KYC数据如果客户风险等级不允许压根不触发推荐类的提示第二层即使第一层放行了提示词里仍要求模型在输出前先自查风险等级匹配情况。双保险才敢上线。3.2 文档解析与投研分析场景文档解析在金融科技里是一个非常高频且极容易出现幻觉的领域。比如研报分析模型要把几百页的PDF读成结构化的要点还要提取关键财务数据。难点在于长文档在输入窗口里被打断模型记不住前文而且财务数据极其敏感多一个零少一个零都是事。我的经验是不要幻想大模型通读全文而是要让提示工程配合检索增强生成RAG架构来做。具体分三步文档切分与索引按章节、段落、主题把PDF切分关键表格单独抽出来转成结构化的数据块定位式提问提示词不再问总结这份研报的核心观点而是问根据以下关于[公司名]的片段总结其在[业务板块]的战略布局数字校核约束提示词里明确要求所有数据必须保留原始单位如需计算请在输出中同时展示算式与结果并以结构化字段提取。这套提示设计配合RAG能有效把模型在胡说贬低到可接受的水平。但注意RAG不是银弹检索到不相关的片段反而会误导模型。所以在提示词里加上如果检索内容与提问主题不直接相关请说明未基于检索内容作答这类防御语句能大幅提高输出质量——这句话本质上是在为检索失败设置兜底。3.3 风控与合规审核场景风控和合规是金融科技的守门员也是提示工程最考验严谨性的场景。这里我拆两个真实做过的任务。任务一是合同合规审核。合同文本内容长达几十页传统做法是人工一条条看。用提示工程做预审提示词的设计思路是列举式对比将规则引擎判定的合规要点逐条写进提示要求模型逐条核对原文并输出条款原文命中规则判断结论。这本质上不是让模型自由裁量而是让模型做受控的信息比对。结果表明模型能把一些明显的漏洞抓出来比如关键位置的条款说法和通用规则不一致效率比人工提高不少。任务二是异常客户询问的语义识别。风控团队往往会用规则过滤明显的黑名单词但客户可能会用变体、代称、暗语来绕开。提示工程在这儿的价值是语义归一化。我给模型设计的提示是以下是客户的原始表述请将其翻译为语义规范的通顺语句不增删信息并标注可能的敏感意图类别。如果无敏感信息请输出正常。 这一步做完后面的规则引擎再用临时上线的关键词去匹配发现异常的速度明显提升。4. 提示评估与迭代提示工程的测试驱动开发4.1 评估数据集的建设提示工程如果没有评测就跟代码不做单测一样——上线全靠运气。我的习惯是从项目第一天就开始积累评测集而不是等项目做完了才想起来补。评测集至少要有三种样本黄金样本业务专家标注的标准答案用于判断模型输出是否准确、完整、规范对抗样本专门用来刁难模型的输入比如包含歧义、隐含身份冒充、用诱导方式套问敏感信息的文本检验模型的边界边界样本符合规范但描述方式多变的同类输入用来保证模型的泛化表现。在金融场景里对抗样本尤其重要。比如有客户故意说我不是要投资就是想了解你们有什么理财产品随便聊聊这表面上是个闲聊但如果模型一本正经地聊起收益可能就踩了销售适当性的合规线。对抗样本的开发通常需要业务人员和风控人员一起参与把曾经踩过的雷都记下来。4.2 自动化评估指标体系单靠人一眼一眼地看结果永远做不出可靠的提示工程。建议至少建立以下四个自动化评估维度评估维度说明主要指标准确率业务关键信息是否正确是否基于给定材料/知识作答关键实体准确率、上下文相关度合规率是否包含过滤器词、是否触发了限定话术、是否超出边界规则违规语句率、合规声明缺失率稳定性同一输入多次生成结果是否趋于一致波动率、重复率可用性输出格式是否符合约定能否被下游系统顺利解析解析成功率、字段缺失率这里有一个细节合规率不能只靠模型自己去保证。建议在提示工程之外叠加一层规则卫士做兜底过滤——用正则、敏感词库把提示层可能漏掉的东西挡在出口。规则卫士本身不属于提示的范畴但它会和提示工程配套出现提升整体防御能力。4.3 迭代流程与回归测试提示词的修改看似低成本风险却很隐蔽改了一个场景的提示可能悄悄破坏另一个场景的行为。我在项目里强制要求任何一轮提示词变更都要在全量评测集上回归一遍。回归测试时最直观的方法是做个对比表哪个样本在旧版本正确、新版本却失败了哪个样本之前会错、这次被修好了。把这些信息整理成日报挂在项目群里让业务方也看得到提示工程在往前走。说实话这一步比技术本身更能赢得业务方的信任——他们看到模型在持续变好而不是AI像个黑盒时好时坏。还有一个迭代经验的点提示词更新的速度不能快于评测集更新的速度。如果你的评测集只有二十个样本提示词改了十版那大概率是在过拟合这二十个样本。正确的做法是评测集每扩充一批真实样本提示词才允许做一轮大的调整。在迭代节奏上宁慢勿快。5. 金融科技场景下大模型选型与私有化部署协同5.1 模型选型的几个非技术考量技术人聊模型选型往往只看参数量和榜单分数但金融场景里有几个非技术考量反而更关键。第一个是对中文金融文本的理解能力。榜单分数高不代表能把一行本产品为浮动收益型不保证本金安全理解到位。我建议用自己业务里的真实文本来做评测而不是迷信通用榜单。第二个是模型的专业知识更新频率。金融市场瞬息万变模型底座里存的知识是有时效的。如果你用的是通用模型它可能不知道最近某类产品的监管口径改了什么。所以提示工程架构师要养成习惯在提示词里明确以上回答仅基于通用知识请结合实际规则进行修正并且配合RAG让模型先看最新知识再看问题。第三个是接口的稳定性。如果在业务高峰期模型接口响应时间忽高忽低再好的提示工程也没用。曾经跟某公司合作时他们的API在上午9:30到10:00股市开盘时段总是超时后来排查是并发处理能力不够。这提醒我们选型时要同时评估服务端的扩容能力和回调备用通道。5.2 私有化部署与混合架构考虑到金融数据的敏感性私有化部署几乎绕不开。很多机构会采用双轨制内部知识类问答走开源模型私有化部署专业的面向外部客户的场景走逻辑更为复杂的API同时配合人审。但在私有化部署的场景里模型的能力往往比商用API弱一些对提示词的理解力也有差距。我做过一个对比同样的提示工程模板在商用大模型上产出90分评价在私有化部署的中小模型上可能只有70分。这时候架构师要做的不是抱怨模型弱而是把提示词拆得更碎、更细降低单步推理负担。具体来说一个复杂任务拆成三步、三个模型调用每步的输出都是下一步的输入提示词里明确每一步只做一件事把推理压力分散每个子任务设计独立的评测点方便定位是哪一步拖垮了整体效果。这套工作流编排提示拆分的做法在模型能力有限的情况下尤其见效。金融场景里的私有化部署中央API联动混合架构我觉得是未来一两年的主流形态提示工程架构师需要尽早适应这种混编节奏。5.3 RAG与提示工程的融合设计金融行业里回答问题前先查库几乎是必须的因为很多问题的答案就藏在产品条款里。RAG检索增强生成的提示设计和直接问答有很大区别。核心在于检索与生成的衔接必须做得非常明确。我的设计习惯是提示词里专门留出检索结果区并且写明以下优先级检索结果 知识库片段 模型自身知识。模型必须优先基于检索结果区的内容作答如果检索结果为空或无关要明确说暂未找到相关信息请咨询人工客服。同时RAG场景下的提示词要特别写清楚引用规范。金融行业要免责必须让模型说清楚信息来自哪里。我给模型设计的输出模板往往长这样{ answer: 针对您的问题根据【产品说明书】第X条您可以……, source_id: 2024-xxx-xx.pdf, confidence: high }把source_id来源标识跟着输出一起出来这样后台系统就能做引用溯源监管问起来也能交代得清楚。在评估环节引用来源缺失率是我必看的一个指标——如果一个回答没有给出任何来源即使内容看着正确也不能算合格。6. 典型落地案例拆解一个银行智能问答系统的提示方案6.1 项目背景与挑战只说结构容易空我拿一个实际操作过的某银行智能问答系统项目做拆解。当时的需求是客户在手机App上问关于存款、贷款、信用卡业务的问题系统要做自动答疑答不上来再转人工。看上去很简单但难题一堆银行的数据分布在十几个业务系统里口径不统一客户提问的方式千奇百怪而客服渠道的容错率又特别低。我们采用的核心策略不是做一个超级AI助手而是搭了一个提示工程中台。这个中台把各种提示模板、评测集、调用参数集中管理提供给多条业务线共用。业务线新增场景只需要在中台配置自己的角色设置业务规则样例就能快速发布。第一个挑战就是口径不统一。举个例子客户问提前还款有手续费吗A业务线的规则是按剩余本金的1%收B产品线的规则是不收。如果模型按通用知识答一定会出错。我们用RAG把各业务线的产品规则按标签分类索引同时在提示词里要求模型先定位产品线归属再回答费率。这样一来同一个模型服务不同的产品也互不干扰了。第二个挑战是转人工的判定标准。我们不希望把压力都抛给模型——有些问题模型根本不该答比如涉及客户账户安全、应急挂失等业务。提示词里专门设计了移交条件如果用户表达出焦急情绪、投诉倾向或身份不明不得直接给出最终结论必须引导向人工客服。这块还特意做了情绪识别的小模型辅助判断把情绪作为输入的一部分传给大模型提示。6.2 提示方案设计的三个关键细节细节一每类业务单独设计规则区。在提示词里划出一块专门承载本业务线专属规则的位置每次调用时动态代入。比如信用卡业务带的规则是可向客户说明分期手续费折算年化利率的计算过程但不得承诺具体获批额度。这些规则来自业务专家逐条整理模型只是执行者不是决策者。细节二托底话术必须写进提示词。什么是托底话术就是当模型回答不了、或者答案的不确定性太高时用来体面收场的官方说辞。我见过太多AI系统把自己逼进死胡同——客户问了一个超出知识库的问题模型在那儿硬编一个答案。我们的提示里明确要求如果从检索结果及知识库中无法定位到准确答案请以以下话术作答您的问题我需要核实一下请稍等我将为您转接人工客服。一句话兜住所有不确定性。细节三把禁止做什么写得比应该做什么更细。金融合规准则光靠一句注意合规是不够的。我们在提示词里把不该做的列表直接展开不得给出具体收益率承诺、不得使用绝对化用语、不得在未经授权的情况下透露任何政策调整信息、不得收受识别到的用户情绪压力而破例。这条禁止列表初见很笨拙但实际效果异常明显——它把模型在边界上的发散空间压缩到了极小。6.3 回顾这个项目的经验沉淀做完这个项目我们对提示工程中台这种模式变得非常坚定。原因很简单团队一旦养成把提示当产品做的习惯新场景的上线速度就会有质的提升。原来从业务提需求到上线可能要一个月现在一周就能做到可用状态剩下的时间都在做评测、调逻辑和压合规。但也必须诚实地说这种方案的运维成本并不低提示词仓库的维护、评测集的扩充、模型升级的回归、规则区的迭代。如果没有一套像样的流程支撑很快就会变成十几个场景十几套模板谁也说不清谁是谁。所以我对想往这个方向走的团队的建议是先上流程再上规模。没有评估基线和版本管理做的场景越多反而越乱。7. 常见问题与排查技巧实录7.1 提示工程落地中常见的五个问题问题现象可能原因排查与解决思路模型回答看似专业但核心数据错误没有把用数据说话明确写进提示模型在自由发挥提示中增加所有数据必须来自检索结果否则注明未查到;必要时叠加外部数据校验客户问得绕模型频繁宕机或答非所问意图识别和多轮状态管理没做模型在多个业务线间混淆增加前置意图分类并为不同意图加载不同提示模板同一问题多次回答逻辑不一致temperature过高或提示词中缺少结构化决策路径调低temperature同时把决策规则拆分成显式步骤让模型走流程而不是凭感觉换了模型底座以后原先好用的提示突然失效新旧模型对指令的理解风格不同过度适配了旧模型模型升级时强制跑一轮回归重新适配提示风格提示词没变但线上效果随机波动检索增强部分召回质量不稳定单独调检索模块同时检查提示中的检索结果优先级是否被模型忽视这五个问题是我在多个项目里反复遇到的典型情况。重点说下为什么模型在自由发挥和没有把数据来源写清楚关系这么大。金融场景下的模型不是创造答案的而是汇总与分析工具。一旦提示词里缺乏所有数据必须可溯源这个强约束模型的合理想象就会被激活。我在所有金融场景的提示模板里都默认加一句所有具体数据、金额、日期、条款必须引用自给定的检索内容若检索内容中不存在请明确回答无法确认不得推测。这句话不一定100%消除幻觉但确实能把幻觉率显著打下来。7.2 实操心得与避坑建议心得之一不要迷信零样本提示词给模型两个例子比什么都管用。金融场景里的输出往往有特定的表达规范和语气。给模型两个带标注的示例它跟着学比单纯靠说理靠谱得多。尤其是一些合规话术的表达范式示例教学效果极佳。当然示例要定期更新防止模型学出新花样尤其是话术模板一更新示例也必须跟着同步。心得之二提示词里的不要会被削弱你要用要做来替代。这是一个语言学层面的技巧。跟模型说不要提收益可能不够强而说只解释产品结构重点落在风险揭示上效果反而更好——因为后者给了模型一个明确的重定向方向而不是让它留在一个什么不能说的真空里纠结。心得之三警惕数据穿越。大模型的训练数据里含有大量增量信息它有可能会把自己从公开新闻里学到的某个公司的信息偷偷补充到你的内部文档问答中。这在投研场景特别危险——模型分不清你给它看的资料的前后时间线。我处理的办法是在每个投研类提示词的开头都写上所有分析必须基于输入文档内容不得引入202X年之后的公开信息并且在输出模板里增加引用时间字段来辅助检查。心得之四在金融科技里提示工程是系统问题不是模型问题。很多人以为调一调提示词就能解决所有问题其实不然。遇到效果不好先分清楚是检索环节丢了信息还是模型推理环节写错逻辑还是输出解析环节格式错乱。我习惯用漏斗排查法从输入到输出每个环节加一个日志埋点交错检查。这个过程比较枯燥但能让项目变成一个可诊断的工程而不是碰运气的黑盒。最后再聊两句我做提示工程这几年最大的感受是这门手艺的成长不在模型发布的时候而在每一个被真实场景教做人的瞬间。那种这提示词看着挺好一上线就翻车的体验几乎每个从业者都经历过但也正是这些瞬间逼着提示工程从一门手艺变成了一套方法论、一整套流程和工程体系。如果你正准备在金融科技里引入大模型我的建议是不要从哪个模型最强开始而要从你业务里最痛的那三个问题开始把它们描述清楚——再打磨你的评测集——再写你的第一版提示词。模型会半年换一代提示词也会跟着迭代但用工程思路解决不确定性问题这件事才是真正沉淀下来的能力。最后送大家一个实际验证过的小技巧每次发布新提示词之前问自己一句——如果这个提示词明天就要接受监管审查我能不能解释清楚为什么这么写能解释就说明你的设计是理性的、结构化的、经得起推敲的不能解释就再回去想一想再上线也不迟。
