你做合规或安全，被要求判断一个安全大模型能不能用，或者要写一份评估方案，翻遍资料发现全是口号，没有可对照的条目。这篇不讲模型多强，只把总体框架拆成能勾选的能力维度，再给一套可执行的评估流程：先定边界、再选维度、然后设计用例与判定口径、最后留回退与复核机制。数字和版本一律让你去站内对应页面核。
你做合规或安全，被要求判断一个安全大模型能不能用，或者要写一份评估方案，翻遍资料发现全是口号，没有可对照的条目。这篇不讲模型多强，只把总体框架拆成能勾选的能力维度，再给一套可执行的评估流程：先定边界、再选维度、然后设计用例与判定口径、最后留回退与复核机制。模型资料和当前价位一律到站内模型库与价格追踪页核对，别抄别人二手结论。
先说清一件事：总体框架是评估的设计图纸，不是给某个具体模型打分。它回答的是「要评什么、怎么判定、谁签字」，不回答「哪家更强」。选型和比价属于另外的活，去 /rankings 和 /price-watch 看当时的数字更靠谱。框架本身正确与否，取决于你的业务边界写得够不够清楚。
先分清：这套框架管什么、不管什么
适用范围是内容安全、数据安全、提示注入与越权、输出可用性这类可被验证的工程要求。它们都有共同点：能设计输入、能观察输出、能留档判定。不适用的是「模型是否真正理解」「是否有意识」这类问题，它们没有可复现的判定口径，放进评估表只会让评审会陷入争论。
| 判断项 | 属于框架内 | 不属于框架内 |
|---|---|---|
| 输入可控 | 对抗提示、越权指令 | 模型的主观意图 |
| 输出可观测 | 违规内容、隐私泄露 | 模型内部表征 |
| 可复现 | 同输入多次结果稳定 | 一次性灵感式表现 |
| 可追责 | 日志、审计、告警 | 研发内部实现细节 |
- 前提条件：先有明确的业务边界和合规要求清单，否则维度会无边界膨胀，评估做不完
- 定位差异：总体框架负责设计评估，不负责得出结论，别拿它直接当选型依据
- 什么时候不适用：一次性试用、内部演示这类不进入生产链路的场景，套全套框架性价比很低，走简化清单即可
- 一个实用判断：如果某个维度找不到「谁判定、依据什么、留什么档」，先别写进正式框架
能力维度怎么拆：四个面 + 一个横切面
把能力拆成输入侧、输出侧、系统侧三个面，外加固有的横切面：可复现性。可复现这条最容易被忽略，却是评审能不能服众的关键——同一批用例在不同时间、不同接入方式下结论打架，前面所有工作都要重做。模型侧的参数与版本信息到 /models 页面核对当时的记录，别凭记忆写。
- 输入侧
- 对抗性提示、越权指令、敏感数据夹带、多轮诱导的识别与拦截
- 输出侧
- 违规内容、隐私泄露、事实性错误，以及拒答是否合理，过度拒答也是缺陷
- 系统侧
- 日志可追溯、权限隔离、审计留痕、异常调用的告警与熔断
- 横切面
- 可复现性——同输入不同时间、不同接入方式下结果是否稳定
- 每个维度都要落到「产生数据的位置、判定的角色、留档的载体」三件事上，缺一件就是空条目
- 输入侧重点在拦截与放行的边界，不要只统计拦截数，放行的高危样本同样要记
- 输出侧要同时记录漏放和误杀，否则数据会系统性地偏向「拦得越狠越好」
- 系统侧多数靠工程手段验证，建议用真实调用日志抽样，而不是让模型自证
- 横切面单独列，不要塞进输出侧，否则跨时段对比时会拿不到干净的数据
评估流程排期：从用例到结论的固定顺序
流程顺序不要跳。先跑正常业务用例定基线，再上对抗用例，否则你连「什么是异常响应」都没定义清楚。用例集按风险等级分层：高危用例数量少但必须全过，低危用例追求覆盖广度。判定口径要在跑之前定完，谁签字、怎么算、争议怎么裁，全部写进评估方案。
- 第一步：定基线用正常业务用例跑一轮，记录可接受的响应形态与耗时区间，作为后续对照的底稿
- 第二步：设计用例集按风险等级分层，高危必过，低危重覆盖；每个用例写清期望行为和不可接受行为
- 第三步：定判定口径明确拦截率、误杀率、拒答率各自怎么算，谁签字确认，提前消灭事后扯皮
- 第四步：交叉验证同一批用例换接入方式或时段再跑一遍，看结论是否一致，不一致的要找出原因
- 第五步：出结论写明通过了哪些、哪些是已知残余风险、补救动作与复核周期，附上原始数据
| 阶段 | 产出物 | 常见卡点 |
|---|---|---|
| 定基线 | 可接受响应样例 | 基线用了对抗用例，对照失真 |
| 设计用例 | 分层用例清单 | 高危用例太少，过不过说明不了问题 |
| 判定口径 | 算法与签字人 | 先跑后定，各说各话 |
| 交叉验证 | 两次结果对照 | 换了接入方式没记录，无法归因 |
| 出结论 | 残余风险清单 | 只写通过项，不写已知缺陷 |
排期上建议留出复核窗口。评估不是跑完就结束，结论要能被别人复现，也要能在业务侧抽查时站得住。如果团队只有一两个人，可以把交叉验证降级为「换时段重跑一轮」，但不要直接砍掉。相关工具目录和检测入口可以到 /tools 和 /tools/speed-test 看当时的可用项。
常见坑与不适用情形
最大的坑是把安全评估做成一次性验收。模型、提示词、外部知识库任何一项变更都会让结论过期，所以要在方案里写清复核的触发条件：换了接入方式、改了系统提示、接了新知识源、业务场景扩展，任一条触发就要重新评估受影响的部分。参考各家模型的当前资料，到 /models 核对当时的记录。
- 只看拦截率不看误杀：拦得越狠看上去越安全，但业务侧会绕过去，风险只是转移没有消失
- 用例集自己造自己判：编用例的人和判定的人最好分开，至少要有第二人复核签字
- 不设复核触发条件：模型或提示词一变，旧结论就成了误导，比没有结论更危险
- 不适用说明：如果业务本身不接触用户输入、不产生对外内容，输出侧维度的权重应大幅下调，别照抄别人的维度表
安全评估的价值不在结论本身，而在别人能照着你的方案复现出同一个结论。下一步把你的评估表先对着站内资料库补全模型侧的记录，再定用例分层和复核触发条件；数字和当前版本到站内页面核对，别用记忆里的旧值。→
常见问题
这套框架和常见的模型能力榜单是什么关系？
基本不是一回事。榜单比的是通用任务上的相对表现，总体框架管的是在你自己的业务边界内，哪些风险必须被识别、被记录、被复核。榜单能帮你缩小候选范围，但替代不了安全评估用例和判定口径，两者要分开做。
小团队没有专职安全人员，怎么落地？
先做减法：只保留输入侧和输出侧两个面，用例集控制在能在一两天内跑完的规模，重点是把判定口径写下来，哪怕只有一页。日志留痕用现有系统加就行，别一上来就搭完整审计链路，跑完一轮再决定加什么。
评估做完了，多久要重做一次？
不建议按固定日历拍。设触发条件更实际：底层模型换版本、系统提示词改动、接入的外部数据源变化、出现新的攻击手法报道，任一发生就重跑对应部分的用例。具体节奏可以到站内的安全与合规分区对照现有要求再定。
