第一次听产品同学说 Zion 要新增“数据鸟瞰图”时我内心 be like……“我们的用户真的需要用‘鸟瞰图’来管理数据库吗自己建了几张表、留了几个字段心里能没数”但在看完这期关于【Zion数据鸟瞰图的设计思路】的直播后我发现自己以前想得太简单了里面的确有太多没想到的痛点。比如很多项目一旦复杂起来就会涉及到非常多的数据表和密密麻麻的字段。那些常用的字段我们确实记得住可如果哪天你想改一个看似不起眼的边缘字段你大概率记不清它在前面几十个页面、上百个组件、甚至哪一层的嵌套交互里被调用过。这时候动上一笔心里全是顾虑生怕系统哪个看不见的角落会偷偷挂掉。再比如当我们去接手别人的项目或者回头面对自己很久没碰的旧系统时看着错综复杂的结构和依赖关系一时之间真的很难理出头绪更别提快速上手了。还有最关键的一点也是 Zion 团队在做产品规划时考虑得比较深远的地方那就是我们未来要尝试用 AI 来辅助开发。但大家知道AI 每次重新启动时对以前的上下文是没有记忆的。如所以这些棘手的难题究竟如何通过一张“鸟瞰图”迎刃而解完整的直播回放已为你放在了文末「阅读原文」中。如果你更习惯安静地阅读我也将直播中关于技术、产品和 AI 协同的核心高光对话整理成了文字。希望这些思想火花能带给你全新的启发。主持人覃貌Zion 开发者生态负责人嘉宾汪宁Zion 产品经理、蒋耀锴Zion CEO为什么单靠页面设计无法支撑复杂应用覃貌: 很多用户在刚看到“数据鸟瞰图”这个功能时可能是一脸懵逼的不知道它是为什么场景设计的。汪宁作为产品经理能不能先跟大家聊聊我们做这个功能的初衷是什么汪宁: 简单来说这个鸟瞰图是从数据的视角来展示我们每一个后端节点以及后端跟前端组件之间的引用关系。我们大部分人理解或搭建一个应用视角通常是从 UI 页面出发的。比如有首页、个人主页里面有各种按钮按钮下又绑定了各种行为流。如果你只从 UI 视角去理解应用会带来一个非常大的问题UI 的层级太深了。一个按钮的第三级交互里可能去修改了某张表。一旦项目变复杂你要记住每个页面的几十个地方都绑定了什么。当你去改动某张表时心里负担会极大因为你不知道改了这个字段会不会导致其他地方崩溃。而数据鸟瞰图就是让你换一个视角。在你不做二次开发或重大升级时它可能显得没那么重要但当你做商业级项目时它能让你从扁平的数据流转层面全局去俯瞰整个应用。蒋耀锴: 其实这涉及到你如何给应用建立“心理建模”。理解一个东西一方面可以通过它的名字和内部结构另一方面更需要通过它“被谁调用”来理解。就像你理解一辆车名字叫“汽车”名字结构是四个轮子加个壳子内部结构但它的用途是“把人从 A 运到 B”被谁调用。有了被调用的视角你对这个东西的了解才完整。覃貌一说汽车我脑子里马上有了画面。这就像是一个“3D 爆炸图”把整个系统底层的调用关系都展开了。汪宁: 对。这就像盖房子为什么水电要先做还要留水电图因为如果你没有电路图和水路图等以后哪个水管坏了你难道要把整堵墙砸开去检修吗有了图你哪个开关坏了直接去对应的节点检修就行不需要砸墙。在 Zion 里也一样。你改了一个字段或者行为流通过鸟瞰图能直接看到它被哪些页面的哪些按钮调用了。你不用在页面、组件里一层层去点直接点过去修改就行。鸟瞰图其实是给 AI 准备的蒋耀锴其实这里还有一个更核心的思考数据鸟瞰图很大程度上是我们为了给 AI 使用而设计的。覃貌给 AI 来用怎么说蒋耀锴比如你刚才在数据模型里加了一个列你接下来要去哪里补全数据绑定人搭过这个项目或多或少还能凭借记忆去找。但 AI 不行AI 每次重新启动时对以前是没有记忆的。如果没有这个关系依赖图AI 根本不可能找到这个字段在哪被调用过。这时候就会出现一个问题AI 修改了一个地方运行的时候其他地方却挂了而且你无法保证能运行到每一个分支。所以如果没有这个逻辑调用图AI 几乎无法去维护一个商业级的产品。汪宁这也涉及到 AI 的 Token 消耗和理解能力。如果把一个复杂项目的全部 Schema 和代码细节直接丢给 AI 当上下文大一点的项目可能会有几十兆MBAI 的上下文窗口直接就爆炸了它根本理解不了。而我们做数据鸟瞰图在底层其实是做了一层抽象。我们用三个字段来表达节点是什么、跟谁有关系、关系是什么。我们把信息密度集中到最大并提供了一个对 AI 极其友好的结构。当 AI 快速理解了这个项目的表关系、AI agent 相互调用关系后它在做增删改查时就会有非常精准的上下文绝对不会漏掉任何受影响的地方。为什么“修改”才是硬骨头覃貌刚才蒋老头现场秀了一手用 AI 直接操控 Zion 的后端去重置项目、建表、做关联甚至生成行为流。我活学活用一下这意思是以后开发者真的只需要跟 AI 交流就能把一整套后端搭出来完整演示可通过点击文末「阅读原文」查看蒋耀锴像刚才演示的我输入“搭建一个二手交易平台要能够付钱”AI 就会自己去建二手物品表、评价表建立关联和约束。甚至连“创建订单”和“安全下单”这种大家平时最容易搞错的服务端定价行为流它都能自己拼出来。如果它觉得无代码拼不出来的复杂逻辑它还会自己写代码块塞进去。覃貌那如果像最近特别火的视频生成模型我想接个 API。如果我不会接是不是可以把这个接入流程编成一个 Skill 丢给 AI然后 AI 结合我自己的数据库设计直接帮我把整个流程打通蒋耀锴可以写个 SkillAI 就能拿着它去搭想象空间非常大。我们很早就在规划AI 搭建需要什么底座。其实从零搭建是最简单的因为不需要理解前人做了什么。最难的是修改修改永远比搭建更困难这就又回到了数据鸟瞰图必须让 AI 清楚地知道每一次修改会影响到哪些范围并把影响到的地方全部修复。只有具备这个闭环AI 搭建才真正具有商用价值。为什么其他平台不做“数据鸟瞰图”覃貌汪宁我之前也用过不少无代码或低代码平台但我好像没看到其他平台做过类似“数据鸟瞰图”这样的功能。是他们不想做还是这背后有什么难点汪宁 我大胆预测一下主要是他们做不到。 大家可能觉得这只是在前端画一张关系连线图。但在无代码编辑器里元数据往往是非常零散和变态的——比如一堆组件、一堆按钮和各种散落的行为。你要把这么杂乱的底层配置数据抽离出来并转化成一个严格的关系视图技术难度极高。像飞书文档也有文档引用图但它的节点类型只有一种就是 doc。而在 Zion 里我们的节点类型极其复杂有数据库、数据表、API、行为流、AI agent、全局变量、权限、触发器、组件、页面……关系类型又有添加、调用、修改等。覃貌听起来节点和关系的维度完全是指数级上升了。汪宁对。首先要把这个极其复杂的节点关系矩阵在产品层面梳理清楚其次要分析我们整个项目的 Schema把结构化数据剥离出来最后还要用前端框架把它高效地渲染出来。当项目非常庞大有成千上万个节点和复杂调用时怎么让浏览器渲染拓扑图而不崩溃本身也是一个巨大的前端性能挑战。所以产生这份图背后的高密度数据结构才是最难搞的。如何平衡“功能强大”与“简单易用”覃貌现在很多低代码平台都在做减法追求“化繁为简”。但看 Zion 的动作比如做数据鸟瞰图、接下来还要做测试环境、版本管理、分支合并等感觉你们反而在做加法展示出很多密密麻麻的专业逻辑。耀锴你是怎么思考 Zion 的产品观和工具观的蒋耀锴本质上你对一个东西想要拥有掌控权你就必须拥有完整的信息。你是不可能把对业务逻辑的理解完全外包出去的。降低难度有两种方式一种是工具帮把复杂度“吸收”掉也就是工具替你做决定。但用户的具体业务逻辑我们是绝对无法替他做决定的。在 Zion 里我们希望每一个节点用户都能深度介入并自己做决策。既然要决策你就得拥有完整的信息否则你凭什么做决策所以如果你想开发商业级的应用你就必须付出对应的代价也就是你的认知代价这是逃不掉的。汪宁作为一个想做出商业级应用的 IDE 开发工具功能的完备度是绝对不能打折的。如果我们连函数调用关系、环境和分支都没有那我们就不是一个合格的 IDE。但“功能完备”不等于“界面繁琐”。我们可以通过“渐进式披露”Progressive Disclosure来组织用户的行动线索。当用户在搭 UI 时他只需要关注前端怎么画当他想梳理业务逻辑时可以通过鸟瞰图清晰地看懂数据引用而当他想提高效率时可以用 AI 来生成和修改内容。任何你在前端看起来极简、用起来极其轻松的体验底层都必须有一套极其有秩序、甚至很复杂的系统在支撑着。所有的秩序感都是复杂的但正是因为我们把底层的复杂配套健全了用户才能用得如此随意和优雅。✍️ 小编笔记以前我们总觉得做开发、搭应用只要眼睛盯着前端漂亮的页面和按钮就够了。但实际上当项目规模越做越大底层错综复杂的调用关系早晚会变成一个谁也理不清的“无底洞”。而“数据鸟瞰图”的出现不仅仅是让我们在日常开发中能少掉几根头发、在修改代码时少踩几个坑更重要的是它为未来的 AI 辅助开发搭建好了关键的安全网。只有让 AI 拥有了这份“系统全局高精地图”它才能真正安全地帮我们去修改和维护一个商业级的项目而不是每次重启都像瞎子摸象。正如直播里说的那样底层的秩序感越是复杂和健全用户在前端的使用体验才能越随意、越优雅。