飞书一体化业务平台

背景

很多企业已经采购了多个业务系统：CRM、合同、财务、费控、进销存、生产管理等。单个系统各自能解决问题，但客户真实的生产场景从不是孤立的，而是由一个个业务系统串起来的整套解决方案。这些独立采买的业务系统之间，数据不同步，流程串联靠人跑，权限开通重复，外部系统接入飞书后体验仍然割裂。飞书一体化业务平台要解决的，就是让客户高频使用的业务系统和飞书更深度预集成，帮助企业把原本割裂的数据、流程、权限和体验重新组织起来。让业务人员就能自己搭流程，自己迭代流程 这个项目早期方向并不清晰。上文提到的数据统一、权限统一、流程统一、体验统一都看起来重要，但资源有限，商业化目标又很明确。产品经理主导了产品方向和范围收敛，我在这个过程中配合参与调研、竞品分析和方案讨论。随着团队逐步判断“流程统一”比数据统一、权限统一更适合作为第一阶段突破口，因此我们要解决的第一个问题是：如何把复杂流程集成设计成业务人员可理解、可搭建、可调试的产品体验。

战略层

用户是谁

在这个项目的团队之前都是为开发者服务，不论是产品还是研发，都收到了所谓“知识的诅咒”，不自觉会代入开发者视角。而我们的命题是要让业务人员，也可以说是普通小白自己搭建业务流程，自己迭代业务流程。最重要的是定义清楚 开发者 和 业务人员 的差别：我把这个差别概括为“三无”：

无代码环境：电脑里没有 IDE，也不会本地调试代码。
无代码知识：不理解入参、出参、凭证、对象、数组等概念。
无代码思维：不习惯用循环、变量、判断、接口等方式描述业务问题。

这直接影响了后续所有设计决策。但产品里不可避免要支持循环、判断、HTTP、代码节点，因为复杂业务系统连接离不开这些能力。但这些能力不能原样暴露给业务人员。设计上必须逐步把技术概念翻译成业务语言：

入参、出参、凭证转译成输入、输出、账号
数组转译成列表
技术字段默认隐藏，只暴露用户完成任务所必需的信息
复杂逻辑先用基础节点承载，后续再沉淀成更聚合的业务节点

这里的核心权衡是：面向业务人员不等于产品没有技术复杂度，而是设计要把复杂度放在用户不必理解的地方。

范围层

先解决流程统一和体验统一问题

这个项目并不是一开始就确定要做工作流。早期团队曾讨论过把生态应用包装成一套解决方案，从数据、权限、流程、体验 4 个方面实现一体化。

在进一步调研后，团队发现数据统一和权限统一都高度依赖客户内部组织推动，产品很难在早期快速规模化。因此第一阶段最终收敛先解决“流程统一”和“体验统一”： **流程统一：**解决跨系统流程靠人工串联的问题，让业务人员可以通过工作流把多个系统连接起来 **体验统一：**将飞书设计规范对外开放，让更多商店应用能够改造成飞书的样子，给用户统一的体验

这个过程中，我参与的不只是界面设计，还完整推动飞书设计规范对外开放。

结构层

平台信息架构

用户可以创建、修改和删除工作流。每个工作流下面会有版本管理，平时编辑的是草稿版本，确认没问题后再发布成正式版本。工作流会包含多个节点，每个节点代表工作流中的一步，比如定时发送、生成文案、调用模型等。用户在搭建过程中可以对节点或整条流程进行调试，系统会记录调试结果，方便排查问题。正式运行后，系统也会留下日志，用来回看每次执行的情况。
应用是飞书应用市场里的接入的应用（如汇联易、智书合同等），给工作流提供相应的业务能力。一个应用下面可以包含多个操作，也可以配置多个账号。操作可以理解成具体能力，比如查询订单、生成合同、发送消息、创建表格、更新表格等；账号则用于管理这些能力背后的授权和访问身份

框架层

1. 工作流页面框架

我把页面拆成三个区域：导航区、画布区和操作区。画布是用户最主要的工作空间，所以尽量保持完整、开阔；导航和操作都围绕画布服务，而不是抢画布的注意力。我重点考虑了 2 个点：

操作区的方向要尽量和工作流的主方向垂直。因为工作流通常会沿着一个方向延展，如果操作区也顺着同一个方向展开，就很容易和节点、连线、浮层互相遮挡，也容易让用户在拖拽或点击时误触。把操作区放在垂直方向上，可以减少和画布内容的冲突，让用户操作时更稳定。
导航区要尽量轻量。这个页面的核心不是“逛导航”，而是在画布里搭建和调整流程，所以导航不应该占太多空间。我把导航做得更薄、更弱，让它只承担定位和切换的作用。这样视觉上会更轻快，画布也能获得更多展示空间，用户进入页面后注意力会自然落在正在编辑的内容上。

2. AI 对话区和画布区的框架布局

