最近在 Hacker News 上看到一个很有意思的项目定位WeaveMark一个面向可复用提示词的规范语言specification language for reusable prompts。这句话看起来简单但背后的判断很犀利提示词工程今天最大的问题不是写不出好提示词而是写出来的提示词没法复用、没法维护、没法协作。大多数团队做 LLM 应用提示词还是以两种形态存在——聊天记录里的纯文本以及脚本里硬编码的字符串。改一版需求就要重新复制粘贴换个模型又要重新调一遍。这篇文章想讲清楚三件事提示词为什么需要一种规范语言而不是更聪明的模板引擎WeaveMark 这类项目试图从哪些维度解决复用问题以及你在自己的项目里怎样借鉴这种思路把提示词当成正式的工程制品来管理。文章中的示例结构用于演示设计思路具体字段和 API 以项目正式文档为准。1. 这篇文章真正要解决的问题先看一个最常见的场景。你负责给团队做一个代码评审助手第一次写提示词花了半小时效果不错。接着产品经理说要支持按前端、后端、数据脚本分场景评审然后另一个团队说他们也要用这个评审助手但模型从 A 换成 B再然后新人接手时问这个提示词为什么这么写哪些词不能动怎么验证改了之后效果没变差这就是提示词工程的真实困境不是写不出来而是写出来之后无法被组织、复用和演进。WeaveMark 的切口选得比较准它把提示词问题上升到了规范语言层面。意思是说提示词本身应该像 XML、YAML、OpenAPI 那样有结构、有约束、有版本、有组合规则而不是一段躺在文档里的自然语言文本。从工程视角看提示词本质上是应用的一部分输入逻辑。一段没有结构的 prompt等于一段没有类型、没有注释、没有回归测试的代码。你今天能调通不代表下个月还能调通你能调通不代表同事换一个模型后还能调通。把提示词变成一种可描述的规范本质上是在为 LLM 应用补上工程化欠账。什么样的人最应该关注这类项目正在做 LLM 应用开发的工程师会遇到提示词版本混乱、更换模型后效果漂移的问题。有一定规模的 AI 团队需要让多个成员协作维护提示词而不是每个人私藏一套。做 AI 平台和工具链的同学提示词规范是提示词即代码这条路上的底层基础设施。如果你只是单个脚本里用一次 prompt这篇文章里的建议可以按需借鉴不必全部照搬。2. 先理解规范语言是什么意思规范语言specification language不是模板引擎也不是配置文件格式它比这两者更接近契约。打个比方普通提示词像一张便签上面写着帮我把这段代码优化一下。模板提示词像一份填空问卷里面挖好了空每次往里填东西。而规范语言像一份合同它不仅要写清楚要做什么还要写清楚输入是什么、输出长什么样、在什么条件下生效、由哪个模型执行、如何验证是否合格。传统软件开发里大家已经习惯用 OpenAPI 描述接口契约用 JSON Schema 描述数据结构用 Protocol Buffers 描述跨语言消息格式。这些规范语言解决的共同问题是让机器可解析、让人类可审查、让工具可校验。提示词规范语言要做的是把这套思路平移到提示词上。WeaveMark 从项目命名就能看出设计取向。Mark 有标记、标注的含义Weave 则暗示组合与编织。合起来看它强调的不仅是把提示词写成结构化文件更是让提示词能够像模块一样被引用、组合、叠加。这比单纯的prompt 模板高一个抽象层级。需要区分几个容易混淆的概念概念典型形态解决的问题局限普通提示词一段自然语言文本完成单次对话任务无法复用、无法校验、无法版本化Prompt 模板带占位符的字符串动态拼接变量没有约束、没有组合能力、容易失控Prompt 规范语言结构化的声明式文件描述提示词的结构、输入、输出、行为需要学习成本需要配套工具链理解这层区别之后再回头看 WeaveMark 的定位就清晰了它想做的不是更好用的模板库而是提示词的描述标准。这个判断对 AI 工程化的影响比表面上看起来要大得多。3. 普通提示词的三个典型痛点为什么提示词复用这么难表面看是大家懒得整理实际上有三个结构性原因。3.1 没有结构机器无法解析普通提示词是一段自然语言模型能读懂但程序读不懂。程序无法判断这段提示词的输入变量有哪些、输出格式是什么、适用模型是什么。结果就是任何自动化都无从下手无法自动校验、无法自动测试、无法自动适配不同模型。比如你有一段提示词你是一个资深 Java 工程师请审查下面的代码……它看起来挺清楚但程序不知道下面的代码从哪里开始、到哪里结束也不知道你期待的输出是 JSON 还是纯文本。这些信息全部靠人眼约定一旦换人、换场景约定就失效了。3.2 没有版本改了就回不去提示词是 AI 应用里改动最频繁、却又最没有版本意识的部分。需求变一下提示词改几个字效果可能天差地别。但因为没有版本管理你根本说不清上个月效果好的那个版本到底是什么内容。更麻烦的是提示词的效果往往依赖模型的版本和行为。同一个提示词GPT 系模型和开源模型的表现可能完全不同。普通提示词把这些信息全部丢失了导致排查问题时只能靠猜。3.3 没有组合每个场景重新造轮子一个稍微复杂一点的 AI 应用往往需要多个提示词协同先总结需求再生成代码再写测试用例最后做评审。这些步骤之间有依赖关系也有公共要素。但在普通写法里每个提示词都是独立的重写公共部分只能靠复制粘贴。复制粘贴带来的问题做过传统开发的人都懂修了一个 bug忘了同步另外三处换了一个术语文档里改了提示词里没改。规范语言的核心价值之一就是把公共部分抽出来通过引用和组合复用而不是复制。4. WeaveMark 的设计思路提示词从文本变为契约从项目标题和公开定位看WeaveMark 的核心理念可以概括为一句话把提示词当作一种可描述、可校验、可组合的工程制品。围绕这个理念一个完整的提示词规范通常需要包含以下几类信息。4.1 元数据元数据描述提示词本身包括名称、版本、作者、用途说明、适用的模型范围等。有了元数据提示词才能被检索、被版本化、被审计。4.2 输入契约输入契约声明这个提示词需要哪些参数每个参数的类型、是否必填、默认值、约束条件。这相当于函数签名。有了输入契约调用方不需要阅读提示词全文也能知道怎么调用它。4.3 输出契约输出契约声明模型应该返回什么格式的结果比如 JSON 对象、Markdown 文本、枚举值以及关键字段的语义。这直接缓解了 LLM 输出不稳定、解析困难的老大难问题。4.4 模板内容模板内容是提示词的主体但和普通模板不同规范语言中的模板内容通常引用输入契约中声明的变量而不是随意拼接。变量从哪里来、如何转义、如何防止注入都有明确的规则。4.5 行为配置与测试用例行为配置包括温度、最大 token、top_p 等采样参数以及目标模型标识。测试用例则是对什么样的输入应该得到什么样的输出的结构化描述。这是提示词工程里最容易被忽略、但价值最高的一部分。把这些要素放在一个文件里提示词就完成了从文本到契约的转变。程序可以解析它CI 可以测试它团队可以评审它模型可以按它执行。这正是specification language for reusable prompts这句话的完整含义。5. 一个最小可复用提示词规范示例下面用 YAML 演示一个符合上述设计思路的提示词规范。注意这是为了讲清概念而设计的示范结构不是 WeaveMark 的官方语法。实际字段名以项目文档为准但核心思想是一致的。# 文件路径prompts/code-review.yaml name: code-review version: 1.0.0 description: 对指定代码片段生成语言无关的评审意见 input: - name: code_snippet type: string required: true description: 待评审的代码片段 - name: language type: string required: false default: auto description: 代码语言auto 表示自动识别 - name: severity type: enum values: [blocker, major, minor] default: major description: 最低报告级别 output: format: json schema: type: array items: type: object properties: severity: { type: string } line: { type: integer } message: { type: string } suggestion: { type: string } required: [severity, message] model: provider: openai-compatible name: gpt-4o-mini temperature: 0.3 max_tokens: 1024 template: | 你是一名严谨的代码评审专家。 请审查用户提供的代码输出 JSON 数组。 每个元素包含 severity、line、message、suggestion 四个字段。 只报告级别不低于 {{ severity }} 的问题。 如果代码语言为 auto请先识别语言再评审。 代码片段 {{ language }} {{ code_snippet }}tests:name: 检测空指针风险 input: code_snippet: String s null; System.out.println(s.length()); language: java expect:severity: blocker message_contains: 空指针这个结构解决了几件事。第一调用方不需要读模板全文只要按照 input 契约传参。第二输出契约明确要求 JSON 数组调用方可以直接反序列化不用写各种正则去猜模型输出。第三模板中的变量来自 input 声明而不是随意拼接从机制上减少了变量错漏。第四tests 字段让提示词是否还正常变成了可以自动检查的问题。 再看一个稍复杂的组合场景。假设你想复用上面的 code-review同时加一个先解释代码逻辑再评审的前置步骤可以拆成两个规范文件再用引用方式组合 yaml # 文件路径prompts/code-review-with-explanation.yaml name: code-review-with-explanation version: 1.0.0 description: 先解释代码逻辑再进行评审 uses: - prompts/explain-code.yaml - prompts/code-review.yaml input: - name: code_snippet type: string required: true pipeline: - step: explain spec: prompts/explain-code.yaml with: code_snippet: {{ input.code_snippet }} - step: review spec: prompts/code-review.yaml with: code_snippet: {{ input.code_snippet }} severity: major这种组合方式最大的价值在于两个基础规范分别维护、分别测试、分别升级组合层只负责编排。某个规范升级了所有引用它的组合层自动受益。这就是可复用从口号变成机制的过程。6. 如何验证提示词规范的运行效果规范语言如果只是写着好看价值有限。真正让它发挥作用的是自动化验证也就是把提示词测试纳入 CI/CD。这里给出一个概念层面的验证流程。6.1 单元级验证单条提示词与测试用例对每个规范文件运行 tests 中定义的用例。把 input 传入模板调用模型获取输出然后检查输出是否符合 expect 中的断言。断言可以分几层结构断言输出能否被 JSON 解析字段是否齐全。内容断言输出中是否包含关键词或者通过一个判别模型打分。行为断言给定同样的输入输出在不同模型版本下的漂移程度。{ test_results: [ { spec: prompts/code-review.yaml, case: 检测空指针风险, passed: true, duration_ms: 830, output: [ { severity: blocker, line: 1, message: 空指针风险, suggestion: 增加判空 } ] } ] }6.2 集成级验证组合链路是否通对于有 pipeline 的组合规范需要验证步骤之间的输出能否被下一步正确消费。比如 explain-code 的输出格式变了下游 code-review 可能解析失败。集成测试专门抓这类问题。6.3 回归验证改提示词之前先跑历史用例这是提示词工程里最值得养成的好习惯。每次修改提示词先跑一遍已积累的测试用例集对比输出差异。没有回归测试的提示词改动本质上是在裸奔。判断验证是否成功不只看有没有输出还要看输出是否可用。一个快速判断标准经过结构断言和内容断言的全部用例通过且没有新增失败用例才算通过验证。如果失败第一步应该检查模板渲染后的完整 prompt确认变量是否正确替换、有没有格式错乱。7. 常见问题与排查思路在把提示词往规范化和复用的方向推进时下面几个问题几乎一定会遇到。问题现象可能原因排查方式解决方案模型输出不符合输出契约模板里对输出格式的约束不够强查看模型返回的原始内容确认是格式问题还是内容问题在模板中补充输出示例必要时加入只输出 JSON 不解释等约束做二次解析修复同一个提示词换模型后效果明显变差不同模型对指令的遵循能力不同对比两个模型在相同测试用例下的输出在规范中声明适用模型范围按模型维护独立配置设置兼容测试变量没有正确渲染模板使用了未声明的变量检查 input 声明与模板占位符是否一致统一变量命名规则引入模板渲染校验工具组合链路中某一步输出异常上游输出格式变化导致下游解析失败查看 pipeline 每一步的输入输出日志为每步输出增加结构校验增加步骤间兼容测试提示词被注入用户输入干扰了系统指令模板直接拼接了未过滤的用户内容检查渲染结果中是否存在用户输入覆盖指令的情况对用户输入做分隔标记限制其长度必要时对输入做转义处理团队协作时同一个规范出现多份不同修改没有版本管理检查文件变更历史和责任人将规范文件纳入 Git 管理采用 PR 评审流程这里特别强调一个容易被忽略的点提示词注入和 SQL 注入是同类问题。当你的提示词包含用户输入时必须像处理外部输入一样处理它。规范语言的价值在这里体现得很明显——如果输入契约明确区分了系统指令和用户数据注入风险至少能被识别出来而不是悄悄混在模板里。8. 最佳实践与工程建议把提示词工程化不是为了增加流程负担而是为了减少不可控。下面几条建议来自日常实践按优先级排列。8.1 先定输入输出契约再写模板很多人的习惯是先把提示词写顺再补结构。正确顺序应该反过来先想清楚这个提示词需要哪些输入参数、必须返回什么格式再设计模板。契约先行模板只是契约的载体。8.2 命名与目录规范把提示词当代码来管理就要有命名规范。建议格式领域-场景-用途.yaml例如code-review.yaml、docs-release-note.yaml。目录按业务域组织避免所有提示词堆在一个文件夹里。8.3 为提示词建立测试资产库每解决一个真实问题就把输入和期望输出沉淀为一个测试用例。三个月后这个资产库比提示词本身更值钱。因为它是团队对什么算好输出的共同认知。8.4 模型相关配置独立管理模型名、温度、max_tokens 这些参数不要和模板强耦合。模板负责说什么配置负责用什么模型、怎么采样。这样换模型时不需要重写提示词逻辑只需切换配置。8.5 安全与权限边界涉及生产环境的提示词变更要走和代码变更一样的评审流程。包含敏感内部信息的提示词要控制仓库访问权限。用户输入必须按不可信数据处理必要时要过滤或截断。8.6 不要过度设计如果你的项目只有两三个提示词强行引入一套完整规范体系反而增加负担。从最小结构开始一个 YAML 文件、一段渲染函数、一个测试脚本积累到能够感受到复用收益时再逐步扩展。9. 总结与后续学习方向WeaveMark 这类项目的出现反映了一个技术趋势提示词正在从一次性对话文本进化为需要规范管理的工程制品。它把复用问题从人靠自觉变成靠结构约束这比任何写作技巧都更根本。如果你想沿着这个方向深入建议按以下路径实践第一步挑一个常用的提示词改写成包含元数据、输入契约、输出契约的结构化文件。第二步为它写两条测试用例覆盖正常输入和边界输入。第三步把结构文件、渲染脚本和测试脚本纳入 Git。第四步当你发现某个提示词被第二个项目复用时再做抽取和组合。提示词工程的下一个阶段大概率不是比拼谁写得更花哨而是比拼谁的提示词能被团队稳定、安全、可度量地维护。从这个角度看规范语言是一个值得提前布局的方向。