企业官网建设流程全解析

把项目命名为caveman，是因为我受够了那些动辄要数据库、要云端协同、要插件生态的信息管理工具。caveman的意思就是回到穴居人时代：不需要复杂的火种技术，也能把日子过明白。我做的不是某个花哨APP，而是一套基于纯文本文件、Git和命令行工具的本地知识管理方案，整套东西就叫caveman。它解决的问题很具体：笔记越记越乱、工具越用越重、内容被平台绑架。如果你受够了Notion的卡顿、印象笔记的层级混乱，又不想一上来就折腾自建Wiki，这篇文章应该对你有用。我会把设计思路、目录结构、同步方案、踩坑记录全部摊开讲，保证你照着做也能搭出自己的版本。

1. 为什么我要用“穴居人”的思路做信息管理

1.1 工具变重，内容反而越来越难找

先说个很现实的现象：市面上的主流笔记工具，功能一个比一个多，数据库、看板、白板、插件市场、协同编辑，恨不得把整个办公室塞进一个侧边栏里。但真正用起来的时候，我发现自己80%的操作仍然只是“记一条想法”和“找回一条旧记录”而已。Notion打开要转圈，页面嵌套五六层，每次想找一个半年前的项目笔记，得先回忆当初把它放在哪个Workspace、哪个Page、哪个Database里。这种成本已经超过了工具带来的收益。

caveman的思路正好反过来：不提供任何花哨结构，只用文件夹、文件名、纯文本。你不需要学习数据库关系，不需要理解权限模型，甚至连Markdown语法都可以只用最基础的几个符号。它就是个“洞穴”，里面有墙（目录），有壁画（文本文件），你要做的就是把信息刻上去，然后能随时找到它。

1.2 数据只归自己，永远不会被“迁移”绑架

用在线工具最让我不安的一件事是导出。今天在某个平台里写了三千条笔记，明天平台改了收费政策，或者某天服务停止运营，你就会发现自己花几年积累的内容变成了一堆无法直接带走的格式。就算能导出，也往往是JSON、HTML这种需要二次处理的产物。caveman从头到尾就是纯文本，目录本身就是内容，文件本身就是记录。想备份就复制文件夹，想换工具就打开文件夹，不需要任何转换。

有人会问：纯文本是不是太简陋了？但反过来想，人类能稳定读几千年的东西，永远是写在石头上的、纸上的、纯文字的东西。复杂格式也许好看，但只有最简单、最公开的格式才最可能长期存在。我个人备份caveman目录已经三年，从没出现过打不开或者损坏的情况，原因很简单：它没有私有格式。

1.3 学习成本几乎为零，5分钟就能开始

别被“命令行走天下”这类标签吓到。虽然caveman推荐用Git和命令行工具，但核心规则用Windows自带的记事本也能跑通。我先说结论：你需要学的只有三个动作——新建文件夹、新建文本文件、给文件取个好名字。剩下的Git、fzf、同步策略都是优化体验的附加项，不是必需品。这也是它叫“caveman”的另一个原因：哪怕你没有任何技术背景，也能像一个穴居人管理洞穴壁画一样管理自己的数字信息。

2. caveman的核心设计：一张洞穴壁画胜过一套ERP

2.1 目录结构：按主题分，别按时间分

caveman的目录结构很老派，和几十年前个人电脑时代的“文件夹管理”没什么本质区别，但关键点在于“顶层分类”必须足够克制。我现在的顶层目录长这样：

caveman/ ├── 00_inbox/ # 临时收集，还没归类的所有内容 ├── 10_projects/ # 有明确起止时间的项目 ├── 20_areas/ # 长期持续关注的领域 ├── 30_resources/ # 参考资料、文章摘录、工具文档 ├── 40_archive/ # 不再活跃但可能回看的旧内容 └── README.md # 整个系统的使用说明和索引

数字前缀是我强烈建议保留的，它有两个作用：第一，让目录按你的思考优先级排序，而不是按字母排序；第二，给分类一个固定的“编号锚点”，以后在笔记里引用时可以直接写见 10_projects/docker迁移方案.md，不用粘贴完整路径。

