FME与AI：FME AI工作流里把System Prompt用来设定角色（“你是一个地理空间工程师”），User Prompt用来下达具体任务——但当工作区里同一个AI Connector被复用来处理多种不同类型的要素时，System Prompt里的角色设定到底该固定不变，还是应该根据输入要素的类型动态切换，动态切换又该怎么在FME里组织参数？

一、问题的提出：复用带来的角色漂移

FME（Feature Manipulate Engine）在2023年前后引入AI Connector类转换器，把大语言模型调用封装成工作区里的一个节点。工程上最自然的做法，是把"调用模型"这件事抽象成一个自定义转换器或一个可复用的Connector配置，让道路、水系、建筑、行政区划等不同要素都走同一个节点。问题随之而来：当这个节点第一次被配置时，作者往往在System Prompt里写下一句通用角色——"你是一个地理空间工程师，擅长解读空间数据"——然后就把注意力转向User Prompt的拼接。

单要素类型时这没问题。可一旦复用，输入要素从"道路中心线"变成"宗地面"，模型的输出风格、术语体系、甚至格式遵循度都会出现肉眼可见的波动。笔者在多个工作区中观察到的典型现象是：同一个Connector处理道路要素时输出规范的中文描述，处理宗地要素时却开始夹杂英文术语并擅自增加字段。这不是模型"变笨"了，而是角色设定与任务语境之间出现了错配——角色漂移（Role Drift）。

角色漂移的本质，是System Prompt提供的先验约束与User Prompt提供的具体任务之间存在语义张力。当任务类型变化而先验不变时，模型需要在推理时自行"脑补"角色该如何调整，这种脑补不稳定、不可复现，也无法通过工作区版本管理来追踪。于是问题被逼到台面上：System Prompt该固定，还是该动态切换？如果动态切换，在FME这种以属性和参数为骨架的图执行环境里，又该怎么组织？

本文的主线判断：角色设定不是一段文本，而是一个接口。接口的稳定部分应当冻结，可变部分应当参数化。把System Prompt当成"一段写死的字符串"来讨论固定还是动态，本身就问错了问题；正确的问法是——哪些维度必须稳定，哪些维度必须可变，二者如何在FME里解耦。

二、理论底座：System Prompt为何有效，又为何会失效

2.1 角色设定的作用机理

大语言模型对System Prompt的敏感性，已被大量研究证实。OpenAI在GPT-3.5/GPT-4的模型文档中明确区分system、user、assistant三类消息，并指出system消息用于设定行为边界与人格（OpenAI, 2023, GPT-4 Technical Report）。Anthropic在其Claude模型文档中进一步强调，system prompt对"角色、语气、约束"的引导效果显著优于把同样内容塞进user消息（Anthropic, 2024, Claude Model Documentation）。学术界方面，Zhou等人在"Instruction-Following Evaluation"相关工作中指出，指令的层级结构（系统级vs任务级）会显著影响模型对冲突指令的取舍（Zhou et al., 2023, arXiv:2311.07911）。

从机制上看，角色设定至少提供三重作用：其一，词汇先验，把模型推向特定领域的术语分布；其二，格式先验，暗示输出的结构与粒度；其三，拒绝边界，告诉模型哪些请求应当谨慎处理。本文评述：这三重作用中，词汇与格式先验对要素类型高度敏感，拒绝边界则相对稳定。这为"分层"提供了直接依据——稳定的部分正是拒绝边界与基本职业身份，可变的部分是词汇与格式。

2.2 角色失效的三种典型场景

角色设定并非万能。综合近两年关于prompt sensitivity的研究，失效场景可归为三类。第一类是角色-任务错配：角色过于宽泛（"你是专家"）导致约束力不足，模型倾向于用通用语料作答。第二类是指令冲突：System Prompt要求"简洁"，User Prompt要求"详尽列出所有字段"，模型在冲突中随机取舍。第三类是长上下文稀释：当User Prompt携带大量属性文本时，System Prompt的权重被稀释，角色约束衰减。Liu等人关于"Lost in the Middle"的研究表明，长上下文中间位置的信息利用率显著下降（Liu et al., 2023, arXiv:2307.03172），这解释了为什么属性一多，角色就"记不住"了。

本文评述：第三类失效对FME场景尤其致命，因为FME的要素属性动辄几十个字段，全部拼进User Prompt会迅速稀释角色约束。这意味着，即便选择"固定System Prompt"，也必须配套属性裁剪策略，否则固定也固定不住。这一点常被忽视。

2.3 结构化输出与角色的一致性要求

