从提示词工程到上下文工程：银行AI应用的方法论升级

何岸 · GreenFinance 研究院 · 数字金融方向 · 2026-03-31

提示词工程的局限

当前多数银行的AI应用仍停留在"提示词工程"阶段——通过调整指令措辞，试图提升大模型输出质量。该方法在简单场景下有一定效果，但在复杂业务场景中很快触及天花板。根本原因在于：模型输出质量高度依赖输入信息的完整性和结构化程度，一条精心编写的提示词无法弥补缺失的业务上下文。

海外银行业的最新实践指向一个方法论转变——从提示词工程向"上下文工程"（Context Engineering）迁移。所谓上下文工程，是指在AI被调用之前，将其所需的数据、规则、约束条件和工具接口系统性地编排，使AI在完整而精确的决策上下文中工作。Shopify CEO在2025年提出"上下文工程是新的全栈开发"，这一判断在银行业正在被验证。

两种路径的效果差异

以企业信用分析场景为例。提示词工程方式下，向大模型输入指令"请分析该企业信用风险并给出建议"，模型仅基于自身训练数据和有限输入信息推理，输出结果不稳定，不同时间重复执行的一致性低于60%。上下文工程方式下，系统在调用模型前自动拼装目标企业的工商登记信息、近三年财务报表、行业对标指标、适用监管政策、历史授信记录等结构化数据，模型在完整上下文中给出分析，输出一致性提升至85%以上，且结论的可验证性显著增强。

差异的本质在于：提示词工程将智能的全部责任压在模型端，上下文工程则将数据和规则的责任留给系统端。后者更稳定、更可控，适合生产环境的规模化部署。

银行业的天然适配性

银行业可能是最适合实施上下文工程的行业之一，原因有三。

一是数据丰富但分散。银行拥有客户交易数据、征信数据、行业数据、政策数据、内部评级数据等大量结构化信息，但分散在核心系统、信贷系统、风控系统等不同平台。上下文工程的本质就是将这些分散数据按场景需求自动编排。

二是规则明确但复杂。银行的业务规则、监管要求和内部制度体系庞杂。这些规则不适合让模型自行推断，而适合作为上下文直接注入。从海外实践看，星展银行在中小企业信贷场景中将超过200条审批规则结构化后注入AI上下文，模型合规性从74%提升至96%。

三是场景重复度高。信贷审批、风险预警、客户营销等场景高度标准化，上下文模板一旦建成即可反复使用，边际成本递减效应显著。

国内落地的关键难点

国内银行实施上下文工程面临两个核心障碍。

一是数据打通。核心系统、信贷系统、风控系统之间的数据接口往往不通畅，实时拼装上下文需要跨系统调用能力。这不是AI团队能独立解决的问题，需要科技部门在数据中台层面提供基础设施支撑。据某国有大行内部评估，仅信贷场景所需的上下文数据就涉及7个系统、23个接口，完整打通预计需要6—9个月。

二是知识维护。行业政策、监管要求持续变化，上下文中的规则和参考数据必须保持动态更新。如果用过时政策指导分析，结论的误导性反而高于无AI辅助的情况。

起步建议

一是选择一个高频场景（如绿色项目识别或中小企业授信），完整梳理该场景所需的全部数据和规则清单。二是将清单中每一项转化为可调用的数据接口或结构化知识块。三是建立自动编排机制——场景触发时，系统自动拼装上下文再交给AI处理。四是设置"上下文新鲜度"检查机制，关键数据超过时效阈值时主动触发更新提醒。先在一个场景跑通完整闭环，再横向复制。