企业官网建设流程全解析

caveman 这个名字，我第一次看到的时候还以为是个游戏模组或者岩石分类工具，直到有一次我在整理项目记录时无意间翻到它的官网，才反应过来——这是个时间追踪工具，而且是个纯粹跑在命令行里的老派工具。用了一段时间之后，我不得不承认，它可能是目前最符合“记录真实工作痕迹”这个需求的小工具之一。它不推销、不社交、不弹窗，只是安静地坐在终端里，问你“刚才在做什么”，然后把答案写进一个纯文本的数据库里。对那些每天要面对一堆开发任务、经常被会议打断、又需要向周报交代时间去向的人来说，caveman 的价值不在于花哨，而在于它的诚实和克制。

它的使用场景非常明确：你不想为“今天我干了什么”而费心回忆，只想在每次切换任务、结束一项工作、或者一天收尾的时候，花几秒钟回答几个问题，剩下的汇总和统计让工具去做。适合的人群也相当清晰——程序员、独立开发者、研究型岗位、以及所有需要复盘时间去向但讨厌复杂操作的人。这篇文章我就把它的设计逻辑、安装方式、真实记录机制、报告生成和集成玩法完整拆一遍，顺带把我踩过的一些坑也列出来。

1. caveman 到底是什么：一个时间追踪工具的设计思路

1.1 为什么叫 caveman，它的核心主张是什么

caveman 由英国程序员 Simon Tatham 开发，他是个老资格的开发者，如果你用过 PuTTY，应该对他的名字不陌生。这个工具的名字其实带着一点自嘲和返璞归真的意味——在一个充满云端同步、AI 助手和可视化仪表盘的时代，它坚持“穴居人”级别的简单：没有 GUI，没有守护进程，没有数据库服务器，只有可执行文件和一个纯文本数据文件。

它的核心主张可以用一句话概括：记录工具不应该干扰你的工作。大多数时间管理软件的问题在于，它们要求你事前去规划，要求你建项目、建任务、建标签，甚至要求你在任务开始前点一下“开始”。可是真实的工作节奏根本不是那样，我们经常是被打断之后才意识到上一件事已经结束了，或者一天过了大半才想起来需要记录。caveman 反其道而行之，它只关心过去的事实，不预测未来。你运行它的时候，它只会问三个问题：你刚才在做什么？这件事是什么时候开始的？你现在要切换到什么？回答完毕，它就安静退场。整个过程不会超过三十秒，而且不需要你提前设置任何结构。

这种设计理念让我联想到了另一个工具——ledger，它同样是命令行、纯文本、不依赖云服务。它们共享同一类价值观：数据属于用户，工具只是辅助；凡是能用文件解决的问题，就不应该引入服务端。如果你习惯了那种“打开软件先选工作区再建任务”的流程，caveman 会给你一种反直觉的轻松感，因为你的记录成本被压到了最低。

1.2 使用场景与目标用户

caveman 适用的场景有很强的指向性。第一类是自由职业者和远程工作者，你需要给客户分项目计费，但又不想用复杂的工时软件；第二类是程序员，尤其是那些一天要在编码、代码审查、会议、文档之间切换多次的人，用 caveman 记录切换过程非常自然；第三类是研究者或者写作人员，他们的工作成果很难用“完成了几个任务”来衡量，但用时间片段来复盘却非常有效。

不太适合 caveman 的人主要是两类：一类是依赖项目经理分配任务、需要团队协作看板的人；另一类是喜欢丰富图表和移动端提醒的用户。它也有一个配套的 HTML 报告生成能力，可以生成按项目、按日期的统计页面，但整体上它还是面向单体用户，你的数据默认只存在你自己的工作目录下。当前的设计中也没有多人协作的概念，所以如果你想拿它来做团队工时管理系统，那大概率会失望。

我个人的建议是：如果你已经有一套基于日历的规划方式，只是缺一个“事后回顾”的工具，caveman 正好补位。它不会替代你的 TODO 列表，而是给你一个可靠的“实际时间都花到哪里去了”的答案。

2. 安装与初始化：把 caveman 跑起来

2.1 源码编译与安装注意事项

caveman 的安装方式比较“古早”，它在官网提供源代码包，需要自己编译。别被这一步吓退，实际上它的依赖非常少，是一个标准的 ANSI C 程序，只需要 make 和一个 C 编译器。在 Linux 和 macOS 上通常直接执行make就能编译出caveman可执行文件，在 Windows 上则需要一个具备 make 能力的编译环境，比如 MSYS2 或者 WSL。

我安装时的具体步骤是这样的：

wget https://www.chiark.greenend.org.uk/~sgtatham/caveman/caveman-1.2.tar.gz tar -xzf caveman-1.2.tar.gz cd caveman-1.2 make sudo make install

安装完成后把二进制加入 PATH，然后建议设置一个别名，因为caveman这个名字有点长，每天敲很多遍会烦。我一般用cm作为别名。值得注意的一点是：这个工具的帮助信息不是通过--help访问的，你需要运行caveman之后在交互界面里输入help命令，或者直接查看 man 文档。第一次接触的人容易在命令行里加--help发现没反应，然后就以为安装失败了，这其实只是设计上的风格选择——它把一切都收敛到了交互模式里。

