Caveman开发风格：用Python和SQLite快速交付内部工具

1. “Caveman”到底是个什么开发套路

要聊“caveman”这个词，得先跳出“穴居人”的字面意思。在程序员圈子里，它其实代表一种非常原生态的开发风格：不搞复杂分支管理，不追求过度设计，不用一堆框架撑场面，拿到需求直接在主分支上开干，写出来的代码像原始人敲石头一样简单粗暴，但能跑、能上线、能解决问题。

我第一次接触到这个说法，是在一个开源项目的 README 里。作者用“caveman-style”形容自己的开发方式：从项目开工到发布，全程只有一个 main 分支，没有 develop、没有 release、没有 feature 分支的花活，提交信息也写得像便签——“add stuff”“fix thing”“more code”。当时我还觉得这人不专业，后来自己做了几个中大型项目，回头再看，反倒觉得这种“原始人打法”有它存在的道理。

简单说，caveman 风格的核心不是“懒”或者“菜”，而是一种刻意做减法的心态：在项目规模没有大到必须引入复杂流程之前，先用最直接的方式把业务跑通，把成本压在最低。它能解决的问题也很明确：项目启动太慢、团队被 Git 流程拖累、代码被过度抽象搞得没人看懂、需求还没稳定就急着搭微服务架构。

这篇内容适合谁看？如果你是刚入行的开发者，想理解为什么有人这么写代码；或者你是小项目负责人，正在纠结要不要上 GitFlow、要不要拆服务——这篇东西能帮你理清思路。我会用自己做过的一个真实小项目来拆解：怎么用 caveman 思路做需求分析、选型、编码、测试，以及哪些环节真的该“当原始人”，哪些环节再节省成本也绝对不能省。

2. 内容整体设计与思路拆解：为什么 Caveman 风格能打

2.1 降低启动成本，先跑起来再说

我做过一个小工具，需求很简单：公司内部要统计各个小组每周的零食消耗数据，然后生成一个榜单，月底给消耗最少的组发奖励。传统做法是什么？需要 Web 前端、后端接口、数据库表设计、权限系统、部署平台……一套东西下来，光架架子就要一周。

用 caveman 思路做，我直接写了一个 Python 脚本，数据存 SQLite 单文件，跑起来就是一个命令行工具，终端里输入几行命令就能录入和查询数据。需求当天下午就交付上线了，第二天同事就开始用了，整个项目代码量不到 600 行。

这就是 caveman 风格最核心的出发点：不要为了未来可能出现的需求，牺牲当前 100% 的交付速度。很多项目死在起步阶段，不是因为技术选型不够先进，而是因为还没开始干活，团队就把精力耗在流程和基建上了。

为什么这种设计合理？逻辑很简单——业务验证期，唯一重要的指标是“有没有人愿意用”。你做一个复杂系统，哪知道核心功能是不是用户真正想要的？等你花两周搭完了，发现用户只想要个 Excel 汇总表，这时间就全浪费了。先给用户一个能用的、糙一点的工具，他用了、反馈了，你才知道下一步该往哪儿使劲。

2.2 减少决策摩擦，用最可靠的老技术

caveman 思路的第二个特征是：能用成熟技术，绝不追新。工具类项目，我首选 Python 标准库加 SQLite，连第三方库都尽量少引。为什么？

稳定压倒一切。Python 标准库被全世界数百万个项目验证过，SQLite 是任何 Python 环境都自带的。这套组合不会出现“版本冲突装不上依赖”“新框架有 bug 没人管”“接口变了文档没更新”这类问题。一个内部小工具，稳定性远比性能重要——哪怕它多跑 0.5 秒，用户根本感知不到，但如果周五晚上崩了没人修，周一大家就没数据用了。

对比来看：

很多人担心单文件脚本没法扩展，这个顾虑不是没道理。但我个人的经验是：一个工具要撑过几百人的内部使用场景，单文件脚本完全扛得住，真正的瓶颈往往出现在并发上千、数据量过亿这种级别——那已经不是一个“小工具”了，到那天再重构成服务端也不迟。先当原始人活下来，再慢慢进化成文明人，这个顺序特别适合内部工具类项目。

2.3 避免过度设计，代码可读性优先

在 caveman 模式里，我写代码只遵守三条原则：

