企业官网建设流程全解析

先说结论：我最近把主力效率工具换成了一个我自己写的命令行小工具，代号caveman。不是什么游戏，也不是什么 NFT，就是一个极端克制的本地记录工具：数据全部躺在 Markdown 文件里，常用命令不超过十个，没有后台常驻进程，不需要注册账号，更不会把我的一举一动传到别人服务器上。

这个工具的核心逻辑只有一句话：像原始人一样记录。原始人不需要花里胡哨的任务看板，不需要弹窗提醒，不需要多级项目分组，他要做的只是在岩壁上划一道痕，告诉自己“今天发生过这件事”。caveman就是把这一道痕做成了终端命令。

如果你和我一样，受够了“打开软件选项目、建任务、设截止日期、打标签、再设提醒”这一整套仪式，只想赶紧把脑子里的事情落到文本里；或者你本来就喜欢 Markdown、Git 和终端的工作流，那我强烈建议把这个思路看完。适合的人很明确：独立开发者、写作者、学生、以及所有不需要跟别人共享任务墙、只需要把自己管理明白的人。

1. 项目起因与定位

1.1 为什么叫 caveman

起名的时候脑子里正好闪过洞穴壁画的画面：原始人把狩猎过程画在岩壁上，没有什么主题分类，没有什么权限管理，画完就算记录完成。我不需要又一个“第二大脑”，我需要的是“最小可用的肚脐眼”。

caveman这个名字其实也是自我提醒：当我又想给它加日历视图、加甘特图、加机器学习周报的时候，看一眼名字，冷静下来。它就是一只洞穴人，做不了太多事，但把最简单的事做得极其顺手。

还有一个很私人的原因：我发现自己越依赖复杂的效率工具，越容易产生一种虚假的掌控感。把任务填进漂亮的面板里，感觉像做了很多事，实际上只是整理了很多待办。caveman刻意不提供这种整理快感，它只提供一条能随时追加的日志流。

1.2 它到底解决什么问题

我把自己之前用 Notion、Todoist 这类工具的真实时间开销算过一笔账：每次新建一个任务，平均要经过“打开软件 → 点击新建 → 选择项目 → 填写标题 → 设置日期 → 选择标签 → 设置优先级”七个步骤。如果任务特别重要，还要再配一个提醒。等这套动作做完，原本想记录的那件事已经在脑子里褪色了。

caveman解决的是三个具体问题：

第一，记录负担。想记任何事，打开终端敲ca log "文案初稿完成 +写作"，回车，完事。从念头出现到落地，不超过三秒钟。没有图形界面反而成了优势，因为终端里没有五颜六色的干扰。

第二，数据锁死。我的日志就是纯文本，放在自己的目录里。以后任何工具不想用了，cat就能读取，用grep就能搜索，用脚本就能转成任何格式。数据所有权清清楚楚，不存在“导出只有 PDF”这种恶心事。

第三，依赖网络。很多云端工具断网就是一块废铁。caveman本地运行，断网时我照样写日志、查回顾、标记完成。同步是主动行为，不是默认上传。

1.3 适合谁，不适合谁

它不是万能钥匙。如果你需要多人协作、共享看板、权限管理，别用caveman，真的不要用。它连多人模式都没有，硬用只会把团队协作变成灾难。

它适合这几类人：习惯终端操作、文字表达能力强于鼠标点选的人；工作内容以写文档、写代码、写作、研究为主的人；对隐私和数据掌控有执念的人；以及被各种效率工具绑架、想从“管理任务”回到“推进任务”的人。

我自己属于最后那类。以前每天光是把待办整理得像艺术品，就要花掉半小时。现在我只关注一条一条日志，任务完成了就在终端敲一句ca done，干净利落。

2. 整体设计与核心思路

2.1 设计哲学：少即是多

caveman的整个设计就三条原则：

一，一条日志是一个最小单位。不要子任务，不要嵌套层级，不要“任务下面挂评论再挂附件”。要复杂关系，你自己脑补；要长期目标，自己写进每周回顾。

