Prompt Poet：用结构化模板重构LLM提示词工程，告别字符串拼接

1. Prompt Poet：告别字符串拼接，用结构化模板重塑LLM提示词工程

如果你和我一样，在构建基于大语言模型（LLM）的应用时，已经厌倦了在Python代码里用一堆f-string、+号和各种if-else来拼接提示词，那么今天要聊的这个工具，可能会让你眼前一亮。我最近在开发一个多轮对话的AI助手项目，当提示词逻辑变得复杂，需要根据用户历史、当前模态（文本/语音）动态插入示例、还要考虑上下文长度限制时，代码很快就变成了一团难以维护的“意大利面条”。直到我发现了Character.AI开源的Prompt Poet。

简单来说，Prompt Poet是一个用于设计和生成LLM提示词的低代码库。它的核心思想是把提示词从代码逻辑中彻底剥离出来，用一种结构化的、声明式的模板语言（YAML + Jinja2）来定义。这听起来可能有点像Web开发里的模板引擎（比如Django Template），但它是专门为LLM提示词这个场景量身定制的。你不再需要写messages = [{"role": "system", "content": f"..."}, ...]这样的代码，而是用一个清晰、可读的YAML文件来描述你的整个对话结构、角色、内容以及动态逻辑。

为什么这很重要？在真实的LLM应用开发中，尤其是面向生产环境，提示词工程远不止是写一段话那么简单。它涉及到动态内容注入（比如根据查询主题插入few-shot示例）、上下文窗口管理（智能截断历史对话）、性能优化（利用GPU前缀缓存降低延迟和成本），以及团队协作（非工程师也能理解和修改提示词）。Prompt Poet通过其独特的设计，恰好瞄准了这些痛点。它不是一个庞大的AI应用框架，而是一个专注、锋利、解决具体问题的工具。接下来，我将带你深入拆解它的设计哲学、核心用法，并分享我在实际项目中应用它时总结出的实战经验和避坑指南。

2. 核心设计哲学：为何选择YAML+Jinja2？

在深入代码之前，理解Prompt Poet背后的设计选择至关重要。市面上已经有不少提示词模板方案，比如LangChain的PromptTemplate、使用JSX的Priompt，或者直接在类文档字符串里写f-string的Mirascope。Prompt Poet选择了YAML和Jinja2的组合，这并非偶然，而是基于对生产级提示词工程需求的深刻洞察。

2.1 分离关注点：逻辑与结构的解耦

传统的提示词构建方式，逻辑（控制流、数据获取）和结构（消息序列、角色分配）是强耦合的，都写在Python代码里。这带来了几个问题：一是可读性差，很难一眼看出完整的提示词结构；二是难以复用，相似的提示词逻辑需要复制粘贴大量代码；三是协作门槛高，产品经理或内容设计师想调整提示词文案，必须求助于开发人员修改代码。

Prompt Poet的解决方案是：用YAML定义结构，用Jinja2嵌入逻辑。YAML是一种对人类友好、易于阅读的数据序列化格式，非常适合用来描述具有层级关系的提示词部件（parts）。每个部件可以有自己的name、role、content和truncation_priority。这样一来，提示词的骨架变得一目了然。而Jinja2作为一个成熟的模板引擎，负责处理动态部分：变量替换、条件判断、循环遍历，甚至调用Python函数。这种分离使得模板文件本身就是一个清晰、自包含的“设计文档”。

2.2 面向生产的核心特性：可预测的截断与缓存优化

许多提示词库只解决了“生成”问题，但忽略了“优化”问题。LLM的上下文窗口是宝贵且有限的资源。当对话历史很长时，如何智能地截断旧消息，为新问题腾出空间？简单的“从头截断”或“从尾截断”都会损失重要信息。更关键的是，在追求低延迟、高并发的生产系统中，如何利用LLM服务商提供的GPU前缀缓存来大幅减少重复计算的token，从而降低成本和响应时间？

Prompt Poet引入了缓存感知的截断算法。这是它区别于其他工具的一个杀手级特性。它不仅仅是把内容截短到token限制以内，而是以一种对缓存友好的方式进行截断。具体来说，它会尝试将截断点固定在一个相对稳定的位置（以truncation_step为粒度移动），而不是每轮对话都根据内容变化剧烈移动截断边界。这样，服务端的前缀缓存命中率会显著提高，因为被缓存的前缀部分（截断点之前的内容）在多次请求中保持相对一致。虽然这可能导致有时截掉的内容比理论上必须截掉的更多一点，但用这点微小的内容损失换取显著的延迟下降和成本节省，在生产环境中通常是值得的。

