从提示词到系统：AI 产品真正的工程分水岭

从一次惊艳到长期可靠

很多 AI 产品在演示时让人眼前一亮，上线后却很快变得不可预测。问题通常不在模型不够强，而在于我们把一次生成误当成了一个完整产品。

一次演示只需要在理想输入下得到好答案；一个真实产品却要面对模糊请求、过期资料、不同权限、工具超时、模型波动、长会话和不可逆操作。两者之间的差距，不是再补一句提示词，而是一整套工程系统。

> 提示词定义一次意图，系统负责兑现长期承诺。

这里的“长期承诺”包括：在不同时间、不同用户和不同异常条件下，产品仍然知道该做什么、能做什么、何时停止，以及怎样证明结果可信。

提示词不是系统

提示词当然重要。它负责告诉模型角色、目标、约束、输出格式和判断标准。好的提示词可以显著改善一次调用的质量，但它无法独立解决以下问题：

用户现在是否有权执行这个动作。
检索到的资料是否最新、相关并且完整。
工具调用失败后应该重试还是换一条路径。
写操作是否已经成功，重试会不会产生重复数据。
长任务中断后从哪里恢复。
新版本是否让某一类真实任务悄悄退化。
最终答案是否有事实依据，而不只是语言流畅。

这些都属于系统责任。

把所有问题继续塞进提示词，常见结果是指令越来越长、规则互相冲突、Token 成本增加，真正的权限、状态和可靠性问题却依然没有解决。

提示词应该表达决策原则，程序应该强制执行安全边界，评估体系应该判断结果是否达标。三者不能互相代替。

从四层骨架到七层系统

原始的 Prompt、Context、Tools、Evals 四层，是理解 AI 产品的好骨架：

层次	负责什么	核心问题
Prompt	定义意图、约束与输出契约	要做什么？
Context	组装此刻相关的事实和状态	需要知道什么？
Tools	读取事实并执行现实动作	可以做什么？
Evals	发现错误、退化并形成反馈	做得好吗？

要进入生产环境，还需要补上三个经常被忽略的层次：

层次	负责什么	核心问题
Runtime	编排调用、超时、重试、取消和停止	怎样持续运行？
State	保存会话、进度、检查点和幂等信息	已经发生了什么？
Guardrails	管理权限、审批、沙箱和敏感数据	哪些动作被允许？

这七层共同构成一个可维护的 AI 系统。模型只是其中的推理与生成能力，不是整个产品。

Prompt：把意图写成任务契约

高质量 Prompt 不是堆砌形容词，而是把产品要求变成明确契约。

一个实用的任务契约通常包含：

目标：最终要交付什么。
背景：模型理解任务必须知道的领域信息。
约束：不能违反的规则和范围。
授权：本次请求允许读取、修改或发布到什么程度。
成功标准：什么证据能够证明任务完成。
输出格式：用户或下游程序怎样消费结果。
求助条件：什么情况下必须停止并请求用户决定。

例如，“分析这个故障”与“定位过去一小时支付失败的主要原因，只读诊断，不修改线上配置，并给出日志和指标证据”之间，差别不是文风，而是任务边界是否可执行。

提示词也要保持精简。重复规则、相互冲突的示例和无关工具说明会稀释真正重要的信息。规则应该各自只出现一次，并按优先级组织。

Context：不是越长越好，而是越相关越好

上下文决定模型此刻能看到的世界。上下文错误，再强的模型也只能在错误前提上推理。

上下文工程需要处理五件事：

选择

只取与当前任务有关的文件、记录、历史和政策。不要为了“保险”把整个知识库塞进上下文。

排序

目标、硬约束和最新事实应该优先于背景资料。高影响信息要靠近决策位置，并明确来源。

新鲜度

价格、状态、权限、版本和业务数据都可能变化。系统要知道哪些事实可以复用，哪些必须重新查询。

压缩

长会话需要压缩旧内容，但不能丢失目标、已确认事实、用户修正、未完成事项和关键证据。

隔离

系统规则、用户输入、工具结果和模型推断应该清楚区分。外部内容不能伪装成高优先级指令。

上下文质量可以用一个简单问题检验：如果把当前内容交给一名新同事，他是否能理解目标、知道哪些事实可信，并继续完成任务？

Tools：把语言能力连接到现实

没有工具时，模型主要负责解释和生成；接入工具后，系统可以搜索资料、读取文件、执行代码、查询数据库和写入外部服务。

工具设计直接影响模型表现。一个好工具应当具备：

