企业官网建设流程全解析

这篇东西原本是我第三次整理自己的笔记迁移记录了。前两次一次讲怎么把数据搬进Notion，一次讲怎么给页面分类，写完之后隔了三个月回头看，发现真正让迁移翻车的从来都不是“导入”这个动作本身，而是导入之后那一大堆摊在地上的数据到底怎么归档重组。所以我干脆把整套经验拆开重写了一遍，标题就叫Notion导入与归档指南·重组版，重点放在“导入前怎么规划”“导入后怎么归档”这两个最容易被人跳过的环节上。如果你最近正好准备从Evernote、OneNote、Bear或者一堆本地Markdown文件迁到Notion，或者你已经迁完了但工作区乱得像搬家当天没拆封的纸箱，这篇应该能帮你少踩几个我踩过的大坑。

1. 先想清楚：导入Notion之前，为什么要先“重组”思路

1.1 换软件的本质：从“文件夹思维”切到“数据库思维”

很多人把Notion当成一个更大的文件夹，觉得把旧笔记一股脑搬进来就完事了。我第一次迁移也是这么想的，结果导入第三天就发现了问题：Evernote里的笔记本结构变成了一堆平铺页面，Bear导出的Markdown文件变成了几十个同样平铺的页面，OneNote那边的表格导入后直接散了架。信息确实都在,但“在哪”这件事彻底乱了。

这里面的核心在于，Evernote、OneNote这类传统笔记工具用的是“文件夹思维”，你只需要决定这条笔记放进哪个笔记本，后续靠笔记本的树状结构去翻找。Notion底层根本不是一个文件柜，它是一套块编辑器加数据库的组合体。页面里的每一段文字、每一张图片、每一个列表都是一个block，而真正支撑“整理”的骨架是各种database属性。这意味着你搬过来的不只是文字的堆叠，还需要同步把“结构”搬过来。

用搬家来类比可能更直观：你从老房子搬进新家，不是把纸箱原封不动堆在客厅就算搬完了，你得先想清楚衣柜放哪、书柜放哪、厨房的东西放哪，然后把对应的箱子拆开归位。如果你只是把箱子全部运进门，那你的客厅会比搬家前还要乱。Notion就是这个新房子，它的衣柜和书柜就是数据库和属性，导入只是把箱子运进门，归档才是让所有东西各就各位的那一步。

所以开头第一步不是打开导入按钮，而是先停下来问自己几个问题。这个环节我称之为“重组前置”，不花这半小时，后面整理会多花三个工作日。

1.2 重组前的三问：这些数据将来要“查”什么

我在第二次迁移前给自己设计了三道必答问题，每一条旧数据都用这三问过一遍再决定让它去哪儿：

第一问：这内容是需要“一条条检索”的记录，还是需要“整篇阅读”的内容？如果是前者，那它就适合做成database，比如书单、订阅的资讯、人脉名片、待办任务；如果是后者，它更适合做成普通page，比如一篇读书笔记、一份会议记录、一段日记。这个区分很多人忽略，导致的结果是你会把本应该做筛选的素材堆成了一篇篇长文，想看“我现在读了几本书”根本筛不出来。

第二问：这些数据需不需要多维度筛选？比如你的读书笔记，如果只是想按标题翻，那普通页面就够了；但如果想按作者、阅读状态、评分、标签来筛选，就必须做成数据库，并且每一列都要单独定义一个属性。一个常见的反面案例是把所有信息塞进标题和正文里，最后想排序、想分组都做不到。

第三问：这些数据之间需不需要互相关联？比如某篇读书笔记对应某一本书、某条会议记录对应某一个项目。如果需要，单纯放在同一个数据库里还不够，要用relation属性把它们连起来。这层关系恰恰是传统笔记工具最不擅长、而Notion最能打的点，导入时提前规划好，后面省掉大量补链接的功夫。

这三问想清楚之后，你会得到一个大致的地图，哪些旧笔记做成数据库、哪些做成页面、哪些只是附件需要单独归档。有了这张地图再动手导入，后面的重组就不是“救火”，而是按图施工。

2. 导入实操：不同来源的内容怎么进Notion才不散架

2.1 Evernote / 印象笔记：导入后立刻检查Tag和笔记本

Evernote是很多人第一个搬家的对象，因为它的历史包袱最重。Notion桌面端提供了官方的Evernote导入通道，入口在右上角Upload/Import菜单，选择Evernote后会引导你安装一个浏览器扩展，授权之后就能把笔记本同步过来。导入完成后，你会发现Notion为每个原笔记本生成一个数据库页面，每一条旧笔记变成数据库里的一行。