二，完成是追加而不是清理。日志一旦写进去，就永远留在当天文件里。做完的事只是把[ ]改成[x]，绝不删除。这条原则很重要：时间久了翻看日志，你看到的是“当时发生了什么”，而不是“当时我把什么安排得明明白白”。

三，统计靠解析，不靠数据库。caveman没有任何数据库，每次统计都是现读文件、现算结果。数据量小的时候，这种“笨办法”反而省心，不用担心数据文件损坏，不用做数据库迁移，也方便用 Git 做版本管理。

它和主流工具的区别，我用一张表说明：

我并不是说主流工具一无是处，而是说“复杂性”本身有成本。对一个单打独斗的人来说，那套复杂系统侵蚀的专注力，远大于它省下的时间。

2.2 技术选型：为什么是 Go + 纯文本

选 Go 做这个工具，理由很直接：编译出来是单个二进制文件，放到任何机器上都能运行，不需要装 Python、Node 这些运行时。我用它就是为了低摩擦，如果记录一个想法之前还要检查依赖版本，那就本末倒置了。

数据层我选了纯文本，而不是 SQLite。有人可能会问：纯文本解析起来慢，统计功能怎么做？说实话，对一个每天几十条日志的个人工具来说，几百个 Markdown 文件用 Go 解析，耗时基本可以忽略。而且纯文本天生自带两个好处：

第一个好处是可 diff。每一条新增日志在 Git 里都会清晰地显示出来。配合 Git 同步，等于免费拥有一个版本历史。

第二个好处是可组合。任何编辑器都能打开，任何语言都能处理，它不会成为信息孤岛。以后想接 Emacs、Obsidian、Jekyll，只要把目录指过去就行。

我没有引入复杂的状态管理，工具本身只负责“追加、标记、搜索、汇总”四件事。状态越少，bug 越少，代码也越好维护。

2.3 目录结构与数据格式

数据目录默认在~/.caveman，结构非常简单：

~/.caveman/ caveman.toml entries/ 2025/ 03/ 13.md templates/ daily.md

每天一个 Markdown 文件，按年、月、日三级目录存放。文件名就是日期，例如13.md，因为年份和月份已经在目录里体现，不需要重复。

当天文件的内容长这样：

# 2025-03-13 - 09:10 晨会：同步版本发布计划 - 09:30 [ ] 完成支付模块自测 +支付 - 10:00 处理线上订单异常 +售后 - 11:20 [x] 回复博客读者评论 +写作

每一行都是一条日志，格式统一为“时间 + 状态 + 内容 + 标签”。标签用+开头，比如+支付、+写作。为什么不直接写 Markdown 的井号#？因为我怕和# 标题冲突，解析起来反而麻烦。后来验证下来，+确实是最省心的选择。

配置也很短：

timezone = "Asia/Shanghai" editor = "vim" habit = ["写作", "跑步", "阅读"]

habit这个配置会用在ca week的周回顾里，专门统计你关心的几类习惯有没有持续做。

3. 安装与基础实操

3.1 环境准备

caveman的目标平台是 Linux、macOS 和 Windows 终端环境。如果你只是想在 Mac 上快速体验，通常需要先安装 Homebrew，再在项目 Release 页面下载对应平台的二进制文件。不想用包管理器的话，直接把下载文件放到 PATH 目录下即可：

chmod +x caveman install -m 755 caveman /usr/local/bin/

有 Go 环境的人也能从源码编译，命令很简单：

go build -o caveman .

编译的时候我建议加上版本号：

go build -ldflags="-X main.version=0.1.0" -o caveman .

这样以后排查问题的时候，ca --version能直接告诉你用的是什么构建。

安装完成后，先跑一次：

caveman init

它会创建~/.caveman目录和默认配置文件，同时生成今天的日志文件。

3.2 核心命令速查

命令刻意保持精简，常用就下面这十个：

这里有个小设计：init之后你甚至不需要记住这么多命令，因为today会直接打开编辑器。很多人实际使用中，99% 的时间只靠log、today、done三件事。

3.3 第一次记录