2.3 模板原生函数调用：将动态数据获取融入模板

Jinja2模板的一个强大特性是能够直接调用传递给它的Python函数。Prompt Poet充分利用了这一点，实现了“模板原生函数调用”。这意味着你可以在模板内部，根据运行时的数据动态决定插入什么内容。

举个例子，你的模板可以这样写：

{% if classify_query_intent(user_query) == "需要代码帮助" %} - name: 代码示例 role: user content: | 这是一个相关的代码示例：{{ fetch_code_example(user_query) }} {% endif %}

这里的classify_query_intent和fetch_code_example都是在Python端定义并传入模板的函数。这使得模板不再是静态文本的填充，而是一个可以执行简单逻辑、甚至发起轻量级外部调用（如查询数据库或调用微服务）的“智能模板”。这种设计极大地增强了模板的灵活性和表现力，让你能够构建出高度动态化、上下文感知的提示词。

3. 从入门到精通：Prompt Poet实战指南

了解了设计理念，我们动手实践。我将以一个构建“智能学习助手”的场景为例，带你一步步掌握Prompt Poet的核心用法。

3.1 基础环境搭建与第一个模板

首先，安装Prompt Poet非常简单：

pip install prompt-poet

假设我们要创建一个能进行多轮对话、并能根据话题提供学习建议的助手。我们首先创建一个最基础的对话模板文件learning_assistant.yml.j2：

# learning_assistant.yml.j2 - name: system_instruction role: system content: | 你是一个名为{{ assistant_name }}的AI学习助手。你的性格是{{ personality }}。 你的核心目标是帮助学生理解复杂概念，提供学习路径建议，并解答疑问。 请始终以友好、耐心、鼓励的方式交流。 - name: conversation_history role: user truncation_priority: 1 content: | {% for msg in history %} {{ msg.role }}: {{ msg.content }} {% endfor %} - name: current_query role: user content: | 学生: {{ current_query_text }} - name: response_prompt role: user content: | {{ assistant_name }}:

这个模板定义了四个部分：

1. 系统指令：设定助手的身份、性格和核心目标。这里使用了变量{{ assistant_name }}和{{ personality }}。
2. 对话历史：通过Jinja2的for循环遍历history列表，将历史消息格式化。关键点是设置了truncation_priority: 1，这意味着当需要截断时，这部分内容会优先被考虑（数字越小，优先级越高，越先被截断）。
3. 当前查询：插入用户当前的问题。
4. 响应提示：引导模型开始生成助手的回复。

在Python代码中使用这个模板：

from prompt_poet import Prompt from openai import OpenAI # 这里以OpenAI SDK为例 # 准备模板数据 template_data = { "assistant_name": "知学", "personality": "严谨而富有热情", "history": [ {"role": "user", "content": "能解释一下牛顿第二定律吗？"}, {"role": "assistant", "content": "当然！牛顿第二定律的核心是 F=ma..."}, {"role": "user", "content": "那它在非惯性参考系中还成立吗？"} ], "current_query_text": "请给我推荐一些深入学习经典力学的书籍。" } # 加载模板并创建Prompt对象 prompt = Prompt(template_path="learning_assistant.yml.j2", template_data=template_data) # 查看生成的完整消息列表（符合OpenAI等API的格式） print(prompt.messages) # 输出类似： # [ # {'role': 'system', 'content': '你是一个名为知学的AI学习助手...'}, # {'role': 'user', 'content': 'user: 能解释一下牛顿第二定律吗？\nassistant: 当然！牛顿第二定律的核心是 F=ma...\nuser: 那它在非惯性参考系中还成立吗？'}, # {'role': 'user', 'content': '学生: 请给我推荐一些深入学习经典力学的书籍。'}, # {'role': 'user', 'content': '知学:'} # ] # 调用LLM client = OpenAI() response = client.chat.completions.create( model="gpt-4", messages=prompt.messages ) print(response.choices[0].message.content)

实操心得一：文件命名与路径模板文件后缀使用.yml.j2是一个很好的约定，.yml表明它是YAML结构，.j2表明它内含Jinja2语法。将模板文件放在独立的templates/目录下，与业务代码分离，便于管理和版本控制。Prompt Poet的template_path参数支持相对路径和绝对路径。