在一体化平台里，AI 的价值很明确：业务人员不懂代码、不懂接口、不懂工作流节点，如果让他们从零搭建复杂流程，门槛会非常高。AI 可以把用户的一段自然语言需求，转译成可编辑的工作流结构，帮助用户跨过从 0 到 1 的第一步。但我没有选择把 AI 做成默认主路径，而是把 AI 对话放在工作流右侧，作为辅助能力。这里的判断是：AI 可以帮助用户生成流程，但不能替代用户理解和控制流程。一体化平台处理的是企业真实业务流程，一旦配置错误，可能影响客户数据同步、消息触达、审批流转甚至业务系统状态。如果用户只是让 AI 生成了一个东西，但不知道它为什么这样生成、每一步在做什么，后续就很难修改、排查和上线。所以我在 AI 位置上做了一个保守但必要的取舍：

如果 AI 默认占据主舞台，用户会自然把它理解成主要操作方式。
但当时 AI 生成效果还不稳定，复杂业务场景也需要用户持续校准。
如果用户高频依赖 AI，却发现生成结果不可控，会产生很强的心理落差。
因此 AI 更适合作为右侧辅助：帮助生成、解释、修改，但主画布仍然承载确定性的流程结构。

这个设计的核心不是 AI 放左还是放右，而是 AI 在产品里的责任边界：AI 负责降低表达门槛，工作流画布负责提供可理解、可验证、可接管的确定性结构。

3. 工作流走向

在确定主工作流方向时，我对比过横向布局和纵向布局两种方案。

横向布局： 优势是很直观地表达“从输入到输出”的链路关系，视觉上更像一条生产线，也符合很多流程图工具的常见做法。但放到这个产品的实际使用场景里，它会带来一个问题：当工作流变长后，用户需要横向移动画布才能继续查看后面的节点。如果没有触摸板，用户往往需要拖动画布、切换拖拽模式，或者依赖横向滚动，这会打断浏览节奏，不利于快速检查完整流程。
纵向布局： 因为这个产品的高频场景不是大范围自由编排，而是沿着一条 AI 生成链路进行浏览、检查、调试和局部调整。纵向更接近用户日常浏览网页、文档和表单的习惯，用户只需要滚动鼠标滚轮，就能从上到下顺着执行顺序查看完整工作流。这个交互成本更低，也更适合快速定位某个节点、检查节点配置和查看执行结果。
纵向布局也更方便和页面里的其他区域配合。主流程从上到下展开，操作区可以放在侧边，让用户看工作流的同时能看到节点详情。减少节点、连线、浮层之间的遮挡和误触。

4. 工作流节点呈现结构

我对比了 Zapier、Relay、n8n、Make、Dify、Coze、钉钉、飞书多维表格工作流等产品，发现工作流大体有三种结构：

线性工作流：步骤从上到下排列，适合普通用户理解。
半自由式工作流：保留流程走向，同时允许分支、循环等复杂结构。
自由式画布：灵活度最高，但更接近开发者工具。 n8n、Make 这类产品更强调“流”，弱化单个节点的信息，常用图标概括节点。它们足够灵活，但学习成本较高，更适合开发者或技术型用户。 Relay、Zapier 这类产品更接近业务人员心智。尤其是 Zapier 的半自由式结构，既能表达复杂流程，又不会让用户一上来面对完全自由画布。所以我主导选择了更接近 Zapier 的半自由式工作流结构。这个选择不是因为它最强大，而是因为它在复杂度和理解成本之间更平衡。同时，我倾向用自然语言描述节点信息，而不是只展示应用图标和字段组合。因为一体化平台的目标用户不是通过技术字段理解流程，而是通过业务语义理解流程。工作流不是给用户展示系统能力，而是帮助用户理解一件业务事情如何自动发生。

5. 变量引用

在工作流搭建中，一个很难处理的体验点是：用户如何引用前面节点产生的数据。对系统来说，这只是变量和字段选择；但对业务用户来说，前置节点的输出往往包含大量技术字段、嵌套层级和不同数据类型。如果直接把所有字段都展示出来，能力最完整，但用户很容易被字段淹没；如果只展示一部分，又可能影响灵活性。 展示全部字段 我们最初尝试过“展示全部字段”的方案。第一版采用级联菜单，让用户一层层展开字段路径。但在实际业务里，很多商店应用的数据结构层级很深，用户需要频繁横向移动和逐级定位，操作成本很高。后来我们改成在一个面板里用树结构承载字段层级，让信息可以集中展示，避免级联菜单不断展开带来的割裂感。但即便如此，字段数量和层级复杂度依然存在，用户仍然需要在大量信息中判断哪个字段能用、哪个字段合适。因此我把这个问题拆成了 2 个演进阶段。

**按类型过滤：**根据当前配置项需要的数据类型，只优先展示可用字段，比如当前需要文本，就优先展示文本类型字段；只有当用户进入表达式编辑等高级场景时，才展示全部字段，保留灵活性。
**AI 智能推荐：**根据用户当前配置意图、字段名称、节点上下文和历史使用习惯，主动推荐最可能使用的数据，甚至在一些明确场景下直接推荐固定值或表达式。

