企业官网建设流程全解析

大模型应用评审如何识别隐性风险

提示词评审不该只判断文字是否通顺。一个看起来合理的提示词，可能在长上下文、异常输出或恶意输入下失去约束。评审的目标是确认：模型拿到的数据是否合适，输出能否被系统安全处理，失败时产品会怎样退回。

将指令、参考资料和用户输入分开

系统规则放在受控位置；检索到的文档和用户问题都是待处理数据，不能因为被放进提示词就变成可信指令。对输入做长度限制、脱敏和来源标记，避免把密钥、完整日志或未过滤的网页内容直接送给模型。提示词中的标签可以改善可读性，但标签本身不是安全边界；工具调用和权限检查必须在模型之外完成。

准备一组对抗样本测试忽略指令、索取内部规则、伪造工具结果和超长文本。测试结果应关注是否越权、是否泄露数据、是否正确拒绝，而不是只看回答是否像人写的。

输出要先校验，再进入业务流程

要求 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 数，也不应假设把规则重复两次就一定能解决长上下文问题。应通过接近真实长度的测试集检查关键约束是否仍被遵守。

最后评审工具权限、超时、重试上限、日志脱敏和人工升级路径。模型不可用或输出无效时，系统应诚实说明不能完成什么，而不是伪造一个确定答案。这样建立的防线比一段看似严厉的提示词更可靠。

发布后持续收集拒绝率、解析失败率、人工纠正率和工具调用结果，按版本比较变化。任何新增数据源、模型版本或工具权限，都可能改变原有风险，因此应重新走一遍针对性评审。评审不是为提示词盖章，而是为系统的输入、输出和操作边界负责。

将这些结论写入上线清单，事故发生时才能快速判断是否需要停止相关能力。

并定期重新验证。

确保变更不会绕过既有控制。

持续检查。