2.2 初始化向导与核心参数

第一次运行 caveman 时，它会在当前目录初始化一个名为caveman.log的数据文件，并启动一个向导。这个向导会询问一些基本信息，比如你的默认工作开始时间、项目名列表、以及是否启用彩色输出等。这个初始化过程设计得比较友好，它会用对话方式引导你完成，不需要你去翻配置文件。

有几个关键参数值得说清楚。第一个是默认时区，caveman 会读取系统时区，但如果你有跨时区协作或者经常出差，建议显式设置，避免记录的本地时间与真实时间错位。第二个是项目的默认标签列表，你可以提前把常用项目写进去，后续记录时会自动补全，这个操作类似 shell 的历史补全，能减少不少输入量。第三个是报告中的“小时单位”设置，caveman 支持十进制小时和 HH:MM 两种显示方式，我建议选十进制，因为后续做费用核算时直接用数字乘单价就行。

初始化完成后，数据文件里会有一些基础记录，但此时还没有任何时间条目。你不需要再准备其他配置文件——它把配置也写进了同一个日志文件里，好处是你搬家或者换电脑时，只要带着caveman.log走，所有历史记录和配置都在。

2.3 核心命令速览

caveman 的所有交互都是运行caveman后输入子命令完成的。最常用的几个命令我用一张表列出来，方便随时查阅：

这里要特别提醒：start和end是本工具的灵魂。它的工作机制不是简单地记录“几号几点我做了什么”，而是记录一个“状态切换序列”。比如你上午 9 点开始写代码，运行start coding，那么从 9 点起就处于 coding 状态；如果你 11 点被叫去开会，运行start meeting，它会自动把 9 点到 11 点之间的时间归给 coding。这种设计省去了大量手工输入起止时间的操作，也让中间的中断变得透明。

3. 核心细节与真实记录机制

3.1 数据存储方式与恢复逻辑

caveman 的数据文件本质上是一堆人类可读的文本行。每行代表一次状态切换，包含四个元素：日期、时间、动作（开始或结束）、项目名。比如下面这样：

2024-03-12 09:02:30 start coding 2024-03-12 11:05:12 start meeting 2024-03-12 11:48:02 end 2024-03-12 13:30:45 start coding

这种格式有一个非常大的好处：完全透明。你随时可以用任何文本编辑器打开它，看看自己那天到底做了什么。我的习惯是每周末用 Vim 打开caveman.log快速扫一遍，这比看任何统计图表都更有真实感，因为你能看到那些细微的切换痕迹——比如下午 2 点突然有十分钟的空档，那多半是接了通电话。

恢复逻辑也很有意思。如果你手动修改了文件，caveman 还能通过日期解析把修改后的内容重新纳入统计，因此它也兼作文档记录。不需要担心工具升级导致数据不可用，因为这个纯文本格式几十年都不会变。比起那些存在云端、数据被锁在私有格式里的商业软件，这种朴素反而成了一种长期主义的设计优点。

3.2 记录时间与容错补漏

真实使用中，你不可能做到每次任务切换都准点打卡，caveman 对此的处理方式相当宽容。当你运行start时，它会询问当前任务是什么时候开始的；如果你不太确定，可以直接回车，它会默认使用当前时间。但更实用的是，它允许你输入一个模糊时间，比如“10分钟前”或者“下午2点”，解析器会尝试理解这些自然语言描述。

这就是 caveman 的一个杀手级特性——它不要求你实时记录，允许事后补记。中午吃饭回来突然想到上午忘了记录，你只需要运行start coding，然后输入“上午9点半”作为开始时间，前面的空档就会被自动填上。如果再配合edit命令微调，你完全可以在一周结束时花十分钟把整周的时间账补完，只要你的记忆力还靠得住。

不过要注意，这种容错也有边界：如果两条记录之间的时间有重叠，caveman 会按照后一条记录为准进行截断。逻辑上它是线性账本，不支持并行任务。也就是说，你不可能同时处于 coding 和 meeting 两个状态。如果你确实需要处理“穿插进行”的工作，建议拆成更细的片段，或者用项目命名去区分，例如coding - backend和coding - frontend。

3.3 别名机制与配置技巧

caveman 除了交互式记录，还支持通过命令行直接传参：caveman start coding这种写法就能直接开启记录，省去进入交互界面的步骤。我是用 shell 别名配合快捷键来提高效率的，比如在.bashrc中加入：

alias cm='caveman' alias cms='caveman status' alias cmr='caveman report'

这样在终端里输入cms就能看到当前进行中的任务，输入cmr就能生成报告。这套组合用习惯了以后，记录过程的心理负担几乎为零。

初始化时设置的项目名列表也很关键。我会建议把它看成一个“项目 + 动作”的复合标签体系，不要只写项目名，应该加上动词。例如coding - feature-x、meeting - weekly、research - logs。这样后续跑stats时，你能直接看出自己在“编码、开会、研究”这些动作上的时间分布。另外，项目名的命名尽量保持稳定，因为 caveman 是按字符串精确匹配来聚合统计的，同一个项目换个写法，报告里就会裂成两行。

