把一个现成的数据包安装进团队空间，看起来应该比从零搭建更省事。真正让人犹豫的，往往是点击安装之后会发生什么：内容会直接进入现有空间，还是先等人确认？已有数据和关联关系，又会让这次安装变得多复杂？
这些问题影响的并非只是安装速度。一次没有想清楚的安装，可能给后续协作留下需要整理的记录和关系；把所有安装都想成同一种审核流程，也会让团队误判什么时候需要提前安排检查。
理解Busabase的安装方式，先要分清当前权限下的默认行为，以及哪些情况需要明确选择review。这样才能在节省准备工作的同时，保留对即将进入空间的内容的判断。
目录出现了，内容处于什么状态？
Busabase 的 package 用 Git 仓库中的 busabase.json 和 content/ 目录描述可安装资源。安装文档将结构与内容分开：Folder、Base、字段和视图会立即创建；记录、Doc、Skill、AirApp 等内容，在凭据具备写权限时默认直接合并。
因此，“已安装”不能自动解释为“先放在旁边，等审核才生效”。若想先检查内容，需要在网页预览中选择 Send the content for review first，或在 CLI 中使用 --require-review。这会把内容留在 ChangeRequest 中，但不会推迟结构的创建。
安装后看到目录树已经变化，同时 Inbox 还有待审提案，是可能出现的正常组合。验收时要分别检查结构和内容，不能只凭左侧树判断整个包已经可用。
先看来源，再看即将创建的对象
网页的 Install from GitHub… 会先获取服务器生成的预览，展示包身份、实际解析的仓库与 ref、资源树、记录与文件数量、命名冲突和警告。修改目标文件夹后要重新看预览，因为冲突集合也会变化。
先确认来源与打算采用的版本。默认分支表达的是获取当时的内容；需要复查同一版本时，记录实际解析的 ref，优先使用可定位的 commit SHA。再看资源树，判断包是否只包含预期范围。一个想借用的知识库若还带有执行指令或应用代码，就应打开对应文件阅读，而不是只看名称。
随后处理冲突。Base slug 在空间内唯一，节点 slug 在文件夹内唯一；遇到重复名称时，可以取消，也可以明确选择重命名安装。--rename 会使用后缀并改写关系指向新 Base。它是安装一组新的资源，不是把现有业务内容自动升级到新版。
“先审核”还有两个容易遗漏的条件
第一，普通 package 如果记录之间已经填有关系值，安装需要先合并记录，才能拿到关系所需的实际 ID。这类包不能采用 --require-review；网页会解释只能直接安装，并不提供审核勾选。仅仅定义一个空关系字段，并不构成这个限制。
这时应重新判断是否愿意直接引入整包，或要求提供方交付可以独立检查的内容范围。不要为了让安装继续就忽略提示。本文建议先审来源、再决定是否安装；并没有要求团队安装任何指定外部包。
第二，模板的示例记录有单独的处理方式：默认会合并样例。CLI 若希望它们也进入审核，需要同时使用 --no-sample-records。所以“主体内容先审”和“样例也先审”是两个检查点。
把选择写进安装前清单
可以把清单保存在现有任务 Base，或为一次安装写进一份 Doc。无需为了引入模板再建立复杂管理系统。记录这些内容就足够开始：
| 检查项 | 应保留的信息 |
|---|---|
| 来源 | 仓库 URL、实际解析的 ref、对应文件位置 |
| 范围 | 目标文件夹、Base 与文件数量、包含的 Skill 或应用 |
| 冲突 | 哪些名字重复，取消还是重命名 |
| 生效方式 | 内容直接合并还是先审核，样例怎样处理 |
| 例外 | 关系值限制、附件或文件警告 |
让已连接的 Agent 帮助整理时，可以这样提出要求：
需要委托Agent时，可以这样描述任务
阅读这份安装预览和包文件。按来源、资源范围、执行指令或代码、冲突、审核选择和警告整理一份检查单，链接到对应文件。只分析并返回检查结果，不执行安装、不修改空间，也不批准提案。
Agent 能帮助定位需要判断的内容，安装授权仍由具有相应权限的人作出。网页安装及预览需要空间写权限；CLI 同样需要对安装资源具备写权限。
把接受方式与写入权限一起决定
想先审内容，就在安装时明确选择审阅路径，并核凭据的实际权限，而不是事后根据出现的目录推测状态。结构立即创建，与内容是否直接合并是两件事；团队应清楚哪些记录和指令已经成为Agent可读取的正式输入。
安装后分别读结构与内容结果。正式内容核实际正文、关联和来源；待审内容进入Inbox看差异。包里带样例或关系时还要按当前安装说明检查例外，不能拿一条“安装成功”概括所有对象的接受状态。
装完后，检查两种结果
先对照预览检查结构：目标文件夹、Base、字段、视图是否符合范围，冲突是否按选择处理。再检查内容：若选择直接合并，打开实际记录和文件；若选择审核，打开对应 ChangeRequest，检查差异后再决定是否合并。看到安装结果里的待审数量时，应进入 Inbox，而不是让 Agent 立即依赖尚未接受的内容。
还要处理安装警告。package 不包含权限、变更历史、Vault secrets 和 webhook rules，也不携带附件字段里的附件值；文件能否上传另受宿主存储能力影响。需要保留整个空间历史和文件时，采用备份与恢复的流程。
一次清楚的安装决定，应留下来源、范围、合并方式和实际结果。这样后续接手的人才能判断：哪些只是已经建好的结构，哪些已经成为正式内容，还有哪些决定尚未完成。