• 第一，变量名和函数名要像人话。宁可多敲几个字符，也不搞缩写。“count_chocolate()”一眼就能看懂，写成“cnt_c()”三个月后我自己都得猜半天。
• 第二，一个函数只干一件事。听起来像教科书废话，但做减法的时候反而容易做到——因为不需要考虑抽象、复用和扩展，每个函数天然就是单一职责的。
• 第三，流程平铺直叙，不要花式嵌套。不用装饰器、不用元类、不搞复杂的继承体系。从上往下读代码，就像看一份操作说明书。

我把这次写的“巧克力库存管理”脚本拆开来看，主流程就是 6 个步骤：读配置文件、连接数据库、显示菜单、接收用户输入、执行增删改查、退出。每一步就是一个函数，函数间没有交叉调用，任何人拿到代码都能顺着读下来。对一个可能要交接给同事甚至明年自己维护的项目来说，这种“一眼能看懂”的价值，远大于“设计模式用得漂亮”。

3. 核心细节解析与实操要点：Caveman 项目的落地关键

3.1 选型不是拍脑袋，参数和场景要匹配

拿我这次的项目举例——做一个命令行版本的“零食库存与消耗记录器”。先解释一下为什么命令行而不是 Web 页面。用户对象是 3 个小组的组长，每周上报一次数据，使用频率极低、并发几乎为零、没有复杂交互。这种场景下，Web 前端那套东西纯属给自己找活干。命令行工具打开终端就能用，还不需要额外维护服务器和域名。

数据存储选 SQLite 的理由：单文件、零配置、支持 SQL 语法、Python 内置模块直接连接。不需要客户机装 MySQL 客户端，不需要运维搭 PostgreSQL 服务。你想想，公司内部工具的痛点从来不是“数据量太大存不下”，而是“换台电脑数据就丢了”“离职交接时别人不知道怎么备份”。SQLite 一个文件拷走就是完整备份，这体验堪比 U 盘即插即用。

操作逻辑设计上，我坚持“越少输入越好”。比如录入一条消耗记录，完整命令是：

python chocolate.py add --item 巧克力 --count 3 --group 研发组

这条命令看着字段多，但每个字段都有明确含义，而且带--help可以随时查看。员工不需要记忆脚本内部实现，只需要把它当成一个“高级计算器”使用。命令行的交互逻辑比图形界面更契合这种高频、固定模式的录入场景——打开、输入、回车，三步完成，鼠标都不用碰。

3.2 按“原始人”思路规划项目目录

传统项目目录是 src、tests、docs、config 分门别类放好，但小工具这么做就太重了。caveman 风格的项目目录通常就是扁平排列，我这次用的结构：

chocolate_tool/ ├── chocolate.py # 主脚本 ├── requirements.txt # 依赖清单（其实只有 sqlite3，标准库） ├── data/ │ └── inventory.db # SQLite 数据文件 ├── tests/ │ └── test_basic.py # 核心逻辑测试 └── README.md # 使用说明

没有必要创建多个模块文件，因为脚本只有几百行，拆成 models.py、views.py、controllers.py 反而让追踪逻辑变得困难——跳来跳去阅读的成本，远高于在一个文件里滚动阅读。我建议文件超过 1500 行、功能确实不再适合单文件承载时，再考虑拆分。caveman 不是反对工程化，而是反对“为了工程化而工程化”的空转。

一个非常容易被忽略的细节是 data 目录的初始化。脚本启动时会自动创建 data 目录和数据库文件，不用手动建，这样即使把项目拷到一台新电脑上，双击就能跑起来。我习惯在设计时把所有“环境准备”都做成自动化的——机器上只要有 Python 解释器，项目就能运行，这是对“零部署成本”最彻底的解释。

3.3 代码实现中的几个关键细节

下面这段是脚本里最核心的建表和插入逻辑，数据设计上我踩过一次坑，后面会细说：

import sqlite3 import os from datetime import datetime DB_PATH = os.path.join(os.path.dirname(__file__), "data", "inventory.db") def init_db(): os.makedirs(os.path.dirname(DB_PATH), exist_ok=True) conn = sqlite3.connect(DB_PATH) conn.execute(""" CREATE TABLE IF NOT EXISTS records ( id INTEGER PRIMARY KEY AUTOINCREMENT, item TEXT NOT NULL, count INTEGER NOT NULL DEFAULT 1, group_name TEXT NOT NULL, created_at TEXT NOT NULL ) """) conn.commit() conn.close() def add_record(item: str, count: int, group_name: str) -> None: conn = sqlite3.connect(DB_PATH) conn.execute( "INSERT INTO records (item, count, group_name, created_at) VALUES (?, ?, ?, ?)", (item, count, group_name, datetime.now().isoformat(timespec="seconds")) ) conn.commit() conn.close()