需要注意，这不仅是一次内容搬家，还是一次“属性映射”。旧笔记里的笔记本名称和Tag会尽量转成属性，但转出来的结果通常不太好看，如果你印象笔记里的标签有七八十个，导进Notion之后就有一堆看起来很高频、实际没分类价值的Tag值堆在那里。我在清洗的时候只看两类标签：一种是能当“主题”用的（比如Python、产品设计、健康管理）保留下来，一种是流水账式标签（比如“待看”“今天心情好”）直接合并或删掉。清洗之后再结合搜索，才会比原来好用。

另一个踩过的坑是：导入完成后，Evernote数据库里会出现很多一条内容占一行的记录，但空属性一大堆。这不是导入失败，是原笔记本来就没有字段。我建议导入后先新建一个表格视图，把空属性隐藏掉，集中检查一遍标题列和内容列，确认没有断档再开始整理。

2.2 Bear、OneNote、Word的隐藏链路

Bear用户没有官方导入通道，但不是无解。Bear桌面版自带导出功能，可以把所有笔记一次性导出成Markdown文件，导出后会得到一个文件夹，每个笔记是一个.md文件，图片和附件在assets里。接下来你只需要新建一个Notion页面，把整个Markdown文件夹拖进去，Notion会自动为每个.md文件生成一个子页面，图片路径也能正常识别。这一招我实际验证过，迁移速度比手动复制粘贴快得多。

OneNote就麻烦不少，官方一直没有给出直连通道。我试过的比较靠谱的路径是：先把OneNote分区导出成.doc或HTML文件，再通过Notion的Import菜单导进来。纯文字内容基本能保住，标题、加粗、列表、表格这些格式大体兼容，但图片和附件大概率丢失，需要回到OneNote里手动导出图片。如果OneNote里的笔记以文字为主，这条链路还算高效，如果笔记里有大量图片和白板手绘，我建议先评估这些内容是否真的需要全量迁入，不值得为一部分长尾旧笔记耗费一整晚去修补。

Word文档反而是最省心的，Notion直接支持.docx导入，能识别标题层级、加粗、斜体、列表和表格，导入后整体观感像一份排版完整的页面。缺点是图片不随文档一起进来，需要一个一个拖回去。这里有个容易混淆的点：扫描版PDF或者导出成PDF的Word文件并不能Word导入，你拖进去只会得到一张图片或空页面，后续完全没法编辑。

2.3 CSV批量导入：结构化数据怎么喂给Notion

如果你手里有一批结构化的历史数据，比如一份Excel读书清单、一套旧项目管理表、一批订阅源列表，CSV导入是最快的方式。Notion的Import菜单里选CSV，它会自动生成一个新database，每一列都映射成一个属性，第一行默认当成列名。

我实际测试下来，CSV导入有四个很容易踩的规范点：

• 日期字段必须写成YYYY-MM-DD或更完整的ISO 8601格式，写成“2024年3月1日”或者“03/01/2024”都会让Notion识别成纯文本，排序功能直接废掉。
• 多选属性里的多个值用英文逗号隔开，Notion会识别为多选。如果值本身是中文逗号，只算一个字符串，这个细节很多人会忽略。
• 第一行列名最好用简洁英文或中文名词，不要带括号备注，因为列名会直接变成属性名，改起来虽然不麻烦，但批量过程中容易看错。
• 文本列里面如果有换行，CSV需要正确使用引号包裹字段，否则会导致内容错行。Excel导出CSV一般会自动处理，但如果你用文本编辑器手搓CSV，这个必须多留个心眼。

导入完成后，默认所有属性都会是文本或纯文本类型，你需要去database的属性设置里手动把“评分”改成数字、“进度”改成Select、“日期”改成日期类型。别嫌这一步麻烦，属性类型没设对，后面的看板视图和日历视图根本排不出来。

2.4 导入后的第一轮重组：从“平铺”到“分层”

等你把多个来源的数据都导入后，工作区通常是一幅惨不忍睹的画面：十几个数据库页面平铺在侧边栏，几十个单页散落在各处，搜索又搜不全。这时候一定不要着急去写新内容，先花一个下午做第一次分层重组。

我的做法是：先建三个顶层页面作为“一级容器”，第一个叫“工作台”，放日常高频使用的数据库和模板；第二个叫“知识库”，放沉淀下来的笔记、阅读摘录、项目复盘；第三个叫“归档”，把暂时用不到的历史数据全部拖进去。这一步做完，侧边栏立刻清爽很多。

拖动页面调整层级这件事，在Notion里非常顺滑，你直接在侧边栏拖拽即可，页面内嵌的链接不会因为位置变化而失效。需要特别提醒的是，导入时自动生成的那些旧数据库不要急着删。先把它们整体拖进“归档”页面，再用数据库右上角的筛选功能把不常看的视图藏起来，等确认新整理体系已经全面接管之后，再考虑销毁。

3. 归档体系搭建：把“堆积”变成“流动”

3.1 用字段给每一条内容安一个“生命周期”