我特意没有按年份分类。试过的人应该都有体会：按年份建目录，找旧资料得先回忆是哪一年，想不起来就只能全盘搜索。按主题分类则会稳定很多，因为领域不会变，项目名不会变，只有时间在变。归档例外，40_archive里面可以按年份再二级分，因为归档层的核心目标就是“沉到最底下”，年份作为检索线索在这里反而合适。

2.2 一张卡片一条命：原子化笔记原则

caveman的一条核心方法论是“一个主题一个文件”。不是把十几条想法堆在一个叫“生活随笔”的文档里，而是每一条值得记录的内容都单独建一个文件，文件名写清楚主题，内容只围绕这一个主题展开。

这个习惯来自卡片盒笔记法的启发。为什么原子化有效？因为文件越小，越容易被检索命中，也越容易被重新组织。拿写作举例，我写一篇技术文章时会参考几十条笔记，如果所有素材都堆在一个大文件里，引用时就得不断滚动翻页，最后大概率因为找不到而放弃使用。而原子化之后，每个素材都是一个独立文件，用fzf输入关键词，一秒就能定位到准确的那张卡片。

大文件的诱惑很难抵抗，因为把东西全放在一处会给人一种安全感。但实际操作下来，超过500行的大文档基本会沦为墓地：内容还在，你永远不愿意打开它。caveman鼓励的是“写短文件”，如果一个文件写完了超过200行，就要考虑拆分成多个卡。

2.3 文件名就是检索入口

原子化笔记配合了一套可预测的文件命名格式，这是caveman里我花时间最多的地方。目前使用的格式是：

YYYY-MM-DD_主题关键词_备注.md

举例：

2025-04-12_用ollama跑本地大模型.md 2025-04-12_docker备份策略_不包含镜像缓存.md 2025-04-11_syncthing同步失败排查.md

日期放在最前面，解决的是时间轴检索问题；主题关键词放在中间，解决的是语义检索问题；备注字段用于区分同一天、同主题下的不同笔记。这样排序后，同一天的笔记会挨在一起，同一个主题的笔记也会因为关键词相近而被搜索到。

不用UUID之类的随机文件名，因为可读性太差。caveman本身就崇尚简单，文件名就是要给人看的，不是给数据库用的。

2.4 内容格式的克制

正文格式我建议只保留五样东西：标题、列表、链接、代码块和引用块。表格能不用就不用，图片尽量丢到assets/目录里用相对路径引用，别往正文里塞base64。

为什么这么克制？因为纯文本文件最大的优势是任何环境都能打开，一旦内容里嵌入大量HTML、内联图片、复杂表格插件，就又开始依赖特定渲染器，等于变相抛弃了纯文本的普适性。我见过有人用Markdown写了一个带高亮、流程图、图标的“豪华笔记”，结果换一个编辑器打开时排版全崩。这个系统叫caveman，不是“史前艺术馆”，能传递核心信息就够了。

3. 实操记录：从零搭一个属于自己的caveman

3.1 初始化目录和忽略规则

搭建过程其实非常短，先创建目录结构：

mkdir -p caveman/{00_inbox,10_projects,20_areas,30_resources,40_archive,assets} cd caveman git init

如果你用macOS或Linux，把上面这段直接跑起来就有底子了。Windows用户打开PowerShell也能执行，或者干脆手动建几个文件夹。注意assets目录我放在了caveman根目录下，用来统一存图片、PDF等二进制文件，因为Git对文本文件友好，对二进制文件不友好，单独放方便以后用.gitignore或Git LFS控制同步范围。

.gitignore文件建议在第一次提交前就写好：

.DS_Store Thumbs.db *.tmp .obsidian/ .idea/ .vscode/

现在很多人会用Obsidian打开caveman目录，但Obsidian会在目录里生成自己的配置文件。这些配置只对本地有效，放进Git里只会制造噪音，所以直接忽略掉。

