尧图网页设计 
很多团队的第一个 AI 功能是这样上线的。某个开发者在聊天窗口里调了半天终于得到一个“效果不错”的 prompt。然后把它复制进代码。上线。一开始看起来还行。过几天问题来了换一批输入格式开始漂。 产品说语气不对。 运营改了两句话准确率掉了。 模型升级后旧 prompt 不稳定。 没有人知道上一次为什么这么写。 也没人知道现在能不能改。这不是模型问题这是工程纪律问题。Prompt 只要进入生产就不再是“写得顺手”的一段文字。它应该像代码一样被设计、测试、审查、版本化和回滚。yi一、Prompt 从技巧变成资产上一篇我们讲了 Prompt Engineering 的边界。它没死它只是变成了工程系统里的第一层契约。既然是契约就不能随手改。一个生产 prompt 至少会影响四件事。1.1 输出质量。它定义模型关注什么、忽略什么、怎么判断。1.2 系统接口。它决定下游拿到的是 JSON、Markdown、分类标签还是一段自然语言。1.3 业务风险。它可能决定退款、审核、风控、代码审查、客服回复这些动作的判断口径。1.4 成本和延迟。prompt 越长示例越多输入输出越复杂成本和延迟都会变。所以生产 prompt 不是文案它更像一个轻量级程序。区别只是它运行在模型里。二、模板不是把句子固定死Prompt template 的目标不是让每次调用一模一样。而是把稳定部分和变化部分分开。稳定部分包括角色 任务定义 业务规则 约束 输出格式 评测标准 失败处理变化部分包括用户输入 当前业务上下文 语言和语气 领域规则 输出长度 安全策略如果这两类混在一起prompt 就很难维护。比如这段你是客服。用户很着急说订单 12345 没到。 请用温和语气回复最多 100 字不要承诺退款。它能跑但不能扩展。更好的方式是模板化role 你是 {{brand}} 的客服助手。 /role task 根据用户问题生成一段客服回复。 /task policy {{support_policy}} /policy tone {{tone}} /tone constraints - 不承诺未确认的退款。 - 不编造物流状态。 - 如果信息不足要求用户补充订单号。 /constraints input {{user_message}} /input output_format 只输出给用户看的回复不要解释推理过程。 /output_format这不是为了好看而是为了让 prompt 可以被系统控制。三、变量要有类型和边界很多 prompt 模板失败不是模板本身错是变量没有边界。比如{{policy}} {{context}} {{examples}}这些变量看起来简单但风险很大。policy如果太长会覆盖任务重点。context如果混入用户原文可能带来 prompt injection。examples如果来自不同版本会制造冲突。所以变量也要像函数参数一样设计。我建议每个变量至少记录五件事name变量名 source来源 type类型 max_length最大长度 trust_level可信级别比如variables: user_message: source: request.body.message type: untrusted_text max_length: 4000 trust_level: external support_policy: source: internal.policy.v3 type: trusted_markdown max_length: 3000 trust_level: internal output_schema: source: schemas/support_reply.json type: json_schema max_length: 2000 trust_level: internal这一步会让你更早发现问题。比如用户输入不能和系统规则放在同一层。比如业务政策不能无限长。比如示例必须和输出 schema 同版本。Prompt 工程不是多写几句是把输入边界说清楚。四、Prompt package 目录结构如果一个 prompt 要进入生产我建议单独建包。一个最小目录可以这样prompts/ support-reply/ prompt.md variables.yaml schema.json examples/ good.jsonl edge.jsonl adversarial.jsonl evals/ golden.jsonl judge.md failures/ 2026-06-20-format-drift.md CHANGELOG.md README.md每个文件有明确职责。prompt.md放模板。variables.yaml定义变量来源和边界。schema.json定义机器可解析输出。examples/放 few-shot 或测试样本。evals/放回归评测集。failures/放线上失败案例。CHANGELOG.md记录每次改动原因。README.md写使用范围和禁用范围。这看起来比复制一段 prompt 麻烦但这是从个人技巧走向团队资产的最低成本。五、评测从 golden set 开始很多团队调 prompt只看三五个例子这不够。你至少需要一个 golden set不是很大。30 到 100 条就能开始。里面要覆盖正常输入 边界输入 空输入 格式破坏输入 恶意输入 业务冲突输入 历史失败输入每条样本要有期望结果期望结果不一定是完整答案可以是关键断言。比如{ id: refund_007, input: 我买错了能不能退订单已经签收 40 天。, assertions: { must_not_contain: [可以退款, 马上退款], must_contain: [超过, 政策, 人工], json_schema_valid: true } }Prompt eval 不一定一开始就做得很复杂。先能自动发现明显回归这就已经能救命。六、三类评测要分开Prompt 评测通常有三类。6.1 格式评测。这类最便宜也最应该自动化。JSON 是否可解析 字段是否齐全 枚举值是否合法 长度是否超限 是否包含禁止字段6.2 事实评测。判断输出是否基于输入证据。常见做法要求引用 evidence 检查 evidence 是否来自输入 事实类字段不允许无来源补全6.3 质量评测。这类最难。比如语气是否合适 建议是否可执行 分类是否符合业务语义 风险判断是否合理这里可以用 LLM judge也可以人工抽检但不要把所有东西都丢给 LLM judge。能用程序判的就用程序判。便宜、确定、可重复。LLM judge 适合语义评估不适合替代所有测试。七、版本管理不是只进 GitPrompt 当然要进 Git。但这还不够。你还要记录为什么改。一个好的 prompt changelog 应该写改动内容 改动原因 关联失败样本 评测结果变化 成本和延迟变化 回滚方式比如## 2026-06-20 v1.4.0 变更 - 增加 evidence 字段要求。 - 不确定时必须输出 unknown。 原因 - 线上出现 3 起无证据补全。 评测 - golden set 通过率91% - 96% - JSON parse failure2% - 0% - 平均输出 token8% 回滚 - 回退到 v1.3.2。这才是工程记录。不是“优化了 prompt”。“优化”这个词在生产系统里信息量太低。八、Prompt diff 要看语义普通文本 diff 能看出哪行变了。但prompt diff 还要看语义影响。比如尽量不要猜测。改成不要猜测。只差两个字。但行为影响很大。又比如输出简洁。改成输出不超过 80 字。这是从模糊偏好变成硬约束。所以 prompt review 不应该只看格式。要问是否改变了任务目标 是否改变了约束强度 是否引入了指令冲突 是否影响输出 schema 是否增加了上下文成本 是否需要新增评测样本这就是 prompt code review。九、失败样本库是最值钱的资产生产 prompt 最宝贵的不是成功样本是失败样本。因为失败样本暴露了真实边界。每次线上失败都应该沉淀成一条 case输入是什么 输出错在哪里 期望行为是什么 归因是哪一类 是 prompt 问题、context 问题、tool 问题还是 eval 问题 是否已加入回归评测如果失败样本没有进入 eval下一次改 prompt 很可能把旧问题重新放出来。这就是回归。AI系统也会回归只是它不像传统代码那样容易被编译器发现。十、什么时候不要继续调 prompt工程纪律也包括知道什么时候停。如果问题是模型没看到事实 业务规则来自多个系统 输出要经过真实校验 任务需要调用外部工具 需要长期记住用户状态 需要审批或回滚继续调 prompt 不是工程是拖延。这时候应该升级到下一层。事实缺失 - Context Engineering 需要行动 - Harness / Tools 需要稳定性 - Evals / Verification 需要多步推进 - State / Loop 需要安全边界 - Permissions / Human OversightPrompt 是入口契约不要让入口承担整栋楼的重量。十一、一张上线前检查表一个生产 prompt 上线前至少问这些问题[ ] prompt 是否在版本库里 [ ] 是否有明确 owner [ ] 是否定义了变量来源和边界 [ ] 是否有输出 schema [ ] 是否有 golden set [ ] 是否覆盖历史失败样本 [ ] 是否跑过回归评测 [ ] 是否记录了 changelog [ ] 是否能回滚到上一版 [ ] 是否知道什么时候不该靠 prompt 修这张表不复杂。但能拦住很多“看起来只是改一句话”的事故。Prompt Engineering 的成熟不是写出更长的 prompt。而是让 prompt 成为团队可以协作维护的工程资产。下一篇我们进入 Context Engineering。因为当 prompt 已经清楚但模型还是答错时问题通常不是“怎么说”。而是它每一步到底看到了什么参考资料Prompt engineering | OpenAI APIA practical guide to building agents | OpenAIPrompt engineering overview | AnthropicBuilding Effective AI Agents | AnthropicPromptfoo documentationOpenAI EvalsLangSmith evaluation docs参考文献提示词的工程纪律模板、变量、评测和版本管理 【学习笔记-AI工程化系列】提示词的工程纪律，模板、变量、评测和版本管理-3/16
很多团队的第一个 AI 功能是这样上线的。某个开发者在聊天窗口里调了半天终于得到一个“效果不错”的 prompt。然后把它复制进代码。上线。一开始看起来还行。过几天问题来了换一批输入格式开始漂。 产品说语气不对。 运营改了两句话准确率掉了。 模型升级后旧 prompt 不稳定。 没有人知道上一次为什么这么写。 也没人知道现在能不能改。这不是模型问题这是工程纪律问题。Prompt 只要进入生产就不再是“写得顺手”的一段文字。它应该像代码一样被设计、测试、审查、版本化和回滚。yi一、Prompt 从技巧变成资产上一篇我们讲了 Prompt Engineering 的边界。它没死它只是变成了工程系统里的第一层契约。既然是契约就不能随手改。一个生产 prompt 至少会影响四件事。1.1 输出质量。它定义模型关注什么、忽略什么、怎么判断。1.2 系统接口。它决定下游拿到的是 JSON、Markdown、分类标签还是一段自然语言。1.3 业务风险。它可能决定退款、审核、风控、代码审查、客服回复这些动作的判断口径。1.4 成本和延迟。prompt 越长示例越多输入输出越复杂成本和延迟都会变。所以生产 prompt 不是文案它更像一个轻量级程序。区别只是它运行在模型里。二、模板不是把句子固定死Prompt template 的目标不是让每次调用一模一样。而是把稳定部分和变化部分分开。稳定部分包括角色 任务定义 业务规则 约束 输出格式 评测标准 失败处理变化部分包括用户输入 当前业务上下文 语言和语气 领域规则 输出长度 安全策略如果这两类混在一起prompt 就很难维护。比如这段你是客服。用户很着急说订单 12345 没到。 请用温和语气回复最多 100 字不要承诺退款。它能跑但不能扩展。更好的方式是模板化role 你是 {{brand}} 的客服助手。 /role task 根据用户问题生成一段客服回复。 /task policy {{support_policy}} /policy tone {{tone}} /tone constraints - 不承诺未确认的退款。 - 不编造物流状态。 - 如果信息不足要求用户补充订单号。 /constraints input {{user_message}} /input output_format 只输出给用户看的回复不要解释推理过程。 /output_format这不是为了好看而是为了让 prompt 可以被系统控制。三、变量要有类型和边界很多 prompt 模板失败不是模板本身错是变量没有边界。比如{{policy}} {{context}} {{examples}}这些变量看起来简单但风险很大。policy如果太长会覆盖任务重点。context如果混入用户原文可能带来 prompt injection。examples如果来自不同版本会制造冲突。所以变量也要像函数参数一样设计。我建议每个变量至少记录五件事name变量名 source来源 type类型 max_length最大长度 trust_level可信级别比如variables: user_message: source: request.body.message type: untrusted_text max_length: 4000 trust_level: external support_policy: source: internal.policy.v3 type: trusted_markdown max_length: 3000 trust_level: internal output_schema: source: schemas/support_reply.json type: json_schema max_length: 2000 trust_level: internal这一步会让你更早发现问题。比如用户输入不能和系统规则放在同一层。比如业务政策不能无限长。比如示例必须和输出 schema 同版本。Prompt 工程不是多写几句是把输入边界说清楚。四、Prompt package 目录结构如果一个 prompt 要进入生产我建议单独建包。一个最小目录可以这样prompts/ support-reply/ prompt.md variables.yaml schema.json examples/ good.jsonl edge.jsonl adversarial.jsonl evals/ golden.jsonl judge.md failures/ 2026-06-20-format-drift.md CHANGELOG.md README.md每个文件有明确职责。prompt.md放模板。variables.yaml定义变量来源和边界。schema.json定义机器可解析输出。examples/放 few-shot 或测试样本。evals/放回归评测集。failures/放线上失败案例。CHANGELOG.md记录每次改动原因。README.md写使用范围和禁用范围。这看起来比复制一段 prompt 麻烦但这是从个人技巧走向团队资产的最低成本。五、评测从 golden set 开始很多团队调 prompt只看三五个例子这不够。你至少需要一个 golden set不是很大。30 到 100 条就能开始。里面要覆盖正常输入 边界输入 空输入 格式破坏输入 恶意输入 业务冲突输入 历史失败输入每条样本要有期望结果期望结果不一定是完整答案可以是关键断言。比如{ id: refund_007, input: 我买错了能不能退订单已经签收 40 天。, assertions: { must_not_contain: [可以退款, 马上退款], must_contain: [超过, 政策, 人工], json_schema_valid: true } }Prompt eval 不一定一开始就做得很复杂。先能自动发现明显回归这就已经能救命。六、三类评测要分开Prompt 评测通常有三类。6.1 格式评测。这类最便宜也最应该自动化。JSON 是否可解析 字段是否齐全 枚举值是否合法 长度是否超限 是否包含禁止字段6.2 事实评测。判断输出是否基于输入证据。常见做法要求引用 evidence 检查 evidence 是否来自输入 事实类字段不允许无来源补全6.3 质量评测。这类最难。比如语气是否合适 建议是否可执行 分类是否符合业务语义 风险判断是否合理这里可以用 LLM judge也可以人工抽检但不要把所有东西都丢给 LLM judge。能用程序判的就用程序判。便宜、确定、可重复。LLM judge 适合语义评估不适合替代所有测试。七、版本管理不是只进 GitPrompt 当然要进 Git。但这还不够。你还要记录为什么改。一个好的 prompt changelog 应该写改动内容 改动原因 关联失败样本 评测结果变化 成本和延迟变化 回滚方式比如## 2026-06-20 v1.4.0 变更 - 增加 evidence 字段要求。 - 不确定时必须输出 unknown。 原因 - 线上出现 3 起无证据补全。 评测 - golden set 通过率91% - 96% - JSON parse failure2% - 0% - 平均输出 token8% 回滚 - 回退到 v1.3.2。这才是工程记录。不是“优化了 prompt”。“优化”这个词在生产系统里信息量太低。八、Prompt diff 要看语义普通文本 diff 能看出哪行变了。但prompt diff 还要看语义影响。比如尽量不要猜测。改成不要猜测。只差两个字。但行为影响很大。又比如输出简洁。改成输出不超过 80 字。这是从模糊偏好变成硬约束。所以 prompt review 不应该只看格式。要问是否改变了任务目标 是否改变了约束强度 是否引入了指令冲突 是否影响输出 schema 是否增加了上下文成本 是否需要新增评测样本这就是 prompt code review。九、失败样本库是最值钱的资产生产 prompt 最宝贵的不是成功样本是失败样本。因为失败样本暴露了真实边界。每次线上失败都应该沉淀成一条 case输入是什么 输出错在哪里 期望行为是什么 归因是哪一类 是 prompt 问题、context 问题、tool 问题还是 eval 问题 是否已加入回归评测如果失败样本没有进入 eval下一次改 prompt 很可能把旧问题重新放出来。这就是回归。AI系统也会回归只是它不像传统代码那样容易被编译器发现。十、什么时候不要继续调 prompt工程纪律也包括知道什么时候停。如果问题是模型没看到事实 业务规则来自多个系统 输出要经过真实校验 任务需要调用外部工具 需要长期记住用户状态 需要审批或回滚继续调 prompt 不是工程是拖延。这时候应该升级到下一层。事实缺失 - Context Engineering 需要行动 - Harness / Tools 需要稳定性 - Evals / Verification 需要多步推进 - State / Loop 需要安全边界 - Permissions / Human OversightPrompt 是入口契约不要让入口承担整栋楼的重量。十一、一张上线前检查表一个生产 prompt 上线前至少问这些问题[ ] prompt 是否在版本库里 [ ] 是否有明确 owner [ ] 是否定义了变量来源和边界 [ ] 是否有输出 schema [ ] 是否有 golden set [ ] 是否覆盖历史失败样本 [ ] 是否跑过回归评测 [ ] 是否记录了 changelog [ ] 是否能回滚到上一版 [ ] 是否知道什么时候不该靠 prompt 修这张表不复杂。但能拦住很多“看起来只是改一句话”的事故。Prompt Engineering 的成熟不是写出更长的 prompt。而是让 prompt 成为团队可以协作维护的工程资产。下一篇我们进入 Context Engineering。因为当 prompt 已经清楚但模型还是答错时问题通常不是“怎么说”。而是它每一步到底看到了什么参考资料Prompt engineering | OpenAI APIA practical guide to building agents | OpenAIPrompt engineering overview | AnthropicBuilding Effective AI Agents | AnthropicPromptfoo documentationOpenAI EvalsLangSmith evaluation docs参考文献提示词的工程纪律模板、变量、评测和版本管理