Prompt 不是即兴发挥结构化设计与版本化评测的工程化路径一、Prompt 作为生产工具的失控工程师每天都在写 Prompt。调试一次模型拼一段 prompt。换个场景又重写一段。存在聊天记录里下次找不到。Prompt 是生产工具但被当一次性消耗品。改一行效果变了没人知道为什么变好变坏。线上挂的 Prompt没人敢动怕回归。新旧 Prompt 谁更好靠试几次感觉判断。这种状态不可持续。LLM 应用越往生产走Prompt 越要可管理。结构化、版本化、可评测、可复用。和代码一样进仓库进 CI。把 Prompt 当代码才有质量基线可言。二、Prompt 的结构化与评测机制工程化的 Prompt不是一坨文本。是一组带语义的片段组合。角色。定义 LLM 扮演什么身份。角色影响输出风格与专业深度。上下文。提供任务背景与领域知识。上下文质量决定回答的针对性。约束。限定输出范围、长度、风格。约束不写LLM 容易跑题或啰嗦。示例。Few-shot 示例锚定输出格式。示例要选有代表性的边界样本。输出格式。结构化输出便于程序解析。JSON Schema 或固定字段。这五要素组合成 Prompt 模板。模板带版本号进版本库。每个版本对应一组评测用例。A/B 测试基于评测集跑评分对比版本优劣。评测用例本身也需评审避免测试集与 Prompt 同源。下面是 Prompt 工程化的数据流flowchart TD A[业务需求] -- B[拆解: 角色/上下文/约束/示例/输出格式] B -- C[模板 v1 落库] C -- D[评测用例集] D -- E[批量调用 LLM] E -- F[评分: 准确率/格式合规/延迟/成本] F -- G{对比基线} G --|优于基线| H[发布为新基线] G --|不及基线| I[回退 分析] style H fill:#e8f5e9 style I fill:#ffebee关键在评分那一步。没有评分就没有 A/B。评分要可量化、可复现、可对比。而非我感觉这版好。三、生产级实现下面用代码描述 Prompt 模板管理与评测工具。带版本管理、变量注入、批量评测。含错误处理与超时隔离。import json import time from dataclasses import dataclass, field from typing import Callable, Any dataclass class PromptTemplate: Prompt 模板五要素结构化。 版本号必须递增便于回归追溯。 没有版本号的模板不允许上线。 name: str version: str role: str context: str constraints: list[str] examples: list[dict] output_format: dict created_at: float field(default_factorytime.time) class PromptRegistry: 模板注册中心按 name 索引所有版本。 设计为内存字典真实系统接数据库或文件仓库。 每次注册做版本冲突检测避免覆盖历史。 def __init__(self) - None: self._store: dict[str, dict[str, PromptTemplate]] {} def register(self, tpl: PromptTemplate) - None: versions self._store.setdefault(tpl.name, {}) if tpl.version in versions: # 版本冲突直接抛出禁止静默覆盖 raise ValueError( f模板 {tpl.name} v{tpl.version} 已存在 ) versions[tpl.version] tpl def get(self, name: str, version: str latest) - PromptTemplate: if name not in self._store: raise KeyError(f模板 {name} 不存在) versions self._store[name] if version latest: # 按 semver 排序取最新 latest sorted(versions.keys())[-1] return versions[latest] return versions[version] def render(tpl: PromptTemplate, variables: dict) - str: 把模板与变量拼成最终 Prompt。 变量缺失时抛错避免悄悄产出残缺 prompt。 设计宁可失败不吞错误。 try: ctx tpl.context.format(**variables) except KeyError as e: raise KeyError(f缺少变量: {e}) from e examples_str json.dumps(tpl.examples, ensure_asciiFalse) constraints_str \n.join(f- {c} for c in tpl.constraints) # 拼装顺序固定角色 → 上下文 → 约束 → 示例 → 输出格式 return ( f# 角色\n{tpl.role}\n\n f# 上下文\n{ctx}\n\n f# 约束\n{constraints_str}\n\n f# 示例\n{examples_str}\n\n f# 输出格式\n{json.dumps(tpl.output_format, ensure_asciiFalse)} ) dataclass class EvalCase: 评测用例输入 期望输出 判定函数。 判定函数由业务自定义避免工具绑死标准。 inputs: dict expected: Any judge: Callable[[Any, Any], bool] dataclass class EvalReport: 评测报告通过率 失败用例。 失败用例必须保留用于回归分析。 total: int 0 passed: int 0 failures: list[dict] field(default_factorylist) avg_latency: float 0.0 def evaluate( tpl: PromptTemplate, cases: list[EvalCase], llm_call: Callable[[str], tuple[Any, float]], timeout: float 30.0, ) - EvalReport: 批量评测对每个用例渲染 调用 判定。 LLM 调用是慢且易失败的外部依赖必须隔离。 单用例失败不中断整体评测。 report EvalReport(totallen(cases)) latencies: list[float] [] for i, case in enumerate(cases): try: prompt render(tpl, case.inputs) output, latency llm_call(prompt) latencies.append(latency) if case.judge(output, case.expected): report.passed 1 else: report.failures.append({ case_index: i, inputs: case.inputs, expected: case.expected, actual: output, }) except Exception as e: # 异常用例单独标记便于区分失败与报错 report.failures.append({ case_index: i, error: str(e), }) report.avg_latency ( sum(latencies) / len(latencies) if latencies else 0.0 ) return report def ab_compare( registry: PromptRegistry, name: str, v_old: str, v_new: str, cases: list[EvalCase], llm_call: Callable[[str], tuple[Any, float]], ) - dict: A/B 对比旧版 vs 新版同评测集跑分。 只有新版显著优于旧版才允许替换基线。 显著由业务定义阈值工具只提供数据。 old evaluate(registry.get(name, v_old), cases, llm_call) new evaluate(registry.get(name, v_new), cases, llm_call) old_rate old.passed / max(old.total, 1) new_rate new.passed / max(new.total, 1) return { old_pass_rate: old_rate, new_pass_rate: new_rate, delta: new_rate - old_rate, old_latency: old.avg_latency, new_latency: new.avg_latency, } if __name__ __main__: registry PromptRegistry() tpl_v1 PromptTemplate( namesummarize, version1.0.0, role你是技术摘要助手, context对以下文章做摘要{article}, constraints[不超过 100 字, 保留关键技术点], examples[{input: 文章A, output: 摘要A}], output_format{summary: string}, ) registry.register(tpl_v1) print(render(registry.get(summarize), {article: 测试文章}))真实系统会接 LLM 网关与评测仓库。评分结果落库按时间序列回归对比。并把 Prompt 变更纳入 PR 评审禁止直接改线上。四、Prompt 不是即兴发挥的代价与边界Prompt 工程化有用但局限明显。Prompt 脆弱性。改一个字效果可能反转。版本管理能追溯但不能消除脆弱。必须配回归评测集兜底。评测集偏差。评测用例本身可能不代表真实分布。评测高分上线翻车。评测集要持续更新引入线上样本。版本爆炸。微调一次出个版本很快堆满仓库。要有淘汰机制旧版本定期归档。只保留有意义的版本序列。可迁移性下降。Prompt 强绑定某模型换模型就废。跨模型评测要单独跑不能直接套用。模型升级时Prompt 也要重新评测。评测成本。全量评测耗 token跑一遍可能上百元。应做抽样评测关键路径全量。并缓存历史结果避免重复跑。Prompt 工程化的几个被忽视的实践要点第一评测用例的期望输出本身要有评审流程否则用例错了再准的 Prompt 也是按错误标准对齐。第二A/B 评测要做统计显著性判断而不是看一两个百分点的差异就下结论小样本下波动很大。第三Prompt 模板里要显式标注模型适配版本因为同一个 Prompt 在不同模型上效果差很多模板与模型要绑定版本管理。最后线上 Prompt 的变更要走灰度而非全量替换先放量 10% 观察指标再决定是否全推避免一次糟糕的 Prompt 直接影响全部用户。五、总结Prompt 是 LLM 应用的核心生产工具必须工程化。机制上以五要素结构化、版本化注册、评测集打分、A/B 对比。工程上靠注册中心与评测报告形成闭环禁止线上手改。落地路线先做模板结构化与版本注册建立评测用例集实现批量评测与 A/B 对比接 CI 门禁强制评审最后做线上灰度发布。Prompt 当代码管LLM 应用才有可能上生产。
