值班交接：提示词上线前，先核完这七项

本班交接提醒：提示词在聊天窗口里答对一次，不等于已经可以上线。用户可能少写一句话、贴入很长的材料，或者要求模型做职责之外的事。上线前要确认的，不是它能不能写出漂亮答案，而是遇到这些情况时，系统还能不能按约定工作。

提示词测试，就是拿一组事先准备的输入，检查模型的回答是否符合要求。不必一开始就搭建复杂平台；一张表、一段调用脚本，加上明确的通过条件，就能开始。

先把“答得对”写成能核查的条件

假设你要上线一个工单分流助手，它的任务是读取用户描述，返回工单类别和紧急程度。测试前先约定允许哪些类别、哪些字段必须返回，以及信息不足时应该追问还是转人工。不要只写“回答准确、态度友好”，因为不同的人可能给出不同判断。

把规则写到可以逐项检查的程度。例如，“只返回约定字段，不得编造订单号；无法判断时返回待人工确认”。这些规则既能帮助你修改提示词，也能让接班同事复查同一份结果。

发布单上逐项核对这七件事

• 准备真实但已脱敏的正常输入，覆盖主要任务，而不是只挑最容易答对的例子。工单助手可以分别测试退款、登录失败和功能咨询，并为每条输入写下预期类别。
• 补上信息不足和异常输入，包括空白内容、错别字、前后矛盾的描述，以及接近应用输入长度上限的材料。检查模型是否按约定追问或停止，而不是自行补齐不存在的事实。
• 检查职责边界，把“忽略之前的规则”等指令放进用户输入或待处理文档。确认模型不会把这些内容当成更高优先级的命令，也不会因此透露内部提示词或执行未授权操作。
• 验证输出能被下游程序使用。程序需要固定字段时，就实际解析返回内容，并检查字段类型、必填项和允许值；不要因为答案看起来整齐，就认定接口格式合格。
• 对关键用例重复运行，并记录不一致的地方。同一条提示词可能产生不同回答，所以一次通过只能说明这一次成功；重复测试也不能证明以后绝不会出错。
• 检查工具调用和失败处理。如果助手能查订单、发消息或修改数据，先在隔离环境测试，并确认高风险操作需要适当授权。超时、限流或返回异常时，也要有明确的提示和处理路径。
• 用同一组用例比较修改前后的结果，并记录提示词版本、模型名称、调用参数、耗时和实际用量。修好一条失败案例之后，还要重跑原有用例，避免修复退款分类时弄坏登录分类。

换模型时，把原来的测试再跑一遍

提示词没有变，模型变了，也应重新检查。比如你准备使用 Claude Haiku 4.5，就在实际计划使用的调用方式和参数下测试，不要把另一个模型的结果直接当作它的上线依据。工具配置、上下文内容和应用中的额外指令也应尽量与正式环境一致。

如果需要通过统一接入方式试用多个模型，Relay365 是一个按量付费的多模型中转服务，可以作为测试入口。统一入口便于组织调用，但不代表不同模型的行为一致，也不能替代你自己的验收用例。

交接时留下结果，也留下退路

上线记录至少应包含测试用例、通过条件、失败项、已知限制和回退版本。涉及权限、数据写入或敏感信息的失败，不宜被其他用例的通过结果抵消；先修复，或收紧功能范围，再决定是否发布。

如果你正好需要多模型测试入口，可以创建 Relay365 账户，从少量脱敏用例开始。发布后仍要观察实际失败案例，把它们补进测试集。下一班最需要接到的，不是“应该没问题”，而是能复跑的记录，以及出问题时明确可用的退路。