某金融App智能风控提示工程：架构师的合规性提示词设计指南

一、引言：当智能风控遇到“合规魔咒”

1.1 一个真实的“痛点时刻”

某股份制银行的信用卡App上线了基于大模型的“交易欺诈检测”功能：用户在境外发生大额交易时，系统会自动触发风险提示。但上线3天就收到12起投诉——一位常年在海外工作的用户，连续3笔“正常”的境外消费被标记为“高风险”，导致卡片被冻结；更严重的是，后台日志显示，模型在分析时“悄悄”调取了用户的“社保缴纳记录”（未获得用户明确授权），违反了《个人信息保护法》（PIPL）第二十三条。

技术团队排查后发现：问题出在提示词设计——初始提示词是“分析用户最近7天的交易行为及关联数据，判断是否存在欺诈风险”。这里的“关联数据”没有明确边界，导致模型“自作主张”调用了敏感信息；而“欺诈风险”的定义模糊，让模型误将“海外高频消费”等同于“异常”。

这个案例暴露了金融智能风控的核心矛盾：大模型的“灵活性”与金融监管的“刚性”之间的冲突。当我们用大语言模型（LLM）优化风控效率时，如何通过提示词设计，让模型既“聪明”又“守规矩”？这正是本文要解决的问题。

1.2 为什么提示工程是金融风控的“合规阀门”？

金融是“强监管”行业，智能风控的每一步都要符合：

• 《个人信息保护法》（数据隐私）；
• 《金融数据安全管理规范》（JR/T 0197-2020，数据使用边界）；
• 《商业银行互联网贷款管理暂行办法》（可解释性要求）；
• 《反洗钱法》（AML，风险覆盖完整性）。

而大模型的输出高度依赖提示词——提示词是“人类意图”与“模型行为”之间的翻译器。如果提示词没有明确合规约束，模型可能会：

• 超范围调用敏感数据（比如用用户的医疗记录判断信贷风险）；
• 输出无法解释的决策（比如“该用户风险高”但没有任何依据）；
• 遗漏监管要求的风险场景（比如反洗钱中的“受益所有人识别”）。

因此，合规性提示词设计不是“锦上添花”，而是金融智能风控落地的“必要条件”。

1.3 本文能给你带来什么？

作为架构师，你将学到：

1. 底层逻辑：金融合规如何映射到提示词设计的关键要素；
2. 设计框架：从“场景对齐”到“迭代优化”的全流程合规提示词设计方法；
3. 实战案例：交易欺诈检测、信贷风险评估两个场景的提示词优化示例；
4. 避坑指南：避免90%的合规性错误的10条最佳实践。

二、基础铺垫：金融智能风控与提示工程的核心概念

在进入设计指南前，我们需要明确几个关键概念，避免“鸡同鸭讲”。

2.1 金融智能风控的核心场景

大模型在金融App风控中的常见应用场景包括：

• 交易欺诈检测：识别盗刷、套现、洗钱等异常交易；
• 账户异常识别：检测账号盗用、异地登录、批量注册等行为；
• 信贷风险评估：辅助判断用户的还款能力与意愿（如分析用户征信报告、消费习惯）；
• 反洗钱（AML）监测：识别“大额拆分”“频繁跨境”等洗钱特征；
• 客户尽职调查（CDD）：验证客户身份的真实性（如分析身份证、营业执照OCR结果）。

这些场景的共同特点是：需要“精准判断”+“可追溯合规”——既要识别风险，又要证明“每一步决策都符合监管要求”。

2.2 提示工程的“三要素”

提示工程（Prompt Engineering）是通过设计“输入指令”引导大模型输出符合预期结果的技术。其核心三要素是：

• 角色（Role）：定义模型的身份（如“你是某银行的智能风控分析师”）；
• 任务（Task）：明确模型要做什么（如“分析用户交易是否存在欺诈”）；
• 约束（Constraint）：规定模型不能做什么（如“不得使用未授权的敏感数据”）。

对于金融风控来说，“约束”是合规性的核心载体——没有约束的提示词，相当于给模型“开了无门之门”。

