提示词模板 ejs

你是不是也在代码里拼过一长串提示词，加个变量就得改半天字符串？换成 EJS 模板后，提示词能像页面一样拆成片段、传进变量、按条件裁剪，改一次全局生效。这篇不吹工具，只讲工程上怎么落地：文件怎么组织、变量怎么传、复用的边界在哪，以及哪些场景其实不该用模板。

你是不是也在代码里拼过一长串提示词，加个变量就得改半天字符串？换成 EJS 模板后，提示词能像页面一样拆成片段、传进变量、按条件裁剪，改一次全局生效。这篇只讲工程上怎么落地：文件怎么组织、变量怎么传、复用的边界在哪，以及哪些场景其实不该用模板。

先把结论放前面：EJS 不是用来「让提示词更高级」的，是用来把散落在代码里的字符串收成可维护文件的。如果你的提示词只有一句话，或者只跑一次就扔，别折腾模板；但只要同一个任务要反复调用、要换语气、要按用户类型给不同版本，模板化就值。下面按「为什么用—变量怎么传—片段怎么复用—出问题怎么查」四段走。

为什么提示词要用模板文件管，而不是留在字符串里

提示词写在字符串里的麻烦，通常不是立刻爆发，而是攒到第三四个版本才发作：改一句语气要全局搜同一段角色设定，发现有五处复制；想对照两版提示词的效果，却分不清哪次改动动了哪里；上线前要做多语言，只能整段再复制一遍。这些都不是 EJS 独有的问题，但模板能把它们变成可操作的编辑动作。

• 改语气时改动只发生在一个片段文件里，不会漏掉某处硬编码的旧版本；
• 同一段角色设定被包含到多个主模板，避免复制后各自跑偏；
• 调参从「手工替换字符串」变成「改一个变量值再渲染」，对照实验更容易做；
• 提示词能进版本管理，和历史代码改动一起回溯，排查效果波动时有据可查。

但要说清不适用的边界。一次性调试、只跑一两次的实验、短到一句话的提示词，写模板反而多一层文件读取和渲染的负担，改起来也不比直接写字符串快。判断标准很简单：这段提示词会不会被第二次调用、会不会需要变体、会不会有一天要回答「上周那版到底写了什么」。三个都答「不会」，就留在代码里。

变量注入：怎么把运行时数据安全地塞进提示词

变量要先分成两类再动手写模板。固定配置是角色、语气、输出格式这些，改动频率低，适合直接写在模板里或用默认值注入；运行时数据是用户输入、检索片段、文件内容，每次调用都不一样，必须通过参数传进去。两类混在一起传，最容易出现「用户输入把角色设定挤到后面」或者「默认值覆盖了真实数据」。

转义输出

把用户输入当纯文本插入，输入里带的分隔符、引号不会破坏模板结构，用户输入一律走这条

原文输出

把内容原样嵌入，适合你自己控制的片段文件，不适合直接接用户输入

默认值

变量缺字段时给兜底文案，避免 undefined 四个字母直接进提示词

截断规则

长文、检索结果先定好按字符还是按段落截，再传进模板，别让模型替你处理超长输入

用户输入一律走转义输出，这是硬规矩。原因是输入里可能出现和模板结构同名的符号，原文输出会让模型把用户内容误当成指令边界。默认值则解决另一个常见故障：上游某个字段没传，渲染出来就是 undefined，模型会老实按字面理解，输出质量断崖式下降。缺字段时给「未提供」这类兜底文案，比静默留空更安全。

// 主模板里只放结构，不塞业务数据
const ejs = require('ejs');
const prompt = ejs.render(templateStr, {
  role: cfg.role,              // 固定配置，有默认值
  tone: cfg.tone || '简洁',
  userInput: sanitize(input),  // 运行时数据，先清洗再传
  examples: cfg.useExamples ? examples : []
});

复用技巧：片段包含、条件分支与多套变体怎么组织

复用的核心是把「变化频率不同」的内容拆开。角色设定、输出格式约束、few-shot 示例这三类，通常变化节奏不一样：角色设定几个月不动，示例可能每周换。拆成独立片段文件，主模板用包含组装，改哪块动哪块，不会牵一发动全身。

条件分支用来减少模板份数。同一份模板用一个开关控制要不要带示例、要不要带思考步骤，比维护两三个几乎一样的文件省事。但开关别堆太多，超过三四个布尔量之后，模板的可读性会掉得比复用收益快，那时候宁可拆成两个明确命名的模板。多语言和多平台变体同理，能用变量分支就用变量，别复制文件，否则改一处漏三处。

还有一个容易被忽略的点：模板本身要带版本意识。提示词改动会直接影响历史输出的一致性，同一个测试用例在不同时间跑出不同结果时，得能回答「是不是上周改了模板」。改动时在文件里留一句简短说明，记录改了什么、为什么改，配合代码版本管理，回溯成本会低很多。

排错与维护：模板出问题按什么顺序查

模板渲染出错和模型输出变差，是两个不同的问题，排查顺序也别混。推荐先看渲染结果本身，再看提示词结构，最后才怀疑模型和长度预算。这个顺序能过滤掉大部分「其实是变量没传进去」的假故障。

1. 把渲染结果落盘看原文不要直接看模板字符串，把渲染后的完整提示词写到文件里打开，确认变量有没有注入、有没有多出空行、多余逗号和重复片段。
2. 再查结构顺序看角色与任务指令是不是被长段用户输入挤到了后面。指令越靠后，模型越容易忽略，必要时把关键约束提到用户数据前面。
3. 最后查长度预算拼接后是否超出上下文限制。到站内基础知识分类页把 Token、上下文这几个词的口径确认一遍，别用不同工具各算一套。
4. 记录有效版本每次确认有效的模板版本记下来，改动前先对照上一版，配合站内 Token 与价格估算工具看成本差别。

维护阶段最省事的做法，是给每个模板配一个最小测试样例：固定输入，看输出是否稳定。样例不用多，能覆盖「有示例」和「无示例」两条路径就够。发现输出漂移时，先跑样例确认是不是模板改动导致，排除了模板因素再去看上游数据和模型侧的变化，能少走弯路。