我见过不少人把Notion数据库建成之后，往里塞了一堆资料，过了一个月再打开发现全是“僵尸数据”——不是没用，但你不知道哪些已经处理完了、哪些还没看、哪些该丢了。归档体系的核心思路是给每一条内容赋予一个“生命周期”。

我在自己的每个主要的归档数据库里都固定维护四个字段：状态字段（Status）、标签字段、创建时间、最后编辑时间。状态字段用Select或Status类型，里面固定放四个值：草稿、进行中、待整理、已归档。这个字段是整个归档流程的地基。

有了这个字段之后，最实用的操作是给数据库视图加一个默认筛选：状态不等于“已归档”。这样日常打开数据库时，所有已经归档的历史数据全部自动隐藏，而你需要找旧内容时，随时可以在筛选里去掉这个条件或直接全库搜索。等于在同一个数据库里做了“当前工作区”和“历史档案馆”两层空间——既不丢数据，又不占视野。

3.2 数据库视图：看板、日历、表格各管一段

数据库视图对很多人来说是个盲区，以为一种表格样式能吃遍所有场景。实际上Notion里的视图是“同一批数据的不同查询结果”，同一个database可以同时存在表格、看板、日历、列表、画廊多种视图，互相之间完全不冲突。

我的经验是按场景分别建视图，而不是就着一个视图硬扛：

• 表格视图：日常编辑主视图，所有属性一列列铺开，方便快速录入和批量修改；
• 看板视图：按状态字段分组，打开就能看到“当下有几条草稿、几条进行中、还有哪些等归档”，是我每周做整理的主战场；
• 日历视图：依赖日期字段，用来管带截止时间的任务和预约类内容，比凭脑子记靠谱得多；
• 画廊视图：给视觉类内容用，比如封面图、灵感素材，用大图模式更直观。

有一个操作习惯很重要：在数据库里新建视图时，请一定把它命名为“我的表格视图”“我的看板视图”之类的独立视图，不要污染默认的“全量数据”视图。多个成员协作时这一点尤其重要，否则你改完筛选条件，别人看到的和你看到的不一样。

3.3 我实测的归档工作流（可直接抄）

整理完视图设置后，我给自己定了一套“三时段归档节奏”，这套节奏我实际跑了三个月，最大的收益是再也不会积压成山：

每天早上开工前，我会先花十分钟打开“收件箱”数据库，把前一天睡前收藏的各种链接、灵感和临时笔记统一添加标记，标成“待整理”。注意这里不是马上整理，只是让它们进入流程。

每周五下午，我会打开“待整理”看板视图，逐条补属性：来源、主题、标签、状态。补完属性之后，有价值的内容挪到对应主题数据库或正式页面，临时没用的直接丢进“已归档”。这个时候我会顺便删掉重复的旧笔记，这个过程很费脑子，但好处是每一周都在清空，而不是攒到年底。

每月最后一天，我会做一次粗粒度体检：用表格视图扫一眼哪些内容“最后编辑时间”已经超过三个月，判断它们是需要对冲到“已归档”还是可以删掉；接着再检查有没有空属性列、有没有标题乱编的行。这套月度体检通常只需要半小时，但它决定了数据库长期不腐烂。

这套流程的意义不在于“定期整理”这个仪式，而在于每次收集新内容时，我心里已经预设了它最终会流向哪个数据库、补上哪些属性。归档不是偶然清理，而是从源头就开始流动。

4. 导出备份：反向操作，把Notion搬回本地

4.1 官方导出格式怎么选（四种一次说清）

很多人只把Notion当在线工具，觉得数据存在云端就安全了。我自己的态度是，任何云端工具都不能替代本地备份，尤其Notion这种承担了全部知识资产的地方，导出备份必须常态化。

Notion官方导出的菜单在右上角Settings，选择Export，提供四种输出格式，适配场景完全不同：

• Markdown & CSV：这是我最常用的日常备份格式。每个页面会生成一个.md文件，页面里的图片和附件统一放在assets文件夹里，每个数据库则生成对应的.csv表格文件。这套格式适合做长期存档、全文检索，也可以作为迁移到Obsidian、Logseq等本地笔记工具的中间格式。
• HTML：这个格式会把每个页面保存成一个完整的网页，图片路径和版式保留度高，适合直接发给别人网页预览、放进个人存档站，但后续编辑性很差。
• PDF：适合单页打印、合同/报告存档，官方甚至支持只导出当前页面或整个数据库页面的PDF。PDF最大的价值是“版式锁定”，不会因为二次编辑而变形。
• Notion原生（JSON）：这个格式会完整保留数据库结构、块类型、关系属性、评论信息。它导出的文件不是给人直接在文本编辑器里看的，而是“用来再次导入Notion”的。如果你需要完整还原整个工作区，比如换账号或者大规模重构，JSON是最稳妥的。

