提示工程实战指南：从语言指令到AI生产力工具

1. 项目概述：当语言成为操控AI的精密扳手

你有没有试过对着一个大模型反复改写同一句话，像调试一段总不跑通的代码？“帮我写一封辞职信”——它给你模板；“请用温和但坚定的语气，结合我三年来主导过三个跨部门项目、带教过五名新人的事实，写一封体现职业成长与感恩的辞职信”——它开始输出有血有肉的内容。这不是玄学，是正在快速成型的一门手艺：Prompt Engineering（提示工程）。它不依赖修改模型参数，不涉及GPU堆叠，只靠对语言结构、认知逻辑和模型行为模式的深度理解，就能把一个通用大模型，临时“塑形”成医生、律师、架构师、甚至你的私人知识助理。

这门手艺的核心价值，在于它把AI从“黑箱应答器”变成了“可编程的认知协作者”。你不需要懂反向传播，但必须懂人类如何思考、如何表达意图、如何拆解复杂任务；你不需要会写PyTorch，但得会设计分步推理链、设置角色约束、构造示例样本。它不是让AI更聪明，而是让你更精准地“翻译”需求——把模糊的“帮我理清思路”，变成模型能执行的“请先列出问题的三个核心矛盾点，再为每个矛盾点提供一个现实可行的缓解方案，最后用一句话总结最优路径”。

我从2023年初开始系统性实践提示工程，最初是为了解决团队内部知识沉淀效率低的问题：工程师写的故障复盘文档，非技术同事根本看不懂；产品需求文档里埋着大量隐含假设，开发一做就偏。我们尝试过培训、过流程改造，效果都有限。直到把提示词设计成一种“轻量级接口协议”——给不同角色配不同的“提示模板包”，比如给测试同学的模板强制要求输出“可验证的检查项”，给市场同事的模板则内置了竞品话术对比框架。三个月后，跨职能协作返工率下降了67%。这让我确信：提示工程不是锦上添花的技巧，而是人机协同时代的基础生产力工具。它适合三类人：第一类是业务一线人员，想零代码调用AI解决具体工作流卡点；第二类是AI应用开发者，需要在不重训模型的前提下提升下游任务效果；第三类是教育者与内容创作者，要批量生成符合特定认知层级的教学材料。只要你每天和文字打交道，它就值得你投入时间去掌握。

2. 核心设计逻辑：为什么“说人话”反而最不高效？

2.1 从“自然语言”到“机器可解析指令”的范式转换

很多人第一次接触提示工程时，本能反应是：“我平时怎么说话，就怎么写提示词。”结果往往失望。原因在于，人类日常对话高度依赖语境省略、常识默认、情感暗示，而当前主流大模型（如GPT-4、Claude 3、Qwen系列）本质上是基于海量文本统计规律的概率预测器，它没有真实的世界经验，也没有持续的记忆上下文。当你对朋友说“那个东西太贵了”，朋友立刻知道你在吐槽刚看的咖啡机，因为你们刚一起逛过商场；但模型看到“那个东西”，只会去猜“那个”指代什么——可能是前文提到的第17个名词，也可能是训练数据里高频共现的“iPhone”。

所以，提示工程的第一课，是放弃“拟人化沟通”，转向“结构化指令设计”。这就像给一台精密机床下指令：你不会说“让它切得漂亮点”，而是明确输入“主轴转速8000rpm，进给量0.2mm/rev，冷却液压力3bar”。对应到提示词，就是把模糊意图拆解为四个刚性要素：

1. 角色定义（Role）：明确模型在此任务中的身份与专业边界。

   • ❌ “帮我分析这个财报”
   • ✅ “你是一位有15年经验的CFO，专注消费电子行业，擅长从现金流结构识别潜在风险。请基于以下财报数据……”
     为什么有效？角色框定了知识范围与表达风格，避免模型调用无关领域的泛化知识（比如用房地产分析逻辑解读芯片厂财报）。

2. 任务分解（Task Decomposition）：将复合目标拆为原子步骤，强制模型显式思考。

   • ❌ “写一篇关于气候变化的科普文章”
   • ✅ “第一步：用不超过3句话，向初中生解释‘温室效应’的物理原理；第二步：列举两个中国东部沿海城市近十年受海平面上升影响的具体案例；第三步：针对学生家长群体，给出三条家庭可操作的减碳建议。”
     为什么有效？避免模型在长文本生成中“自由发挥”，确保关键信息不被稀释。实测显示，Chain-of-Thought（思维链）式分解能使事实准确性提升42%（基于我们对1200条医疗问答的抽样验证）。

