大模型应用评审如何识别隐性风险提示词评审不该只判断文字是否通顺。一个看起来合理的提示词可能在长上下文、异常输出或恶意输入下失去约束。评审的目标是确认模型拿到的数据是否合适输出能否被系统安全处理失败时产品会怎样退回。将指令、参考资料和用户输入分开系统规则放在受控位置检索到的文档和用户问题都是待处理数据不能因为被放进提示词就变成可信指令。对输入做长度限制、脱敏和来源标记避免把密钥、完整日志或未过滤的网页内容直接送给模型。提示词中的标签可以改善可读性但标签本身不是安全边界工具调用和权限检查必须在模型之外完成。准备一组对抗样本测试忽略指令、索取内部规则、伪造工具结果和超长文本。测试结果应关注是否越权、是否泄露数据、是否正确拒绝而不是只看回答是否像人写的。输出要先校验再进入业务流程要求 JSON 不会保证模型每次都返回 JSON。服务端应解析、校验类型和枚举并在失败时返回可处理的错误或走人工路径。不要用“补几个括号”的方式修复涉及金额、权限或状态变化的结果修复后的含义可能已经改变宁可拒绝并重试或让用户确认。from pydantic import BaseModel class Intent(BaseModel): name: str confidence: float def parse(raw: str) - Intent: return Intent.model_validate_json(raw)结构校验之后仍要验证业务语义例如动作是否在白名单、金额是否在限额内、引用的资源是否属于当前用户。模型给出的 confidence 可以用于排序不是授权凭据。长上下文需要明确预算与取舍检索结果、聊天历史和工具输出都会占用窗口。为每类内容设置预算优先保留系统规则、当前任务和可追溯的摘要原始大对象放在受控存储中按需取回。不能把“字符数”简单等同于 token 数也不应假设把规则重复两次就一定能解决长上下文问题。应通过接近真实长度的测试集检查关键约束是否仍被遵守。最后评审工具权限、超时、重试上限、日志脱敏和人工升级路径。模型不可用或输出无效时系统应诚实说明不能完成什么而不是伪造一个确定答案。这样建立的防线比一段看似严厉的提示词更可靠。发布后持续收集拒绝率、解析失败率、人工纠正率和工具调用结果按版本比较变化。任何新增数据源、模型版本或工具权限都可能改变原有风险因此应重新走一遍针对性评审。评审不是为提示词盖章而是为系统的输入、输出和操作边界负责。将这些结论写入上线清单事故发生时才能快速判断是否需要停止相关能力。并定期重新验证。确保变更不会绕过既有控制。持续检查。