技能介绍

要解决的问题

当提示词从 demo 走向生产，最常见的失控是：提示逻辑散落在各个 handler 里，用 f-string 或 + 拼接上下文，参数硬编码，变量命名随代码演进越来越随意。结果是改一个措辞要翻三个文件，同一段系统提示在三个服务里各有一份副本，出问题时只能靠日志里的对话记录回溯。

POML（Prompt Object Markup Language）的思路是把提示词从应用代码里拆出来，做成受版本控制的结构化资产：提示文本、数据绑定、样式、测试都收敛到声明式文件里。

技能如何工作

这个技能的核心是围绕 POML 的一整套工作流：

结构化标记：用类 HTML 语法书写提示词，通过 <Prompt>、<Data>、<Part> 这类语义组件组织内容，让提示词本身可读、可复用、可维护，而不是一大段裸文本。
数据组件：把外部变量（用户输入、检索结果、数据库字段）声明为数据组件，在渲染时注入，提示模板与数据源解耦。
模板与样式：通过模板机制复用公共片段，通过样式组件统一管理提示的输出格式与语气约束。
SDK 渲染：渲染交给官方 SDK，Node.js（JavaScript/TypeScript）和 Python 各有一套，可以接入常见的 LLM 框架和现有应用流程。另有实验性的 mini-poml-rs，面向没有 JavaScript 或 Python 解释器的环境。
VS Code 测试：通过编辑器扩展在编写阶段做交互式测试，需要事先配置好 LLM provider 的连接信息。

典型步骤是：把提示资产写成 .poml 文件并纳入源码仓库 → 用数据组件声明变量 → 通过 SDK 在应用中渲染 → 在 VS Code 里直接迭代测试。上游还有基于 Python + Angular 的聊天机器人示例（ai-chatbot-with-python-and-angular），演示了 POML 与 Langchain 框架配合的落地方式。

适用边界

适用：提示词逻辑复杂、需要在团队间共享、希望纳入 Git 评审与回归测试的项目。
不适用：一两句的临时提示，直接写在代码里成本更低，引入 POML 反而增加心智负担。
注意：mini-poml-rs 是实验性项目，生产环境渲染应优先走官方 Node.js / Python SDK；交互式测试依赖已配置的 LLM provider，未配置时只能在渲染层验证结构；引入 POML 意味着提示资产与代码要同步演进，团队需要约定好目录归属与变更流程。

文档与示例见官方文档站。