安装好之后，我建议你先做一次完整测试：

caveman log "初始化 caveman，记录第一条日志" caveman today

执行完打开今天的文件，你会看到类似内容：

# 2025-03-13 - 09:10 初始化 caveman，记录第一条日志

如果目录或文件权限有问题，log命令会直接报错，不会静默失败。这是我很坚持的一点：数据工具最怕“写不进去但告诉你是成功”。

4. 核心功能解析与实操要点

4.1 日志记录：一句话作为最小单位

caveman log是整个工具的基础。它接受一个字符串参数，自动补上当前时间，追加到今天的日志文件末尾：

caveman log "完成用户注册接口联调 +支付"

这条命令会在当天文件末尾追加：

- 14:22 [ ] 完成用户注册接口联调 +支付

注意，新追加的日志默认是“未完成”状态，用[ ]标出来。为什么不是直接当成一个纯事件记录？因为在实际使用中，日志和任务是同一个东西。上午我记下“要处理某某 bug”，下午处理完，我希望它能在统计里变成完成项。与其区分“事件型日志”和“任务型日志”，不如统一用完成状态来表示。

这个设计还有一个隐藏好处：你不需要在记录瞬间决定某件事是不是任务。先记下来，之后可以随时标记完成。工具不会强迫你做分类判断，分类判断是最消耗脑力的动作之一。

4.2 完成标记：用追加代替删除

我在设计时最坚持的一点是：不要删除，只标记。

当一行日志对应的事情做完了，执行：

caveman done "完成用户注册接口联调"

它会找到当天文件里和“完成用户注册接口联调”模糊匹配的那一行，把[ ]改成[x]：

- 14:22 [x] 完成用户注册接口联调 +支付

为什么要用模糊匹配而不用行号？因为行号会随着日志追加而变化，今天记的是第 8 行，明天日志一多就找不到。模糊匹配只认关键字，只要句子是唯一的，就能准确命中。如果匹配到多条，命令会列出来让你选择，不会默认改第一条也不会上来就全改。

对于“做到一半被外部打断”的情况，可以用：

caveman wait "用户注册接口联调"

它会改成[!]状态。这个状态的统计不计入完成，但也不会消失，提醒你这件事还没结束。

这里有一条实操经验：写日志的时候不要让句子太短，至少要包含一个名词和一个动词。太短的句子，比如“处理一下”“写邮件”，三天后就变成天书，连你自己都不知道当时要处理什么。日志是写给未来的自己看的，模糊匹配只是辅助，充分的信息量才是复盘的关键。

4.3 统计和回顾：克制中的关键能力

没有数据库，统计就靠每个文件实时解析。caveman stats会给出总体情况：

caveman stats

输出类似：

2025-03-13 总结 日志总数: 12 已完成: 8 等待中: 2 未完成: 2 完成率: 66.7%

caveman week是周回顾的核心命令：

caveman week

输出类似：

本周（W11） 日志总数: 54 已完成: 45 平均每天: 7.7 条 +写作 完成 6 条，未完成 2 条 +跑步 完成 3 条，未完成 3 条 +支付 完成 9 条，未完成 1 条

这种统计不需要花哨的图表，只需要“我看到数字就能判断：这周是不是又在某个重要事情上拖延了。”真正的复盘并不需要工具替你生成一张带趋势线的报表，需要的是你可以快速从一个混沌的日志流里跳出来，看见模式和漏洞。

4.4 搜索：不建索引的全文 grep

caveman search本质上就是针对日志内容的递归搜索，但做了一层格式化输出：

caveman search "接口"

它会返回所有包含“接口”的行，并带上日期：

2025-03-13 14:22 [x] 完成用户注册接口联调 +支付 2025-03-12 16:40 [x] 确认支付回调接口参数 +支付 2025-03-11 09:15 [ ] 整理对外 API 接口文档 +文档

如果你以后不想再被某个工具绑定，完全可以写脚本把目录里的 Markdown 全部转成 CSV 或 JSON。数据格式简单，迁移成本就低，这就是纯文本的长期价值。

