夜雨聆风讨论提示词工程化的两项核心技术：模板化与分层组装。
一、模板化
模板化的核心机制是提取变动内容，以占位符替代，保持骨架结构稳定。这一方法在规模化应用中不可或缺。
1.1 手写方式的瓶颈
以运营岗位生成周报的场景为例。原始做法是每次从零开始输入：
“你是一位产品经理，擅长数据分析，请根据下面的工作记录生成本周总结……”
随后附加工作记录与格式要求。单次操作尚可接受，但面临每日重复、多人共用、频繁调整格式等场景时，固定内容的反复输入成为效率瓶颈。真正需要调整的，仅是少数变量。
1.2 Jinja2 模板引擎
变量增多、逻辑复杂时，需引入编程手段。Python 生态中的 Jinja2 模板引擎适用于提示词管理：
from jinja2 import Template
prompt_template = Template("""
你是一位{{ role }}，擅长{{ skill }}。
请根据以下输入，{{ task }}。
{% if examples %}
参考示例：
{% for ex in examples %}
输入：{{ ex.input }}
输出：{{ ex.output }}
{% endfor %}
{% endif %}
""")
prompt = prompt_template.render(
role="产品经理",
skill="撰写周报",
task="生成本周工作总结",
examples=[
{"input": "完成了3个客户访谈", "output": "完成3个核心客户访谈"}
]
)模板中 {{ }} 包裹的变量由实际值替换，{% if %} 实现条件渲染，{% for %} 处理循环逻辑。role、skill、task 等值可来源于用户输入、数据库或动态判断。模板结构统一维护，确保输出口径一致。
1.3 配置化分离
模板化解决生成机制问题，配置化则解决协作问题。业务人员通常更熟悉客户需求与质量标准，但不愿接触代码。将结构定义迁移至 YAML 格式：
name: 周报生成器
version: 1.0
system_prompt: "你是一位资深产品经理..."
user_prompt_template: |
本周工作记录：
{{ work_records }}
要求：
- 字数：{{ max_words }}
- 格式：{{ format }}
variables:
- work_records
- max_words
- format业务人员可直接修改 YAML 文件，调整角色设定或格式要求，无需了解 Python 语法。开发端仅需实现配置读取与模板渲染逻辑。配置可存放于数据库、Redis 或配置中心，支持热更新，避免重新部署。
二、分层组装
主流大语言模型 API 均区分系统提示词（System Prompt）与用户提示词（User Prompt）。这一区分提供了天然的分层框架。
2.1 系统层与用户层的分工
系统提示词承担基调设定，用户提示词承担任务传达。
以房产咨询机器人为例：
系统提示词：
“你是一位经验丰富的房地产经纪人，仔细阅读披露文件，基于事实评估房产状况，帮助买家理解风险与机会。回答简洁专业。”
用户提示词：
“上下文：[disclosure.pdf] 问题：总结该房产的噪音投诉情况（如有）。”
分离的原因在于稳定性差异。系统提示词中的角色身份、风格要求长期不变；用户提示词中的具体问题、附加材料随请求变化。
系统提示词通常位于输入序列前端。大语言模型对位置靠前的指令敏感度更高，重要约束置于系统层可获得更稳定的执行效果。
2.2 静态层与动态层
分层思路可扩展为静态层与动态层的叠加。
静态层包含不随单次请求变化的内容：角色核心设定、安全策略、默认格式规范、知识边界。这类内容在部署时确定，保持长期稳定，确保行为基线的一致性。
动态层包含随请求实时生成的内容：用户当前输入、对话历史、检索召回的文档片段、意图分类后的条件模块。这类内容每次不同，实现个性化响应与场景适配。
2.3 组装逻辑
完整提示词的典型组装顺序：
静态系统层（角色、安全、规范）→ 动态上下文层（历史摘要、用户画像）→ 动态任务层（当前输入、检索内容、条件组件）→ 动态约束层（格式、长度等特殊要求）。
分层结构实现解耦：静态层由开发团队维护，版本发布时统一更新；动态层由运行时数据驱动，单次请求独立变化。静态层可预加载缓存，动态层按需计算，兼顾一致性与性能。
2.4 按需组合原则
常见误区是追求要素完备，将角色、背景、目标、输入、示例、约束、风格、格式尽数堆砌。实际应遵循任务复杂度适配原则：
简单任务（一句话润色）：行动、目的、期望三要素即可。
中等任务（业务场景）：四要素附加风格或示例。
复杂任务（商业方案、创意写作、严格格式）：启用六至七要素的完整配置。
要素清单仅作参考，非强制要求。应根据实际需求动态调整，缺项补项，避免过度配置。
三、渐进实施
不必从变量占位符起步，验证有效后逐步引入条件判断与循环。业务场景确需配置化时，再实施 YAML 或数据库方案。
模板代码应遵循代码规范：注释说明变量用途，采用有意义的命名，保持缩进与格式整洁。避免因提示词属性而降低质量要求。
提示词变更直接影响输出质量，必须建立版本管理机制。文件名纳入版本号与时间戳（如 weekly_report_v1.0_20240115.md），保留历史版本并记录变更日志，支持效果回退。
进一步可建立测试集：收集代表性输入，定义评判标准，修改后执行回归测试。生产环境中尤为必要。
四、结语
提示词工程前期投入看似增加，但运行稳定后收益显著。提示词从一次性输入转变为人机协作系统的基础设施，具备稳定性、可靠性与可迭代性。
高效的提示词不在于每次从零创作的技巧，而在于将成功经验转化为团队可共享、可复用的知识资产。