3.2 高级功能实战：条件逻辑、函数调用与模块化

现在，让我们的助手变得更智能。我们希望它能：

1. 如果用户的问题是关于编程的，自动插入一个相关的代码示例。
2. 如果用户连续提问超过3次，插入一个鼓励休息的提醒。
3. 将复杂的模板拆分成可复用的模块。

首先，我们在Python端定义两个辅助函数：

def topic_classifier(query: str) -> str: """简单的话题分类器（实际项目中可能调用更复杂的模型或服务）""" programming_keywords = ["代码", "编程", "函数", "循环", "bug", "Python", "Java"] if any(kw in query for kw in programming_keywords): return "programming" return "general" def fetch_code_example(topic: str) -> str: """根据话题获取代码示例（这里简化为静态字典）""" examples = { "programming": "例如，在Python中计算斐波那契数列：\ndef fib(n):\n a, b = 0, 1\n for _ in range(n):\n a, b = b, a+b\n return a", } return examples.get(topic, "")

然后，我们创建主模板smart_assistant.yml.j2，并利用include指令实现模块化：

# 主模板: smart_assistant.yml.j2 {% include 'templates/parts/system_intro.yml.j2' %} {# 根据历史长度决定是否插入休息提醒 #} {% if history|length >= 3 %} {% include 'templates/parts/break_reminder.yml.j2' %} {% endif %} {# 根据话题决定是否插入代码示例 #} {% set topic = classify_topic(current_query_text) %} {% if topic == "programming" %} - name: dynamic_code_example role: user content: | 检测到您的问题可能与编程相关，这里有一个参考示例： {{ fetch_code_example(topic) }} {% endif %} {% include 'templates/parts/conversation_history.yml.j2' %} {% include 'templates/parts/current_query.yml.j2' %} {% include 'templates/parts/response_prompt.yml.j2' %}

我们将不同的部分拆分成独立的子模板文件：

• templates/parts/system_intro.yml.j2: 存放系统指令。
• templates/parts/break_reminder.yml.j2: 存放休息提醒内容。
• templates/parts/conversation_history.yml.j2: 历史消息循环逻辑。
• templates/parts/current_query.yml.j2: 当前问题插入。
• templates/parts/response_prompt.yml.j2: 响应引导。

使用这个更智能的模板：

from prompt_poet import Prompt # 将自定义函数传入模板上下文 template_data = { "assistant_name": "知学", "personality": "严谨而富有热情", "history": [...], # 假设有4条历史记录 "current_query_text": "Python里的装饰器怎么理解？", "classify_topic": topic_classifier, # 传入函数 "fetch_code_example": fetch_code_example # 传入函数 } prompt = Prompt( template_path="smart_assistant.yml.j2", template_data=template_data ) # 此时，prompt.messages 将包含： # 1. 系统介绍 # 2. 休息提醒（因为history长度>=3） # 3. 动态代码示例（因为话题被分类为programming） # 4. 历史对话 # 5. 当前问题 # 6. 响应提示

实操心得二：函数注入与性能在模板中调用函数非常强大，但要注意性能。classify_topic这类函数会在每次渲染模板时都被调用。如果函数内部涉及网络IO（如调用另一个API）或复杂计算，可能会成为性能瓶颈。务必确保这些函数是高效的，或者考虑对结果进行缓存。对于纯数据转换，也可以考虑在传入template_data前，在Python端预先计算好。

3.3 精细化控制：Token统计与嵌套章节

对于生产系统，监控和优化token使用量是必须的。Prompt Poet提供了详细的token统计功能，特别是通过嵌套章节，你可以获得每个逻辑部分的token消耗明细。

让我们改造之前的系统指令部分，将其拆分为更细的章节：

# templates/parts/detailed_system_intro.yml.j2 - name: system_instructions role: system sections: - name: assistant_identity content: | 你是一个名为{{ assistant_name }}的AI学习助手。 - name: core_principles content: | 你的核心原则是：1) 准确无误；2) 循序渐进；3) 鼓励探索。 - name: communication_style content: | 你的交流风格是：{{ personality }}。请多用比喻和例子来解释复杂概念。 - name: safety_guardrail content: | 安全准则：你不得生成有害、歧视性或违反伦理的内容。如果遇到无法回答的问题，应礼貌地引导至其他话题。

在代码中，我们可以这样获取详细的统计数据：

