dotpmt：告别硬编码提示词，实现LLM提示词与代码分离管理

1. 项目概述：告别代码中的“硬编码”提示词

如果你和我一样，在日常开发中频繁地与各种大语言模型（LLM）打交道，无论是调用 OpenAI 的 GPT、Anthropic 的 Claude，还是部署在本地或云端的开源模型，那么你一定对下面这种场景深恶痛绝：一个精心设计的、动辄数百字的提示词（Prompt），被硬生生地塞在代码文件里，变成一个冗长无比的字符串常量。它可能夹在两个函数中间，或者被定义在某个配置对象的深处。当你需要微调提示词，或者为不同场景准备不同版本时，你不得不在代码、版本控制和部署流程之间反复横跳，稍有不慎就会引入错误，或者让代码库变得一团糟。

dotpmt这个工具，就是为了解决这个痛点而生的。它的核心思想简单到令人拍案叫绝：将提示词从代码中彻底分离出来。它让你可以把提示词当作独立的、一等公民的“内容文件”来管理，就像我们管理.json配置文件、.md文档一样。通过一个极简的模板语法，你可以在提示词中插入动态变量，然后在代码中轻松地加载和渲染它们。这样一来，你的代码逻辑保持清晰简洁，而提示词则可以独立地进行版本控制、编辑、测试和复用。这对于任何涉及提示工程（Prompt Engineering）的项目来说，都是一个能显著提升开发效率和维护性的基础工具。

2. 核心设计思路：为什么我们需要分离提示词？

在深入dotpmt的具体用法之前，我们先花点时间聊聊为什么“分离提示词”这个做法如此重要。这不仅仅是代码整洁的问题，它直接关系到项目的可维护性、协作效率和迭代速度。

2.1 硬编码提示词的四大痛点

痛点一：代码可读性灾难。想象一下，一个精心设计的、包含多轮对话示例、复杂格式要求和系统指令的提示词，可能长达几十行。当它作为一个字符串字面量出现在你的main.py或index.js中间时，它会严重割裂代码的逻辑流。其他开发者（或者三个月后的你自己）在阅读代码时，需要费力地跳过这片“文本沼泽”才能理解业务逻辑。

痛点二：版本控制与协作困难。提示词的迭代是提示工程的核心。今天你可能想调整一下语气，明天可能想增加一个示例，后天可能发现某个指令会引发模型的奇怪行为。如果提示词混在代码里，每次修改都意味着要提交代码文件的变更。在团队协作中，这很容易与功能性的代码修改产生冲突。更理想的状态是，提示词的修改可以像修改文档或配置文件一样，拥有独立的提交历史和评审流程。

痛点三：难以实现 A/B 测试与多环境配置。在实际产品中，我们经常需要对不同的用户群体、不同的场景使用略微不同的提示词，或者进行提示词的 A/B 测试。如果提示词硬编码在代码中，实现这些功能就需要引入复杂的条件逻辑或配置系统。而如果提示词本身就是外部文件，你可以轻松地为不同环境准备不同的.pmt文件（例如prompts/prod/summarize.pmt和prompts/staging/summarize.pmt），或者根据配置动态加载不同版本的文件。

痛点四：缺乏专业工具支持。当提示词是代码中的字符串时，你无法利用专业的文本编辑器或 IDE 为其提供语法高亮、格式化、拼写检查等支持。而独立的.pmt文件可以被识别为纯文本或自定义语言，从而获得更好的编辑体验。

2.2dotpmt的解决方案哲学

dotpmt的设计哲学是“极简”和“约定优于配置”。它没有试图去构建一个复杂的提示词管理系统，而是提供了一个最小化的、无侵入性的胶水层。它的工作流程非常直观：

1. 编写：在项目目录下（例如prompts/）创建.pmt文件，用纯文本写下你的提示词。
2. 模板化：在需要动态内容的地方，使用双花括号{{variable_name}}插入变量。
3. 加载：在代码中，使用loadPrompt函数，指定文件路径和变量值。
4. 使用：将渲染后的完整提示词字符串，传递给你的 LLM SDK。