CREATE TABLE IF NOT EXISTS是幂等操作——哪怕脚本被反复执行，也不会重复建表报错；datetime.now().isoformat()把时间直接存成可读的字符串，排序和比较都没问题；时间存成 ISO 格式的好处是，后续如果真的要迁移到 MySQL，这个字段几乎不需要转换。

这个实现有一点要注意：conn.execute后面必须跟着conn.commit()，否则插入数据不生效。有些初学者经常漏掉这行，结果数据写入没报错，但重启程序后数据就没了。我习惯在封装函数内部就完成“连接→执行→提交→关闭”的完整生命周期，这样调用方永远不需要关心数据库事务管理。这其实不是 caveman 风格的妥协，而是通过减少暴露给使用方的概念，让整体系统的认知负担降到最低。

3.4 测试该写还得写，但别写成负担

“caveman”不等于不写测试，而是写最便宜能保命的测试。我的原则是：核心业务逻辑必须有测试，界面和外围流程能省则省。对这个脚本来说，核心逻辑就是数据统计和排名计算——这部分如果算错了，整个工具就废了。

我写的测试用例非常简单：

import sqlite3 def test_ranking_calculation(): conn = sqlite3.connect(":memory:") conn.execute("CREATE TABLE records (item TEXT, count INTEGER, group_name TEXT, created_at TEXT)") conn.executemany( "INSERT INTO records VALUES (?, ?, ?, ?)", [ ("巧克力", 5, "研发组", "2025-01-01T10:00:00"), ("巧克力", 3, "测试组", "2025-01-01T11:00:00"), ("薯片", 2, "研发组", "2025-01-01T12:00:00"), ] ) conn.commit() rows = conn.execute( "SELECT group_name, SUM(count) as total FROM records GROUP BY group_name ORDER BY total DESC" ).fetchall() assert rows[0][0] == "研发组" assert rows[0][1] == 7 conn.close()

用了 SQLite 的内存模式（:memory:），不用碰真实的数据库文件，测试跑完自动清空，又快又干净。这个测试的价值在于：以后如果有人要改统计逻辑、加过滤条件、改排序规则，跑一遍测试就知道有没有把基数算错，不至于上线后给用户报一个诡异的数据。

4. 实操过程与核心环节实现：从零到交付的完整流程

4.1 需求确认：别急着动手，先问清楚三个问题

这次项目开始前，我先去跟实际用户聊了 20 分钟。就是这 20 分钟，让我少走了不少弯路。核心问题就三个：

• 这个工具的数据谁来录？多久录一次？——答：三个小组的组长，每周五下午各录一次。
• 最想看到什么统计结果？——答：每个小组总的消耗量，按月排名。
• 会不会有两个人同时操作？——答：基本不会，就算同时录，大不了后录的覆盖前录的。

这三个答案直接决定了我后续所有的技术选型：低频使用不需要并发控制；数据量小不需要复杂存储；输出只要一个排名列表，不需要图形可视化。很多项目做完了没人用的原因不是功能不够多，而是没搞清楚用户到底要什么。caveman 风格的“快速交付”靠的不是编码快，而是需求范围控制得准——知道什么不该做，比知道什么该做更重要。

4.2 环境准备与脚手架搭建

正式写代码之前，先把环境弄干净。我用 Python 3.11（用 3.8 以上都行），关键点是：不要让系统全局环境污染依赖。这边我用了虚拟环境，习惯性的操作是：

mkdir chocolate_tool cd chocolate_tool python3 -m venv venv source venv/bin/activate

启动虚拟环境后，pip list基本是空的，但 sqlite3 是 Python 标准库的成员，所以不需要额外安装。项目唯一需要写的“依赖文件”其实是给未来的自己看的说明，记录运行版本和入口命令。

设置 Python 环境时一个常见的坑：macOS 系统自带的 Python 是老版本 2.x，直接敲python可能会踩到环境不兼容。正确的做法是先确认版本：

python3 --version

如果是 3.6 以下，建议去官网装新版本。这一步虽然简单，但很多人项目跑不起来就是卡在这里。

4.3 核心功能编码：主菜单循环与数据操作