prompt = Prompt(template_path="smart_assistant.yml.j2", template_data=template_data) # 必须先进行tokenize才能获取统计信息 prompt.tokenize() # 获取分层的章节统计 hierarchical_stats = prompt.section_stats for part in hierarchical_stats: print(f"部件: {part['part_name']}, 总Tokens: {part['part_tokens']}") if part.get('has_sections'): for section in part['sections']: print(f" -> 章节 [{section['section_name']}]: {section['section_tokens']} tokens") # 获取扁平的token计数映射 flat_counts = prompt.get_section_token_counts() print(flat_counts) # 输出可能类似： # { # 'system_instructions': { # 'assistant_identity': 25, # 'core_principles': 40, # 'communication_style': 35, # 'safety_guardrail': 60 # }, # 'dynamic_code_example': {...}, # ... # }

注意事项：嵌套章节的使用限制一个PromptPart只能包含content或sections中的一个，不能同时存在。sections下的每个content需要使用YAML的块标量（|）来正确保留换行符。另外，由于tokenizer在边界处理上的特性，各个章节的token数之和可能不等于父部件的总token数，这是正常现象。这个功能是完全向后兼容的，没有章节的旧模板可以继续工作。

4. 生产级部署：缓存、截断与性能调优

在开发环境玩转模板只是第一步，将Prompt Poet应用到高并发、低延迟的生产环境，需要关注几个关键点：模板缓存、智能截断策略和tokenizer选择。

4.1 模板注册表与缓存策略

虽然Prompt Poet的文档提到了“模板注册表”的概念，但它目前并非一个内置的、开箱即用的高级功能。在实践中，我们需要自己实现模板的加载和缓存，以避免每次请求都从磁盘读取文件带来的I/O开销。

一个简单的实现方案是使用functools.lru_cache来缓存编译好的Jinja2模板环境或直接缓存Prompt类的某个中间状态。但更通用的做法是缓存原始的模板字符串。下面是一个示例：

import hashlib from functools import lru_cache from pathlib import Path from prompt_poet import Prompt class CachedPromptFactory: def __init__(self, template_dir: str = "./templates"): self.template_dir = Path(template_dir) # 缓存渲染好的Prompt对象？不，这不可行，因为template_data每次不同。 # 我们缓存加载的模板文件内容。 self._template_cache = {} @lru_cache(maxsize=128) def _get_template_content(self, template_name: str) -> str: """缓存模板文件内容""" file_path = self.template_dir / f"{template_name}.yml.j2" if file_path not in self._template_cache: with open(file_path, 'r', encoding='utf-8') as f: self._template_cache[file_path] = f.read() return self._template_cache[file_path] def create_prompt(self, template_name: str, template_data: dict) -> Prompt: """创建Prompt对象，使用缓存的模板内容""" raw_template = self._get_template_content(template_name) # 注意：这里我们使用 raw_template 参数，而不是 template_path return Prompt(raw_template=raw_template, template_data=template_data) # 使用示例 factory = CachedPromptFactory() for _ in range(1000): # 模拟多次请求 prompt = factory.create_prompt( "smart_assistant", {"assistant_name": "Bot", "current_query_text": "Hello", "history": []} ) # ... 使用prompt

重要提示：Prompt对象本身与template_data强相关，因此不能直接缓存整个Prompt对象。上述方案缓存的是不经常变化的模板文件内容。对于极度追求性能的场景，可以进一步缓存jinja2.Template对象。

4.2 缓存感知截断详解与参数调优

这是Prompt Poet最硬核也最具价值的功能之一。为了最大化利用LLM服务商的GPU前缀缓存，我们需要理解其截断算法并合理设置参数。

假设你的LLM服务商（如某些云服务或自建集群）支持前缀缓存，其原理是：对于输入序列的某个前缀部分，如果多次请求中完全相同，其计算结果可以被缓存并复用，从而跳过这部分token的重复计算。Prompt Poet的truncate方法通过一种“阶梯式”截断来稳定这个前缀。

TOKEN_LIMIT = 8192 # 模型上下文总限制 TRUNCATION_STEP = 512 # 截断步长 prompt.tokenize() # 必须先计算token prompt.truncate(token_limit=TOKEN_LIMIT, truncation_step=TRUNCATION_STEP) # 截断后，prompt.messages 中的内容会被智能地缩短

算法逻辑：

