分享对象：未接触飞书低代码但有兴趣的开发人员
分享目标：快速理解核心价值 · 建立低代码认知 · 激发实践兴趣
作为开发人员，我们是否经常面临这些场景？
紧急需求上线压力：3天内完成临时工具，传统开发周期1-2周
重复劳动冗余：通用工具需重复编写前端/后端/数据库代码
模块复用困难：不同业务线重复开发权限、消息等通用模块
需求变更响应慢：字段/流程调整需重新编码部署
核心矛盾：传统开发的"高成本、长周期" 与 业务需求"快迭代、轻量级"的不匹配
飞书APaaS——为解决这些问题而生的低代码开发平台
飞书APaaS不是"简化版编码"，而是开发人员的效率工具，核心优势是站在飞书生态的"巨人肩膀上"
复用飞书组织架构、员工信息、角色权限，无需开发登录模块
无缝对接飞书消息、会议、文档，无需集成第三方接口
直接关联飞书多维表格、审批、人事等原生应用数据
自动适配飞书PC端、移动端、网页端，无需额外开发
自动部署、版本管理、监控告警，无需关注底层资源
以"项目任务分配与跟踪工具"为例：
| 开发模块 | 传统编码开发 | 飞书APaaS开发 |
|---|---|---|
| 登录与权限 | 开发账号密码登录、角色权限管理 | 直接复用飞书组织架构与权限 |
| 任务创建与分配 | 开发前端表单、后端接口、数据库表 | 拖拽表单组件，关联飞书员工数据 |
| 进度提醒 | 集成第三方消息接口，开发提醒逻辑 | 配置飞书消息通知规则，一键触发 |
| 数据统计报表 | 开发报表前端、数据查询接口 | 拖拽报表组件，关联任务数据自动生成 |
| 多端适配 | 分别开发PC端、移动端界面 | 平台自动适配，无需额外开发 |
表单、列表、报表、流程等组件拖拽配置，无需编码
JavaScript脚本、API调用、Webhook扩展复杂逻辑
可视化创建数据模型，关联飞书原生/外部数据
可视化设计分支、条件、并行等复杂流程
轻量级业务系统、内部协作工具、数据报表工具、审批流程应用、飞书生态扩展应用
高并发交易系统、核心算法密集型应用、深度定制UI/交互的C端APP、脱离飞书生态的独立系统
从"从零构建"到"组合创新"，聚焦核心业务差异，复用飞书生态能力
简单逻辑可视化拖拽，复杂逻辑编码实现，封装自定义组件复用
从小需求试错：基础工具 → 流程扩展 → 外部对接，快速迭代掌握核心能力
1. 飞书APaaS最大的核心优势是以下哪一项？（ ）
A. 完全不需要编写代码
B. 深度集成飞书生态能力
C. 支持高并发场景
D. 可开发独立C端APP
答案：B
解析：飞书APaaS的核心优势是深度集成飞书组织架构、消息、数据等原生能力；A选项"完全不需要编码"错误（复杂逻辑需编码），C、D均超出其能力边界。
2. 以下哪项需求最适合用飞书APaaS开发？（ ）
A. 企业电商交易平台
B. 内部员工考勤查询工具
C. 大数据分析引擎
D. AI图像识别系统
答案：B
解析：内部员工考勤查询工具属于轻量级内部工具，可复用飞书组织架构和考勤数据，适合飞书APaaS；A（高并发）、C（算法密集）、D（核心算法）均超出其能力边界。
1. 作为开发人员，在使用飞书APaaS开发时，如何平衡"可视化拖拽"和"编码"的使用？
参考答案：
简单逻辑（如表单布局、基础列表、简单流程）用可视化拖拽实现，减少重复劳动；复杂逻辑（如数据清洗、复杂计算、外部系统对接）用编码（JavaScript脚本、API调用）实现；将常用复杂逻辑封装成自定义组件复用，兼顾效率和灵活性。
2. 假设业务方提出"开发一个跨部门需求审批工具，要求3天内上线"，请简述你用飞书APaaS的开发思路。
参考答案：
① 复用飞书组织架构，确定审批流程中的角色（申请人、部门负责人、审批人）；
② 用可视化拖拽创建需求审批表单（含需求描述、优先级、关联部门等字段）；
③ 用流程引擎设计审批流程（申请人提交→部门负责人审核→审批人终审，按优先级设置节点）；
④ 配置飞书消息通知规则（每步审批后提醒相关人）；
⑤ 拖拽生成审批进度查询列表；
⑥ 测试后上线，全程聚焦核心流程，无需开发登录、权限等模块。
飞书APaaS对开发人员而言，是效率升级而非"技术降级"——摆脱重复劳动，聚焦核心业务与技术创新
飞书APaaS将持续迭代：更强大的代码扩展能力、更丰富的组件库、更深度的外部集成
结合所在部门需求，构思一个适合用飞书APaaS开发的工具，下次交流分享！
谢谢大家！
Q&A 环节欢迎交流