1. 为什么是caveman：简单到像穴居人一样的任务管理
我大概是在三个月前，把自己的任务管理方式彻底推倒重来的。原因不复杂，就是受够了。以前电脑里躺着三四个所谓的效率软件，手机上也装了两个，桌面挂件、日历提醒、标签体系全都折腾过，最后反而陷入一个很尴尬的循环：整理任务花的时间，比完成任务还多。后来我偶然看到一款叫caveman的命令行任务管理工具的截图和介绍，第一反应是“这也太原始了”，第二反应是“这才对啊”。它把整个任务系统压缩成一句话：一个纯文本文件，几条简单命令，没有任何服务端，没有任何花哨界面。我立刻意识到，这就是我一直缺的东西，于是顺着它的思路，自己动手搭了一套完全属于自己的极简任务系统，并沿用这个名字作为代号。
caveman这个名字，直译是穴居人，放在这个场景里非常传神。穴居人不需要复杂的工具，一块石头、一根木棍就能解决生存问题。任务管理也一样，大多数时候我们根本不需要复杂的工作流引擎、自动化规则、团队协作看板。我需要的就是快速记下一件事，到时间看一眼，做完划掉，隔阵子回顾一下。那些额外的东西不但没有帮助，反而成为负担。这套极简方案的适用范围很广：独立开发者管理自己的项目、学生安排学习和毕业设计、自由职业者跟踪待办事项、甚至普通上班族记录一日清单都可以用。
如果你也是一个工具囤积症患者，或者正处于“工具太多但效率太低”的状态，这篇文章值得你看完。我会把整个方案的思路、存储格式、核心代码、日常使用流程、踩过的坑全部写出来。不是让你照抄我的代码，而是希望告诉你这种极简思路怎么落地，以及为什么它能长期坚持下来。
2. 核心设计拆解：一个caveman任务系统的完整结构
2.1 存储格式：为什么要用一行一条的纯文本
任务管理系统的地基，是数据存储方式。我用过数据库方案的，也用过JSON方案，后来全部放弃了。数据库方案有个隐藏成本：你想查询数据，必须写SQL，必须保证数据库服务正常运行，一念及此就觉得累。JSON方案相对轻量，但每次读写都要保证结构完整，括号嵌套、引号转义，处理起来头大。
caveman方案采用的是最朴素的存储格式：纯文本文件，一行一条任务。
[ ] 整理月度财务账单 [x] 完成项目性能报告 [ ] 预约体检 #health @personal这种格式有什么好处？第一，任何设备、任何编辑器都能直接打开。Windows的记事本、macOS的文本编辑、Linux的Vim，乃至手机上的备忘录，统统可以处理它。第二，版本管理非常友好。纯文本文件可以直接丢进Git仓库，每次修改都能看到差异对比，比数据库导出SQL可读多了。第三，不会有“文件损坏导致整个系统崩溃”的问题。最多坏一行，改掉就好。
在格式设计上，我参考了todo.txt的风格，做了一些自己的调整。每行任务由几个字段组成：状态标记、任务内容、项目分类、标签、优先级。状态标记放在行首，用方括号括起来，空方括号表示未完成，x表示已完成，这样一眼扫过去就知道哪些事是待办的。
2.2 数据结构：状态、优先级、项目与标签
任务系统的核心数据结构并不需要太复杂，关键是定义清楚几个维度。
第一是状态，我用三种状态就够了：待办、进行中、已完成。曾经想过加“已推迟”“等待”这些状态，实际用下来发现没用，因为人面对一个状态列表，超过三个选项就开始纠结了，这是心理负担，不是管理效率。待办就是还没开始，进行中就是今天正在做，已完成就是结束。仅此而已。
第二是优先级，我不用A、B、C这种分级，更不用什么P0、P1、P2、P3的企业级字段。我的做法是在任务内容前面加一个感叹号表示紧急，两个感叹号表示非常紧急。因为优先级本质上只影响一件事：排序。你只需要知道哪些任务需要排在前面，一个简单的标记就够。
第三是项目归属和标签。比如一个任务跟“网站改版”有关，就加上@website这个标签。跟个人生活有关，就加@personal。标签用@开头，放在任务末尾，方便用脚本按标签筛选。
2.3 命令设计：五个基础命令覆盖所有需求
整套系统的交互设计，其实是学caveman那套极简思路的：能用一条命令行解决的事，绝不用第二个命令。
我总共设计了五个命令：
add：添加任务done：完成任务list：列出任务report：统计完成情况help：查看帮助
有人可能会问，怎么没有编辑任务、删除任务、推迟任务这些命令？我的回答是：直接打开文本文件改就行了。文本文件的最大优势就是可以随时手动编辑，操作顺手而且可控。命令行的价值在于高频操作，低频操作交给编辑器反而更灵活。
2.4 为什么不做成Web应用或者App
这个决定很多人不理解。既然要做工具，为什么不做成Web应用，手机电脑都能访问，不是更方便吗？
我的理由很简单：多端同步意味着需要服务器，意味着需要考虑认证、网络、数据一致性。这些都是维护成本。我的任务数据量不大，纯文本文件在本地存储完全够用，多设备同步可以用Git仓库解决，这才是真正无状态的方案。手机端需要查看任务时，我只需要记住任务文件的路径，配合一个资深的文本编辑器就能搞定。
当然，如果你工作环境允许，也可以把任务文件放到坚果云、Dropbox这类同步盘里，实现自动同步。这不是caveman方案的核心，但作为扩展手段是完全合理的。
3. 实操过程：用纯Python标准库实现caveman完整工具
3.1 环境准备与文件规划
实现这套工具，我不建议引入任何第三方依赖。Python标准库足够完成所有功能，这一点在现代开发环境里几乎零门槛。我用的是Python 3.8以上版本，Windows、macOS、Linux全部兼容，核心逻辑完全不依赖操作系统API。
先规划好文件结构：
caveman/ |-- caveman.py # 主程序 |-- tasks.txt # 任务数据文件 |-- done.txt # 已完成归档文件 |-- config.py # 可选的配置项主程序caveman.py放在系统PATH路径下的任意位置，或者用别名指向它。tasks.txt是日常要操作的任务文件，done.txt存放已完成的历史数据，用于后续统计。
3.2 核心实现：任务读取与添加功能
先从最基础的读取和添加做起。读取任务文件，按行解析，返回一个列表。
import os from datetime import date TASK_FILE = os.path.expanduser("~/caveman/tasks.txt") DONE_FILE = os.path.expanduser("~/caveman/done.txt") def load_tasks(): if not os.path.exists(TASK_FILE): return [] with open(TASK_FILE, "r", encoding="utf-8") as f: lines = [line.strip() for line in f if line.strip()] return lines添加任务时，根据参数构造一行文本，追加到文件末尾。需要注意的一点是：任务内容如果包含空格，命令行传参时需要用引号括起来，否则会被当作多个参数处理。我在add命令里做了参数拼接，不管传几个参数，全部合并成一个字符串。
def add_task(text): task_line = f"[ ] {text}" with open(TASK_FILE, "a", encoding="utf-8") as f: f.write(task_line + "\n") print(f"任务已添加: {text}")3.3 核心实现：任务列表展示与状态切换
列表展示功能需要考虑两件事：一是排序，二是过滤。我在list命令里支持通过可选参数按标签、按关键词过滤，默认展示所有未完成任务，并按优先级排序。
def list_tasks(keyword=None, tag=None): tasks = load_tasks() pending = [t for t in tasks if not t.startswith("[x]")] pending.sort(key=lambda x: (not x.startswith("[!]"), x)) for idx, task in enumerate(pending, 1): if keyword and keyword not in task: continue if tag and f"@{tag}" not in task: continue print(f"{idx}. {task}")这里排序的逻辑是：标记了感叹号的任务排前面，其余按加入顺序展示。标号idx很重要，因为完成任务时需要通过这个编号定位具体是哪一行，这就是为什么我不去解析完整任务ID而是直接用行号的原因。
完成一个任务时，根据编号找到对应的行，把状态标记从[ ]改成[x]，同时把这行追加到done.txt归档文件里。这里有个容易踩的坑：当任务列表不是按文件顺序展示时，行号并不等于列表的索引，所以我在代码里需要维护一个“展示列表到文件行”的映射。
def done_task(idx): tasks = load_tasks() pending_indices = [i for i, t in enumerate(tasks) if not t.startswith("[x]")] if idx < 1 or idx > len(pending_indices): print("编号无效") return target = pending_indices[idx - 1] tasks[target] = tasks[target].replace("[ ]", "[x]", 1) with open(TASK_FILE, "w", encoding="utf-8") as f: f.write("\n".join(tasks) + "\n") with open(DONE_FILE, "a", encoding="utf-8") as f: f.write(tasks[target] + f" done:{date.today()}\n") print(f"已完成: {tasks[target]}")3.4 核心实现：周报统计功能
统计功能是我用得最多的一个能力，毕竟任务管理最终要回答一个问题：我到底干了多少事？report命令读取done.txt文件，统计当天和当周的完成数量。这里我用了一个小技巧：完成过的任务行末尾记录了完成日期，格式是done:2025-01-08，通过解析这一串就能筛出指定时间范围内的数据。
from collections import Counter def report(): if not os.path.exists(DONE_FILE): print("暂无已完成任务") return today = date.today().isoformat() week_start = date.fromisoformat(today) week_start = week_start.fromordinal(week_start.toordinal() - week_start.weekday()).isoformat() done_count = 0 week_count = 0 with open(DONE_FILE, "r", encoding="utf-8") as f: for line in f: if f"done:{today}" in line: done_count += 1 if f"done:{week_start}" in line or line >= f"done:{week_start}": week_count += 1 print(f"今日完成: {done_count}") print(f"本周完成: {week_count}")这个统计逻辑写得比较粗糙，但在我个人的使用场景里完全够用。不需要精确到分钟级别的日期解析，字符串匹配就能满足需求。
3.5 配置命令行入口与日常使用流程
主程序写好后，我在bash配置里加了一个别名，这样每次只需要敲一个单词就能调用。
alias caveman='python3 ~/caveman/caveman.py'日常使用流程变得非常顺滑。每天早上起来，先执行caveman list看一眼待办事项。想到新的事情，直接caveman add，不需要打开任何应用界面。完成一件事，执行caveman done 3，系统自动归档到done.txt并给出反馈。晚上站在一天结束的当口，执行一次caveman report，看看今天到底处理了几个任务。
这套流程的核心理念和caveman这个名字的含义一模一样：把工具的使用成本降到最低，让人专注于做事本身，而不是专注于操作工具。事实上，一旦工具的使用成本降低，你会发现自己的记录意愿反而增强了，因为每记一笔只需要不到两秒钟。
4. 常见问题与排查技巧实录
4.1 中文编码与跨平台乱码问题
我在Windows上最初运行这个工具时，遇到了中文乱码问题。原因是Windows控制台默认编码可能是GBK，而Python打开文件时指定的UTF-8编码没有作用到输出。
解决方法是：在脚本文件顶部强制设置标准输出编码。
import sys import io if sys.platform == "win32": sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8")还有一个更简单的思路：把PowerShell或者CMD的默认代码页切换到UTF-8。执行chcp 65001命令，再运行Python脚本，中文输出就正常了。但如果你的脚本会在其他机器上运行，还是建议在代码层面处理，一劳永逸。
4.2 多设备同步时的文件冲突问题
把tasks.txt放到同步盘后，会遇到一个典型场景：电脑A上添加了两个任务，电脑B上完成了一个任务，然后同步盘提示文件冲突，生成了一个类似“tasks (冲突的副本).txt”的文件。
这个问题我后来用Git仓库方案解决了。把整个caveman目录做成一个Git仓库，每次操作后手动commit一次。虽然每次要多敲一条git add和git commit，但这些操作完全可以合并成一条自定义命令，批量完成提交动作。
function caveman-sync() { git add tasks.txt done.txt git commit -m "tasks update" git pull --rebase git push }这种方式的额外收益是：每次任务变更都有历史记录，可以回溯某天到底改了什么。对于有复盘习惯的人来说，这比任何“同步冲突解决器”都好用。
4.3 任务积压与归档策略
用久了之后，tasks.txt里的任务会越来越多。即便完成过的任务被移除了，但长期未完成的任务会不断堆积。时间一长，列表变得很长，看着就心烦，极简的优势也荡然无存。
我的处理方式是：每周做一次清理。把所有超过两周还没开始的任务审一遍，要么直接删除，要么重新改写为更具体的下一步行动。如果一件事两周都没动手，它通常不是真的重要，要么是缺乏行动动力，要么是任务本身定义得太模糊。比如说，“整理读书笔记”这种任务，就会被我改成“把《人类简史》第一章的笔记录入到Obsidian”。
archived.txt这个文件我不建议删除，因为它是历史记录的一部分，留着可以回看自己过去处理过的所有事项。
4.4 为什么不直接用现成的todo.txt工具
有人肯定会问：todo.txt生态里已经有很多成熟工具了，你为什么还自己写一遍？这个问题我自己也想过。
答案是：自己写的工具可以完全按照自己的想法演进。想加一个功能，改几行代码就行。看到某个输出格式不顺眼，改一下print语句就行。这种灵活性是任何现成工具都替代不了的。而且caveman整套代码加起来不到150行，维护成本极低，不会成为新的负担。
我也不是建议所有人都从头写一个。如果你不想碰代码，直接使用todo.txt的官方命令行工具是完全可行的，思路和效果几乎一致。我这里的存在，本质上是对todo.txt哲学的一次极简复刻和再定制。
5. 几个演进方向：从caveman系统到更大场景
5.1 与日历结合：任务和时间的桥接
纯文本任务系统有一个盲区：它管理“要做什么”，但不管理“什么时候做”。我尝试过在任务文本里加入日期标记，比如任务末尾写上due:2025-01-10，然后用一个脚本扫描所有任务，把三天内要到期的任务列出来，输出结果类似于“今日到期”和“即将到期”。
后来我更进一步，让caveman生成一个简单的iCalendar格式文件，导入系统日历。这样手机日历上也能看到关键任务，但数据源始终是那一个文本文件，不会出现多个系统数据不一致的问题。iCalendar格式本身也是纯文本，两行代码就能实现转换。
5.2 与GitHub Actions结合：自动生成每日任务卡片
如果你稍微有一点CI/CD经验，可以把caveman仓库丢到GitHub上，配置一个每日定时任务，自动读取tasks.txt并把未完成任务转换成一条Issue卡片，或者往某个Telegram机器人推送一条消息。这种方式特别适合还在读书或者喜欢看板式管理的朋友。
具体不细说，但有一句话经验值得听：自动化不是越多越好，而是要找到那个“真正每次手动操作都重复”的动作，把它自动化才划算。我的caveman系统里，唯一值得自动化的就是周报统计，这个已经做了。
5.3 更进一步的极简：一个文本文件搞定一切
写到结尾这里，我再分享一个小技巧。我最近把自己的caveman方案又简化了一层：不再区分tasks.txt和done.txt，所有内容全部放在一个文件里，未完成的任务排在前面，完成的任务保留在文件后半段，中间用一行分隔符---隔开。
这样做的最大好处是：打开文件，从头到尾就是一个完整的项目流水账。开始的时候看到待办，往下拉是已经完成的事，整个上下文一目了然。有时候工具做得太细腻，反而失去了文本原本该有的流畅感。
6. 实际操作中的几点个人体会
用了三个多月的caveman方案，最大的感受是：任务管理的核心不是工具，而是降低负担。以前我花在“选择工具”上的时间，现在全部花在了“做事情”上。每天打开终端，敲两三条命令，几分钟内就能完成任务的记录、查看、确认，完全不干扰工作流。
如果你也想试试这套方案，我建议从Copy我的代码开始，先用一周感受一下，再做自己的改动。第一周你可能会觉得命令行不够顺手，但熬过这个适应期，你会发现一个纯粹文本系统带来的踏实感。任务数据落在自己的电脑上，不依赖任何公司的服务器，不担心某个软件停止服务，这本身就是一种确定性和安全感。