这个过程中，dotpmt只做了一件事：读取文本文件，并替换其中的变量占位符。它不关心你用什么模型、什么 SDK，也不强制你使用特定的项目结构。这种轻量级的设计使得它能够无缝集成到任何现有的 Node.js（或 TypeScript）项目中。

3. 从零开始：安装与环境配置

让我们开始动手。dotpmt是一个 Node.js 包，所以前提是你的项目已经初始化并使用了npm、yarn、pnpm等包管理器之一。

3.1 安装 dotpmt

打开你的终端，进入项目根目录，执行安装命令。这里以npm为例：

npm install dotpmt

如果你使用yarn或pnpm，对应的命令是yarn add dotpmt或pnpm add dotpmt。安装完成后，你可以在package.json的dependencies中看到它。

注意：dotpmt本身几乎没有依赖，安装速度会很快。它主要依赖 Node.js 的原生文件系统模块 (fs) 来读取文件，因此非常轻量。

3.2 项目结构规划

在开始创建提示词文件之前，我强烈建议你先规划一下存放它们的目录结构。一个清晰的结构能让你和你的团队长期受益。以下是几种常见的模式，你可以根据项目复杂度选择：

模式一：简单扁平结构（适合小型项目）

your-project/ ├── src/ ├── prompts/ # 所有提示词文件都放在这里 │ ├── summarize.pmt │ ├── classify.pmt │ └── translate.pmt ├── package.json └── ...

模式二：按功能/模块划分（适合中型项目）

your-project/ ├── src/ │ ├── modules/ │ │ ├── customer-service/ │ │ │ └── prompts/ # 客服模块专用提示词 │ │ │ ├── intent.pmt │ │ │ └── reply.pmt │ │ └── content-moderator/ │ │ └── prompts/ # 内容审核模块专用提示词 │ │ └── check.pmt ├── shared/ │ └── prompts/ # 全局共享的提示词 │ ├── system.pmt │ └── format.pmt └── package.json

模式三：按环境或版本划分（适合进行 A/B 测试或多环境部署）

your-project/ ├── prompts/ │ ├── v1/ # 提示词版本1 │ │ ├── summarize.pmt │ │ └── chat.pmt │ ├── v2/ # 提示词版本2（新实验） │ │ ├── summarize.pmt │ │ └── chat.pmt │ └── production/ # 生产环境稳定版 │ └── summarize.pmt └── ...

我个人在大多数项目中从模式一开始，随着提示词数量增多，自然演进到模式二。模式三通常在与特性开关（Feature Flag）系统结合时使用。

4. 深入.pmt文件：语法与最佳实践

.pmt文件的本质是纯文本文件，扩展名.pmt可以理解为 “Prompt Template” 的缩写。它的语法极其简单，核心就是双花括号{{}}插值。

4.1 基础模板语法

创建一个名为prompts/greet.pmt的文件：

# 这是一个简单的问候提示词 你是一个友好的助手。请根据用户的姓名和心情，生成一段个性化的问候语。 用户姓名：{{name}} 用户当前心情：{{mood}} 请开始你的问候：

在这个文件中：

• #开头的行是注释，dotpmt在加载时会原样保留它们。注释对于说明提示词的意图、使用场景和注意事项至关重要。
• {{name}}和{{mood}}是变量占位符。它们将在代码中被提供的实际值替换。

4.2 处理复杂内容与转义

当需要插入的变量本身包含可能破坏模板结构的字符（比如变量值本身就包含{{或}}）时，你不需要担心。dotpmt使用的模板引擎（默认是类似 Mustache 的简单替换）通常能正确处理。但更常见的问题是插入多行内容。

例如，你要总结一篇文章：

# summarize.pmt 请用中文总结以下文本的主要内容，并提取三个关键词。 文本内容：

{{content}}

总结：

注意，这里我们用三个反引号包裹了{{content}}变量。这是因为我们预期content变量是一段很长的、可能包含换行的文本。在代码中加载时，dotpmt会将{{content}}整体替换为变量的值，保留其原有的格式。

4.3 高级用法：条件逻辑与循环的替代方案

