大模型安全功能的交付验收先把对象说清楚韩朔处理安全分析里的“大模型安全功能的交付验收”时通常不会先讨论工具多不多而是先把任务压到一个具体场景谁在什么条件下发起操作系统需要留下什么结果哪一步出错必须停止。只要这个场景还说不清后面的架构图和参数表就很容易变成装饰。落地时先把会被谁使用、输入从哪里来、输出落到哪里写进任务说明。不要把一个宽泛的需求拆成很多漂亮的名词真正需要确认的是每个动作是否会改动状态、是否依赖外部服务以及失败后用户会看到什么。把这些问题放到实现前比上线后靠日志猜原因省事得多。处理这类问题时我会先挑一条最常见的路径跑通再故意让它遇到缺字段、超时、权限不足和重复提交。记录的重点不是“测试通过”而是当时的输入、版本和结果。能复现的记录才能帮助后来的人判断改动影响。讨论大模型安全Prompt 注入、越狱攻击与防御评估实践时从原型到生产的验收清单常被写成一串工具或原则读完仍不知道该先检查什么。更实用的起点是把当前任务限定下来提示词、检索内容和工具返回值都可能是不可信输入。本文只谈可在授权范围内复核的做法。生产验收从拒绝路径开始把涉及的对象列成清单不可信文本、工具权限、模型输出和外部数据源。对每项补上来源、修改者、依赖关系和失败后的影响。这里不追求面面俱到先选一条真实流程才能分清哪些观察是事实哪些只是猜测。把工具调用当作受控副作用原型验证的是可行性生产验收验证的是边界。两者之间至少要补齐身份认证、权限控制、失败处理、日志脱敏和依赖治理。验收清单按用户旅程编写正常请求、越权请求、异常输入、依赖失败和回滚。每项写清责任人、证据和通过标准。没有通过的项目不要用口头承诺替代。记录风险接受范围和修复计划确保上线决策可追溯。留下能复查的记录记录至少应包含本次范围与授权前提、输入或样本的来源、环境和版本、预期结果、实际观察以及下一步由谁处理。还要核对模型是否被允许调用工具以及调用参数是否经过校验。对于大模型安全Prompt 注入、越狱攻击与防御评估实践可保留的证据包括策略决策、工具调用记录、拒绝原因与脱敏后的请求关联标识。原型通过不等于可上线不应把模型生成的文字直接当作执行指令。如果材料不足结论可以停在“尚待验证”把未知项列出来比用概括性的成功或失败更诚实。下一次变更时沿用同一份记录即可判断原来的前提是否还成立。验收现场怎样留住问题验收时不要只让开发人员操作一遍。让没有参与实现的人按任务说明完成一次正常请求再按预先约定的边界样本提交请求往往更容易暴露说明里遗漏的默认权限、错误提示或审批入口。观察者不需要猜模型“应该怎么想”只需记录页面给出的状态与后台实际动作是否一致。遇到拒绝结果也要看它有没有泄漏原始提示词、内部工具名或检索片段。对安全功能来说拒绝本身只是一个起点调用是否真的被阻止、临时资源是否释放、审计记录能否关联到这次请求才构成完整的验收证据。把这些发现写进遗留项下一次发布前逐条核对即可。