3.2 用Git做版本管理和自动备份

caveman最让我安心的部分是Git版本管理。每次修改完笔记后，执行两次命令就能留下一个快照：

git add -A git commit -m "更新日志"

如果你连这个都嫌麻烦，可以写个简单脚本save.sh：

#!/bin/bash cd "$(dirname "$0")" git add -A git commit -m "$(date '+%Y-%m-%d %H:%M') 自动备份"

然后用cron或系统的定时任务每30分钟执行一次，等于给自己配了一个自动存档点。回到Gitea、GitHub、GitLab都支持定时拉取，也可以把这个脚本挂在NAS里跑。

版本管理的最大价值不是“防硬盘损坏”，而是给你犯错的勇气。以前用在线文档时代我敢随手写随手删，是因为知道云上有历史版本。现在caveman给了我同样的能力，而且历史版本存在本地Git库里，不依赖任何云服务。一次误删文件，直接git checkout -- 文件路径就能恢复。

3.3 多设备同步的两种路线

先说结论：不要用网盘同步caveman目录。网盘一般不做冲突合并，两台设备同时修改同一个文件，最后会生成一堆“xxx（冲突副本）.md”，比不同步还乱。我试过各种方案后，留下了两种相对顺手的同步路线。

路线一：私有Git仓库。如果你有一台常开的服务器或NAS，在它上面建一个裸仓库，然后本地仓库把这个仓库设为remote。这样手机、电脑和平板都能通过Git拉取和提交。好处是保留完整历史，缺点是移动端提交没那么顺手，需要App支持。

路线二：Syncthing。这是一个点对点同步工具，不需要中央服务器，两台设备直接相互传文件。Syncthing的优势是实时同步，移动端也有App，适合快速记录场景。代价是它不做版本管理，配合Git使用更稳，也就是“同步靠Syncthing，历史靠Git”。

我个人现在是这个组合：电脑和手机之间用Syncthing实时同步，服务器上有一个Git裸仓库负责保存历史版本和冲突兜底。这套组合跑了一年多，没有出现一次数据丢失，很值得推荐。

3.4 移动端怎么配合

移动端的定位是“快速捕捉”而不是“深度编辑”。我用的是Android手机，装了Syncthing和Markdown编辑器，解锁后直接把语音转文字或手打的想法丢进00_inbox/，等回到电脑前再统一整理。如果你用iPhone，思路也一样：找一个支持按文件夹打开本地Markdown文件的App，不需要它自带同步，把文件夹关联到Syncthing的本地路径就行。

千万别在移动端安装一堆全套笔记软件，那样又回到工具越用越重的老路。caveman的原则永远是：移动端负责“抓”，桌面端负责“理”。

4. 真实踩过的坑与排查速查表

4.1 文件多了之后fzf变慢

caveman用了半年后，文件数量超过两三千个，这时候启动fzf会出现明显卡顿，尤其当目录里有大量.node_modules或构建产物时，慢得让人怀疑人生。排查后发现不是文件太多，而是fzf没有排除那些根本不该搜索的目录。

解决方案很简单，在fzf配置里指定搜索路径和排除规则：

export FZF_DEFAULT_COMMAND="rg --files --hidden --glob '!.git' --glob '!node_modules' --glob '!assets/*.pdf'"

如果你用的是ripgrep（rg），这一条命令就能让搜索性能提升数倍。另外建议把40_archive/也列入排除规则，归档的内容大多数时候知道具体名字，不需要全局模糊搜索。

4.2 中英文混合内容的检索问题

我一开始用fzf默认算法，发现对中文关键词匹配做得还行，但对“中英混排”的文件名会出现漏匹配。比如文件名是用Ollama跑本地模型.md，搜“ollama”能命中，但搜“本地大模型”可能会因为分词不准而漏掉。

后来我改成fzf的模糊匹配并启用--algo=v2，同时养成一个习惯：文件名里同时写中文关键词和英文专有名词。搜索时用英文命中，阅读时靠中文理解，两者互为补充。对于纯中文的搜索需求，fzf配合rg其实已经够用，不需要额外搞搜索数据库。

