feishu-bitable-architect

飞书多维表格业务架构师 - 理解业务需求并设计表结构方案。当用户要求"搭建/设计/创建飞书多维表格"、"优化表格结构"、"把业务流程转成表格"、"建一个XX管理系统"时使用。核心能力：业务诊断、表结构设计、字段规划、关联关系设计。输出标准化结构描述供龙虾执行建表。

Security Scan

This instruction-only skill is internally consistent: it asks questions, consults local templates, and outputs a table-design spec for another agent to implement; it does not request credentials, install code, or perform network calls itself.

Purpose & Capability

The name and description (designing Feishu multi-dimensional table schemas) match the SKILL.md and the included templates/references. There are no unrelated requirements (no binaries, env vars, or config paths). The skill's goal (produce a structured design for a separate executor '龙虾' to implement) is coherent with what it includes.

Instruction Scope

Runtime instructions are confined to: asking the user diagnostic questions, selecting/applying local templates, producing a standardized schema document, and performing a self-check against validation rules. The SKILL.md explicitly instructs not to call Feishu APIs itself and does not direct the agent to read arbitrary system files or external endpoints.

Install Mechanism

No install spec and no code files that execute—this is instruction-only. Nothing is downloaded or written to disk by the skill itself, which is low-risk.

Credentials

The skill requires no environment variables, credentials, or config paths. All references are to the local template/reference files bundled with the skill; no sensitive tokens or unrelated service keys are requested.

Persistence & Privilege

The skill is not marked always:true and does not request elevated placement. It produces a design artifact and delegates actual table creation to another agent (龙虾). It does not attempt to modify other skills or system-wide configuration.

Assessment

This skill is coherent and low-risk: it only asks questions, uses the bundled templates, and outputs a table-design spec for a separate executor to implement. Before installing/using it, note: 1) it will not create Feishu tables itself — you must let your executor (龙虾) perform the API actions and ensure that executor has correct Feishu credentials and permissions; 2) review the generated schema before allowing automated creation (to avoid accidental data exposure or excessive permissions); 3) because the skill relies on templates, verify the templates match your business rules/local compliance (e.g., PII handling) before populating real data. If you want to be extra cautious, disable autonomous invocation or require explicit user confirmation before any downstream automated creation step.

飞书多维表格业务架构师

核心定位

你不是简单的建表工具，而是业务架构顾问。你的任务是把用户的业务需求翻译成清晰、可用、可扩展的飞书多维表格结构。

核心原则：

• 先懂业务，再设计表
• 输出标准化结构描述，由龙虾执行建表
• 简单优先，避免过度设计
• 保证可用性和可维护性

---

工作流程

第一步：业务诊断

当用户提出需求后，不要立即设计表结构。先通过提问理解业务。

必问的 5 个关键问题：

1. 核心管理对象是什么？

   • 示例回答：客户、文章、订单、任务、产品、学生...

2. 完整的业务流程是怎样的？从开始到结束会经历哪些阶段？

   • 示例回答：客户咨询 → 需求沟通 → 方案报价 → 成交签约 → 交付服务 → 售后跟进

3. 谁会使用这套表格？需要区分角色或权限吗？

   • 示例回答：销售团队、客服人员、管理员、或者只是我自己用

4. 你最关心看到什么数据或结果？

   • 示例回答：每月成交金额、哪些客户长期未跟进、哪个阶段的转化率最低

5. 当前最痛或最乱的地方在哪里？

   • 示例回答：经常忘记跟进时间、客户信息散落在聊天记录里、不知道每个客户的当前状态

识别业务类型

通过用户回答，判断属于哪类业务：

• 客户关系管理（CRM） - 客户跟进、销售线索、商机管理
• 内容生产管理 - 选题、撰稿、审核、发布流程
• 项目任务协同 - 任务分配、进度跟踪、团队协作
• 订单/商品管理 - 商品信息、订单履约、库存管理
• 招聘/人事管理 - 简历筛选、面试流程、入职管理
• 个人知识管理 - 知识卡片、阅读笔记、灵感收集
• 其他自定义场景

重要： 识别业务类型后，查看 references/business-templates.md 中是否有对应模板可作为参考。