4.2 导出后目录怎么重建

导出Markdown & CSV后，你会拿到一个压缩包，解压后里面是一整套文件夹结构，大体上是这样的：每个顶层页面对应一个文件夹，子页面逐级套子文件夹，每个页面的.md文件放在对应文件夹里，assets文件夹装图片和附件。这个结构和Notion内部的层级一一对应，说明官方在设计导出格式时就考虑到了跨软件迁移。

这时候有一个讲究：不要手动修改导出生成的文件名。Notion导出文件在命名时会带上页面ID，图片引用也依赖这个ID，你一旦改了文件名，图片路径就会失效。我一开始想强迫症发作把文件名全改成中文标题，结果打开后发现一堆编辑器的图片全部断链，后来只能重新导出一次。

如果你想把这份备份变成新的知识库入口，比较顺的路线是直接用Obsidian打开这个文件夹作为库。Obsidian原生支持Markdown，能直接渲染Notion导出的.md文件，assets图片路径也能对上。我在实际迁移体验中，这套组合基本可以做到“Notion内页面跳转，Obsidian里也能继续用”，只是它不识别Notion的数据库关系，所以数据库类的二维表体验会打折扣。

4.3 备份节奏与多副本策略

备份节奏上，我给自己定了一个“三副本”策略：本地电脑一份、网络盘中一份、私有Git仓库一份。这个策略不神秘，就是避免任何单点存储失效。

具体操作上，我会在每周五做一次全库JSON导出，偶尔赶时间就跳过Markdown & CSV，但JSON从不缺席，因为只有它能完整还原Notion原生结构。日常新增内容则依赖云端实时同步，这层不算备份，只是在线服务的既有能力。

需要特别强调的一点是：定期备份不算完，还要定期试恢复。我最初连续备份了一个多月，一次也没真正导入回去验证过。结果等到某天需要还原数据时，发现大数据库JSON恢复过程耗时极长不说，偶尔还会卡在某个页面。后来我把“试恢复”加入每月体检流程，每次还原一个小型数据库确认流程没问题。备份有没有用，只有“成功恢复一次”才算数。

压缩包的命名我也建议带日期，比如notion-backup-20240630.zip，否则两个月后你就会碰到七八个一模一样的“Export-2024”文件，根本分不清哪个是最新的。

5. 常见问题与排查技巧实录

5.1 导入后页面大量空白，原内容消失

如果导入后页面整体只有一个空壳，正文全部丢掉了，多半是来源格式里包含Notion无法理解的复杂嵌套结构。Evernote和OneNote里大量使用的表格嵌套、文本框和高级排版最容易触发这个问题。我的处理策略是：先去来源软件里把该笔记纯文本复制出来，在新页面里粘贴，再手动恢复格式。如果笔记数量很多，也可以优先保存“纯文本版”，至少能保住内容，格式后面有空再补。

5.2 图片断了、附件文件名变成哈希

Notion导入外部笔记时经常遇到图片路径漂移，尤其Evernote里加密图片、内嵌附件，导入后往往变成一个下载链接或者干脆断掉。还有一个常见现象是附件文件名被改成一长串哈希值，看起来完全不知道原文件是什么。遇到这种情况，不要试图在Notion里一张张重新传，先把来源软件的原始导出数据留在本地，需要哪个就回到原压缩包里按时间或文件名反查。我做了一次大清理之后就形成习惯：任何导入任务都会同步保存一份“来源软件原始导出包”，用于兜底。

5.3 数据库关系在导入后丢失，关系属性变成孤零零的文本

CSV、Word、Evernote导入都没法保留数据表之间的relation关系，关系字段导入后要么丢失，要么变成一串看起来像文本的ID值。如果你迁移的数据原本就依赖“这本书关联三篇读书笔记”“这个项目关联五条任务”，最稳妥的方式是先导出为Notion原生JSON再导入，不要用Markdown/CSV链路。要是已经用CSV迁移完了，就只能手动重建关系，以我对大规模数据的体验，这一步实在避不开，但也未必是坏事——重建关系时正好可以把早年间乱建的关系重新理一遍。

5.4 常用问题速查表

最后分享两个很小的实操习惯，给我省了不少事：一是在所有归档数据库里统一加上“创建时间”和“最后编辑时间”两个字段，别看它们不起眼，月度体检全靠它们判断哪些数据该进“已归档”；二是每次做完整备份导出的同时，顺手在文件名里写下当天日期，养成这个习惯之后，回滚历史版本只需要按时间戳找文件，比任何复杂的Tag体系都好用。我自己到目前还在持续微调这套导入与归档流程，它不算完美，但已经能让我在大量历史数据面前保持“日常清爽、历史可查”的状态。如果你也正在整理自己的Notion工作区，希望这篇重组版的经验能给你搭出一套适合自己的底子。