当AI Connector的输出需要被下游转换器解析（例如JSON转属性）时，输出契约的稳定性比角色措辞更重要。OpenAI的JSON Mode与Structured Outputs、Anthropic的tool use、以及开源侧的Outlines、Guidance等约束解码方案，都在把"格式遵循"从概率问题变成工程问题（Willard & Louf, 2023, arXiv:2307.09702）。本文评述：一旦采用结构化输出，System Prompt里关于"输出什么格式"的描述就应当从角色文本中剥离，交给schema或工具定义来承担。角色文本只保留"你是谁、你服务什么业务、你遵守什么边界"，格式交给机器可校验的契约。这是分层设计的第二个依据。

三、固定派与动态派的论战与本文立场

3.1 固定派的理由

固定派的核心论据是可复现性与可维护性。System Prompt写死，工作区版本diff清晰，出问题容易定位；动态拼接则把逻辑藏进了表达式，调试成本上升。此外，固定角色有利于跨要素类型的行为一致性，避免同一批数据因要素类型不同而输出风格割裂。工程上还有一层考虑：FME的私有参数与属性映射本身就有学习曲线，把Prompt也参数化，会抬高团队协作门槛。

3.2 动态派的理由

动态派强调任务适配。地理空间数据天然异构，道路的网络拓扑语义、宗地的权属语义、水系的流向语义差异极大，用同一套词汇先验去覆盖，必然有一方被牺牲。更现实的是，动态角色可以显著降低User Prompt的负担——把"请以宗地权属视角分析"这类语境前移到System层，User层只留具体指令，整体Token反而可能更省。近期关于"role prompting"的实证研究也显示，角色设定的收益高度依赖任务领域匹配度，错配角色的收益接近于零甚至为负（相关综述见Prompt Engineering Survey, 2024, arXiv:2402.07927）。

3.3 本文立场：分层而非二选一

笔者认为，固定与动态之争是把一个二维问题压成了一维。真正需要决策的是两个正交维度：角色内核（职业身份、服务目标、安全边界、语言风格基线）应当固定；任务外壳（领域词汇、输出字段、分析视角、格式契约）应当随要素类型参数化。二者通过FME的参数机制解耦，既保留可复现性，又获得适配性。

四、分层设计：稳定内核与可变外壳

4.1 三层结构

笔者建议把System Prompt拆成三层：内核层（Kernel）、领域层（Domain）、契约层（Contract）。内核层固定不变，领域层由参数注入，契约层由schema或工具定义承担。三层在拼接时保持固定顺序，便于缓存与调试。

【内核层 · 固定】
你是一名地理空间工程师，服务于空间数据治理与自动化流程。
你遵守以下不可协商的边界：
1) 不臆造坐标、面积、权属等事实性数值；
2) 不确定时明确说明不确定，并给出核验建议；
3) 输出语言为简体中文，术语遵循国家测绘地理信息标准。
你的判断以输入要素的几何与属性为依据，不引入外部假设。

【领域层 · 参数注入】
当前处理的要素类型：{{FEATURE_TYPE}}
该类型的业务语义：{{DOMAIN_SEMANTICS}}
常用术语表：{{TERM_GLOSSARY}}
分析视角：{{ANALYSIS_LENS}}

【契约层 · schema/工具定义承担】
输出字段与类型由下游JSON Schema约束，不在本段描述。

4.2 为什么内核必须固定

内核层承载的是安全边界与职业身份，这两者一旦可变，就打开了"提示注入"的口子。FME工作区常常处理外部来源数据，属性字段可能被第三方填充，若领域层参数直接来自属性且未做清洗，恶意内容可能篡改角色。因此内核层必须硬编码在Connector配置中，且拼接顺序在内核之后，确保内核的"先验权重"不被覆盖。本文评述：这与Anthropic提出的"system prompt优先级高于user content"原则一致，工程上应把内核视为不可变配置项，纳入版本管理但不允许运行时修改。

4.3 领域层参数的最小充分集

领域层参数不是越多越好。参数过多会稀释角色约束（见2.2节），也会增加维护负担。笔者建议控制在4个以内：要素类型、业务语义、术语表、分析视角。其中术语表可用短列表形式，控制在20个词以内；业务语义用一两句话概括；分析视角用短语（如"拓扑连通性优先""权属边界优先"）。这套最小充分集在笔者的多个工作区中覆盖了道路、水系、建筑、宗地、行政区划五类要素，未出现明显适配缺口。

五、FME中的三条组织路径与参数规范

5.1 路径一：私有参数+文本拼接