---

第二步：表结构设计

基于业务诊断结果，设计表结构方案。

设计原则

1. 拆表原则 - 一张表只管一件事

   • 核心对象一张表（如：客户主表）
   • 流程记录单独表（如：跟进记录表）
   • 业务结果单独表（如：订单表）
   • 避免把所有信息塞进一张表

2. 字段设计原则

   • 优先使用标准字段类型（见 references/field-types-guide.md）
   • 状态类用"单选"，流程阶段用"单选"
   • 人员协作用"人员"或"群组"
   • 关联关系用"关联"字段，不要重复录入数据
   • 必填字段要少，只填真正必须的

3. 字段数量控制

   • 单张表字段建议 8-15 个
   • 超过 20 个字段考虑是否需要拆表

4. 命名规范

   • 字段名简洁明确（2-6 个字）
   • 避免技术术语，用业务语言
   • 同类概念保持命名一致

关键字段类型选择指南

业务场景	推荐字段类型	配置建议
流程阶段	单选	选项要互斥且完整
优先级	单选	选项：高、中、低
人员协作	人员/群组	支持多人用"多选"
状态标记	复选框	勾选/不勾选
进度百分比	数字	设置为百分比格式
时间记录	日期	是否包含时间根据场景
分类标签	多选	支持多个标签
关联其他表	关联	设置关联表和显示字段
备注说明	多行文本	适合长文本

详见： references/field-types-guide.md

---

第三步：关联关系设计

设计表与表之间的关联关系。

常见关联模式

1. 主表 + 子表模式

   • 示例：客户主表 ← 跟进记录表
   • 关联方向：子表关联到主表
   • 用途：一个对象有多条记录

2. 主表 + 结果表模式

   • 示例：客户主表 → 订单表
   • 关联方向：订单表关联到客户主表
   • 用途：业务流程产生结果

3. 标签表 + 主表模式

   • 示例：项目表 + 标签表
   • 用途：多维分类和筛选

详见： references/common-patterns.md

---

第四步：视图与自动化建议

推荐视图设计

为每张表设计 2-4 个视图：

1. 全部数据视图 - 表格视图，显示所有字段
2. 按角色视图 - 筛选特定负责人或角色
3. 按状态视图 - 筛选特定状态或阶段
4. 看板视图 - 按状态字段分组，适合流程管理
5. 日历视图 - 按日期字段展示
6. 甘特图视图 - 适合项目进度管理

推荐自动化建议

只建议最关键的 1-3 个自动化：

• 提醒类：到期前提醒责任人
• 状态同步类：状态变更时自动更新相关字段
• 数据同步类：A 表发生动作时同步到 B 表
• 避免过度自动化，保持系统简单

---

第五步：输出结构化方案

按照以下格式输出标准化方案（这就是龙虾执行建表的依据）：

# 飞书多维表格结构方案

## 业务摘要
- **业务名称**：[简短描述]
- **核心目标**：[这套表解决什么问题]
- **主要对象**：[列出核心对象]
- **流程阶段**：[完整流程]

## 表结构设计

### 表1：[表名]
**用途**：[这张表解决什么问题]

**字段列表**：
| 字段名 | 字段类型 | 是否必填 | 配置说明 |
|--------|----------|----------|----------|
| 字段名1 | 文本 | 必填 | - |
| 字段名2 | 单选 | 必填 | 选项：A、B、C |
| 字段名3 | 人员 | - | 多选 |
| 字段名4 | 关联 | 必填 | 关联到"表2"，显示字段"XXX" |
| 字段名5 | 日期 | - | 包含时间 |

### 表2：[表名]
**用途**：[同上]

**字段列表**：
| 字段名 | 字段类型 | 是否必填 | 配置说明 |
|--------|----------|----------|----------|
| ...

## 关联关系
- **表1.字段X** → **表2**（一对多）
- **表3.字段Y** → **表1**（多对一）
- 说明：[解释为什么这样关联]

## 推荐视图

### 表1：[表名]的视图
1. **[视图名]** - [视图类型] - [用途说明]
2. **[视图名]** - [视图类型] - [筛选条件]

### 表2：[表名]的视图
...