整个脚本的核心结构就是一个“主菜单循环”，这个模式在命令行工具里非常经典：

def main(): init_db() print("巧克力库存管理工具") print("1. 录入消耗记录") print("2. 查看本周统计") print("3. 查看本月排名") print("4. 导出全部数据") print("0. 退出") choice = input("请选择：") if choice == "1": add_interactive() elif choice == "2": query_weekly() elif choice == "3": query_monthly_rank() elif choice == "4": export_data() elif choice == "0": return else: print("无效输入，请重试") main()

我不写while True做循环，而是用递归调用main()。这种写法的好处是选择完之后自动回到菜单，状态管理天然隔离——每次进入菜单都是全新的状态，不会残留上一次操作的临时变量。当然，递归层级深了会有栈溢出的风险，但一个菜单程序最深不过十来层，完全不是问题。

录入交互函数长这样：

def add_interactive(): item = input("物品名称（如：巧克力）：").strip() count_input = input("消耗数量：").strip() group = input("小组名称（如：研发组）：").strip() if not item or not count_input or not group: print("信息不完整，本次取消") return try: count = int(count_input) except ValueError: print("数量必须是整数") return if count <= 0: print("数量必须大于 0") return add_record(item, count, group) print(f"已记录：{group} 消耗 {item} x {count}")

看到.strip()了吗？这个细节非常重要——用户输入时习惯敲个空格或者换行，不清理掉的话，存进数据库的就是“巧克力 ”这种带尾巴的脏数据，后面查询一匹配就出问题。而int(count_input)的 try-except 捕获了用户输错格式的情况，不让脚本直接崩溃。加这些防御性代码的成本很低，但给使用者的体验提升非常大。

核心统计函数，也就是整个工具的灵魂——月度小组排名：

def query_monthly_rank(): month = datetime.now().strftime("%Y-%m") conn = sqlite3.connect(DB_PATH) rows = conn.execute( """ SELECT group_name, SUM(count) AS total FROM records WHERE created_at LIKE ? GROUP BY group_name ORDER BY total DESC """, (month + "%",) ).fetchall() conn.close() if not rows: print(f"{month} 还没有任何记录") return print(f"===== {month} 小组消耗排名 =====") for i, (group, total) in enumerate(rows, start=1): print(f"第{i}名：{group}，总消耗 {total} 件")

这里用LIKE ?加month + "%"实现“取这个月所有记录”的效果——因为created_at存的是 ISO 时间格式，字符串天然按字典序可比较，"2025-06-%"能匹配到 6 月的所有数据。没有用BETWEEN去算月初月末的时间戳，因为那是过度设计，换算成本地时区、处理月末边界，搞不好还容易出 off-by-one 错误。字符串匹配对当前场景完全够用，而且写法上更直观——读代码的人一眼就知道这是在筛日期前缀。

4.4 数据入库的参数校验规则

这一环我要特意单拎出来说，因为脏数据给后续查询带来的麻烦是灾难级的。我用的是一个笨办法但很有效的方案——“白名单校验法”，只允许明确合法的数据进库：

• 物品名称必须是字符串，且去除首尾空格后长度大于 0。
• 数量必须是整数，且在 1 到 9999 之间，超出这个范围直接拒绝。
• 小组名称限定在预设的三个组里面（可以从配置文件读取）。
• 时间字段不允许手动输入，一律由程序自动生成。

为什么这么严格？因为我吃过亏。之前有个脚本没有做校验，同事手滑录了一条“消耗数量 -5”的记录，月底排名时那组总消耗变成了负数，整个排名直接乱掉。排查了半小时才在数据里找到这条脏记录。从那以后，我所有工具都会在校验上多写几行，宁可多打几段代码，也好过事后查数据查得头秃。

4.5 数据导出与交接运维

传统开发里，导出数据做报表一般要联调各种接口，可在 caveman 工具里，导出就是再写一个函数，把数据库里所有记录拼成 CSV 输出：

def export_data(): conn = sqlite3.connect(DB_PATH) rows = conn.execute( "SELECT id, item, count, group_name, created_at FROM records ORDER BY created_at DESC" ).fetchall() conn.close() with open("records_export.csv", "w", encoding="utf-8") as f: f.write("ID,物品,数量,小组,时间\n") for r in rows: f.write(f"{r[0]},{r[1]},{r[2]},{r[3]},{r[4]}\n") print(f"已导出 {len(rows)} 条记录到 records_export.csv")

