当提示词从“输入框里的一句话”变成“系统里的一等公民”时所有做 LLM 应用的人都会撞到同一个问题这段提示词该怎么存放、怎么复用、怎么验证以前我们写提示词是“写完就丢”现在它却像一个需要长期维护的工程资产——改一次、坏一处、找半天重构一次提示词就像给老系统擦屁股四处打补丁。WeaveMark 是一个值得关注的答案。它在 Hacker News 上以 Show HN 的形式公开定位是 a specification language for reusable prompts也就是一种面向可复用提示词的规范语言。这句话的信息量很大它不只是又一个“提示词模板工具”而是试图把提示词当成一种可以被定义、组合、测试和版本化的结构化资产。这个思路一旦成立提示词管理就能从“文本复制粘贴”走向“代码级工程化”。这篇文章会先拆解规范语言与普通提示词模板之间的本质差异再梳理这类语言的核心概念然后用一个演示性示例说明如何定义、组合和验证可复用提示词最后给出项目接入流程、常见问题与工程建议。如果你正在做 Agent 应用或者被提示词版本问题折磨过这篇内容值得收藏后慢慢看。1. 我们遇到的问题提示词开始变成“包袱”先看一个真实场景。你的团队做了一个客服机器人系统提示词写在代码里维护在一个 200 行的 prompt 变量中。某天产品经理说“回答要更简洁一些”你随手改了末尾的一句话然后客服群里立刻反馈“机器人开始瞎编了”。你定位问题时才发现这段提示词服务于 3 个不同的业务分支一个分支改了措辞其他分支的指令全部受到影响。这就是提示词工程化的典型痛点。我把它们归为三类第一不可复用。提示词通常和具体业务代码耦合在一起同一个“中文客服语气”或“输出 JSON 格式”的指令在十几个文件里各写了一遍改动时只能全局搜索逐一替换。第二不可验证。改了提示词之后只能靠人工在对话框里跑几个例子没人知道哪个分支的输出会发生变化也没有自动化的回归手段。第三不可追踪。完全不知道当前线上跑的是哪个版本的提示词某次 Prompt 修改导致效果变差之后想回滚都不知道该回到哪一行。这三个问题单独看都能忍但它们叠加在一起就会让 LLM 应用从“开发完成”进入“维护地狱”。以往我们处理代码依赖、配置管理和接口契约已经积累了成熟的工程方法现在轮到提示词了却还停留在文本时代。WeaveMark 这种规范语言出现的背景正是这个矛盾。2. 基础概念规范语言到底是什么规范语言Specification Language听起来很高端但它并不是一个新概念。SQL 是一种规范语言它描述“查询什么数据”而不是“如何遍历每一行”正则表达式也是一种小型的规范语言它描述“字符串应该长什么样”而不是“用 if/else 怎么判断”。它们都有一个共同特点用专门设计的语法把人的意图表达成机器可解析、可校验、可执行的结构。WeaveMark 按这个思路处理提示词。它不是把你写的 prompt 原文直接存成字符串而是定义一套语法用来描述一个提示词单元的组成它是什么角色它接受哪些变量它输出什么格式它依赖哪些其他提示词单元它有哪些预期的测试用例。普通提示词模板做的是“字符串拼接”规范语言做的是“结构化定义”。举个例子传统模板是这么写的prompt f你是一个{role}请用{style}风格回答{task}。这样的模板能解决一部分复用问题但它没有任何校验能力。如果把role拼错或者task为空模板也不会知道。更麻烦的是当多个模板嵌套在一起时变量名冲突、上下文覆盖、输出格式被其他指令污染这些问题都只能在运行时暴露而且暴露方式往往是“输出莫名其妙”。规范语言则主张提示词单元本身要带契约。它声明“我需要一个 role 变量类型是字符串取值应该来自枚举”声明“这个单元只负责规定回复格式不负责生成业务内容”声明“当输入这类任务时输出必须符合 JSON Schema”。有了这些契约提示词就能被独立测试也能被组合进更大的系统。下面用一个表格做对比维度普通 Prompt 模板规范语言以 WeaveMark 思路为例基本单位一段字符串带有结构和元数据的提示词单元复用方式变量替换、复制粘贴声明式引用、组合校验能力基本没有变量校验、格式校验、测试用例可测试性依赖人工观察可按单元自动测试版本管理整段文本 diff按单元独立追踪组合安全性容易互相污染通过命名空间和契约隔离这张表想说明一个判断规范语言的价值不是让写提示词更简单而是让提示词系统变得更可维护。3. 为什么提示词需要“可复用”的规范语言只说“提示词乱”还不够关键是要理解为什么规范语言能解决问题尤其是它和普通重构之间的区别。一个成熟的 LLM 应用里提示词通常不是一段独立的文本而是多层结构的组合。以 Agent 应用为例系统层提示词定义 Agent 的总体行为方式例如“你是企业级客服助手回答要专业、简洁、不猜测”。任务层提示词定义具体任务怎么做例如“根据用户订单号查询物流信息”。格式层提示词定义输出的结构例如“必须输出 JSON包含 status、message、data 三个字段”。安全层提示词定义边界例如“如果用户请求涉及其他用户隐私应拒绝并给出原因”。这些层次的提示词会以不同方式组合。最笨的方式是写一个巨大的模板函数把所有逻辑用 if/else 串起来规范语言的方式是让每个层次成为独立的提示词单元然后声明它们之间的关系。这样就有了复用一套“JSON 输出格式单元”可以被所有任务复用一套“拒绝回答策略”可以被所有业务分支复用。我理解的“可复用”至少有三个层次。第一个层次是内容的复用同一个提示词段落不需要重复出现。第二个层次是行为的复用一个已经验证过输出稳定的提示词单元可以固定下来不再被其他修改干扰。第三个层次是流程的复用测试用例、验证规则和提示词单元绑定提示词改了测试集不会丢。这种设计背后的思考是提示词正在变成软件的逻辑组成部分。既然是逻辑就应该像函数一样有输入、输出、边界和依赖而不是像字符串一样只能整体替换。规范语言给了提示词一个“形状”没有这个形状复用和测试就无从谈起。4. 核心概念拆解一个可复用提示词单元由什么组成要理解 WeaveMark 这类规范语言可以把握五个核心概念。这些概念不一定每个都出现在 WeaveMark 的最终语法里但它们是此类工具普遍要处理的问题。4.1 提示词单元提示词单元是规范语言的最小可复用单位。它描述一段完整提示词的各个方面。在实际中它可能对应一个角色定义、一段输出格式要求、一个安全边界规则或一个任务模板。一个单元通常有唯一标识符、类型、内容模板和元数据。标识符用来引用类型告诉工具这段提示词适合放在哪个层级内容模板是真正送进模型的文本元数据记录作者、版本、适用模型、更新日期等。4.2 变量与上下文声明变量是提示词动态化的关键。规范语言会把变量定义显式化包括变量名、类型、是否必填、默认值、取值范围等。这样渲染提示词之前就能检查变量是否完整避免运行时拼接出残缺的指令。变量还需要区分来源。有些变量来自用户输入有些来自系统内部状态有些来自其他提示词单元的输出。不同来源的变量在安全和优先级上应该被不同对待。4.3 组合与引用一个单元可以引用其他单元这解决的是提示词模块化的问题。组合有两种常见方式串联和嵌套。串联是“先讲角色再讲任务再讲格式”嵌套是“一个输出格式单元内部包含多个字段级说明”。与代码一样组合也会产生命名冲突。所以规范语言通常需要命名空间或作用域的设计避免两个单元定义了同名变量而互相覆盖。4.4 验证器与测试用例这是规范语言与普通模板最大的分水岭。一个可复用的提示词单元不应该只是“文本”它还应该包含如何验证自身正确性的信息。例如给定一组输入这个单元应该触发什么输出模式输出必须包含哪些字段哪些输出行为是禁止的。有了验证器提示词修改就可以纳入自动化测试。你改了一个提示词单元运行测试如果它导致 20 个用例中的 3 个输出格式不合法就能在发布前发现而不是上线后等用户投诉。4.5 元数据与版本提示词环境里不同模型对指令的敏感度不同同一个提示词在 GPT-4 和开源模型上的表现可能差异很大。所以单元需要记录它针对哪个模型版本编写、预期温度参数、历史变更原因等元数据。版本管理解决的是“改坏了怎么办”的问题。当多个单元被组合时每次发布的完整提示词都应该有一个可追溯的版本快照这样线上出问题才能快速回滚。5. 演示示例用规范语言定义可复用提示词说明一下WeaveMark 的完整语法细节必须以其项目官方文档为准下面这个示例的目的是用一种贴近规范语言一般设计思路的简化格式演示“定义、组合、验证”这三个关键动作长什么样。请不要把它当作 WeaveMark 的真实官方语法。假设我们要构建一个“数据分析助手”其中有一个提示词单元专门负责“把用户问题转换为 SQL”另一个单元负责“输出结果的格式约束”。先看第一个提示词单元的定义# prompts/sql_translator.yaml id: sql_translator type: task model: default description: 将用户自然语言问题转换为可执行 SQL variables: question: type: string required: true description: 用户提出的业务问题 schema_info: type: string required: true description: 数据库表结构与关系说明 dialect: type: string required: false default: sqlite enum: [sqlite, mysql, postgresql] content: | 你是数据库专家请根据以下数据库结构生成 SQL 查询。 数据库结构 {{ schema_info }} 用户问题{{ question }} 目标方言{{ dialect }} 请只返回 SQL 语句不要任何解释。 tests: - name: 查询订单数 variables: question: 每个城市有多少订单 schema_info: orders(id, city, amount) assert_output: contains: [SELECT, FROM orders] - name: 禁止解释 variables: question: 统计总金额 schema_info: orders(id, city, amount) assert_output: not_contains: [SELECT, FROM orders]这个单元说明了几个关键能力变量被显式声明question和schema_info必填dialect可选且有默认值和枚举约束内容模板使用双大括号引用变量模板可读性更好且变量来源一目了然每个单元自带测试用例测试可以校验输出“包含什么”和“不包含什么”。再看第二个单元它只负责输出格式# prompts/json_response.yaml id: json_response type: format content: | 你的输出必须是合法 JSON结构如下 { sql: 生成的 SQL 语句, risk_level: low | medium | high } 不要输出 markdown 代码块标记不要输出额外文字。两个单元各自独立维护。接着在另一个文件里组合它们形成一个完整任务# prompts/sql_answer.yaml id: sql_answer type: task imports: - sql_translator - json_response variables: question: type: string required: true schema_info: type: string required: true content: | {{ sql_translator }} 生成 SQL 后请按照以下格式返回 {{ json_response }}从这段示例可以看到组合后并不是简单地把文本拼在一起而是把两个单元的变量约束、测试和变更历史一并带入。后续如果想修改“SQL 翻译策略”只需要编辑sql_translator.yaml相关应用都会感知到变化如果只想改输出格式则完全不需要动翻译逻辑本身。这种设计的关键收益是改动被隔离在了单个单元范围内。如果团队里不同人负责不同的提示词单元协作也会更顺畅。6. 在项目中落地规范语言的流程了解了概念和示例接下来看看实际项目中如何一步步落地。按我的经验不要上来就重写全部提示词而是走一套渐进式流程。6.1 阶段一盘点现有提示词先从代码仓库和配置中心里找出所有提示词按用途分类。分类维度可以是角色定义、任务指令、格式约束、安全策略、少量样本。这一步的核心产出是一张“提示词清单”记录每段提示词部署在哪个服务、由哪个版本控制、依赖哪些变量。很多团队做完这一步就发现了问题同一段“你是客服助手”的角色定义居然有 7 个副本且各有不同的微调版本。这就是规范化的第一批候选对象。6.2 阶段二抽象公共单元找出在多个场景中重复出现的提示词片段把它们抽成独立的提示词单元。优先抽取两类内容一是完全相同的静态文本如输出格式约束二是变化维度相对有限的角色设定如“客服助手”“代码审查员”“教学讲解员”。抽取之后给每个单元补上变量声明和测试用例。这个过程本质上是把“文档式提示词”重构为“代码式提示词单元”。6.3 阶段三接入加载与渲染在代码层面实现规范语言的加载器和渲染器。常规做法是加载所有.yaml或.json格式的提示词定义解析变量和导入关系在运行时通过模板引擎渲染成最终提示词文本。这个阶段要注意的是渲染逻辑必须保持简单不要在里面混入业务逻辑。复杂的条件判断应该放在规范语言的定义层而不是代码层。6.4 阶段四建立自动化回归利用提示词单元自带的测试用例把它们接入 CI/CD 流水线。每次修改提示词后执行测试集对比输出差异。从工程角度看这一步的意义是让“提示词变更”从“自由冒险”变成“有门禁的提交”。测试内容可以先从硬性规则开始比如“输出必须是合法 JSON”“不能包含敏感词”“必须包含指定字段”后续再逐步加入模型评估维度的测试。7. 实际场景案例三个值得复用的提示词单元为了让思路更具体我用三个场景说明可复用提示词单元在实际项目中的价值。7.1 Agent 任务分解场景Agent 应用通常有一个负责任务分解的系统提示词。不同 Agent 行动机不同但“将用户目标拆解为步骤”这段指令可以复用。定义任务分解单元后新的 Agent 只需要声明import: task_decomposer就能获得一致的拆分行为不需要重复调试同一段逻辑。这种单元的测试用例可以设计为给定一个复杂任务检查输出是否包含 “step 1”“step 2” 等结构标记或是否按预期维度拆分。7.2 自然语言转 SQL 场景前面示例中的sql_translator就是一个典型场景。在这个场景里不同的业务系统共享同一套 SQL 生成提示词但schema_info不同、dialect不同。通过变量复用团队只需要维护一份提示词单元就能服务多个数据域。这个场景的风险点主要在于 SQL 安全提示词单元中应该加入“禁止生成 DELETE 或 DROP 语句”这类约束并在测试用例中覆盖。7.3 统一的输出格式约束场景很多应用会要求模型以 JSON 格式输出但每次手写 JSON 约束很容易出现格式不一致。把“严格 JSON 输出”做成一个提示词单元并在单元里加入“不允许输出 markdown 代码块”等硬性规则就能在所有调用链路上复用。当模型升级导致 JSON 输出不稳定时只需要修改这一个单元并运行测试集确认各业务场景的兼容性而不是逐个改服务代码。8. 常见问题与排查思路我根据自己的实践和观察整理了一份常见问题清单。如果你在采用规范语言管理提示词时遇到问题可以从这张表开始排查。问题现象可能原因排查方式解决方案渲染后的提示词变量为空变量名拼写错误或未声明检查单元定义中的 variables 与实际引用统一变量命名使用校验器在渲染前检查必填项组合后的提示词互相干扰多个单元定义了同名变量检查导入链和命名空间使用更具体的变量前缀或强制命名空间隔离模型输出不再遵守格式约束格式单元被其他单元覆盖对比最近一次组合测试记录将格式约束放到提示词末尾并添加输出后置校验修改一个单元影响多个场景单元粒度太粗多个场景耦合查看单元引用关系图拆分更细粒度的单元再按场景组合提示词回滚后行为仍异常模型缓存或外部依赖未同步回滚检查线上版本快照每次发布保留完整提示词版本快照不只单独回滚单元测试用例通过但线上效果差测试数据与真实分布差距大对比测试样本和真实用户输入分布逐步引入真实流量样本扩充测试集这条排查路径的核心逻辑是先看渲染层再看组合层最后看模型层。绝大多数问题都能在渲染或组合层被规范语言提前拦截真正进入模型层的问题往往需要引入更完整的评测体系。9. 最佳实践与工程建议关于提示词规范语言的工程化落地我整理了几条比较实用的建议。9.1 提示词即代码必须纳入版本管理提示词单元应该与代码一起提交、一起评审、一起发布而不是放在某个关系数据库的字段里。版本管理不仅是为了回滚更是为了让人能看到提示词演化的历史理解每一次改动的原因。建议在每个提示词单元的元数据中增加changed_by、changed_reason字段写清楚为什么改。这比代码注释更重要因为提示词的语义变化往往不明显。9.2 单一事实来源同一个含义的角色设定或格式约束只应该在一个提示词单元里定义。团队里要明确“唯一的客服角色定义文件”是哪一个其他系统通过导入或引用获取而不是复制一份。这一点做不好规范化反而会增加维护负担——因为你多了一套需要同步的副本。9.3 先定契约再写内容定义一个提示词单元时先想清楚它的输入变量、输出约束和测试用例再写具体的内容文本。这种“契约优先”的顺序和 TDD 的思路类似能够避免提示词越写越随意。测试用例不需要一开始就追求数量但至少要覆盖正常情况、边界情况和禁止行为三类。9.4 注意组合顺序对模型的影响提示词组合的顺序并不是无所谓的。通常模型对指令的注意力会集中在后段因此“必须遵守的硬性规则”放在偏后位置更可靠而“角色背景信息”放在前面作为上下文铺垫。规范语言如果支持组合顺序的显式声明生产环境里要充分利用它。9.5 安全边界要显式声明提示词注入是一个真实风险。当提示词单元需要拼接用户输入时应该在单元级别声明“该部分是用户可控输入不参与系统指令解析”并在渲染层做必要的隔离或转义。不要依赖模型自己去判断哪些是用户输入、哪些是系统指令。9.6 建立评测闭环规范语言只解决“提示词能不能被测试”的问题真正提升效果还需要评测闭环。可以把提示词单元变更、测试集执行、模型输出评估三个阶段串成一条流程每次改动都能留下记录。这样提示词优化就不是凭感觉而是有数据支撑的迭代。10. 总结与后续学习方向WeaveMark 这类规范语言最值得借鉴的地方不是某段具体语法而是它把提示词从“文本素材”提升为“结构化工程资产”的思路。提示词单元、变量契约、组合机制、测试用例、版本元数据这几个能力组合起来才能让提示词管理真正跟上 LLM 应用的迭代速度。如果你对这个方向感兴趣下一步可以从这几件事开始第一梳理你手头项目里的提示词尝试把它拆成可复用的单元第二哪怕不引入完整工具先给每个提示词补上变量声明和测试用例第三关注 WeaveMark 项目的后续迭代看看它在语法设计和生态工具上怎么解决问题。做 LLM 应用开发提示词迟早要跨过“随手写写”的阶段。早一点把它当成代码来管理后面就能少一点“改一行坏一片”的狼狈。