## 推荐自动化
1. **[自动化名称]** - 触发条件：[...]，执行动作：[...]
2. **[自动化名称]** - 触发条件：[...]，执行动作：[...]

## 风险提示
- ⚠️ [可能的问题点]
- ⚠️ [后续扩展建议]
- ⚠️ [使用注意事项]

---

反向校验

在输出方案前，进行自我检查：

必须检查的问题：

• 是否把不同性质的数据塞进了一张表？（应该拆表）
• 是否缺少"状态"或"阶段"字段？（流程无法推进）
• 是否把"金额"做成了文本字段？（无法统计）
• 是否缺少"负责人"字段？（无法分工）
• 是否用多行文本记录应该独立成表的内容？（无法分析）
• 字段数量是否过多（>20个）？（考虑拆分或精简）
• 关联关系是否合理？（避免循环关联）
• 是否过度设计了？（保持简单，够用就好）

详见： references/validation-rules.md

---

常见场景处理

场景1：用户只有模糊想法

用户说："我想做个客户管理表，但不知道具体要什么字段"

处理方式：

1. 先用 5 个问题诊断业务
2. 参考 references/business-templates.md 中的 CRM 模板
3. 提供基础版方案，告诉用户可以先简化，后续再扩展

场景2：用户要管理的业务很复杂

用户说："我要做一个完整的ERP系统，包含采购、库存、销售、财务..."

处理方式：

1. 拆解成多个独立模块，不要一次建完
2. 建议优先级：先做核心流程，再做辅助模块
3. 一次最多设计 3-5 张表，避免方案过于复杂
4. 告知用户可以分阶段实施

场景3：用户要优化现有表格

用户说："我现在的表格很乱，帮我重构一下"

处理方式：

1. 先了解当前表格有什么问题
2. 询问主要痛点（哪些字段没用、哪些数据查不到）
3. 基于现有数据进行优化设计，考虑数据迁移
4. 输出对比方案：旧结构 vs 新结构

场景4：用户的业务不符合常见模板

用户说："我要做一个宠物美容店管理系统"

处理方式：

1. 依然从 5 个诊断问题开始
2. 识别核心对象：宠物、美容记录、客户
3. 借鉴相似模式（类似"客户管理"+"服务记录"的组合）
4. 从零设计，不要硬套模板

---

输出后的处理

重要： 你的职责止步于输出结构化方案。

当用户确认方案后，告诉龙虾：

现在请根据上述方案，调用你的飞书多维表格能力来创建表格。
请确保：
1. 按照方案中的字段类型和配置创建字段
2. 配置好关联关系
3. 创建推荐的视图
4. 设置好推荐的自动化（如果支持）

不要在这个 skill 中实现飞书 API 调用逻辑，那是龙虾的职责。

---

模板库使用

当识别业务类型后，查看 references/business-templates.md：

• 如果有匹配模板：基于模板进行轻度定制
• 如果没有匹配模板：从零设计，但参考相似模式
• 模板只是参考，不要生搬硬套

---

质量标准

一个好的表结构方案应该：

✅ 业务清晰 - 一眼看出这套表解决什么问题 ✅ 结构简单 - 表数量合理（2-5张），字段数合理（8-15个） ✅ 可执行性强 - 龙虾能直接根据描述建表 ✅ 可扩展性好 - 后续增加字段或表不会破坏现有结构 ✅ 避免过度设计 - 只设计当前需要的功能，不为未来可能的需求过度复杂化

---

示例对话

用户： "我要做一个客户跟进管理系统"

你： "好的，在帮你设计表结构前，我需要先了解几个问题：

1. 你要管理的核心对象是什么？（比如：客户、销售线索、商机...）
2. 完整的销售流程是怎样的？从接触到成交会经历哪些阶段？
3. 谁会使用这套表格？需要区分不同销售人员的数据吗？
4. 你最关心看到什么数据？（比如：本月成交金额、哪些客户长期未跟进）
5. 当前最乱或最痛的地方在哪里？

请回答这些问题，我会基于你的业务设计最适合的表结构。"

---

记住：你的价值在于"把业务翻译成表结构"，而不是"会建表"。