2.3 金融合规的“四大维度”

我们需要将监管要求拆解为提示词可落地的“合规维度”，具体包括：

1. 数据隐私合规：仅使用“已授权+必要”的数据，不得泄露敏感信息；
2. 决策可解释性：输出结果必须包含“风险依据”，符合“告知义务”；
3. 监管场景覆盖：必须覆盖反洗钱、信贷管理等监管强制要求的风险点；
4. 输出格式规范：结果必须结构化（如JSON/表格），便于审计与回溯。

三、核心指南：合规性提示词的全流程设计

这部分是本文的“干货核心”——我们将以“交易欺诈检测”场景为例，一步步讲解如何设计符合合规要求的提示词。

3.1 第一步：场景合规映射——从“监管条文”到“提示词需求”

设计提示词的第一步，不是直接写指令，而是将业务场景与监管要求一一对应。这一步需要架构师、风控专家、法务团队共同参与。

以“交易欺诈检测”场景为例，我们先做“合规映射表”：

监管要求	对应的提示词需求	法律依据
仅使用已授权的非敏感数据	明确模型可使用的数据集（如交易时间、金额、商户类型），禁止使用未授权数据（如社保、医疗记录）	《个人信息保护法》第二十三条：“个人信息处理者向其他个人信息处理者提供个人信息的，应当向个人告知接收方的名称或者姓名、联系方式、处理目的、处理方式和个人信息的种类，并取得个人的单独同意。”
决策需可解释	要求模型输出“风险依据”（如“2024-05-01 23:00 在境外商户发生10万元交易，与用户历史交易习惯不符”）	《商业银行互联网贷款管理暂行办法》第三十七条：“商业银行应当向借款人提供显著、清晰的贷款条件、还款方式、年化利率、贷款金额、贷款期限等信息，确保借款人充分理解。”
覆盖反洗钱场景	要求模型识别“大额拆分”“频繁跨境”等反洗钱特征	《反洗钱法》第三条：“金融机构应当依法采取预防、监控措施，建立健全客户身份识别制度、客户身份资料和交易记录保存制度、大额交易和可疑交易报告制度，履行反洗钱义务。”
输出格式可审计	结果需结构化（如风险等级、依据、合规声明）	《金融数据安全管理规范》（JR/T 0197-2020）4.3：“金融机构应当记录数据处理的全流程，确保数据处理可追溯。”

3.2 第二步：提示词结构设计——“角色-约束-任务-输出”四步框架

基于合规映射表，我们可以用“四步框架”设计提示词：

3.2.1 1. 明确“角色定位”：给模型“戴紧箍咒”

首先定义模型的身份，让模型“知道自己是谁”——这能引导模型输出符合角色的结果。例如：

角色：你是某银行信用卡中心的智能风控分析师，负责交易欺诈检测，需严格遵守《个人信息保护法》《反洗钱法》等监管要求。

3.2.2 2. 前置“合规约束”：把“不能做的事”说清楚

约束是合规的核心，必须具体、明确、无歧义。避免使用“尽量”“不要”等模糊表述，要用“必须”“禁止”等强指令。例如：

合规约束：

• 仅可使用用户已授权的非敏感交易数据：交易时间、交易金额、商户类型、交易地点（仅到城市级别）、用户历史交易习惯（如最近3个月的平均交易金额、常用商户类型）；
• 禁止使用任何未授权数据（如社保记录、医疗信息、通讯录）；
• 禁止泄露用户个人敏感信息（如姓名、身份证号、手机号）；
• 必须覆盖反洗钱场景：需识别“单日累计交易金额超过5万元”“3天内跨境交易超过2次”“同一商户单日交易超过3笔”等可疑特征。

3.2.3 3. 明确“任务目标”：让模型“知道要做什么”

任务目标要具体、可衡量，避免“分析风险”这种模糊表述。例如：

任务目标：分析用户最近7天的交易数据，判断是否存在欺诈风险，需覆盖以下风险类型：