5. 一次完整的日常使用流程

5.1 早晨：先写三个意图

我每天到工位的第一件事，不是打开邮箱，也不是刷消息，而是打开终端：

ca today

然后直接在当前文件里写下今天最想推进的三件事，通常放在文件顶部：

# 2025-03-13 - 09:05 [ ] 完成支付模块自测 +支付 - 09:05 [ ] 写完博客《本地优先工具》初稿 +写作 - 09:05 [ ] 回复三个合作邮件 +沟通

写完这三行，今天的“锚点”就有了。之后无论被多少信息冲散，只要回来翻一眼文件，就能想起来自己今天到底要做什么。

这一步的关键不是计划得完美，而是把意图从脑子搬运到文本里。大脑不是用来存储的，大脑是用来思考的。我见过很多效率工具用户，喜欢做极其详尽的 morning plan，光计划就花一两个小时，这反而是自我感动。caveman的粒度只要求三件事，做不到的事写太多也没用。

5.2 白天：被打断时用日志缓冲

白天的工作中，最大的敌人不是困难任务，而是频繁打断。以前被人问一句“那个账单什么时候处理”，我会立刻切到任务管理软件，建一个任务，再回来写代码，上下文切换成本极高。

现在如果被打断，我只敲：

ca log "处理用户账单查询问题 +售后"

几秒钟完成记录，然后继续手头的代码。记录之后，这件事就进入了当天的日志流，不会被忘记，也不会占用大脑带宽。等手头代码告一段落，再回到终端批量执行ca done。

批量处理完成状态是我实践下来最高效的动作。不要在每次完成一件事后立刻打开终端，那样反而多一次上下文切换。攒三四件事，在喝水、上厕所、等编译的时候集中标记，效率最高。

5.3 周五下午：周回顾

每周五下午我会固定花十五分钟做周回顾。动作很简单：

ca week

先看完成率和标签分布，然后打开这一周的所有文件：

ca search "本周" # 这句并不需要，正常的做法是直接看目录

实际操作中我更推荐直接进入这个目录看：

$EDITOR ~/.caveman/entries/2025/03/

这时候一周的记录都在眼前。我会回答自己三个问题：这周真正推动的事情有哪些？哪些事反复出现但一直没完成？下周最重要的三件事应该是什么？

这三个问题的答案，直接写进下周一日志文件的顶部。整个回顾过程不离开终端，不需要导出报表，不会掉进“处理数据”的兔子洞。

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

6.1 命令找不到

很多刚下载二进制的人会遇到：

zsh: command not found: caveman

原因大多是文件没有放进 PATH。排查思路很简单：

which caveman

如果没有输出，说明路径不在$PATH里。临时验证可以这样：

./caveman --version

长期使用建议放在/usr/local/bin：

install -m 755 caveman /usr/local/bin/

另外要注意，下载文件名如果是caveman-linux-amd64，记得重命名成caveman，否则输入命令的时候会很不顺手。

6.2 记录时间跑到昨天去了

日志用的是系统本地时间，如果你在容器或者远程服务器上用，很容易出现“时区不对”的问题。表现就是你今天敲下log，结果跑到了昨天的文件里。

解决方案是在配置里固定时区：

timezone = "Asia/Shanghai"

caveman在解析时间时会优先用配置文件里的时区。修改配置后，可以执行：

ca today

确认今天的文件是否生成正确。如果还是不对，先检查系统时间本身：

date

系统时间错了，任何工具都救不了。

6.3 误标记完成或者标错了

ca done用模糊匹配，偶尔会出现“匹配到很多条”的情况。工具会把候选列出来让你选，所以基本不会乱改。但如果你不小心把某条标成了[x]，想撤销：

ca undo "用户注册接口联调"

它会精确地把[x]还原成[ ]。这个命令没有单独出现在常用表里，因为它本质上只是“反向标记”。

如果文件被你自己手贱改坏了，也不用慌。只要是同步过的数据，就从 Git 历史里恢复：

git checkout -- entries/2025/03/13.md