3. 约束条件（Constraints）：用硬性规则封堵常见失效路径。

   • ❌ “总结这篇论文”
   • ✅ “用中文输出，严格控制在200字以内；禁止使用‘本文’‘该研究’等指代性词汇；所有专业术语首次出现时需括号内附英文原名（如：Transformer（Transformer））；若原文未提及具体数据，不得自行编造。”
     为什么有效？约束条件直击模型两大顽疾：冗余描述（如反复强调“综上所述”）和幻觉生成（如虚构不存在的实验数据）。我们曾用同一份法律合同摘要测试，添加“禁止推测条款未明确约定的责任主体”后，错误责任归属率从31%降至0%。

4. 输出格式（Output Format）：指定结构化载体，降低后续处理成本。

   • ❌ “列出用户痛点”
   • ✅ “以Markdown表格形式输出，列名为：痛点编号 | 用户场景 | 表述原话（引号内） | 潜在需求（用‘希望……’句式） | 优先级（高/中/低）”
     为什么有效？结构化输出可直接导入Excel或数据库，避免人工二次整理。在客户调研分析中，我们用此方式将单份报告生成耗时从4小时压缩至11分钟。

提示：新手最容易犯的错误，是把提示词写成“需求说明书”。比如“我要一个能帮销售写邮件的AI”，这属于目标，不是指令。真正有效的提示词，应该像一份可执行的“操作手册”，每一步都告诉模型“此刻该做什么、依据什么、做到什么程度”。

2.2 不同任务类型对应的核心策略选择

提示工程不是万能膏药，不同任务类型有其天然适配的策略。强行套用高级技巧，反而增加失败概率。我们根据两年内37个落地项目的实操数据，总结出策略匹配黄金法则：

这里有个反直觉的经验：越专业的任务，越要减少“创造性”修饰词。比如医疗咨询提示词，我们严禁使用“生动形象地解释”“用比喻帮助理解”这类表述——因为医学概念的准确性远高于可读性。曾有一个项目，客户坚持要“让患者轻松听懂糖尿病机制”，我们妥协加入了“用厨房烧水比喻胰岛素作用”，结果模型生成了“胰岛素像锅盖，盖住水壶口防止水蒸气逃逸”，完全违背生理事实。最终方案是：用纯术语解释，但附加一句“如需面向患者简化，请明确告知，我将提供符合《健康科普规范》的版本”。

2.3 模型特性驱动的提示词动态适配

同一个提示词，在GPT-4、Claude 3和国产Qwen2-72B上表现可能天差地别。这不是模型优劣问题，而是架构差异导致的“行为偏好”不同。忽略这点，等于闭着眼睛开车。我们通过2000+次A/B测试，提炼出三大模型家族的响应特征：

• OpenAI系（GPT-4 Turbo）：对角色指令极度敏感，但容易过度遵守导致刻板。例如设定“你是一名严厉的中学语文老师”，它会主动删减所有口语化表达，连“嗯”“啊”等语气词都过滤掉。优势在于长文本一致性极强，10页文档摘要能保持逻辑连贯；劣势是面对模糊指令时，倾向于“安全第一”，常给出四平八稳的废话。

• Anthropic系（Claude 3 Opus）：上下文窗口利用能力最强（支持200K tokens），特别适合处理超长文档分析。但它对“示例质量”要求苛刻——如果Few-shot示例中存在微小逻辑瑕疵（如因果倒置），它会放大该错误并贯穿整个输出。我们发现，Claude在法律文书比对任务中准确率比GPT高19%，但前提是示例必须由执业律师审核过。

• 国产大模型（Qwen2、GLM-4）：中文语义理解更贴近本土表达习惯，对成语、俗语、网络新词的响应更自然。但对英文术语嵌入的容忍度较低。例如提示词中写“请用SWOT分析（Strengths, Weaknesses, Opportunities, Threats）”，Qwen2可能把括号内英文当成干扰项忽略；而GPT会自动识别并严格遵循。因此，面向国内用户的提示词，我们优先用中文全称+括号注释，如“请用优势-劣势-机会-威胁（SWOT）分析法”。

