飞书权限最危险的地方，不是“它看到了”，而是“它能动了”
很多人第一次接 OpenClaw 到飞书，思路都很自然：
- 能不能读消息
- 能不能发消息
- 能不能改文档
- 能不能写表格
看起来都是为了“更好用”。
但一旦你把它接进真实工作环境，问题就变成了：
这些权限真的都该现在就给吗？
答案通常是否定的。
为什么“能用”不等于“该开”
因为权限不是越全越好，而是越全越难收。
飞书里很多权限一旦开出来，问题就不再只是“它能不能帮你干活”，而是：
- 它是不是能以你的身份发出去
- 它是不是能改真实文档
- 它是不是能读到你本来没想让它读的东西
- 它是不是能长期保持这种能力
这就是为什么飞书权限真正该遵循的是：
最小权限，而不是最大便利。
最该保守对待的 5 类权限
1. send_as_user
这是最典型的高风险权限。
一旦开了，它就可能不只是“帮你回复”，而是真的以你的身份去发内容。
风险点在于：
- 发错就是你发错
- 群里看见的是你，不是机器人
- 一旦误判，成本很高
2. offline_access
这意味着它可能在你不在场的时候，继续刷新并使用用户权限。
这类权限危险的地方在于：
- 时间跨度变长
- 审计难度提高
- 你对“它现在还能做什么”的感知会变弱
3. 文档写权限
例如：
- 创建文档
- 改文档
- 评论
- 上传文档媒体
只读和读写差别非常大。
一旦写权限开宽，误操作就直接变成真实改动。
4. 多维表格写权限
很多人低估多维表格的敏感性。
但在很多团队里，多维表格已经是实际业务系统的一部分。
它一旦能改：
- 记录
- 字段
- 表结构
- 视图
那就不只是辅助，而是在碰业务数据了。
5. 日程 / 任务 / 通讯录
这类权限的风险不一定直观，但很真实：
- 日程会暴露会议安排
- 任务会暴露工作进度
- 通讯录会暴露组织结构
它们在很多场景下，比“会不会发消息”更敏感。
为什么很多人会开过头
原因通常不是鲁莽，而是这三个错觉：
错觉 1：先全开，后面再慢慢收
现实通常相反。
一旦习惯建立起来，后面你只会越来越不想收。
错觉 2：我自己在用，所以风险可控
问题是，很多风险不来自“别人攻击你”，而来自：
- 误操作
- 幻觉
- 规则没写清
- 技能链路叠加
错觉 3：我已经有机器人了，所以它应该什么都能做
机器人存在，不等于它就应该拥有全部能力。
能做和该做，是两回事。
更稳的开权限顺序
更现实的顺序通常是：
- 先开最小消息读取和最小回复能力
- 先在测试群或私聊验证
- 再开文档读取
- 最后才考虑文档写入、表格写入、用户身份发送
也就是说，顺序应该是：
- 先看见
- 再理解
- 再建议
- 最后才是替你动手
如果你是个人用户，最该记住什么
先拿个人账号玩起来，别一上来接企业真实环境。
尤其在下面这些情况里，更应该保守：
- 你还在试各种社区 skill
- 你还没做初始化
- 你还没有“先预览、再确认”的使用习惯
如果你是企业管理员，最该盯什么
你最该盯的不是某一个模型，而是：
- 哪些应用能接
- 哪些权限能开
- 哪些机器人能进群
- 是否有
send_as_user - 是否有
offline_access - 审计看不看得到
很多治理问题，不在使用层，而在接入层就已经决定了。
一个最实用的判断句
如果某项权限让 OpenClaw 从“帮你看”变成“帮你做”，那它就应该比你想象中更谨慎。
这类权限不是不能开，而是：
- 要更晚开
- 要更小范围开
- 要更明确地知道失败代价
结论
飞书权限越强，OpenClaw 能做的确实越多。
但真正成熟的用法，从来都不是“先把能开的都开了”，而是：
先用最小权限跑稳，再一点点放开真正有价值的能力。
权限越强，越要保守。
这是为了长期可用，不是为了保守本身。