最直接的做法是在自定义转换器中暴露私有参数（Private Parameter），如FEATURE_TYPE、DOMAIN_SEMANTICS，然后在AI Connector的System Prompt字段里用FME的文本拼接语法引用。优点是配置直观、版本diff清晰；缺点是参数值在调用方写死，跨要素类型复用时仍需多个转换器实例。适合要素类型少、变化不频繁的场景。

5.2 路径二：属性映射+AttributeManager

更灵活的做法是把领域层参数做成要素属性，由上游的AttributeManager或AttributeCreator根据要素类型赋值，再在System Prompt中引用属性值。FME的文本编辑器支持在字符串中插入属性引用，运行时逐要素求值。这样同一个Connector实例即可处理多种要素，参数随要素流动。关键设计点在于：属性赋值逻辑要集中在一个"参数装配"子流程里，避免散落在多个转换器中。

5.3 路径三：条件分支+Prompt路由

当要素类型差异极大、领域层参数无法用统一模板表达时，可用TestFilter或FeatureTypeFilter做分支，每个分支配置独立的System Prompt片段，再汇入同一个AI调用。这本质上是"Prompt路由"（Prompt Routing）的手工版。优点是每类要素的Prompt可独立优化；缺点是分支膨胀后维护成本高，且容易出现分支遗漏。笔者建议分支数控制在5个以内，超过则回到路径二，用参数化表达差异。

5.4 参数命名与数据字典

参数命名建议采用"前缀_语义"格式，如AI_FEATURE_TYPE、AI_DOMAIN_SEMANTICS、AI_TERM_GLOSSARY、AI_ANALYSIS_LENS，前缀统一便于在AttributeManager中批量筛选。所有参数应登记到工作区附带的参数数据字典中，记录取值域、默认值、责任人与变更记录。这一步看似繁琐，但在团队协作中能显著降低"参数值写错导致输出跑偏"的排查时间。

六、实战：多要素类型复用的完整工作区设计

6.1 工作区骨架

一个可复用的工作区骨架包含五个环节：输入读取、参数装配、属性裁剪、AI调用、输出解析。参数装配环节是本文方案的核心，它根据要素类型为每个要素写入领域层参数；属性裁剪环节负责把无关字段剔除，避免长上下文稀释；AI调用环节使用统一的Connector配置，System Prompt引用属性；输出解析环节用JSON解析器或Schema校验器把结果转回属性。

Reader → AttributeManager(参数装配) → AttributeKeeper(属性裁剪)
      → AI Connector(System Prompt含属性引用) → JSONFlattener/SchemaValidator
      → AttributeManager(结果回写) → Writer

6.2 参数装配的映射表设计

参数装配推荐用一张外部映射表驱动，而非在AttributeManager里写死条件。映射表可以是CSV或数据库表，字段包括FEATURE_TYPE、DOMAIN_SEMANTICS、TERM_GLOSSARY、ANALYSIS_LENS。工作区启动时读取映射表，用FeatureMerger按要素类型关联，把参数挂到要素上。这样做的好处是：新增要素类型只需改表，不用改工作区；参数变更可审计；非技术同事也能维护。

注：上表为笔者工作区中的示例配置，非实测数据集，仅作结构说明。

6.3 属性裁剪策略

属性裁剪的目标是把User Prompt的上下文长度控制在模型有效注意力范围内。笔者的做法是：先用AttributeKeeper保留业务必需字段（通常5-8个），再对长文本字段做截断（如地址截断到前50字符），最后用ListBuilder把字段拼成结构化文本。裁剪规则应写入工作区注释，并在参数数据字典中登记"哪些字段不进入Prompt及原因"。

6.4 输出解析与回退

输出解析要处理三种情况：正常JSON、格式偏差、模型拒答。正常JSON直接展平回写；格式偏差用容错解析器（如正则提取+JSON修复）尝试恢复，失败则标记为待人工复核；模型拒答则记录原始响应并触发告警。本文评述：回退路径的设计质量，往往比Prompt本身更决定生产可用性。一个没有回退的工作区，在真实数据上跑一周就会积累大量脏数据。

七、数据与实测：动态切换的收益边界

7.1 模拟实验设计

为量化动态切换的收益，笔者设计了一组模拟实验（数据为模拟数据，非真实业务数据）。实验构造四类要素（道路、水系、宗地、建筑）各50条，每条含6个属性字段。设置三组Prompt策略：A组固定System Prompt（仅通用角色）；B组动态System Prompt（内核+领域层参数注入）；C组动态System Prompt+属性裁剪。评价指标为输出格式遵循率、术语准确率（人工抽检）、平均Token消耗。每组重复3次取均值。