encoding="utf-8"这一行一定要写上——不写的话在 Windows 上默认用 GBK 编码，生成的 CSV 用 Excel 打开中文直接乱码。运维层面，整个系统的“部署”就是把这个文件夹打个压缩包，发到需要的人手里，解压后运行python chocolate.py。没有服务器要配置，没有防火墙要开端口，没有环境变量要设置。

交接文档怎么写？我 README.md 里只放了四段内容：项目是干什么的一句话说清楚、环境要求（Python 3.8+）、运行命令、常见问题（如何改小组名单、如何备份数据库）。不要写一大堆架构说明，维护者只需要“能跑、能改、能备份”就够了。

5. 常见问题与排查技巧实录：Caveman 项目也会踩坑

5.1 四大高频问题速查表

5.2 一个让我印象深刻的排查经历：时间字段类型选错

最早设计表结构时，我把created_at字段设成了 INTEGER，存 Unix 时间戳。当时的想法是“时间戳存储效率高、排序方便”。结果到月底统计月度排名时，要按“月份”分组，我得先写一个 SQL 函数把时间戳转成"YYYY-MM"字符串，语法在 SQLite 里又长又绕，调试花了一个多小时。

后来我直接把字段类型改回 TEXT，存 ISO 格式字符串。收益立竿见影：LIKE "2025-06%"一行解决月份筛选，人眼也能读懂，不需要任何转换函数。用“人类可读格式”承载业务字段，而不是用“机器最优格式”，这个决策失误后的复盘改变了我后来所有工具的设计习惯——除非有明确的性能瓶颈，否则优先选可读性强的方案。

5.3 用户反馈驱动的功能迭代

功能交付后，我让三位组长试用了一周，收集到的最有价值的反馈是：“每次都要输入小组名，太啰嗦了，能不能记住我是谁？”于是加了一个轻量配置功能，在项目根目录放一个config.ini：

[user] default_group = 研发组

录入时如果检测到默认小组配置，就不需要再手动输入小组名。这是一个极小成本的改动，但显著提升了使用体验。caveman 风格的项目要特别重视这种“小步快跑式迭代”——因为整体复杂度低，改起来快，你完全可以根据用户反馈随时调整，而不是像大项目那样把需求攒到下一版本再发。

5.4 数据备份与误删恢复的土办法

小工具最容易忽略的是容灾。我的做法很简单：在main()菜单里加一个“备份数据库”选项，实现方式是把inventory.db复制一份带时间戳的新文件：

cp data/inventory.db data/backup_20250601.db

另外在每天第一次启动时自动做一次静默备份。这个方案比任何专业的备份系统都更贴合内部小工具的场景——成本几乎为零，但关键时刻能救命。有人误删数据记录时，直接把备份文件覆盖回去就恢复到当天早上的状态。

个人体会：这类小项目最容易翻车的不是技术，而是写代码的人忘了用户是真实的人，不是单纯的数据输入器。多给用户留提示、多做校验、多考虑误操作场景，工具才能真正活下去。

6. 这波 Caveman 开发，我的真实体会与建议

做这个项目最大的感受是：“原始”不等于“粗糙”，“简单”不等于“草率”。caveman 风格的核心是精准识别哪些环节可以减配，哪些环节必须加固。像参数校验、编码格式、备份恢复这些，都是一行不能省的“安全底线”；而分支管理、微服务、容器化这些，则是小场景下完全可以砍掉的“面子工程”。

如果你也想试试这个套路，我的建议是：

从“给自己用的工具”开始练手，比如个人记账脚本、定时文件整理脚本、收藏夹去重器。这类项目不需要对别人负责，你可以大胆尝试“只留主干、长出来再说”的开发节奏。等熟练了之后，再尝试把它推广到团队内部的低风险场景，积累经验之后，你对“什么时候必须精细化、什么时候可以简化”的判断力会灵敏非常多。

对我来说，caveman 与其说是一种技术风格，不如说是一种提醒：别忘了大项目是从小工具长出来的，而小工具最需要的不是复杂的骨架，而是能解决真问题的内核。下次接到一个看起来不大的需求，与其一上来就架构规划、模块拆分、环境搭建三步走，不妨先问自己一句：如果我是一个原始人，面前只有一块石头和一根木棍，我会怎么做？答案往往就是最短的交付路径，也是最接近业务真需求的方向。