企业官网建设流程全解析

当提示词从“输入框里的一句话”变成“系统里的一等公民”时，所有做 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”。有了这些契约，提示词就能被独立测试，也能被组合进更大的系统。

下面用一个表格做对比：

这张表想说明一个判断：规范语言的价值，不是让写提示词更简单，而是让提示词系统变得更可维护。

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. 常见问题与排查思路

我根据自己的实践和观察，整理了一份常见问题清单。如果你在采用规范语言管理提示词时遇到问题，可以从这张表开始排查。

这条排查路径的核心逻辑是：先看渲染层，再看组合层，最后看模型层。绝大多数问题都能在渲染或组合层被规范语言提前拦截，真正进入模型层的问题，往往需要引入更完整的评测体系。

9. 最佳实践与工程建议

关于提示词规范语言的工程化落地，我整理了几条比较实用的建议。

9.1 提示词即代码，必须纳入版本管理

提示词单元应该与代码一起提交、一起评审、一起发布，而不是放在某个关系数据库的字段里。版本管理不仅是为了回滚，更是为了让人能看到提示词演化的历史，理解每一次改动的原因。

建议在每个提示词单元的元数据中增加changed_by、changed_reason字段，写清楚为什么改。这比代码注释更重要，因为提示词的语义变化往往不明显。

9.2 单一事实来源

同一个含义的角色设定或格式约束，只应该在一个提示词单元里定义。团队里要明确“唯一的客服角色定义文件”是哪一个，其他系统通过导入或引用获取，而不是复制一份。

这一点做不好，规范化反而会增加维护负担——因为你多了一套需要同步的副本。

9.3 先定契约，再写内容

定义一个提示词单元时，先想清楚它的输入变量、输出约束和测试用例，再写具体的内容文本。这种“契约优先”的顺序和 TDD 的思路类似，能够避免提示词越写越随意。

测试用例不需要一开始就追求数量，但至少要覆盖正常情况、边界情况和禁止行为三类。

9.4 注意组合顺序对模型的影响

提示词组合的顺序并不是无所谓的。通常模型对指令的注意力会集中在后段，因此“必须遵守的硬性规则”放在偏后位置更可靠；而“角色背景信息”放在前面，作为上下文铺垫。规范语言如果支持组合顺序的显式声明，生产环境里要充分利用它。

9.5 安全边界要显式声明

提示词注入是一个真实风险。当提示词单元需要拼接用户输入时，应该在单元级别声明“该部分是用户可控输入，不参与系统指令解析”，并在渲染层做必要的隔离或转义。不要依赖模型自己去判断哪些是用户输入、哪些是系统指令。

9.6 建立评测闭环

规范语言只解决“提示词能不能被测试”的问题，真正提升效果还需要评测闭环。可以把提示词单元变更、测试集执行、模型输出评估三个阶段串成一条流程，每次改动都能留下记录。这样，提示词优化就不是凭感觉，而是有数据支撑的迭代。

10. 总结与后续学习方向

WeaveMark 这类规范语言最值得借鉴的地方，不是某段具体语法，而是它把提示词从“文本素材”提升为“结构化工程资产”的思路。提示词单元、变量契约、组合机制、测试用例、版本元数据，这几个能力组合起来，才能让提示词管理真正跟上 LLM 应用的迭代速度。

如果你对这个方向感兴趣，下一步可以从这几件事开始：第一，梳理你手头项目里的提示词，尝试把它拆成可复用的单元；第二，哪怕不引入完整工具，先给每个提示词补上变量声明和测试用例；第三，关注 WeaveMark 项目的后续迭代，看看它在语法设计和生态工具上怎么解决问题。

做 LLM 应用开发，提示词迟早要跨过“随手写写”的阶段。早一点把它当成代码来管理，后面就能少一点“改一行坏一片”的狼狈。