没有同步过的，唯一的办法是看编辑器缓存或者手动重建。所以我会强烈建议：哪怕只有一个设备，也把~/.caveman初始化成 Git 仓库。这不是为了上云，是为了给自己留后悔药。

6.4 日志文件越来越长

有人担心一年之后每天的文件会爆炸。实际上单日日志很少会超过几十行，真正多的是长期文件累积。

目前的做法是按月归档：每个月结束后，可以用：

caveman archive --month 2025-03

把三月的所有entries/2025/03文件合并归档成archive/2025-03.md。归档后不影响搜索，因为search默认也会扫archive目录。

不过就我的使用量看，一年也才几百条日志，全部放着也不过几 MB，完全不需要焦虑。大量归档反而会让“当周回顾”失去上下文。我的建议是：只归档超过一年且确定不会再回顾的月份。

6.5 多设备同步冲突

sync命令实际上是git add && git commit && git push的一层封装。如果你在两台电脑上改了同一个文件，就可能出现冲突。

好在caveman的数据模式是“按天分文件”，两台设备同时修改同一天文件的概率并不高。万一冲突了：

caveman sync --merge

它会尝试把两边的日志按时间顺序合并到同一个文件里。如果自动合并失败，就把你带进编辑器手动解决，冲突标记是标准的 Git 格式：

<<<<<<< HEAD - 09:10 晨会 ======= - 09:30 处理订单 >>>>>>> remote

手动选择保留哪些行就好。这个场景很少发生，但知道怎么解决，真碰上了就不会心慌。

7. 使用心得与下一步打算

7.1 踩过的坑

我试过在caveman里加太多东西。一开始计划让它支持子任务，用缩进表示层级；后来又试着引入自定义状态，比如“暂停”“阻塞”“已完成但有疑问”。最后发现，这些通通都是给工具增加熵，却给使用者增加选择。

真正留到最终版本的只有一个状态位：完成，或者没完成。等待状态[!]都是在后来几十条“做到一半”的实践中才加的，因为确实有太多外部依赖没法单纯用“未完成”表达。

另一个坑是我曾把标签设计成很多种：+项目、#领域、@地点、!优先级。用了一个月，我发现绝大多数日志只有一个标签，第二个标签几乎从来不用。减到最后，只剩一个+分类。工具要跟随人的真实习惯，而不是反过来要求用户遵守一套复杂的标记体系。

7.2 它不适合什么场景

诚实地说，caveman不适合 deadline 密集的工作。如果一个任务必须被提醒才能完成，那它需要的不是日志工具，而是日历。

我现在的组合是：caveman负责记录、回顾和沉淀，系统日历负责那些“错过就出事”的外部约定。日志文件里只写“要推进什么”，日历里才写“必须何时交付”。一个让我保持节奏，一个让我守住底线。

团队协作就更别想了。caveman的多设备同步只解决“一个人的数据迁移”，不解决“多个人的任务分配”。团队如果需要共享进度，用一个正经的项目管理工具无可厚非。

7.3 后续可以怎么扩展

因为数据是纯文本，扩展空间其实很大。我现在已经在用脚本做几件事：

第一，每天 18:00 自动生成当天完成情况，通过内部机器人发到自己的聊天窗口。其实就是：

0 18 * * * caveman stats

第二，把每月的日志转成纯文本周报，粘贴到周报系统里。不用截图，不用导出 PDF，直接文本最省事。

第三，开始尝试在每周回顾时把“未完成”条目抽出来重新写入下周计划。这个动作目前是手动完成的，但数据都在 Markdown 里，写脚本自动做并不难。

我个人在实际操作中的体会是：工具真正的价值不在于功能多丰富，而在于它能不能把记录这个动作的摩擦降到最低。caveman没有把效率这件事变得“好看”，但它让我第一次觉得“记录”不是负担，而是思考的一部分。如果你也常年被效率工具的复杂度拖累，强烈建议从今天起，只用一个文本文件加一条命令，先跑通两周再说。

毕竟，原始人能活下来，靠的从来不是工具多，而是把每一件小事记进岩壁里，然后继续向前走。