这个设计点的核心，不是单纯做一个变量选择器，而是降低业务用户在技术字段里迷路的概率。通过“全部可用 → 类型过滤 → 智能推荐”的递进方式，既保留了工作流产品的灵活性，也逐步减少了用户理解字段、判断字段和查找字段的成本。

6. COT 展示

AI 对话里还有一个很有意思的设计问题：要不要展示 AI 的思考过程，以及展示到什么程度。最早很多 AI 产品会用“思考中”告诉用户系统还在处理，这本质上是一种状态反馈，解决的是等待过程中的不确定感。后来 DeepSeek 把深度思考完整展开，用户能看到模型一步步推理，这在当时很有冲击力，也强化了“模型真的在认真思考”的感知。但我认为，完整展开的 COT 很大程度上也带有炫技性质。它证明了模型有能力，却不一定真正服务用户任务。对于一体化平台的业务用户来说，用户的目标不是欣赏 AI 怎么推理，而是判断：

它有没有理解我的业务需求？
它准备怎么拆流程？
哪些步骤需要我确认？
哪些地方可能有风险？
最终生成的工作流能不能跑？

当深度思考全部展开时，反而会产生新的负担。用户懒得看，也很难从长推理里抓住重点。于是行业里的 COT 展示开始演进：从全部展开，到默认折叠，再到部分折叠，再到思考过程和正文穿插出现。我对这个变化的理解是：COT 的价值不在于展示 AI 想了多少，而在于在关键决策点给用户足够的信任和控制感。放到一体化平台里，COT 不应该完整暴露为一大段推理文本，而应该被重新组织成业务用户能消费的中间过程。比如 AI 生成工作流时，可以把思考过程拆成几类：

需求理解：我理解你想把 A 系统的数据同步到 B 系统。
流程拆解：我会拆成触发、查询、判断、写入、通知几个步骤。
缺失信息：我还需要你确认账号、字段映射、触发频率。
风险提示：这个流程会向外部系统写入数据，建议先试运行。
生成结果：下面是可编辑的工作流草稿。

这比完整展示模型推理更有价值。因为它不是让用户读 AI 的脑内独白，而是把 AI 的思考转译成用户可以确认、修改和接管的结构。

我没有把 AI 交互理解成“对话框 + 生成按钮”，而是把它看成复杂业务工具里的新型解释层。AI 要帮用户跨过技术门槛，但不能拿走用户对业务流程的理解权和控制权。因此我在框架上选择让 AI 位于右侧、作为辅助能力；在 COT 展示上，也更倾向于把思考过程转译成可确认的业务步骤，而不是完整展开模型推理。

结果

这个项目最终完成了从方向探索到客户交付的阶段性突破。 **流程统一：**完成了方案探索、客户共创和 MVP 设计，并进入真实开发和上线。在客户交付上，平台陆续服务多个共创客户，并在 2025 年年底完成正式签单，实现商业化价值从 0 到 1 的突破。部分预集成场景具备复用潜力，后续可以开放给更多客户，降低实施成本。 **体验统一：**完成了飞书设计规范对外开放，设计指南和设计规范已在飞书开放平台上线，并向多家联盟伙伴和客户开放设计文件，帮助第三方应用更接近飞书体验。收获了飞书客户的好评

我的收获

这个项目让我更清楚地意识到：当产品方向还不清晰时，设计师的价值不只是把界面画出来，而是帮助团队把复杂能力翻译成用户能理解、能验证、能接管的产品体验。我在这个项目里主导的不是范围定义，而是方向收敛后的核心设计决策：

工作流应该采用什么结构。
技术节点如何转译成业务语言。
添加操作、变量引用、调试链路如何降低理解成本。
AI 应该是主路径还是辅助能力。
COT 应该如何从模型推理变成用户可消费的确认过程。
API 连接器是否适合业务人员。
客户交付如何沉淀成可复用能力。

除了产品体验本身，我也在项目中尝试把 AI 用到实际工作流里。连接器数量变多后，很多产品文案和字段说明需要反复调整，如果完全依赖研发修改，沟通链路长，也会占用研发人力。后来我利用后端提供的数据库运维平台，直接下载连接器原始代码，用 AI 快速批量修改对应的产品文案，再反向同步回数据库。这个过程减少了设计、产品和研发之间的来回沟通，也让我更直观地感受到：AI 不只是产品里的功能，也可以成为设计师提升交付效率的工具。一体化平台的核心不是把所有系统接进飞书，而是帮助业务人员在不理解技术细节的情况下，也能把跨系统业务流程搭起来、跑起来，并在真实业务里持续运转。这也是我在这个项目里最重要的设计判断：好的一体化，不是把复杂性消灭，而是把复杂性重新分配。让系统承担技术复杂度，让用户保留业务判断权；而设计师也可以借助 AI，把一部分重复、繁琐的协作成本交给工具处理，把更多精力放回体验判断和产品决策上。