"能做/不能做"要写下来，而不是靠模型自觉
AI 功能的能力边界如果只写在提示词里 ✗，就等于靠模型自觉 ✔ —— 它会在边界上摇摆 ✗。
正确做法是把权限与边界做成显式声明 ✔，并在代码层执行 ✔（不是提示词层 ✗）。
一、能力矩阵（先写清"谁能做什么"）
角色 × 动作 × 对象 × 条件
客服 × 查询 × 订单 × 仅本租户
客服 × 修改 × 地址 × 需用户确认
主管 × 退款 × 订单 × 金额 ≤ 500 且需二次确认
外部 × 任何写操作 × 任何对象 × ❌ 禁止
要点：矩阵是代码里的配置 ✔，不是文档里的描述 ✗；
矩阵要可测试（每行一条用例 ✔）。
二、三层防线（缺一不可）
- 参数层：模型给的参数先校验（范围、枚举、外键存在 ✔）；
- 权限层：动作与对象是否在矩阵内 ✔（独立于模型判断 ✔）；
- 确认层：高风险动作必须人确认 ✔（确认信息要人看得懂 ✔）。
模型输出只作为意图 ✔，执行与否由这三层决定 ✔（见接线与工具设计两篇 ✔）。
三、"不能做"要能说出来
- 拒绝时说明为什么（权限不足 / 需要确认 / 超出范围 ✔）；
- 给出可行替代（"可以帮你提交申请，由主管审批" ✔）；
- 记录拒绝原因（便于发现"权限过紧"或"角色配错" ✔）。
忌讳：静默失败 ✗ 或假装成功 ✗（后者最危险 ✔）。
四、审计与最小权限
- 最小权限：默认只给需要的动作 ✔（不要"为了方便"给全部 ✗）；
- 审计日志：谁、什么时候、以什么身份、执行了什么动作 ✔；
- 定期复核：每季度看一遍谁拥有高风险权限 ✔（离职/转岗后及时收回 ✔）。
五、三个常见漏洞
- 把权限判断交给模型 ✗（提示词写"你不能改地址"，模型仍可能改 ✔）；
- 只在界面隐藏按钮 ✗（直接调接口就绕过了 ✔）—— 与检索权限同一个坑 ✔；
- 权限配置写死在代码里 ✗（改一次要发版 ✔）→ 放配置 ✔，但要有审计与默认拒绝 ✔。
一条判据
拿一份"越权用例清单"（20 条 ✔）直接打接口（不走界面 ✔），
是否全部被拒绝且拒绝原因清楚 ✔？有一条通过，就是权限漏洞 ✗。