规范先行（Spec-First）智能体：为什么契约必须先于提示词落实

我接手时，我们客服智能体的提示词已经达到了 2,400 个 token，而编写它的工程师已经离职了。其中的每一条指令对于某些生产行为来说都是“承重的”，但没人能告诉我哪些才是关键。一条关于“在回答之前务必先复述用户问题”的条目看起来像是凑数的，直到我们删掉它后，CSAT（客户满意度）在一周内下降了四个百分点。事实证明，提示词就是规范（specification）。它既是实现（implementation），也是测试套件（test suite）——它是隐性的、未记录的，仅存在于那位已经离职的工程师脑中。

这就是“提示词即规范”的终局。提示词既是智能体应该做什么，也是它如何做，一旦提示词规模超过了单个作者的掌握范围，两者就会变得无法区分。你无法重构它，因为你不知道哪些行编码了需求，哪些行仅仅是暗示。你无法评审变更，因为没有可以与之对比的基准产物。你无法让任何人接手并负责它，因为负责意味着“最近阅读过全文并记得每一项条款存在的原因”，这是一项没人愿意批准的、长达六个月的投资。

“规范优先”颠覆了这种顺序。契约（contract）——输入、输出、不变量、错误情况、拒绝语义、升级触发条件——是一个先于提示词并约束每次修订的一等产物（first-class artifact）。对提示词的修改变成了针对规范的补丁（diff），而不是对规范本身的重写。这种转变听起来很官僚，直到你看到它所释放的潜力：评估（evals）源自规范而非反之，评审只需几分钟而非整个下午，最终能让新工程师在没有六个月学徒期的情况下直接接手整个模块。

“提示词即规范”的失败模式

大多数团队所实践的提示词工程（Prompt engineering），是一种迭代式的手艺。你写一个提示词，运行一些例子，发现问题，添加一个条款，再运行更多例子，发现新的失败，再添加一个条款。三个月后，你得到了一个在许多情况下表现良好，但在其余情况下表现诡异的提示词。六个月后，你得到了一个除了原作者之外，任何人都无法在不引起回归（regressions）的情况下进行修改的提示词。

失败的不是这门手艺——迭代优化是大多数工程的运作方式——而是提示词同时承担了三个角色。它规定了预期的行为。它通过措辞、顺序和强调来实现该行为。它还充当了测试套件，因为促使每个条款产生的示例都被固化在了条款中，而不是作为回归测试被捕获。当这三个角色坍缩为一个产物时，每次修改都变得高风险：你无法判断你是在修改需求、实现方式还是测试。

你能在下游看到这些症状。提示词更改被回滚，因为“它在某个我无法重现的边界情况中表现得很奇怪”。两位工程师为一个行为是 Bug 还是预期设计争论一小时，因为没有规范来裁决。提示词增长超过了“两个作者能同时在大脑中理解”的阈值并固化——任何改动的风险都超过了预期收益，因此提示词被冻结，而它周围的产品却在不断迭代。供应商推出了新模型，同样的提示词产生了细微差别的输出；没人能说清新的输出是否违反了契约，因为根本没有契约可供违反。

当你跨入这个区域时的征兆：当有人问“为什么提示词里写了 X？”答案是“我在用户报告了 Y 之后加上的”，但没人能拿出 Y、针对 Y 的回归测试，或者规范中被 Y 违反的部分。

契约实际上包含什么

一个有用的契约既不是设计文档，也不是增加了额外步骤的提示词。它是一个专注的产物，命名了那些提示词不擅长显式表达的事物。至少包括：

• 输入（Inputs）。 智能体接收内容的形态——用户消息、工具输出、检索到的上下文、对话历史——以及典型案例和边界情况的具体示例。长度限制。什么是保证提供的，什么是可能缺失的。
• 输出（Outputs）。 智能体生成内容的形态，包括格式（JSON schema、markdown 结构、特定字段）、可接受的内容范围和必填章节。“回答问题”不是输出规范；“返回一个包含 answer（≤200 字）和 confidence（低/中/高）的 JSON 对象”才是。
• 不变量（Invariants）。 无论输入如何，每个输出都必须满足的条件。智能体永远不泄露系统提示词。它永远不承诺价格。它永远不声明未检索到的事实。如果不使用规范，不变量就是你会添加防护栏（guardrail）的那些地方。
• 错误情况（Error cases）。 当智能体无法完成正常流程时该怎么做。信息缺失、检索冲突、工具失败、用户意图模糊。每种情况在规范中都有一个具名的分支和示例。
• 拒绝语义（Refusal semantics）。 智能体拒绝执行什么以及如何拒绝。拒绝是有表现形式的——语气、解释、建议的替代方案、升级流程——这种表现形式是契约的一部分，而不是提示词碰巧产生的一种“氛围”。
• 升级触发条件（Escalation triggers）。 智能体将任务移交给人工、另一个智能体或另一个工具的具体条件。“用户感到沮丧”不是触发条件；“用户明确要求人工，或在同一个子目标上连续三轮没有进展，或任何被审核工具标记的输入”才是。

这些都不是新鲜事——这些是过去两年在挖掘 LLM 失败案例过程中，形式化契约研究所总结出的类别——但类别本身不是重点。重点是契约是 独立于提示词的，而对提示词的修改是对“规范未变”的声明。如果修改实际上改变了规范中定义的内容，那么规范必须先改变。这一条规则正是让其余工程纪律变得具有“承重”意义的关键。

加载中…