要让提示词精准响应上下文变化、支持条件分支与模块复用，必须超越简单的变量替换，掌握Jinja2高级渲染技术——这直接决定了提示词能否处理复杂业务逻辑，而不仅仅是字符串拼接。

如何实现？核心在于四大关键技巧：模板继承、宏封装、条件判断以及过滤器链。

利用模板继承统一工作流结构

当你在多个节点中（例如意图识别→RAG检索→最终回复）反复处理时间格式化、错误兜底、安全转义等琐碎逻辑时，就应当引入模板继承。这并非锦上添花，而是避免后期改动一处遗漏十处的根本解决方案。

第一步：在任意节点的Jinja2代码区顶部定义基础块结构：

{% block pre_processing %}{% endblock %}
{% block main_content %}{% endblock %}
{% block post_processing %}{% endblock %}

第二步：在需要复用该结构的其他节点中，使用 {% extends "base_template.jinja" %} 声明继承关系。这里需要特别注意：请注意：Dify不实际读取文件系统，这里的"base_template.jinja"是逻辑引用名，必须与你当前节点中定义的块名完全一致。

第三步：只覆盖你需要定制的部分。例如，在RAG节点中这样编写：

{% extends "base_template.jinja" %}
{% block main_content %}
请基于以下检索结果回答用户问题：
{% for doc in rag_results %}
- {{ doc.title | truncate(80) }}: {{ doc.content | escape }}
{% endfor %}
{% endblock %}

用宏（macro）封装高频逻辑

当某段逻辑（比如会员等级加权、多语言fallback、敏感词过滤）在三个以上节点反复出现时，宏就是你的代码压缩包。

方法一：在单个节点内定义并调用

{% macro format_user_profile(user) %}
{{ user.name }}（{{ user.level | upper }}会员，注册{{ user.join_days }}天）
{% endmacro %}
欢迎回来，{{ format_user_profile(context.user) }}！

方法二：跨节点复用——将宏定义放在最上游节点（如“会话初始化”节点），然后在下游节点通过context对象传递已渲染结果。切记：不要在下游重复定义同名宏，否则会覆盖上游逻辑。

用条件判断实现动态提示路径

用户问“退货”和问“查物流”，提示词结构完全不同；硬编码两条提示词迟早会失控，用 if/elif/else 才能守住边界。

① 先判断核心意图：

{% if context.intent == "return" %}
您正在申请退货，请确认订单号{{ context.order_id }}，并说明退货原因：
{% elif context.intent == "tracking" %}
正在为您查询订单{{ context.order_id }}的物流状态，请稍候……
{% else %}
请明确您的需求：退货、查物流，还是其他服务？
{% endif %}

② 嵌套判断处理权限差异：

{% if context.user.level == "vip" %}
作为VIP用户，您可享受优先审核与免运费退货。
{% elif context.user.level == "gold" %}
黄金会员退货需提供开箱视频。
{% else %}
普通用户退货需满足7天无理由条件。
{% endif %}

这一步有一个极易被忽略的细节：不能省略 context.key 存在性检查。如果 intent 字段为空，整个 if 块会静默失败，返回空字符串，导致模型收不到任何指令。

用过滤器链强化输出可控性

Dify内置的 dify_ 前缀过滤器是安全阀，不用它们等同于裸奔。

直接使用 {{ user_input }} 风险极高——可能带XSS脚本、超长文本拖垮模型。必须链式过滤：

{{ user_input | trim | truncate(200) | escape | dify_sanitize }}

其中 dify_sanitize 是Dify专属过滤器，专清LLM注入类payload；而 truncate(200) 必须放在 escape 之前，否则HTML实体字符会被计入长度，导致截断失效。