1. tokenize(): 计算整个提示词各部分的token数。
2. truncate(): 如果总token数超过TOKEN_LIMIT，则开始截断。
3. 它优先截断truncation_priority值更小的部分（值越小优先级越高）。对于相同优先级的多个部分（如多条历史消息），按它们在模板中出现的顺序（从旧到新）截断。
4. 关键点在于，它不会精确地截到刚好TOKEN_LIMIT。相反，它会以TRUNCATION_STEP为“台阶”，将截断边界对齐到最近的TRUNCATION_STEP整数倍位置。例如，如果计算出的理想截断点是第1250个token，TRUNCATION_STEP=512，那么实际截断点会被调整到第1024个token（因为floor(1250/512)*512 = 1024）。
5. 这样做的结果是，在连续的多次对话中，只要新增内容没有导致总token数跨越下一个TRUNCATION_STEP的边界，截断点就会保持不变。不变的前缀就意味着更高的缓存命中率。

参数调优建议：

• TRUNCATION_STEP的设置需要权衡。值越大，缓存命中率可能越高（因为前缀更稳定），但可能截掉更多本可保留的有用内容。通常可以从模型上下文窗口的1/16或1/32开始尝试，例如对于8K上下文，设置512或256。
• 监控你的应用的前缀缓存命中率（如果服务商提供此指标）和平均响应延迟。通过A/B测试，寻找一个在内容保留和性能提升之间的最佳平衡点。
• 为不同优先级的部件合理设置truncation_priority。通常，最旧的、信息密度可能较低的历史消息优先级最高（值最小），而最新的系统指令或用户当前查询优先级最低（值最大或不设置，即最后被截断）。

4.3 自定义Tokenizer与编码函数

默认情况下，Prompt Poet使用TikToken的o200k_base编码器（适用于如GPT-4o等模型）。但如果你使用的模型不是OpenAI系列，就需要指定对应的tokenizer。

from transformers import AutoTokenizer # 使用HuggingFace tokenizer from prompt_poet import Prompt # 加载你的模型对应的tokenizer hf_tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.2-1B-Instruct") def encode_with_hf(text: str) -> List[int]: # 注意：这里只返回input_ids，忽略attention_mask等 return hf_tokenizer.encode(text, add_special_tokens=False) # 创建Prompt时传入自定义编码函数 prompt = Prompt( raw_template=raw_template, template_data=template_data, encode_func=encode_with_hf # 关键参数 ) prompt.tokenize() # 现在会使用你提供的encode_func来计算token print(len(prompt.tokens)) # 查看token数量

踩坑记录：Token计数的一致性不同tokenizer对同一文本的计数结果差异可能很大。务必确保你用于截断计算的tokenizer与后端LLM服务使用的tokenizer完全一致。如果你使用Azure OpenAI服务，就用TikToken；如果你使用Llama模型的自托管服务，就用对应的HuggingFace tokenizer。计数不一致会导致截断位置错误，可能截断关键指令或导致输入长度超限错误。

5. 常见问题排查与实战技巧

在实际项目集成中，你可能会遇到一些典型问题。以下是我总结的排查清单和技巧。

5.1 模板渲染问题

问题：Jinja2模板语法错误或变量未定义。

• 症状：调用Prompt()初始化或访问prompt.messages时抛出jinja2.exceptions.TemplateError或UndefinedError。
• 排查：
  1. 检查YAML和Jinja2语法是否正确。特别注意缩进和冒号，YAML对格式非常敏感。可以使用在线YAML校验器。
  2. 确认所有在模板中使用的变量（如{{ variable_name }}）都已包含在传入的template_data字典中。
  3. 如果使用了{% include %}，检查文件路径是否正确，以及被包含的文件本身是否有语法错误。
• 技巧：在开发阶段，可以先用prompt.string属性输出渲染后的纯文本字符串，这比直接看messages列表更直观，便于调试模板逻辑和变量替换结果。

问题：模板渲染结果不符合预期，比如循环或条件判断未生效。

• 排查：
  1. 检查传递给Jinja2函数（如classify_topic）的输入参数类型和返回值是否符合{% if %}语句的期望。Jinja2中，空列表、None、False、0 都会被判定为False。
  2. 在Python端打印出template_data，确保数据结构和值是正确的。
  3. 在模板中临时添加调试输出，例如{{ variable_name|tojson }}来查看变量内容（需要确保tojson过滤器可用或使用简单输出）。

5.2 截断与Token相关

问题：截断后，重要的系统指令或最新消息丢失了。