单一、明确的职责。
清楚的名称和使用条件。
强类型参数、必填项和范围限制。
稳定的返回结构。
可行动的错误信息。
明确的只读或写入语义。
最小权限与凭据隔离。
必要时支持幂等和结果查询。

“调用失败”不是足够的工具反馈。系统应该说明失败阶段、是否可重试、是否产生了部分结果，以及下一步有哪些安全选择。

工具数量同样不是越多越好。用途重叠、描述含糊的工具会增加选择成本。只向当前任务暴露必要工具，往往比提供一整套万能接口更可靠。

Runtime：让多步任务可控地运行

只要任务需要多轮观察和行动，就需要 Runtime 管理生命周期。

Runtime 负责：

调用模型与工具。
把工具结果返回给下一轮判断。
控制并发、步骤和成本预算。
处理超时、有限重试和取消。
检测重复调用和无效循环。
在外部写入前触发审批。
判断任务完成、受阻或需要用户介入。
对最终结果执行验证。

运行时不应该把“工具返回成功”直接等同于“用户目标完成”。代码写入成功后还要测试，文章提交前还要校验，数据更新后还要确认回执。

对于固定步骤，普通程序或工作流更可靠；只有在中间结果会改变下一步路径时，才需要让模型参与动态决策。

State：让任务记得自己走到了哪里

多轮和长时间任务必须管理状态。否则一次网络中断、进程重启或用户离开，就会让系统重新开始。

状态通常包括：

当前目标和任务阶段。
已确认事实与尚未验证的假设。
已完成步骤和工具结果。
用户授权、审批和修正。
文件或数据的变更记录。
检查点、重试次数和幂等键。
最终验证证据。

状态不等于把所有历史原样保留。系统需要区分工作记忆、可复用知识和必须实时核验的事实。

特别是发布文章、发送消息、创建订单等外部写入，应该记录稳定幂等键。网络超时并不代表操作失败，盲目重试可能造成重复结果。

Guardrails：把安全边界做成系统机制

“请谨慎操作”不是安全机制。

生产系统需要把关键边界强制化：

认证用户身份，并按任务授予最小权限。
区分读取、修改、外部写入和破坏性操作。
对删除、购买、发送和发布设置明确审批条件。
使用文件系统、网络和代码执行沙箱。
校验命令、路径、目标对象和参数范围。
把密钥留在执行层，不写入 Prompt、正文或日志。
限制调用速率、并发、时间和成本。
允许用户随时取消、纠正或接管。

Guardrails 的目标不是让系统失去行动能力，而是让它在授权范围内顺畅推进，在越界前可靠停下。

Evals：把“感觉不错”变成可度量质量

传统软件的错误往往表现为程序崩溃、状态码异常或断言失败。AI 系统多了一类更棘手的问题：程序成功运行了，但结果并不好。

因此，评估不能只看 API 是否返回成功，还要判断：

结果是否正确。
关键结论是否有证据支撑。
是否遗漏用户要求。
输出格式是否可用。
是否调用了不必要或错误的工具。
是否发生越权或高风险操作。
延迟和成本是否在预算内。
相同任务重复运行是否稳定。

评估可以分为四层：

确定性校验

检查 JSON Schema、字段完整性、链接、文件格式、代码编译和业务规则。这类规则能用普通程序判断，就不应该交给模型猜。

参考答案评估

对有明确正确答案的任务，比较关键事实、步骤和最终结果。测试集应覆盖正常输入、边界情况和已知失败案例。

模型评分

对文案质量、解释完整性和开放式分析，可以使用模型评分，但要先用人工样本校准标准，避免评分器只偏好更长、更流畅的答案。

人工评审

高影响、难量化或新类型任务仍需要人工判断。人工评审结果应该进入测试集，而不是停留在聊天记录里。

把评估放进开发循环

评估的价值不只是发布前打分，而是形成持续反馈回路：

从真实使用中收集失败案例。
去除敏感数据，整理成可重复测试。
标注期望结果、允许差异和失败类型。
在当前版本上建立基线。
每次只修改一个主要变量。
重新运行相同评估集。
比较质量、成本、延迟和风险。
通过后再逐步发布并监控线上指标。

需要特别警惕“只优化平均分”。少数高风险失败可能被漂亮的总体数据掩盖。除了平均质量，还要单独观察越权率、事实错误率、重复写入率和严重失败数。

把真实失败固化成测试案例，是 AI 产品从经验驱动走向工程驱动的关键一步。

可观察性：没有记录就无法改进

AI 系统需要同时记录结果和过程。否则一个回答出错时，团队很难判断问题来自 Prompt、Context、Tools、Runtime 还是模型本身。

建议记录：

