用提示词合同固定团队 AI 输出的格式与边界

团队把同一项任务交给 AI 时，经常得到结构不同、结论越界或无法回查的结果。原因通常不是少写了一句“请专业回答”，而是任务没有明确输入是什么、必须产出哪些字段、哪些信息不能推断，以及信息不足时应如何停止。一个可复用提示词应更像接口合同：调用者知道要提供什么，执行者知道允许做什么，验收者也能判断结果是否合格。本文以代码审查为例，逐步构造一份最小合同，并说明如何用固定样例验证它。

提示词合同包含什么

一份最小合同可以拆成六部分：

“角色”可以帮助确定术语和关注点，但不能代替这些约束。只有“你是资深工程师”而没有输出合同，仍然无法验收。

从一个模糊请求开始

下面的请求无法约束审查范围，也没有证据要求：

请作为资深后端工程师审查这段代码，给出专业建议。

模型可能讨论性能、命名、架构甚至业务需求。即使内容很多，也很难判断是否遗漏真正的缺陷。

写成可复核的最小合同

可以改成下面的模板：

任务：审查输入代码中的正确性和可维护性问题。

输入：
- language：编程语言和版本
- code：待审查代码
- expected_behavior：调用方声明的预期行为

范围：
- 检查会导致错误结果、异常或资源泄漏的问题
- 检查明显影响后续修改的结构问题
- 不推断未提供的业务规则
- 不评价与输入无关的技术选型

输出：
按严重程度列出发现。每项必须包含：
1. location：最小代码位置
2. problem：可观察的问题
3. condition：触发条件
4. consequence：实际影响
5. suggestion：最小修复方向

证据：
- 每项发现必须引用输入中的具体语句或控制流
- 没有足够证据时标记为“待确认”，不得写成确定结论

失败条件：
- code 为空时返回 INPUT_MISSING
- 无法判断语言时返回 LANGUAGE_REQUIRED
- 没有发现时返回 NO_FINDINGS，并列出尚未覆盖的风险

模板没有规定必须发现多少问题，也没有要求生成完整修复代码。这样可以减少为了满足数量而制造结论的倾向。

给输出增加机器可读结构

若结果还要进入自动化流程，可以约定 JSON 结构：

{
  "status": "OK",
  "findings": [
    {
      "severity": "high",
      "location": "function_name:line",
      "problem": "...",
      "condition": "...",
      "consequence": "...",
      "suggestion": "...",
      "confidence": "confirmed"
    }
  ],
  "limitations": ["..."]
}

结构化输出不等于内容正确。解析方仍要校验字段是否存在、枚举值是否合法，并处理模型在字段之外返回文本的情况。不要用正则表达式从任意自然语言中猜测关键状态。

用对照样例验证合同

至少准备三类固定输入：

正常样例

包含一个可以从代码直接证明的问题。验收重点是位置、触发条件和影响能否互相对应，而不是措辞是否一致。

无问题样例

输入一段范围内没有明显缺陷的代码。预期返回 NO_FINDINGS，而不是为了显得有用而提出无关重构。

无效输入样例

分别缺少代码、语言或预期行为。确认系统能按合同返回缺失状态，不凭空补全上下文。

每次修改提示词后重新运行同一组样例，记录输入版本、提示词版本和人工判定。仅凭一次“看起来不错”的结果，不能说明合同已经稳定。

把事实与偏好分开

编码规范、允许的依赖和输出格式属于团队约束，应作为显式输入或版本化规则传入。某次审查中的代码、报错和需求则属于任务输入。不要把临时项目事实写进长期通用指令，否则后续任务可能继承错误背景。

同样，不要在合同中写“永远使用某种框架”这类没有范围的偏好。应说明适用仓库、版本和例外处理方式。

变更提示词时控制变量

验证提示词变化时，保持模型、参数和样例不变；验证模型变化时，保持提示词和样例不变。否则结果发生变化后无法归因。对高风险流程，还应保存原始输入与输出的脱敏记录，供人工复查。

结论与限制

可复用提示词的核心不是堆叠技巧，而是建立输入、范围、输出、证据和失败条件。把任务写成最小合同，再用正常、无问题和无效样例反复验证，团队才能对输出建立一致的验收标准。

本文方法适合约束文本分析与结构化生成，不能保证模型事实无误，也不能替代编译、测试、静态分析或人工评审。涉及具体工具的系统指令、结构化输出能力和字段限制，仍需依据当前接口文档验证。