4. 输出报告与钩子集成

4.1 四种报告格式对比

caveman 的report命令支持生成四种格式：纯文本（txt）、HTML、CSV 和 JSON。其中纯文本格式适合在终端直接查看，HTML 适合浏览，CSV 适合导入 Excel 或在线表格，JSON 则适合写脚本进一步处理。

我日常用得最多的是 HTML 报告，因为它会按日期排序、按项目着色，看起来非常直观，而且可以直接在浏览器里打印成 PDF 作为周报附件。CSV 格式我一般用来做月度汇总，导入 Excel 后自己再加一列“单价 × 小时数”就能算成本。JSON 格式用得最少，一般只在写自动统计脚本时才用。

生成报告的命令也很简单，在 caveman 交互界面里输入report后选择格式与时间范围。另外，它还支持stats命令，它会生成一个简单的 ASCII 图表，按项目显示占据的时间百分比。这个图表虽然简陋，但对快速把握一周的时间分布非常有帮助——比如周一开会占比突然到 60% 以上，就该反思是不是会议密度过大。

4.2 Git 钩子自动生成日报告

如果你是一个 Git 重度使用者，caveman 有一个非常巧妙的玩法——把它接入 Git 的钩子。我的做法是在项目仓库里创建.git/hooks/pre-commit文件，内容大致如下：

#!/bin/sh caveman report --format=text --since=today > time-report.txt git add time-report.txt

每次提交代码时，它会自动生成一份当日的时间报告并附带进提交。这样做的好处是，你提交代码时也同步提交了“这段时间的工作痕迹”，代码审查时如果能配合时间报告，就能还原出某个功能的实际开发耗时。不过我建议不要把自动生成的报告放到与源码同级的位置，而是放到docs/或者reports/目录下，避免污染根目录。

如果你用git commit --amend或者 rebase 之类的操作，注意时间报告的内容是基于“当前时间”的，因此补交时可能会把你正在做的其他任务时间也算进去，这个坑我在一开始踩过几次，后面就只在pre-commit里生成，而不再在 hook 里存储历史报告文件，减少误提交的干扰。

4.3 估算时间与统计视图

caveman 的统计视角对“估算”这件事情有独特的帮助。它不仅能告诉你每件事花了多久，还能通过read命令回溯某一天的记录，看看当时的时间切分。这种“事后复盘”的价值在于，你可以逐渐修正自己的任务估算能力。

比如我连续记录了六周之后，发现自己对“debug 时间”的估算总是偏少，实际用时往往是预估的两倍。如果不借助工具，这种偏差很难被量化，因为大脑倾向于美化记忆。有了记录之后，我写项目排期时会自动给调试类任务乘以 1.5 的系数，准确率提升了很多。这就是实时记录数据带来的直接收益——它不是用来惩罚你“哪里浪费时间”，而是帮你了解自己的真实工作节奏。

5. 常见问题与实战心得

5.1 高频问题排查速查表

我整理了一份使用 caveman 过程中最容易遇到的几个问题，以及对应的解决办法，供大家按图索骥：

有一个问题我想单独强调：如果日志文件被错误地截断或误删，恢复起来非常麻烦。因为 caveman 没有云同步，它在本地只有一份数据。我的建议是，把caveman.log纳入 Git 仓库或同步盘，并在.gitignore之外单独为它建一条备份策略。我自己是把日志文件放在 Dropbox 的同步目录里，配合版本历史，误删也能找回。

5.2 几条长期使用的建议

最后说几条我从实际使用中总结出来的经验，不是官方文档里的内容，但我觉得非常有用。

第一条，尽量固定每天第一次记录的时间点。你可以把它嵌入晨间例程：打开电脑后第一件事就是运行caveman start daily-planning，这样无论后面怎么切换，当天的起点是明确的。

第二条，不要追求 100% 的完美记录。你漏记一段很正常，与其强迫自己补全每一个空洞，不如接受不完美，保持“大致准确”即可。caveman 的定位是给你一个可靠的时间镜像，不是让你产生更多焦虑。

第三条，定期运行 report 并留档。我通常是每周一生成上周周报 PDF，存到工作档案目录。这样季度总结时无需再翻原始数据，直接看周报就能回顾大概。

第四条，善用 edit 命令修正模糊边界。比如你写着写着代码被拉去处理了 15 分钟服务器问题，回来又继续写，可以把这 15 分钟单独拆成ops - server-issue条目。这种细节粒度在月度复盘时非常有用，能帮你发现那些“隐性运维时间”。

caveman 这个工具我已经用了快两年，它没有逆天的功能，也没有好看的数据可视化面板，但它帮我解决了一个最核心的问题——不再凭记忆编造时间账。每次客户问我某个功能实际花了多久，我都能从报告里翻出真实数据来回答。这种“心里有底”的感觉，是那些花哨的时间管理软件很少能带给你的。如果你也厌倦了到处记账、被各种提醒打扰，不妨试试这个穴居人风格的老派工具，它可能比你想的更懂“记录”这件事。