请求使用的模型、版本和关键配置。
上下文来源、时间和截断情况。
工具调用、参数摘要、耗时和结果状态。
重试、回退、审批和停止原因。
最终输出与验证结果。
用户纠正、人工接管和后续反馈。
Token、延迟和外部服务成本。

日志必须注意隐私和凭据隔离。可观察性不是把完整上下文永久保存，而是保存足以复盘、又符合数据治理要求的证据。

一个从 Demo 到产品的例子

假设我们要做一个“根据内部资料回答客户问题”的功能。

第一版：只有 Prompt

把用户问题和一段固定说明发送给模型。演示很快，但答案可能使用过期信息，也无法说明来源。

第二版：加入 Context

从知识库检索相关资料，只提供最新、最相关的段落，并要求答案附带来源。系统开始具备事实基础。

第三版：加入 Tools

允许查询订单状态、产品配置和服务记录。工具只返回必要字段，并按用户权限过滤数据。

第四版：加入 Runtime 与 State

当资料冲突时继续查询；工具超时时有限重试；长对话保留目标和关键事实；创建工单时使用幂等键。

第五版：加入 Guardrails

普通咨询保持只读；退款、补偿和修改订单需要明确授权或人工审批；敏感信息在进入模型前脱敏。

第六版：加入 Evals 与反馈

用真实问题建立评估集，检查事实正确性、引用覆盖、拒答质量、工具选择、延迟和成本。线上收集人工修正，持续补充回归案例。

同一个模型没有变化，产品却从一次生成变成了可验证、可恢复、可治理的服务。

常见故障应该查哪一层

现象	更可能的问题层
回答方向错误	Prompt 的目标或完成标准不清
事实过期或缺失	Context 的检索、新鲜度或压缩失效
选错工具、参数混乱	Tools 的职责、描述或返回语义不清
重复调用、任务卡住	Runtime 缺少预算、重复检测或停止条件
重试后产生两条数据	State 缺少幂等和调用记录
普通请求触发外部写入	Guardrails 的授权边界失效
新版本悄悄变差	Evals 覆盖不足或没有持续回归
出错后无法复盘	可观察性缺少上下文和调用证据

先定位层次，再选择修复方式。很多“再改一下 Prompt”的需求，实际根因可能是工具错误信息含糊、上下文过期或没有结果验证。

一条务实的落地路径

不要一开始就建设庞大的 Agent 平台。可以按风险和价值逐步演进：

先定义一个具体、高频、可验证的任务。
用最短 Prompt 和少量示例建立基线。
补齐真实 Context，并标注来源和新鲜度。
只接入任务真正需要的窄工具。
增加超时、取消、有限重试和停止条件。
对写操作加入最小权限、审批和幂等。
把真实失败沉淀为评估集。
记录质量、延迟、成本和严重失败。
证明稳定后，再扩大自主范围和使用场景。

每次只改变一个主要变量，才能知道质量变化究竟来自模型、Prompt、Context 还是工具。

上线前检查清单

准备把 AI 功能交给真实用户前，至少确认：

目标、约束和成功标准清楚。
Prompt 没有重复或互相冲突的规则。
上下文来源可信、相关并且足够新。
工具职责单一，参数和错误语义明确。
只读与写入权限已经分离。
外部写入支持审批、幂等或结果查询。
任务有超时、取消、预算和停止条件。
长任务有状态和中断恢复方案。
最终结果有确定性校验或证据要求。
真实失败已经进入回归评估集。
线上质量、延迟、成本和风险可观察。
用户能够看到关键进度并安全接管。
敏感数据不会泄露到 Prompt、日志或不必要的外部服务。

如果这些条件还没有建立，系统更接近 Demo，而不是可以长期承诺结果的产品。

让智能变得可维护

模型会继续变强，调用成本也可能继续下降。但产品真正的壁垒，不是某一句“神奇提示词”，而是把不稳定的生成能力组织成稳定、透明、可恢复、可持续改进的体验。

Prompt 决定系统如何理解意图，Context 决定它掌握哪些事实，Tools 决定它能做什么，Runtime 与 State 决定任务能否持续推进，Guardrails 决定哪些行为被允许，Evals 和可观察性决定系统能否发现错误并不断变好。

这才是 AI 产品真正的工程分水岭：从追求一次好答案，转向兑现一个可以长期验证的产品承诺。

参考资料

OpenAI 的官方模型指导建议提供目标、背景、硬约束、所需证据、成功标准和输出格式，并明确工具路由、权限边界、重试停止条件与最终验证。这些原则可以作为 AI 系统设计的工程检查项：OpenAI Model guidance。