4.3 图片和附件到底怎么放

这是我最开始踩得最惨的坑。最早我把图片直接放进Markdown文件对应的子目录里，结果同一张图被两篇笔记引用时，只好复制两份副本，后续想改图又要改两个地方。

最终的统一规范是：所有附件都放caveman根目录的assets/下面，按照内容类型继续分子目录，比如assets/images/、assets/pdfs/、assets/videos/。正文里使用相对路径引用：

![架构图](../../assets/images/2025-04-12-项目架构.png)

注意相对路径是从当前笔记文件出发计算的，不是从caveman根目录。所以建议每层笔记目录的层级深度保持一致，比如都固定在10_projects/xxx/下，减少路径计算的麻烦。这个规范看起来简单，但如果一开始不定好，后面改起来会累死。

4.4 敏感内容的加密处理

caveman整体是纯文本，纯文本有一个天然问题：一旦设备丢失或同步泄露，内容等于裸奔。我的做法是最敏感的信息不直接进caveman，比如密码、密钥、证件号这些，统一交给专门的密码管理器。如果只是“有点敏感但不太重要的内容”，可以用GPG对单个文件加密：

gpg -c --cipher-algo AES256 2025-04-12_银行相关记录.md

执行后会生成一个.gpg文件，原来的纯文本文件可以删除。需要查看时再解密到临时文件，看完后立刻删除。这套流程不复杂，但对防止同步过程中的泄露已经足够了。记住，不要在caveman的明文里写密码，即使有加密方案，明文本身就是风险。

下面把我遇到的高频问题整理成速查表，方便你以后对照排查。

5. 关于caveman这套做法的边界和延伸

5.1 哪些场景真的不适合

caveman不是万能方案，有些场景用它就是自找麻烦。比如需要大量结构化查询的数据库型内容，类似图书管理系统、客户台账、库存记录，这种数据天生该用表格、数据库或专门的App，硬塞进纯文本只能收获痛苦。再比如多人实时协同编辑，纯文本文件加Git确实能做版本合并，但对非技术背景的协作者来说学习成本偏高，还不如用成熟的在线文档。

此外，如果你是一个重度多媒体内容创作者，每天要处理大量照片、视频素材，caveman的纯文本目录管理思路可以借鉴，但没有必要把多媒体文件全部塞进来。资产目录单独存放，笔记里只保留引用，这才是合理的分工。

5.2 能做的轻量扩展

caveman最好的一点是扩展性完全掌握在你手里。我用它做过的延伸包括：

• 用todo.txt格式维护一个20_areas/40_待办事项.md，配合简单的模板脚本生成每日清单。
• 写一个Python脚本，定时扫描00_inbox/里的文件，根据文件名关键词自动移动到对应顶层目录。
• 用pandoc把某个项目下的所有Markdown笔记拼接输出为HTML或PDF，生成一个简单的项目报告。
• 把整个caveman目录用静态站点生成器（比如MkDocs）渲染成一个本地Wiki，方便在浏览器里阅读。

这些扩展都不会破坏核心结构，因为它们只是在纯文本的基础上做“读取”和“转换”，不会把内容绑死在特定工具上。这也是最初选择“穴居人”思路的原因：给自己留一条永远可以退回去的简单路。

最后再多说一句

caveman这套东西真正改变的其实不是技术，而是我面对信息的态度。过去我花了很多时间整理工具，整理模板，整理插件，最后真正读进去的知识却没多少。换成纯文本目录之后，我每天只做三件事：丢进收件箱，定期整理，需要时搜索。没有排行榜，没有视图切换，没有未读红点。内容回到它本来该有的样子：写在墙上的字，落在地上的石头。这个项目很小，但它让我重新拿回了对信息的控制权。如果你也想摆脱“工具当主人”的状态，建议从今天开始，建一个caveman目录，丢第一条笔记进去试试。