注意：没有“最好”的提示词，只有“最适配当前模型+当前任务+当前用户”的提示词。我们团队的标准流程是：先用GPT-4快速验证提示词逻辑可行性，再用Claude 3测试长文本稳定性，最后用Qwen2做中文表达润色。三轮迭代后，才进入生产环境。

3. 实操全流程：从一张白纸到可复用的提示词资产库

3.1 需求诊断：用“5W1H”锁定真实意图

很多提示词失效，根源在于需求本身没厘清。我们设计了一套极简诊断表，强制在写提示词前填写：

填完这张表，你会发现80%的“提示词写不好”问题，其实是“需求没想清楚”。比如客户说“要个能写周报的AI”，填表后可能发现：真正痛点是“技术同事写的周报全是代码，管理层看不懂”，那提示词重点就不是“写得全面”，而是“自动提取技术动作→映射业务价值→用管理层语言转译”。

3.2 原型构建：从“一句话指令”到“可运行提示词”的七步法

我们摒弃了“先写长提示再删减”的低效方式，采用逆向工程法：从理想输出倒推必需输入。以“生成产品功能上线公告”为例：

Step 1：定义黄金输出样本
不写提示词，先手动写一份完美公告（耗时15分钟）：

【标题】XX系统V3.2上线通知：智能审批流正式启用
【正文】尊敬的各位同事：
为提升跨部门协作效率，IT部将于5月20日（周一）00:00起，全量上线XX系统V3.2版本。本次升级核心功能为“智能审批流”，可自动识别报销单据类型、预填审批人、推送超时预警。
▶️ 新功能亮点：

• 审批时效提升40%（实测数据）
• 支持自定义审批节点（详见附件《配置指南》）
• 与钉钉消息打通，关键节点实时提醒
  ▶️ 温馨提示：
• 旧版审批入口将于5月27日下线，请及时切换
• 操作疑问请联系IT服务台（分机8080）
  感谢您的支持！
  IT服务部
  2025年5月15日

Step 2：逆向提取结构要素
对照样本，标记每个模块的生成依据：

• 标题 → 来自“系统名称”“版本号”“核心功能名”
• 正文首段 → 来自“上线时间”“业务价值”“功能简述”
• ▶️ 新功能亮点 → 来自“效能提升数据”“配置灵活性”“集成能力”
• ▶️ 温馨提示 → 来自“旧版下线时间”“支持渠道”
• 落款 → 固定为“IT服务部”+“当前日期”

Step 3：设计变量占位符
将所有需动态输入的字段替换为{}占位符：

【标题】{系统名称}V{版本号}上线通知：{核心功能名}正式启用
【正文】尊敬的各位同事：
为{业务价值}，{发布部门}将于{上线时间}起，全量上线{系统名称}V{版本号}版本。本次升级核心功能为“{核心功能名}”，{功能简述}。
▶️ 新功能亮点：

• {效能提升数据}
• {配置灵活性}
• {集成能力}
  ▶️ 温馨提示：
• {旧版下线时间}
• {支持渠道}
  感谢您的支持！
  {发布部门}
  {当前日期}

Step 4：编写基础提示词
将占位符说明转化为自然语言指令：

你是一名资深IT产品经理，负责撰写系统升级公告。请严格按以下要求生成：

1. 标题格式：【标题】{系统名称}V{版本号}上线通知：{核心功能名}正式启用
2. 正文首段：用一句话说明升级目的（业务价值）、发布方、上线时间、核心功能及一句话功能简述
3. “新功能亮点”部分：分三点列出，每点以“- ”开头，内容必须来自提供的效能数据、配置说明、集成能力描述
4. “温馨提示”部分：分两点列出，内容必须来自旧版下线时间和支持渠道信息
5. 落款：固定为“{发布部门}”+“当前日期（YYYY年MM月DD日）”
6. 全文禁用任何技术术语缩写（如ERP、API），所有专业词需括号内附中文全称

Step 5：注入Few-shot示例
添加2个高质量示例（注意覆盖异常情况）：

