第一次听产品同学说 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 当上下文，大一点的项目可能会有几十兆（MB），AI 的上下文窗口直接就爆炸了，它根本理解不了。
而我们做数据鸟瞰图，在底层其实是做了一层抽象。我们用三个字段来表达，节点是什么、跟谁有关系、关系是什么。我们把信息密度集中到最大，并提供了一个对 AI 极其友好的结构。当 AI 快速理解了这个项目的表关系、AI agent 相互调用关系后，它在做增删改查时就会有非常精准的上下文，绝对不会漏掉任何受影响的地方。
为什么"修改"才是硬骨头？
覃貌：刚才蒋老头现场秀了一手，用 AI 直接操控 Zion 的后端去重置项目、建表、做关联，甚至生成行为流。我活学活用一下，这意思是，以后开发者真的只需要跟 AI 交流，就能把一整套后端搭出来？（完整演示可通过点击文末「阅读原文」查看）
蒋耀锴：像刚才演示的，我输入"搭建一个二手交易平台，要能够付钱"，AI 就会自己去建二手物品表、评价表，建立关联和约束。甚至连"创建订单"和"安全下单"这种大家平时最容易搞错的服务端定价行为流，它都能自己拼出来。如果它觉得无代码拼不出来的复杂逻辑，它还会自己写代码块塞进去。
覃貌：那如果像最近特别火的视频生成模型，我想接个 API。如果我不会接，是不是可以把这个接入流程编成一个 Skill 丢给 AI，然后 AI 结合我自己的数据库设计，直接帮我把整个流程打通？
蒋耀锴：可以，写个 Skill，AI 就能拿着它去搭，想象空间非常大。我们很早就在规划，AI 搭建需要什么底座。
其实从零搭建是最简单的，因为不需要理解前人做了什么。最难的是修改，修改永远比搭建更困难，这就又回到了数据鸟瞰图，必须让 AI 清楚地知道每一次修改会影响到哪些范围，并把影响到的地方全部修复。只有具备这个闭环，AI 搭建才真正具有商用价值。
为什么其他平台不做"数据鸟瞰图"？
覃貌：汪宁，我之前也用过不少无代码或低代码平台，但我好像没看到其他平台做过类似"数据鸟瞰图"这样的功能。是他们不想做，还是这背后有什么难点？
汪宁： 我大胆预测一下：主要是他们做不到。 大家可能觉得这只是在前端画一张关系连线图。但在无代码编辑器里，元数据往往是非常零散和变态的------比如一堆组件、一堆按钮和各种散落的行为。你要把这么杂乱的底层配置数据，抽离出来并转化成一个严格的关系视图，技术难度极高。
像飞书文档也有文档引用图，但它的节点类型只有一种，就是 doc。而在 Zion 里，我们的节点类型极其复杂：有数据库、数据表、API、行为流、AI agent、全局变量、权限、触发器、组件、页面......关系类型又有添加、调用、修改等。
覃貌：听起来节点和关系的维度完全是指数级上升了。
汪宁：对。首先要把这个极其复杂的节点关系矩阵在产品层面梳理清楚；其次，要分析我们整个项目的 Schema，把结构化数据剥离出来；最后，还要用前端框架把它高效地渲染出来。当项目非常庞大，有成千上万个节点和复杂调用时，怎么让浏览器渲染拓扑图而不崩溃，本身也是一个巨大的前端性能挑战。所以产生这份图背后的高密度数据结构，才是最难搞的。
如何平衡"功能强大"与"简单易用"？
覃貌：现在很多低代码平台都在做减法，追求"化繁为简"。但看 Zion 的动作，比如做数据鸟瞰图、接下来还要做测试环境、版本管理、分支合并等，感觉你们反而在做加法，展示出很多密密麻麻的专业逻辑。耀锴，你是怎么思考 Zion 的产品观和工具观的？
蒋耀锴：本质上，你对一个东西想要拥有掌控权，你就必须拥有完整的信息。你是不可能把对业务逻辑的理解完全外包出去的。
降低难度有两种方式，一种是工具帮把复杂度"吸收"掉，也就是工具替你做决定。但用户的具体业务逻辑，我们是绝对无法替他做决定的。在 Zion 里，我们希望每一个节点用户都能深度介入并自己做决策。既然要决策，你就得拥有完整的信息，否则你凭什么做决策？所以，如果你想开发商业级的应用，你就必须付出对应的代价，也就是你的认知代价，这是逃不掉的。
汪宁：作为一个想做出商业级应用的 IDE 开发工具，功能的完备度是绝对不能打折的。如果我们连函数调用关系、环境和分支都没有，那我们就不是一个合格的 IDE。
但"功能完备"不等于"界面繁琐"。我们可以通过"渐进式披露"（Progressive Disclosure）来组织用户的行动线索。当用户在搭 UI 时，他只需要关注前端怎么画；当他想梳理业务逻辑时，可以通过鸟瞰图清晰地看懂数据引用；而当他想提高效率时，可以用 AI 来生成和修改内容。
任何你在前端看起来极简、用起来极其轻松的体验，底层都必须有一套极其有秩序、甚至很复杂的系统在支撑着。所有的秩序感都是复杂的，但正是因为我们把底层的复杂配套健全了，用户才能用得如此随意和优雅。
✍️ 小编笔记
以前我们总觉得做开发、搭应用，只要眼睛盯着前端漂亮的页面和按钮就够了。但实际上，当项目规模越做越大，底层错综复杂的调用关系早晚会变成一个谁也理不清的"无底洞"。
而"数据鸟瞰图"的出现，不仅仅是让我们在日常开发中能少掉几根头发、在修改代码时少踩几个坑，更重要的是，它为未来的 AI 辅助开发搭建好了关键的安全网。只有让 AI 拥有了这份"系统全局高精地图"，它才能真正安全地帮我们去修改和维护一个商业级的项目，而不是每次重启都像瞎子摸象。
正如直播里说的那样：底层的秩序感越是复杂和健全，用户在前端的使用体验才能越随意、越优雅。