[RULE] 能力同意矩阵

类型: 流程
强度: 9/10
验证: ✓0 / ✗0

定义

IF: AI 需要决定是否执行某个动作

THEN: 用「能力 × 同意」二维矩阵做判断

              有同意              无同意
         ┌─────────────────┬─────────────────┐
有能力   │  直接执行        │  请求同意        │
         │  → 做完通知      │  → 同意后执行    │
         ├─────────────────┼─────────────────┤
无能力   │  请求授权        │  Handover       │
         │  → 授权后执行    │  → 交给用户     │
         └─────────────────┴─────────────────┘

原理

把复杂决策降维成 2×2，好理解、好实现、好解释。

两个维度

维度	定义	判断依据
能力	AI 能否完成这个动作	工具链、API、技术能力
同意	用户是否允许 AI 自动做	历史授权、风险等级、偏好

四种策略

象限	策略	示例
有能力+有同意	直接执行	自动回复标准退款邮件
有能力+无同意	请求同意	"我可以帮你做 X，你同意吗？"
无能力+有同意	请求授权	"我需要访问日历权限才能帮你安排"
无能力+无同意	Handover	给出背景和建议，交给用户

渐进式授权

用户信任是逐步建立的：

初始状态：大部分动作无同意
    ↓
AI 每次请求同意时，用户可选"以后这类都自动做"
    ↓
系统记住偏好，下次同类动作自动执行
    ↓
用户逐步放权，AI 能做的越来越多

应用场景

场景	判断
会议邀请 → 生成 Prep Doc	有能力+无同意 → 请求同意
退款申请 → 执行退款	有能力+有同意 → 直接执行
PR 通知 → 读取 diff	无能力(需API)+有同意 → 请求授权
合同审阅 → 最终决策	无能力+无同意 → Handover

与"换位思考"的结合

1. AI 换位思考：如果我是用户，我想做什么？（Intent）
2. 把 Intent 拆成 Action Chain
3. 对每个 Action 用本矩阵判断
4. 执行 / 请求 / Handover

证据

支持: INFO-066（AI 驾驶舱/人的选择是 AI 上限）
反例: 暂无

关联

INFO: INFO-20251219-066（AI 驾驶舱）
RULE: RULE-先Spec后代码（Action 需要 Spec 定义）
NODE: NODE-AI-Agent
NODE: NODE-数字家园