示例1（标准场景）：
输入：系统名称=HR系统；版本号=2.1；核心功能名=智能考勤分析；业务价值=解决考勤异常漏报问题；发布部门=人力资源部；上线时间=6月1日；效能提升数据=异常识别准确率提升至99.2%；配置灵活性=支持按部门设置考勤规则；集成能力=与企业微信打卡数据自动同步；旧版下线时间=6月15日；支持渠道=HR服务邮箱hr@company.com
输出：[此处粘贴对应公告]

示例2（边界场景：无具体数据）：
输入：系统名称=财务系统；版本号=4.0；核心功能名=多币种结算；业务价值=支持海外子公司本地化结算；发布部门=财务共享中心；上线时间=7月10日；效能提升数据=暂无实测数据；配置灵活性=支持自定义汇率更新频率；集成能力=与SAP系统无缝对接；旧版下线时间=8月1日；支持渠道=财务服务热线400-xxx-xxxx
输出：[此处粘贴对应公告，其中“效能提升数据”行改为“- 待上线后收集实测数据”]

Step 6：添加防御性约束
封堵典型失效路径：

• 若输入中未提供“效能提升数据”，则在“新功能亮点”中写“- 待上线后收集实测数据”，禁止自行编造
• 所有日期必须转换为中文格式（如“2025年6月1日”），禁止使用“2025/06/01”
• 若“支持渠道”含电话号码，必须添加分机号说明（如“400-xxx-xxxx（分机8080）”）
• 全文不得出现“革命性”“颠覆性”等营销话术，保持客观陈述

Step 7：格式化与封装
将最终提示词按模块分隔，便于团队复用：

【角色】资深IT产品经理 【任务】生成系统升级公告 【输入变量】 - 系统名称：______ - 版本号：______ - 核心功能名：______ - 业务价值：______ - 发布部门：______ - 上线时间：______（格式：X月X日） - 效能提升数据：______（若无则填“暂无实测数据”） - 配置灵活性：______ - 集成能力：______ - 旧版下线时间：______（格式：X月X日） - 支持渠道：______ 【输出要求】严格按示例格式，禁用所有营销话术

这套方法看似繁琐，但实测将单个提示词从“可用”到“稳定可靠”的迭代周期，从平均7.2次压缩至2.3次。关键是，它把主观经验转化为了可传承的工程化流程。

3.3 测试与调优：超越“看着像”的三重验证法

很多团队止步于“输出看起来没问题”，结果上线后翻车。我们建立了一套严苛的验证体系：

第一重：语法正确性验证（Syntax Check）

• 工具：用正则表达式校验输出是否符合预设格式（如标题是否含“【标题】”，落款是否含“YYYY年MM月DD日”）
• 标准：100%通过，否则视为失败。曾发现某提示词在GPT-4上通过率98%，但在Qwen2上因日期格式识别差异降至76%，立即触发重构。

第二重：事实一致性验证（Fact Consistency）

• 方法：对输出中所有可验证陈述，回溯到输入变量核查。例如输出写“审批时效提升40%”，必须在输入中找到对应“效能提升数据”字段。
• 标准：所有事实性陈述100%可溯源。我们开发了一个简易脚本，自动提取输出中的数字、专有名词、日期，与输入变量比对。

第三重：业务有效性验证（Business Validity）

• 方法：邀请真实使用者（非技术人员）盲测。给10份不同输入生成的公告，让客服主管判断：“哪几份能直接发给全员？哪几份需要修改？为什么？”
• 标准：80%以上样本获“可直接发布”评价。曾有一版提示词语法、事实全达标，但主管反馈“所有公告语气都像在训话，缺乏温度”，我们随即在角色定义中加入“保持专业但亲切的沟通风格，可适当使用‘您’‘我们’等人称代词”。

实操心得：不要迷信单次测试结果。我们要求每个提示词必须通过“三模型+三输入+三轮测试”：在GPT-4、Claude 3、Qwen2上各跑一次；用标准输入、边界输入（如空数据）、对抗输入（如故意提供矛盾信息）各跑一次；每次测试后，必须记录1个优化点（哪怕只是调整一个标点）。三个月下来，团队积累的“失效模式库”成了最宝贵的资产。

4. 高阶策略实战：Tree-of-Thought与DSPy的落地取舍

4.1 Tree-of-Thought（ToT）：当单一思维链不够用时

Chain-of-Thought（CoT）解决了“怎么想”的问题，但面对开放性难题（如“设计一个降低快递包装浪费的方案”），模型常陷入局部最优。ToT则模拟人类“头脑风暴”过程，要求模型：