注：上表为模拟数据，用于说明策略间相对差异，不代表任何真实模型或业务的绝对性能。实验环境为单机FME工作区调用通用大模型API，温度参数0.2，每类要素50条，重复3次取均值。

7.2 结果解读

动态策略在格式遵循与术语准确上均有提升，但Token消耗上升约15%；叠加属性裁剪后，Token反而低于固定策略，说明裁剪的收益足以抵消领域层注入的成本。本文评述：这组模拟数据揭示了一个容易被忽略的结论——动态切换的成本不是来自"动态"本身，而是来自"没有裁剪"。很多团队担心动态Prompt会推高成本，实际上只要配套裁剪，总成本可控甚至更优。

7.3 收益边界

动态切换并非在所有场景都划算。当要素类型单一、属性稳定时，固定的收益已接近上限，动态只增加复杂度；当要素类型差异主要体现在格式而非语义时，应优先用schema解决，而非改角色；当模型本身对角色不敏感（部分小参数模型）时，动态的边际收益有限。笔者的经验边界是：要素类型≥3且语义差异明显时，动态值得投入；否则优先固定+裁剪。

八、成本、延迟与治理

8.1 Token成本结构

System Prompt的Token在每次调用中都会重复计费，因此内核层的措辞应尽量精简。笔者建议内核层控制在200 Token以内，领域层控制在150 Token以内。若使用支持Prompt Caching的API（如部分厂商提供的缓存机制），固定内核可被缓存，边际成本进一步下降。本文评述：把内核做短、做稳，本身就是一种成本优化，这与"动态"并不矛盾。

8.2 延迟与批处理

FME工作区处理要素时，逐要素调用模型会带来显著延迟。工程上应优先使用批处理接口（若模型支持），或在工作区内做并发控制。动态Prompt不影响单次延迟的量级，但参数装配环节若设计不当（如每要素都去查映射表），会引入额外IO。建议映射表在启动时一次性读入内存，用FeatureMerger关联。

8.3 治理与审计

动态Prompt把"行为定义"分散到了参数表里，治理难度上升。建议三项措施：其一，参数表纳入版本控制，变更留痕；其二，工作区运行时记录每个要素实际使用的参数快照，便于回溯；其三，定期抽样评估输出质量，形成质量基线。本文评述：治理成本是动态方案的主要隐性成本，团队在决策时应把它计入总账，而非只看准确率提升。

九、前沿预判：从Prompt路由到智能体编排

9.1 自动Prompt路由

当前的手工参数装配，未来可能被自动路由取代。已有研究探索用小模型或分类器先判断输入类型，再选择对应的Prompt模板（相关方向见路由与MoE思想在Prompt层的迁移，2024年前后多篇预印本）。本文评述：自动路由的收益在于减少人工维护映射表，但引入了路由错误的风险，短期内更适合作为"建议+人工确认"的辅助，而非全自动。

9.2 地理空间智能体

更长远看，FME工作区可能演化为"工具集"，由智能体根据任务自主选择工具与角色。地理空间领域的智能体研究近两年升温，涉及空间推理、工具调用与多步规划。本文评述：智能体编排会进一步弱化"单一System Prompt"的概念，角色变成智能体状态的一部分，随任务阶段演化。这对FME的意义是：未来的复用单元可能不是Connector，而是"带角色状态的子工作流"。

9.3 可观测性

无论固定还是动态，可观测性都是落地前提。建议在工作区中埋点记录：实际Prompt全文、模型响应、Token数、耗时、解析结果。这些数据既是排错依据，也是后续优化的训练素材。本文评述：把Prompt当代码管理、把调用当服务观测，是地理空间AI工作流走向生产化的必经之路。

十、结论与排错清单

回到最初的问题：System Prompt该固定还是动态？本文的答案是——内核固定，外壳参数化，契约交给schema。固定保证行为一致与安全边界，参数化保证任务适配，schema保证输出可校验。三者通过FME的私有参数、属性映射与条件分支落地，形成可维护、可审计、可回退的工程方案。

最后补充一点工程直觉：Prompt设计没有银弹，固定与动态的取舍应服从于团队的可维护能力。一个团队能稳定维护的复杂度是有限的，把复杂度花在刀刃上——通常是属性裁剪与回退设计——比追求"完美角色"更能提升生产可用性。

延伸阅读与教程链接

• FME官方文档：AI Connector与自定义转换器参数配置（docs.safe.com）
• FME社区教程：在工作区中使用属性值拼接文本（community.safe.com）
• OpenAI Prompt Engineering Guide（platform.openai.com）
• Anthropic System Prompts 文档（docs.anthropic.com）
• Prompt Engineering Survey（arXiv:2402.07927）

主要参考文献