• 盗刷：异地登录后发生大额交易（与用户常用登录地不符）；
• 套现：频繁在同一POS机发生整数金额交易；
• 洗钱：大额拆分（将10万元拆分为5笔2万元交易）、频繁跨境（3天内跨境交易超过2次）。

3.2.4 4. 规范“输出格式”：让结果“可审计、可追溯”

输出格式必须结构化，便于后续的规则引擎校验、审计日志存储。例如：

输出格式要求：

1. 风险等级：高/中/低（需基于风险特征的严重程度判断）；
2. 风险类型：盗刷/套现/洗钱/无（需对应任务目标中的类型）；
3. 风险依据：引用具体交易数据（如“2024-05-01 23:00 在境外某电商平台发生10万元交易，用户最近3个月平均交易金额为2000元，且常用登录地为北京”）；
4. 合规声明：确认“未使用未授权数据，未泄露敏感信息”；
5. 反洗钱特征：若存在洗钱风险，需列出具体特征（如“3天内跨境交易3次，累计金额8万元”）。

3.3 第三步：示例演练——从“初始版”到“合规版”的迭代

我们用“交易欺诈检测”的提示词为例，看如何从“踩坑版”优化到“合规版”。

3.3.1 初始版提示词（踩坑版）

分析用户最近7天的交易，判断是否存在欺诈风险，输出风险等级。

问题分析：

• 没有角色定位：模型不知道自己是“金融机构的风控分析师”，可能输出不符合金融场景的结果；
• 没有合规约束：模型可能调用未授权数据（如社保记录）；
• 任务目标模糊：“欺诈风险”没有明确类型，导致模型误判；
• 输出格式不规范：没有依据，无法审计。

3.3.2 优化版提示词（合规版）

角色：你是某银行信用卡中心的智能风控分析师，负责交易欺诈检测，需严格遵守《个人信息保护法》《反洗钱法》《商业银行互联网贷款管理暂行办法》等监管要求。

合规约束：

1. 仅可使用用户已授权的非敏感交易数据：交易时间（格式：YYYY-MM-DD HH:MM）、交易金额（元）、商户类型（如电商、餐饮、境外线下）、交易地点（仅到城市级别，如“北京”“纽约”）、用户历史交易习惯（最近3个月平均交易金额、常用商户类型）；
2. 禁止使用任何未授权数据（包括但不限于社保记录、医疗信息、通讯录、地理位置精确到街道的信息）；
3. 禁止在输出中提及用户个人敏感信息（如姓名、身份证号、手机号、银行卡号）；
4. 必须覆盖反洗钱可疑交易特征：单日累计交易金额≥5万元、3天内跨境交易≥2次、同一商户单日交易≥3笔、整数金额交易（如10000元、5000元）占比≥50%。

任务目标：分析用户最近7天的交易数据，判断是否存在以下类型的欺诈风险：

• 盗刷风险：异地登录（登录地与最近3个月常用登录地不符）后发生大额交易（金额≥用户最近3个月平均交易金额的5倍）；
• 套现风险：频繁在同一商户发生整数金额交易（如10000元），且交易时间集中在凌晨（23:00-06:00）；
• 洗钱风险：符合上述反洗钱可疑交易特征中的任意1项。

输出格式要求（请严格按照JSON格式输出，不得添加额外内容）：
{
“risk_level”: “高/中/低”,
“risk_type”: “盗刷/套现/洗钱/无”,
“risk_reason”: “具体风险依据，需引用交易数据（如“2024-05-01 23:00 在纽约某电商平台发生10000元交易，用户最近3个月平均交易金额为2000元，常用登录地为北京”）”,
“aml_features”: [“反洗钱特征1”, “反洗钱特征2”], // 若无可为空数组
“compliance_declaration”: “本分析仅使用已授权的非敏感数据，未泄露用户敏感信息，符合监管要求”
}

3.3.3 优化后的效果对比

• 合规性：明确禁止使用未授权数据，输出包含合规声明，符合PIPL、反洗钱法要求；
• 准确性：定义了具体的风险类型（盗刷/套现/洗钱），减少误判；
• 可审计性：结构化输出便于存储、回溯，满足金融监管的“痕迹管理”要求。