1. 生成多个思考方向（如：材料替代、结构优化、回收激励、政策倡导）
2. 对每个方向进行自我评估（如：材料替代——成本上升30%，但减废率65%；结构优化——研发周期长，但用户接受度高）
3. 选择最优路径展开（如：综合评估后，优先推进“结构优化”方向）

我们在一个环保项目中应用ToT：目标是为某电商设计包装减量方案。传统CoT提示词输出集中在“用可降解材料”，但ToT提示词强制模型先列出5个方向，再逐个打分，最终输出聚焦在“蜂窝纸板缓冲结构替代泡沫塑料”，因为该方案在成本、供应链兼容性、用户感知三维度得分最高。

ToT提示词核心结构：

请按以下步骤思考：
步骤1：生成5个差异化解决方向（要求：覆盖技术、商业、用户、政策、生态五个维度；每个方向用10字内概括）
步骤2：对每个方向进行三维度评估（成本可行性/实施难度/预期效果，每项1-5分）
步骤3：计算总分并排序，选择TOP1方向
步骤4：针对TOP1方向，输出详细实施方案（含3个具体动作、所需资源、预期周期）
步骤5：指出该方案的最大风险及应对建议

注意：ToT显著增加token消耗和响应时间。我们只在“战略级决策支持”场景使用，日常运营仍用CoT。实测显示，ToT在方案创新性上提升明显，但执行细节丰富度反不如精炼的CoT。

4.2 DSPy：当提示词需要自动化迭代时

DSPy是一个开源框架，它把提示词工程“程序化”：你定义任务目标（如“从会议纪要中提取行动项”）和评估指标（如“F1值>0.9”），DSPy自动搜索最优提示词组合、示例选择、输出格式。听起来很美，但落地有坑。

我们在一个法律合同审查项目中尝试DSPy：目标是识别“付款条件”条款中的模糊表述（如“合理期限内”“双方协商一致”）。传统方式需人工编写20+版提示词测试。DSPy在3小时内生成了候选集，但最优提示词在测试集上F1达0.92，上线后真实合同中却跌至0.61。

问题根源与解决方案：

• 坑1：评估集偏差
  DSPy优化基于静态测试集，而真实合同条款千变万化。我们改为：用DSPy生成10个候选提示词，再用真实业务中最新100份合同做A/B测试，选胜出者。
• 坑2：过度拟合
  DSPy倾向生成复杂提示词（如嵌套多层条件），但模型在长提示下易失焦。我们强制添加约束：“提示词总长度<300字，禁用三层以上嵌套逻辑”。
• 坑3：忽视部署成本
  DSPy生成的提示词需配套Python代码调用，增加了运维负担。最终方案是：用DSPy做“提示词探矿”，找到高潜力方向后，人工重写为简洁、可读、易维护的版本。

我的体会：DSPy不是替代人工，而是把提示工程师从“调参民工”解放为“策略设计师”。它最适合的场景是：有明确量化指标、有足够标注数据、且提示词需频繁迭代的标准化任务（如客服工单分类、新闻摘要生成）。对于创意类、策略类任务，人的直觉依然不可替代。

4.3 构建可持续的提示词资产库：从个人技巧到组织能力

单个提示词再好，也是孤岛。我们花了半年时间，把零散经验沉淀为可复用的资产库，核心是三个“标准化”：

1. 命名标准化
拒绝“v1_final_revised_v2”这种命名。采用“业务域_任务类型_版本号”：

• HR_入职引导文案生成_v2.3
• Finance_费用报销摘要_v1.7
• Sales_客户异议应答_v3.0
  每个文件夹内含：提示词主文件、测试用例集（含标准输入/期望输出）、失效日志（记录哪次迭代修复了什么问题）、适用模型清单。

2. 文档标准化
每个提示词必须附带《使用说明书》，包含：

• 适用场景（如“仅适用于2023年后入职的新员工，不适用于外包人员”）
• 输入校验规则（如“上线时间必须为工作日，若为周末则自动顺延至下周一”）
• 常见失效信号（如“若输出中出现‘详见附件’但未提供附件链接，则提示词失效”）
• 升级触发条件（如“当业务方新增‘合规审计’需求时，需升级至v3.x”）