• 原因：truncation_priority设置不合理。默认情况下，未设置优先级的部件优先级为0（最高）。如果所有部件优先级相同，则按出现顺序截断（先出现的先被截）。
• 解决：为你最重要的部件（如核心系统指令、当前用户问题）设置较高的truncation_priority值（例如999），或者不设置（默认最后处理）。为最不重要的、可丢弃的部件（如远古历史消息）设置较低的优先级值（如1）。
• 示例调整：

  - name: core_system_rule # 核心规则，绝不能丢 role: system truncation_priority: 1000 # 设置一个非常大的值，确保最后被截 content: | 你必须遵守以下核心规则：... - name: chat_history role: user truncation_priority: 1 # 历史消息优先被截 content: | {% for msg in history %} {{ msg.role }}: {{ msg.content }} {% endfor %} - name: current_query # 当前问题，也很重要 role: user # 不设置truncation_priority，默认优先级高于设置了正整数的部分 content: | 用户: {{ current_query }}

问题：prompt.tokenize()或prompt.truncate()非常慢。

• 原因：如果提示词非常长，或者使用了较慢的自定义encode_func，tokenize过程可能成为瓶颈。
• 优化：
  1. 考虑对最终的prompt.tokens或prompt.messages进行缓存，如果相同的提示词可能被重复使用（注意template_data要相同）。
  2. 评估是否真的需要在每次请求中都调用tokenize和truncate。如果上下文长度固定且远未达到上限，或许可以跳过截断。
  3. 确保自定义的encode_func是高效的。对于HuggingFace tokenizer，避免重复加载模型。

5.3 与现有框架集成

问题：如何与LangChain、LlamaIndex等框架一起使用？Prompt Poet生成的prompt.messages是一个标准的字典列表，格式与OpenAI API、Anthropic API等兼容。因此，它可以无缝接入大多数框架。

• LangChain：直接将prompt.messages传递给ChatOpenAI或ChatAnthropic等LLM封装器的invoke或generate方法。

  from langchain_openai import ChatOpenAI from prompt_poet import Prompt prompt = Prompt(...) llm = ChatOpenAI(model="gpt-4") # 方法一：使用 invoke response = llm.invoke(prompt.messages) # 方法二：手动构造 AIMessage, HumanMessage 等（如果框架需要） from langchain_core.messages import SystemMessage, HumanMessage messages = [] for part in prompt.parts: if part.role == 'system': messages.append(SystemMessage(content=part.content)) else: messages.append(HumanMessage(content=part.content)) response = llm.invoke(messages)

• 直接HTTP请求：将prompt.messages直接作为JSON请求体的一部分发送给LLM API。

  import requests prompt = Prompt(...) api_payload = { "model": "your-model-name", "messages": prompt.messages, "temperature": 0.7 } response = requests.post("https://api.your-llm-provider.com/v1/chat/completions", json=api_payload)

5.4 内容格式化与空白处理

问题：生成的提示词中出现了多余的空行或空格，影响了模型理解。

• 原因：YAML的多行字符串（使用|）会保留换行符，而Jinja2模板标签（如{% for %}、{% if %}）周围也可能产生空白。
• 解决：
  1. Prompt Poet默认会尝试剥离不必要的空白，但有时不够彻底。
  2. 在Jinja2标签中使用减号-来控制空白。{%-表示删除该标签前的空白，-%}表示删除该标签后的空白。
  3. 使用内置的<|space|>占位符来显式表示需要一个空格，避免依赖不确定的空白字符。

  {% for item in list -%} {# 删除for循环前的换行 #} - name: item_{{ loop.index }} content: {{ item }} {% endfor %} {# 这里会保留一个换行，作为YAML列表项的分隔是需要的 #} - name: greeting content: | 你好，<|space|>{{ username }}！ {# 确保“你好，”和用户名之间有一个空格 #}

  4. 如果问题依然存在，在生成后使用prompt.string检查最终字符串，并用Python的字符串方法（如.strip()、'\n'.join(line.strip() for line in s.split('\n'))）进行后处理。

将Prompt Poet集成到你的LLM应用流水线中，开始时可能会觉得多了一层抽象，有点麻烦。但一旦你习惯了这种声明式的模板编写方式，并体验到它在复杂提示词管理、团队协作和性能优化上带来的好处，就很难再回到过去那种在代码中拼接字符串的日子了。它尤其适合那些提示词逻辑复杂、需要频繁A/B测试、且对响应延迟和成本有要求的项目。