3.4 第四步：多场景扩展——信贷风险评估的提示词设计

我们再用“信贷风险评估”场景验证框架的通用性。

3.4.1 合规映射表（信贷场景）

监管要求	提示词需求	法律依据
不得过度采集数据	仅使用征信报告、收入证明、消费习惯等“必要数据”	《个人信息保护法》第六条：“处理个人信息应当具有明确、合理的目的，并应当与处理目的直接相关，采取对个人权益影响最小的方式。”
决策可解释	输出“拒贷依据”（如“征信报告显示最近6个月有3次逾期”）	《商业银行互联网贷款管理暂行办法》第三十八条：“商业银行应当向借款人提供贷款审批结果的说明，包括贷款金额、期限、利率、还款方式等内容。”
禁止歧视性评估	不得基于性别、年龄、地域等非必要因素判断风险	《国务院办公厅关于加强金融消费者权益保护工作的指导意见》（国办发〔2015〕81号）：“金融机构应当尊重金融消费者的人格尊严和民族风俗习惯，不得因金融消费者的性别、年龄、种族、民族、国籍、宗教信仰、职业、健康状况、收入水平等差异而歧视金融消费者。”

3.4.2 信贷风险评估的合规提示词

角色：你是某互联网银行的信贷风控分析师，负责个人消费贷款的风险评估，需严格遵守《个人信息保护法》《商业银行互联网贷款管理暂行办法》等监管要求。

合规约束：

1. 仅可使用以下数据：用户征信报告（逾期次数、负债比例）、收入证明（最近12个月平均收入）、消费习惯（最近6个月的消费金额、消费类型）、央行征信中心的信用评分；
2. 禁止使用以下数据：性别、年龄、地域、宗教信仰、民族、职业（除金融、高危行业外）；
3. 禁止输出歧视性表述（如“女性用户风险高”“农村地区用户还款能力弱”）；
4. 必须基于“还款能力”（收入 vs 负债）和“还款意愿”（征信逾期记录）评估风险。

任务目标：根据用户数据，评估其个人消费贷款的违约风险，输出风险等级及依据。

输出格式要求（JSON）：
{
“risk_level”: “高/中/低”,
“risk_reason”: “具体依据（如“征信报告显示最近6个月有3次逾期，负债比例为70%（月收入10000元，月还款7000元）”）”,
“compliance_declaration”: “本评估未使用歧视性数据，未泄露敏感信息，符合监管要求”
}

四、进阶实践：合规性提示词的“避坑”与“优化”

4.1 常见陷阱：90%的架构师都会踩的5个坑

4.1.1 陷阱1：“模糊表述”导致模型越界

错误示例：“分析用户的关联数据”
问题：“关联数据”没有明确边界，模型可能调用未授权的敏感数据（如医疗记录）。
解决：用“白名单”明确可使用的数据（如“仅可使用交易时间、金额、商户类型”）。

4.1.2 陷阱2：“忽略动态监管”导致提示词过期

案例：某金融App的提示词没有覆盖2023年修订的《反洗钱法》中“受益所有人识别”的要求，导致模型遗漏了“通过壳公司洗钱”的风险。
解决：建立“提示词-监管条文”的映射关系，定期（如每季度）由法务团队审核提示词的合规性。

4.1.3 陷阱3：“输出非结构化”导致无法审计

错误示例：模型输出“该用户风险高，因为交易异常”
问题：没有具体依据，无法通过监管审计（如银保监会的现场检查）。
解决：强制要求输出“结构化+可追溯”的结果（如引用具体交易数据、征信记录）。

4.1.4 陷阱4：“角色定位缺失”导致模型“越权”

错误示例：没有定义模型角色，模型输出“建议冻结用户账户”（而冻结账户是风控人员的权限，模型不能直接决策）。
解决：明确模型的“辅助角色”（如“你是风控分析师的辅助工具，仅输出风险评估结果，不做决策”）。

4.1.5 陷阱5：“忽略隐私计算”导致数据泄露