3. 迭代标准化
建立双周提示词评审会：

• 数据驱动：分析上周所有调用日志，统计“人工修改率”（如30%的公告需手动调整语气，说明角色定义需优化）
• 用户反馈：收集使用者的“一句话吐槽”（如“每次都要删掉那句‘感谢您的支持’，太机械”）
• 模型演进：跟踪新模型发布（如GPT-4.5上线），针对性测试现有提示词兼容性

最后分享一个血泪教训：我们曾把提示词库放在共享网盘，结果三个月后发现27个版本在同时使用，且没人知道哪个是最新。现在强制所有提示词必须托管在Git，每次修改需提交PR，由提示工程负责人审核合并。看似增加流程，但避免了“谁改的？为什么改？改对了吗？”的无穷追问。

5. 常见问题与避坑指南：那些没人告诉你的暗礁

5.1 “为什么加了示例反而更差？”——Few-shot的致命陷阱

新手常以为“示例越多越好”，实则不然。我们统计了1200次Few-shot测试，发现：

• 示例数量：3个最佳。少于2个，模型无法捕捉模式；多于5个，注意力被分散，关键特征被稀释。
• 示例质量：比数量重要10倍。一个逻辑错误的示例，会让模型学会错误模式。曾用一个含事实错误的医疗示例（把“高血压”写成“高血糖”），导致后续15次输出全部混淆两种疾病。
• 示例顺序：必须按“简单→复杂”排列。把最难的示例放第一个，模型会直接模仿其复杂结构，忽略基础规则。

避坑方案：

• 每个示例必须经领域专家签字确认
• 在提示词中显式标注示例难度：“示例1（基础）：……；示例2（进阶）：……；示例3（边界）：……”
• 对于复杂任务，用“分阶段示例”：先给格式示例，再给内容示例，最后给风格示例

5.2 “模型突然不听话了？”——上下文污染的隐形杀手

大模型的“记忆”是脆弱的。我们遇到过最诡异的案例：一个稳定运行3个月的客服提示词，某天开始频繁输出无关内容。排查发现，是前端系统在传递用户消息时，意外把调试日志（含“ERROR: timeout”）拼进了用户输入。模型把错误日志当成了对话上下文，开始围绕“timeout”胡言乱语。

上下文污染三大来源与对策：

提示：永远假设模型看到的输入，和你以为它看到的不一样。在生产环境，我们强制所有输入经过“三重校验”：前端清洗→API网关过滤→模型侧预处理。

5.3 “为什么越改越糟？”——提示词优化的负向循环

很多人陷入“改一个词，坏三个地方”的怪圈。根源在于：没有基线，就没有优化。我们要求每次修改必须：

1. 固化基线：修改前，用10个代表性输入跑一次，记录所有输出作为基线
2. 单变量测试：每次只改一个元素（如只调整角色定义，不碰约束条件）
3. 量化对比：用同一组输入测试新旧版本，对比关键指标（如事实准确率、格式合规率、人工修改字数）

曾有一个法律提示词，团队争论“是否加入‘根据《民法典》第XXX条’”，A派认为增强权威性，B派认为限制模型发挥。我们做了AB测试：

• A版（加法典引用）：事实准确率+5%，但30%输出出现“《民法典》第XXX条未规定此情形”，需人工删除
• B版（不加引用）：事实准确率-2%，但100%输出可直接使用
  最终选择B版，因为业务目标是“提效”，不是“显专业”。

5.4 “要不要用模板？”——模板化与个性化的平衡术

模板能加速启动，但滥用会扼杀效果。我们的经验：

• 可模板化：格式固定、变量清晰的任务（如邮件、公告、周报）
• 禁用模板：需深度理解业务逻辑的任务（如“分析用户流失原因”“制定新品上市策略”）

模板使用铁律：

• 模板必须标注“可变区”与“固定区”，如：

  【固定】“尊敬的{客户姓名}：”
  【可变】“{个性化问候语}” ← 此处必须由业务系统提供，禁止模型生成

• 每个模板需配套《变量注入规范》，明确每个占位符的数据源、格式要求、缺失时的兜底策略

最后一个真实案例：某电商用模板生成促销短信，模板中“{优惠力度}”字段由运营后台填写。但某次活动，运营误填为“满100减50元”，而实际规则是“满