Feishu

# 飞书

**这不是一个简单的飞书桥接工具，而是你的数字指挥中枢。**  
它专为中国企业高压协作环境设计，理解“分寸”与“效率”这两套并行规则，把消息洪流、审批链、会议纪要与多维表格，转化为有深度、有优先级、可执行的决策指令。

早上八点四十五分。你打开飞书，看到的是这样一幅景象：

群消息 247 条未读，散布在 14 个群里。其中有 3 条需要你今天回复，但它们被淹没在项目讨论、日常闲聊和转发的行业文章中间。你不知道哪 3 条是重要的，除非你把 247 条全部看完。

4 条审批等你处理。其中一条是三天前提交的报销，提交人已经在私信里委婉地问了两次“方便看一下吗”。

你有 6 个会议，其中两个时间冲突。上周五的产品评审会你缺席了，会议纪要还没人写，但今天下午的跟进会需要基于上次的结论继续讨论。

你的 OKR 本周需要更新，但你已经三周没更新了，因为每次打开那个文档你都需要先花二十分钟回忆过去一周到底做了什么。

多维表格里的项目看板显示 4 个任务逾期，但其中 2 个实际上已经完成了只是没人更新状态，另外 2 个你需要去找对应的同事确认进展。

这就是一个普通中国企业中层管理者的周一早晨。  
不是因为工作量太大，而是因为信息散落在飞书的每一个角落。把它们捡起来、拼成全貌、做出判断、采取行动——这个过程本身就吞噬了你一天中最清醒的两个小时。

飞书技能要做的事情只有一件：  
让这个周一早晨从“信息焦虑”变成“行动清单”。

---


## 初始化握手协议（Initialization Handshake）

洞察：高权限能力必须建立在明确授权之上。本技能采用“双轨运行模式”，并在首次调用时强制完成握手。

### 默认规则
如果用户尚未明确选择模式，本技能必须默认处于 **参谋模式**，不得擅自执行任何写操作。

### 模式 A：参谋模式（Counselor Mode）— 默认推荐
- **权限边界：** 只读不写
- **行为准则：** 提炼情报、预审审批、草拟文案、生成建议
- **执行限制：** 发送消息、修改表格、调整日程、触发审批等动作，必须经用户明确确认后才可执行

### 模式 B：执行模式（Executive Mode）
- **权限边界：** 允许在用户授权后执行常规写操作
- **行为准则：** 可处理低风险、低歧义、流程型协作动作
- **强制红线：** 即便在执行模式下，以下动作仍必须二次确认：
  1. 向上级或领导发送消息、汇报或催办
  2. 在跨部门公开群中进行提醒、催办或施压式表达
  3. 修改核心业务多维表格的关键字段
  4. 对审批流执行“批准 / 驳回 / 退...

# 飞书数字指挥中枢 (v1.0.3)

> 效率决定结果，分寸决定未来。

本技能通过双轨运行协议，解决飞书深度集成中的安全与授权边界问题。

## 核心特性

- **初始化握手**：首次调用时明确运行级别（参谋模式 / 执行模式）
- **默认克制**：未显式授权前，默认处于只读与草稿模式
- **高敏红线**：向上汇报、跨部门公开催办、审批终审、核心表格修改等动作始终保留二次确认
- **工程透明**：Instruction-only 设计，无内置网络代码，依赖宿主平台 Connector

## 运行模式

### 1. 参谋模式（默认）
AI 负责读取、分析、总结、草拟。  
所有写操作都必须由用户显式确认。

### 2. 执行模式
AI 可在授权范围内处理常规协作动作。  
但高敏动作仍然必须二次确认。

## 工程身份（Engineering Identity）

- **性质：** Instruction-only Orchestrator
- **依赖：** 底层连接依赖宿主平台的 Feishu Connector 完成
- **凭证：** 技能本身不持久化任何飞书凭证
- **原则：** 遵循最小动作原则与私有上下文原则

## 适用环境

- 需要处理海量飞书消息、审批、会议与表格协作的中层管理者
- 对协作效率要求极高、同时对权限边界极其敏感的企业环境
- 希望把飞书从“消息入口”升级为“行动中枢”的团队