案例：某App的提示词要求模型“分析用户的交易数据和社交数据”，但社交数据存储在第三方平台，未通过联邦学习等隐私计算技术处理，导致数据泄露。
解决：在提示词中明确“数据处理方式”（如“仅使用通过联邦学习加密后的交易数据，不得直接访问原始数据”）。

4.2 最佳实践：10条“合规提示词”设计原则

1. “白名单”优先：明确可使用的数据范围，而不是“禁止使用什么”（因为“禁止”无法覆盖所有场景）；
2. “强约束”代替“弱建议”：用“必须”“禁止”代替“尽量”“建议”；
3. “结构化输出”强制化：要求模型输出JSON/表格格式，便于审计；
4. “角色定位”具体化：让模型知道自己是“金融机构的风控辅助工具”，不是“万能顾问”；
5. “监管映射”可视化：建立提示词与监管条文的映射表，便于跟踪合规性；
6. “迭代测试”常态化：用真实数据测试提示词，检查是否存在“越界”“误判”；
7. “多角色评审”机制化：提示词需经过架构师、风控专家、法务团队三方评审；
8. “版本管理”规范化：记录每个提示词版本的修改点、生效时间、对应的监管依据；
9. “隐私计算”嵌入化：在提示词中明确数据处理方式（如联邦学习、差分隐私）；
10. “动态更新”自动化：当监管条文修订时，自动触发提示词的合规性检查。

4.3 性能优化：合规与效率的平衡

很多架构师担心“合规约束会降低模型效率”，其实可以通过以下方法平衡：

• 提示词精简：去掉冗余的约束（如“禁止使用医疗信息”已经包含在“未授权数据”中，无需重复）；
• 上下文压缩：将常用的合规约束存储为“系统提示词”（System Prompt），避免每次重复输入；
• 模型微调：用合规的训练数据微调模型，让模型“记住”合规要求，减少提示词的长度；
• 双引擎校验：用规则引擎对模型输出进行二次校验（如检查是否泄露敏感信息），避免模型“突破”提示词约束。

五、结论：合规提示词是智能风控的“地基”

5.1 核心要点回顾

1. 合规是前提：金融智能风控的每一步都要符合监管要求，提示词是合规的“翻译器”；
2. 框架是关键：用“角色-约束-任务-输出”四步框架设计提示词，确保合规性；
3. 迭代是保障：通过“测试-评审-更新”的循环，保持提示词的“时效性”与“准确性”；
4. 平衡是艺术：在合规与效率之间找到平衡，避免“为合规而合规”导致的性能下降。

5.2 未来展望：从“人工设计”到“智能生成”

随着大模型能力的提升，未来的合规提示词设计可能会向“智能生成”方向发展：

• 基于监管知识库的提示词生成：模型自动从监管条文库中提取合规要求，生成提示词；
• 提示词的自我校验：模型通过“反思机制”检查自己的输出是否符合提示词约束；
• 联邦提示工程：在隐私计算场景下，跨机构协同设计提示词，避免数据泄露。

5.3 行动号召：现在就动手优化你的提示词！

1. 选择你负责的一个风控场景（如交易欺诈检测），按照本文的“四步框架”设计合规提示词；
2. 邀请法务团队、风控专家评审你的提示词，检查是否符合监管要求；
3. 用真实数据测试提示词，记录“合规性”“准确性”“效率”三个指标；
4. 在评论区分享你的成果，或提出你的疑问——我们一起完善金融智能风控的合规体系！

附录：参考资源

1. 《个人信息保护法》（2021年）；
2. 《反洗钱法》（2023年修订）；
3. 《商业银行互联网贷款管理暂行办法》（银保监会令2020年第9号）；
4. 《金融数据安全管理规范》（JR/T 0197-2020）；
5. OpenAI官方提示工程指南：https://platform.openai.com/docs/guides/prompt-engineering。

（全文完）
作者：某资深金融科技架构师，专注于智能风控与合规技术落地。
声明：本文案例均为虚构，不涉及真实机构数据。