dotpmt的官方实现专注于简单的变量替换，并不内置复杂的条件判断或循环语法（如{% if %}或{{#each}}）。这是其保持简单的设计选择。那么，如何实现动态结构呢？

方案一：在 JavaScript/TypeScript 代码中构建逻辑。这是最灵活的方式。你可以在调用loadPrompt之前，根据条件决定传入哪些变量，甚至决定加载哪个不同的.pmt文件。

import { loadPrompt } from "dotpmt"; function generatePrompt(userRole: string, query: string) { let promptTemplate; if (userRole === 'admin') { promptTemplate = 'prompts/query-admin.pmt'; } else { promptTemplate = 'prompts/query-user.pmt'; } const prompt = loadPrompt(promptTemplate, { query: query, // 可以为不同模板传入不同的变量集 ...(userRole === 'admin' && { secretKey: process.env.ADMIN_KEY }) }); return prompt; }

方案二：使用“开关变量”和注释。在提示词内部，你可以通过变量来控制文本块是否生效。这需要模型有一定的指令遵循能力。

# conditional.pmt 你是一个翻译助手。 {{#if shouldExplain}}请先解释以下术语，然后再翻译。{{/if}} {{! 这不是真正的模板语法，是给模型看的注释 }} 需要处理的文本：{{text}}

在代码中，你可以将shouldExplain变量设置为一个具体的指令字符串：

const prompt = loadPrompt("prompts/conditional.pmt", { shouldExplain: "请先解释以下术语，然后再翻译。", // 直接传入要显示的文本 text: "Quantum Entanglement" }); // 渲染结果会是：“你是一个翻译助手。请先解释以下术语，然后再翻译。需要处理的文本：Quantum Entanglement”

虽然{{#if}}在文件中看起来像模板指令，但对dotpmt来说，它只是另一个叫shouldExplain的变量。我们通过代码逻辑来控制这个变量的内容（是要插入的文本还是空字符串），从而模拟条件效果。注释{{! ... }}部分在加载后依然存在，是给阅读提示词文件的人看的，对模型影响很小。

实操心得：我建议将复杂的逻辑留在代码中，让.pmt文件尽可能保持“声明式”和“纯净”。.pmt文件的核心价值在于其可读性和可维护性，如果里面塞满了复杂的模板标签，就违背了分离的初衷。把.pmt文件看作是“静态的蓝图”，而代码是“动态的构建师”。

5. 在项目中集成与使用dotpmt

现在，我们来看看如何在真实的代码中使用它。我们将结合常用的 LLM SDK（如 OpenAI Node.js 库）来演示一个完整的工作流。

5.1 基础加载与渲染

假设我们有如下提示词文件prompts/creative-writer.pmt：

# creative-writer.pmt 你是一位才华横溢的科幻作家。请根据以下核心设定，写一个短篇故事的开头段落。 核心设定： - 时代：{{era}} - 关键科技：{{tech}} - 故事基调：{{tone}} 故事开头：

在 TypeScript 代码中，我们这样使用它：

import { loadPrompt } from "dotpmt"; import OpenAI from "openai"; // 初始化 OpenAI 客户端（示例，需要你的 API KEY） const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY, }); async function generateStoryStart() { try { // 1. 加载并渲染提示词模板 const fullPrompt = loadPrompt("./prompts/creative-writer.pmt", { era: "22世纪，星际殖民时代", tech: "意识上传与共享网络", tone: "充满希望但又带有一丝孤独感", }); console.log("=== 生成的完整提示词 ==="); console.log(fullPrompt); console.log("=====================\n"); // 2. 调用 LLM API const completion = await openai.chat.completions.create({ model: "gpt-4", // 或 "gpt-3.5-turbo" messages: [ { role: "system", content: "你是一个有帮助的助手。" }, // 系统指令可以单独管理 { role: "user", content: fullPrompt }, ], temperature: 0.8, max_tokens: 500, }); // 3. 处理结果 const storyStart = completion.choices[0]?.message?.content; if (storyStart) { console.log("生成的故事开头：\n"); console.log(storyStart); return storyStart; } else { throw new Error("未能生成故事内容。"); } } catch (error) { console.error("生成故事时发生错误：", error); // 这里可以添加更细致的错误处理，比如重试、降级策略等 throw error; } } // 执行函数 generateStoryStart();

这段代码清晰地展示了分离的好处：业务逻辑（调用 API、处理响应）和内容定义（提示词）完全解耦。如果你想调整故事设定，只需要修改.pmt文件或传入的变量值，完全不用碰这坨异步逻辑。

5.2 路径解析与常用技巧

loadPrompt函数的第一个参数是文件路径。这里有一些细节需要注意：

相对路径的基准目录：loadPrompt使用的相对路径，是相对于当前执行 Node.js 进程的当前工作目录（process.cwd()），而不是相对于当前源代码文件。这可能导致在项目结构复杂时出现找不到文件的错误。

最佳实践：使用绝对路径或__dirname。为了更可靠，我推荐使用path模块来构建绝对路径。

import { loadPrompt } from "dotpmt"; import path from "path"; // 方法一：如果提示词目录在项目根目录下 const promptPath1 = path.join(process.cwd(), "prompts", "summarize.pmt"); // 方法二：如果提示词目录与当前源文件在同一目录或子目录（更常见于模块化结构） const __dirname = new URL('.', import.meta.url).pathname; // ES Modules 获取 __dirname const promptPath2 = path.join(__dirname, "prompts", "summarize.pmt"); const prompt = loadPrompt(promptPath2, { input: "一些文本" });

封装工具函数：为了避免在每个使用提示词的地方都写路径拼接，你可以创建一个工具函数。

// utils/promptLoader.ts import { loadPrompt } from "dotpmt"; import path from "path"; const PROMPTS_BASE_DIR = path.join(process.cwd(), 'prompts'); export function loadProjectPrompt(templateName: string, variables: Record<string, any>): string { const templatePath = path.join(PROMPTS_BASE_DIR, `${templateName}.pmt`); // 这里可以添加缓存、日志、环境覆盖等逻辑 return loadPrompt(templatePath, variables); } // 在其他文件中使用 import { loadProjectPrompt } from '../utils/promptLoader'; const prompt = loadProjectPrompt('summarize', { input: longText });

5.3 与不同 LLM SDK 的配合

dotpmt是模型无关的，它可以和任何 SDK 配合。

配合 Anthropic Claude SDK：

import { loadPrompt } from "dotpmt"; import Anthropic from '@anthropic-ai/sdk'; const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY }); const promptTemplate = loadPrompt("prompts/analyze.pmt", { document: docText }); const message = await anthropic.messages.create({ model: 'claude-3-opus-20240229', max_tokens: 1000, messages: [{ role: 'user', content: promptTemplate }], });

配合本地开源模型（通过 OpenAI 兼容 API）：假设你使用ollama或vLLM部署了本地模型，并提供了与 OpenAI 兼容的 API 端点。

import { loadPrompt } from "dotpmt"; import OpenAI from "openai"; // 仍然可以使用 OpenAI 包，只需改 baseURL const localLLM = new OpenAI({ baseURL: 'http://localhost:11434/v1', // Ollama 的兼容端点 apiKey: 'ollama', // 通常不需要真实的 key }); const prompt = loadPrompt("prompts/local-chat.pmt", { query: userQuestion }); const response = await localLLM.chat.completions.create({ model: 'llama3', // 你的本地模型名称 messages: [{ role: 'user', content: prompt }], });

6. 工程化实践：将dotpmt融入开发流程

仅仅在代码中使用dotpmt还不够，要充分发挥其价值，需要将其融入整个开发和运维流程。

6.1 版本控制策略

.pmt文件应该被纳入 Git 版本控制。我建议：

1. 为提示词编写有意义的提交信息。例如：“feat(prompt): 为总结提示词增加长度控制指令” 或 “fix(prompt): 修正翻译提示词中的歧义示例”。这有助于通过git log -- prompts/快速追踪提示词的演变历史。
2. 考虑使用.gitattributes。你可以指定.pmt文件为文本文件，并为其设置差异比较驱动，以便在git diff时获得更清晰的对比视图。

   # .gitattributes *.pmt text diff

3. 建立分支策略。如果正在进行重大的提示词实验（例如，为提升效果完全重写了一个核心提示词），可以在特性分支上进行，避免影响主分支的稳定性。

6.2 测试提示词

如何测试一个.pmt文件渲染后的效果，以及它能否产生预期的模型输出？

单元测试（渲染测试）：你可以测试loadPrompt函数是否按预期替换了变量。

// __tests__/promptRendering.test.ts import { loadPrompt } from "dotpmt"; import path from "path"; describe('Prompt Rendering', () => { it('should correctly render the greet prompt', () => { const prompt = loadPrompt(path.join(__dirname, '../prompts/greet.pmt'), { name: '小明', mood: '开心' }); expect(prompt).toContain('用户姓名：小明'); expect(prompt).toContain('用户当前心情：开心'); expect(prompt).not.toContain('{{name}}'); // 确保所有变量都被替换 }); });

集成测试/快照测试：对于复杂的提示词，你可以使用“快照测试”来确保其结构不会意外改变。

it('matches the summarize prompt snapshot', () => { const prompt = loadPrompt(path.join(__dirname, '../prompts/summarize.pmt'), { content: '[TEST_CONTENT]' }); expect(prompt).toMatchSnapshot(); // Jest 会将第一次运行的结果存为快照，后续运行与之比较 });

端到端测试（可选但推荐）：对于关键业务提示词，可以编写一个简单的测试，用一组固定的输入调用真实的 LLM API（可以使用低成本的模型如gpt-3.5-turbo），并断言输出中包含某些关键词或符合某种格式。注意，这类测试可能不稳定（因为模型输出有随机性）且会产生 API 调用成本，适合在 CI/CD 的特定阶段（如发布前）运行。

6.3 提示词的国际化 (i18n)

如果你的应用需要支持多语言，提示词也需要国际化。dotpmt可以很好地配合 i18n 方案。

目录结构示例：

prompts/ ├── en/ # 英文提示词 │ ├── greet.pmt │ └── summarize.pmt ├── zh-CN/ # 简体中文提示词 │ ├── greet.pmt │ └── summarize.pmt └── ja/ # 日文提示词 ├── greet.pmt └── summarize.pmt

代码中动态加载：

import { loadPrompt } from "dotpmt"; import path from "path"; function getLocalizedPrompt(templateName: string, locale: string, variables: object) { const templatePath = path.join(process.cwd(), 'prompts', locale, `${templateName}.pmt`); // 可以添加回退逻辑，例如 locale='zh-TW' 找不到时回退到 'zh-CN' return loadPrompt(templatePath, variables); } const userLocale = getUserLocale(); // 例如 'zh-CN' const prompt = getLocalizedPrompt('greet', userLocale, { name: '用户' });

7. 常见问题与排查技巧实录

在实际使用dotpmt的过程中，你可能会遇到一些问题。下面是我总结的一些常见坑点和解决方法。

7.1 文件找不到错误

问题：运行代码时抛出错误，提示ENOENT: no such file or directory。

排查步骤：

1. 检查路径：首先，打印出你传递给loadPrompt的完整路径。确保它指向一个真实存在的文件。

   const templatePath = path.join(__dirname, 'prompts', 'my.pmt'); console.log('Looking for prompt at:', templatePath); // 在终端检查这个路径是否正确

2. 检查工作目录：如果你使用相对路径（如./prompts/test.pmt），请确认 Node.js 进程的当前工作目录是什么。在项目根目录启动脚本和在子目录启动脚本，./的含义不同。
3. 检查文件扩展名：确保文件全名是my.pmt，而不是my.pmt.txt（Windows 默认隐藏已知扩展名可能导致此问题）。
4. 检查文件权限：确保运行 Node.js 进程的用户有读取该文件的权限。

7.2 变量未被替换

问题：渲染后的提示词中仍然包含{{variable}}占位符。

排查步骤：

1. 检查变量名拼写：确保模板文件中的变量名和传入loadPrompt的变量对象中的键名完全一致（包括大小写）。

   // 模板中是 {{userName}} // 代码中必须是 { userName: 'John' }，而不是 { username: 'John' }

2. 检查变量值：传入的变量值是否是undefined或null？如果是，它们可能不会被替换为空字符串，而是保留原样。dotpmt的内部实现决定了其行为，安全起见，建议在传入前处理。

   const safeVariables = {}; for (const [key, value] of Object.entries(rawVariables)) { safeVariables[key] = value !== undefined && value !== null ? value : ''; } const prompt = loadPrompt(templatePath, safeVariables);

3. 检查模板语法：确保没有多余的空格或特殊字符破坏了{{}}结构。例如{{ variable }}（内部有空格）可能无法被识别，这取决于dotpmt的具体实现。通常应使用{{variable}}。

7.3 处理多行文本和特殊字符

问题：当变量值包含多行文本、引号或反引号时，渲染后的提示词格式混乱，可能影响模型理解。

解决方案：

• 对于多行文本：如前所述，在模板中考虑用反引号（```）或 XML 标签（如<text>...</text>）包裹变量区域，明确指示边界。
• 对于 JSON 或代码：如果变量值是一段 JSON 或代码，在模板中将其放在代码块内。

  请分析以下 JSON 数据： ```json {{jsonData}}

• 转义问题：通常，现代 LLM 对提示词中的各种字符都有较好的鲁棒性。但如果遇到问题，可以在代码层面对变量值进行最小程度的转义（如将\替换为\\），但绝大多数情况下不需要。

7.4 性能与缓存考量

问题：每次调用loadPrompt都会读取文件系统，在高频调用场景下可能成为性能瓶颈。

解决方案：实现一个简单的内存缓存。下面是一个示例：

import { loadPrompt } from "dotpmt"; import fs from 'fs/promises'; const promptCache = new Map<string, string>(); // 缓存模板原始内容 async function loadPromptWithCache(templatePath: string, variables: Record<string, any>): Promise<string> { let templateContent = promptCache.get(templatePath); if (!templateContent) { // 缓存未命中，读取文件 templateContent = await fs.readFile(templatePath, 'utf-8'); promptCache.set(templatePath, templateContent); console.log(`Loaded and cached template: ${templatePath}`); } // 简单的变量替换（假设 dotpmt 的 loadPrompt 是同步的且我们已拿到内容） // 注意：这里需要重新实现或调用 dotpmt 的渲染核心。 // 如果 dotpmt 未暴露渲染函数，可以手动实现，或继续使用 loadPrompt 但缓存文件读取结果。 // 更简单的方法是缓存 loadPrompt 的结果（如果变量组合有限）。 } // 另一种更粗暴但有效的缓存：缓存渲染后的结果（仅当变量组合有限时） const renderCache = new Map<string, string>(); function getCacheKey(templatePath: string, variables: object) { return `${templatePath}:${JSON.stringify(variables)}`; } function loadPromptCached(templatePath: string, variables: Record<string, any>): string { const cacheKey = getCacheKey(templatePath, variables); if (renderCache.has(cacheKey)) { return renderCache.get(cacheKey)!; } const result = loadPrompt(templatePath, variables); renderCache.set(cacheKey, result); return result; }

注意事项：在开发环境下，你可能希望禁用缓存，以便实时看到对.pmt文件的修改。可以通过环境变量来控制缓存行为。

const useCache = process.env.NODE_ENV === 'production';

7.5 与现有配置管理系统的结合

问题：项目已经使用了dotenv管理环境变量，或者config库管理配置，如何与dotpmt共存？

解决方案：将它们视为不同层级的配置。环境变量（dotenv）管理密钥和端点等机密信息；应用配置（config）管理功能开关、超时时间等；dotpmt管理面向模型的“内容”配置。它们可以结合使用：

import { loadPrompt } from "dotpmt"; import config from 'config'; // 从应用配置中获取模板变量 const defaultTone = config.get('prompt.defaultTone'); // 从环境变量中获取模型相关配置 const modelName = process.env.LLM_MODEL; const prompt = loadPrompt("prompts/email.pmt", { userName: user.name, tone: user.customTone || defaultTone, // 用户自定义或默认 }); // 调用 LLM const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); await client.chat.completions.create({ model: modelName, messages: [{ role: 'user', content: prompt }], });

8. 超越基础：探索进阶模式与生态

当你熟练使用dotpmt的基本功能后，可能会思考如何扩展它来满足更复杂的需求。这里有一些思路。

8.1 模板组合与继承

有时，多个提示词共享一个公共的“头部”（比如系统指令）或“尾部”。你可以通过组合多个.pmt文件来实现。

实现一个简单的组合函数：

// utils/promptComposer.ts import { loadPrompt } from "dotpmt"; import path from "path"; export function composePrompt( templateNames: string[], // 例如 ['system-header', 'main-task', 'format-footer'] variables: Record<string, any> ): string { const promptsBaseDir = path.join(process.cwd(), 'prompts'); let fullPrompt = ''; for (const name of templateNames) { const templatePath = path.join(promptsBaseDir, `${name}.pmt`); const part = loadPrompt(templatePath, variables); // 注意：所有部分共享同一套变量 fullPrompt += part + '\n\n'; // 用空行连接各部分 } return fullPrompt.trim(); }

然后你可以创建system-header.pmt、main-task.pmt等文件，像搭积木一样组合它们。

8.2 集成提示词版本管理与审计

对于企业级应用，你可能需要知道生产环境中使用的是哪个版本的提示词。可以在渲染时注入元数据。

在模板中注入版本信息：创建一个_meta.pmt文件，但它不作为提示词部分，而是被代码读取。

// 读取提示词文件并计算哈希（作为版本标识） import crypto from 'crypto'; import fs from 'fs/promises'; async function getPromptVersion(templatePath: string): Promise<string> { const content = await fs.readFile(templatePath, 'utf-8'); return crypto.createHash('md5').update(content).digest('hex').substring(0, 8); // 取前8位作为简版哈希 } async function loadPromptWithVersion(templatePath: string, variables: object) { const [promptContent, version] = await Promise.all([ fs.readFile(templatePath, 'utf-8'), getPromptVersion(templatePath) ]); // 渲染提示词 const renderedPrompt = renderTemplate(promptContent, variables); // 假设有 renderTemplate 函数 // 将版本信息作为注释附加在最后（不影响模型，但便于日志记录） const promptWithVersion = `${renderedPrompt}\n\n<!-- Prompt Version: ${version} -->`; return { content: promptWithVersion, version: version }; }

这样，在发送给模型的提示词末尾会有一个 HTML 注释记录版本，同时函数也返回版本号，可以记录在日志或数据库中，便于追踪和回滚。

8.3 探索社区与替代方案

dotpmt以其简单性取胜。如果你发现需要更强大的功能（如条件逻辑、循环、过滤器、部分模板等），可以了解其他更成熟的模板引擎或专门的提示词管理工具：

• 模板引擎：Handlebars.js、EJS、Nunjucks。它们功能强大，但可能过于复杂，且需要小心避免在提示词中引入非预期的输出。
• 专用提示词管理平台：对于大型团队，可以考虑PromptHub、Humanloop等 SaaS 平台，它们提供了可视化编辑、版本控制、A/B 测试和分析功能。
• LangChain 等框架的提示词工具：如果你已经在使用 LangChain，它内置了PromptTemplate和从文件加载提示词的功能，与dotpmt理念类似但更集成化。

选择哪种工具，取决于你的项目规模、团队协作需求和复杂度要求。对于大多数中小型项目和个人开发者而言，dotpmt的简单直接往往是最高效的选择。

经过以上几个环节的拆解和实践，你应该已经能够将dotpmt娴熟地应用到自己的 AI 项目中了。它的价值不在于提供了多么炫酷的功能，而在于它精准地切中了一个普遍存在的痛点，并用一种近乎零成本的方式解决了它。这种“小而美”的工具，正是工程实践中提升幸福感的关键。我个人习惯在项目初期就引入dotpmt，从一开始就建立清晰的内容与代码的边界，这为后续的迭代和维护铺平了道路。