我最早听到caveman这个词不是从化石纪录片里而是自己的一个极简项目上线后同事看了一眼仓库说你就用这么朴素的方式做我说了一句嗯因为它是caveman——一个刻意保持原始的、只用最小工具链的项目代号。这个名字后来被我延伸成了一套做事的思路刻意把复杂度压到不能再低低到像穴居人一样只用最顺手的那几样东西却依然能解决真实问题。如果你也是一个人维护项目、在小团队里写代码、或者长期被现代工程最佳实践压得喘不过气这篇文章会很对你胃口。我会从一个真实工具的开发过程出发拆解caveman式工作法的三个底层原则、完整实现路径、在几个场景里的实战结果以及哪些情况你必须果断放弃它。全程不空谈理念只有可以直接复用的判断标准和操作方法。1. 项目背后caveman 到底在抵抗什么1.1 从一次连不上网就干不了活的经历说起我做过一个内部小工具功能不复杂把散乱的文件按命名规则批量分类。最初版本是现写的Python单文件大概400行没有任何第三方依赖。运行方式也简单python tidy.py --source ./downloads完事。后来我本着规范化的想法引入了配置管理、日志系统、参数校验库还接了一套构建脚本。结果有次出差在高铁上想临时改一下分类规则发现项目跑不起来了——因为那套工程化依赖需要从内部镜像拉包凭证过期了。我盯着终端里的报错突然意识到这个工具真正需要的就是单文件、Python标准库、一行命令。我花了整整一个下午把它的所有额外依赖全部删掉回到caveman状态。那次之后我明白一件事大多数工程复杂度不是一开始就需要的而是觉得迟早会需要才引入的。Caveman式思路抵抗的正是这种基于假设的复杂度。它要求你诚实回答如果没有这些工具我的核心流程到底会卡在哪里大多数时候答案是不会卡。1.2 所谓现代工程能力里有多少是真实需求你我心里都清楚今天的项目仓库里塞着多少防御性配置。我见过一个实际逻辑只有五百行的项目却配了ESLint、Prettier、Husky、Commitlint、Playwright、Docker、多环境变量文件、GitHub Actions。你说这些没用吗有但那是给十人团队、持续三年迭代、多人交接的场景准备的。如果项目是自己维护的小工具这些配置的实际效果只是把每次改动从五分钟拖成二十五分钟。Caveman式思路不是反技术、反工具。它只是把工具按需要而不是流行来做选择。一个判断标准我用了很久如果你去掉了某个环节项目的核心价值依然成立那它就不是必需品而是多余的护卫。真正的工程能力不是堆砌了多少现代工具是你知道在什么粒度上停下来。2. Caveman 的底层三原则依赖最小化、抽象随用随取、流程一眼看穿2.1 依赖是负债不是资产几乎每位工程师都经历过更新依赖后老代码跑不通的至暗时刻。第三方库在你引入那一刻就同时注入了三笔长期负债安全通告要跟进、API变化要适配、行为差异要排查。我给自己定了三条硬性规则每一次想引进新库之前都必须过一遍它省下的时间是否远大于它未来五年可能吃掉的时间它解决的是核心问题还是边角料如果明天卸载它我的改动量有多大举个例子。在Python里处理JSON很多人习惯引入pandas或requests这类重武器。但其实标准库json加上pathlib已经能覆盖八成需求。你要做的只是把JSON文件读进来、改几个字段、再写出去标准库干净利落还不用考虑pandas版本和Python版本的匹配问题。Caveman式依赖原则绝不是零依赖而是每一个依赖都要有明确的服役期。如果某个库只负责一个很小的功能你完全可以自己写那二十行代码把控制权留在自己手里。2.2 抽象延迟到第三次重复不要重复自己DRY是很多人从入行就听到的金科玉律但也正是它成就了大量过度设计。我见过有人为了两个地方共用一段差不多的逻辑提前造了一个配置驱动的抽象层结果三个月后需求一变那段抽象层成了唯一没人敢改的东西。Caveman式抽象原则很朴素第一次出现直接写第二次出现可以复制再小改直到第三次重复才抽取公共函数或组件。举个具体场景。我在做文件分类工具时最开始需要提取日期项目名这种命名模式分别在处理图片、文档、压缩包三个分支里用到。前两次我直接写了相近的逻辑等到第三个分支出现时我才抽出extract_meta(filename)这个函数。这时它的入参、返回结构和调用方式都已经经过真实场景验证抽象得恰到好处。如果一开始就抽我大概率会猜错参数设计。记住抽象必须要由真实重复驱动而不是由对重复的恐惧驱动。2.3 构建与运行流程要像点火一样简单Caveman项目有个直观特征跑起来的方式简单到不用看文档。通常就是一条命令或者直接执行一个脚本文件。我倾向于把事情拆成一个运行时最小集语言运行时、标准库、一个文本编辑器、一个终端。就这四样。不需要包管理器不可以用但要在项目真正开始依赖别人之前始终问一句我真的需要它吗。下面这个对比表是我在一次分享里列过的基本概括了我对两种方式的理解维度现代工程化方案Caveman方案运行环境Docker容器、云服务、多阶段构建本机语言运行时依赖数量数十个到数百个0到5个启动命令多步流水线、配置环境变量一条命令故障排查范围需要查依赖链、构建缓存、网络配置直接看代码和数据扩展方式加模块、加队列、加服务先加函数不行再加文件这不是说现代方案错了。它的复杂度大部分是响应规模化需求的必要成本。但caveman式的意义在于如果你不需要规模化就不要提前付这笔成本。一个运行流程如果要经过五步配置才能跑通那么出问题时你很难判断是代码问题还是环境问题。3. 用 Caveman 思维从零做出一个可用工具3.1 从需求的一句话描述开始Caveman式开发不是想到哪写到哪它有非常严格的收敛过程。第一步把所有模糊想法压成一句话。我当时的需求是这样写的输入是一个目录处理是将其中所有文件名按日期和类型重命名归类输出是整理后的目录结构失败时打印出未处理的文件名和原因。一句话里必须说清四件事输入是什么、处理做什么、输出是什么、失败怎么办。很多时候项目做歪是因为只定义了前两项根本没定义后两项。一旦你写出这句话你的项目边界就定了后面的所有代码都是在兑现这句话。然后把它扩展成可以验收的几条标准能处理至少两类文件图片类和文档类。重命名规则统一YYYY-MM-DD_projectname_type。无匹配规则的文件原样保留并在结束时列出来。整个操作可以一键撤销备份日志。有了这些我就可以把做得多豪华的冲动收起来了。3.2 物理边界单文件、单命令、单输出Caveman式工具最典型的形态是单文件。为什么强调物理边界因为单文件意味着你打开它就能看懂全部逻辑不需要在十几个模块之间跳转。Git跟踪、代码评审都很轻松diff一目了然。拷到任何一台有Python环境的机器上就能跑没有安装依赖一说。重构成本极低重写一版也就是半小时的事。我当时的结构是这样组织的tidy.py - main() - parse_args() - scan_files(source_dir) - extract_meta(filename) - resolve_conflict(target_name) - move_and_rename(file) - backup_log()每个函数负责一件具体的小事函数之间只用返回值传递数据不用类、不用全局状态。这样就算没有任何框架逻辑依然清晰。3.3 实现路径从第一行能跑的代码到可用我一直强调开发时不要试图一次写完美。用caveman式方法尤其要遵守这个节奏第一步先把主线跑通。忽略所有异常处理只做扫描目录、提取信息、重命名、移动文件这条最开心的路径。这一步能跑你心里就有底了。第二步加入失败路径。考虑文件不存在、目标重名、文件被占用、没有匹配规则。resolve_conflict()就是在这一步引入的如果发现目标文件已存在自动在文件名后追加_1、_2。第三步加入帮助说明。--help可读、参数名直观这是给未来的自己看的不是给用户看的。第四步用三个测试目录实测。一个乱序目录、一个含重名文件的目录、一个空目录每个都跑一遍记录输出和日志。整个过程中我没有引入任何一个第三方库。处理路径用pathlib移动文件用shutil解析参数用argparse全部是Python标准库。最后统计下来核心代码也就三百多行。3.4 验收标准与删代码清单验收阶段我只做两件事。第一对照之前写的验收标准逐条检查第二认真地删代码。删代码这件事很多人不会当回事。但在cavema式开发里删和写同等重要。我整理了一份删代码清单每次交付前都会过一遍有没有为未来可能用到写的配置项删掉。有没有为万一用户想这样定义但现在还没人用的参数删掉。有没有对称地实现了一个正向功能的反向功能比如有了归档就顺手写了取消归档但需求里根本没有后者删掉。有没有为了某个设计模式硬拗出来的接口层删掉。我在那次重构里删掉了大约一百五十行防御性代码。删完再跑一遍验收标准全部通过。那种感觉就是代码变得诚实了每一行都有存在的理由。4. 实战验证Caveman 方式在三个场景下的表现4.1 命令行批处理最大的坑是顺手引入的可靠性负担命令行批处理是caveman式思路最舒服的领域但它也藏着一个坑你以为引入一个库会让程序更可靠结果它反而带来了可靠性负担。我有一次处理日志数据要提取时间戳和错误码。本来用标准库re写个正则二十分钟搞定。但我当时顺手引入了一个名为dateutil的库来解析时间理由是规范。结果它和系统里的另一个包的版本冲突解析明明正确的格式却抛异常。那一刻出了问题都不在业务逻辑全在依赖关系上。那天之后我给自己立了一个规矩批处理脚本里能用标准库就绝不用外部库。脚本的生命周期通常很短短到不值得为它维护一份依赖清单。如果脚本真活过了一年到时再按需引入也不迟。4.2 极简前端页面不用构建工具时的边界有人可能觉得caveman式只适合后端脚本前端离了框架根本没法活。我实际做过一个内部报告页用的是纯HTML加CSS加原生JavaScript一个单文件没有构建工具没有框架甚至没有专门的服务端渲染。效果出乎意料地好。它的典型优点拷贝到任意一台电脑上用浏览器打开就能看不需要Node环境、不需要npm install、不需要处理跨域代理。对于一个每周自动生成一次、给三五个人看的数据报告这套方案的学习成本和维护成本都接近于零。但我也要诚实说说它的边界。当页面开始需要复杂状态管理、重复交互组件、多视图路由时原生方案的代码量会急剧膨胀可维护性开始崩坏。这时候引入一个轻量框架是合理决策。关键在于是按需引入而不是默认引入。Caveman式前端不是永远不用框架而是在不用框架也能解决问题的时候敢于不用。4.3 个人知识库文件优先而非数据库第三个场景可能出乎意料是个人知识库。我用了好几年纯Markdown文件的方式管理笔记、文章草稿和项目文档目录结构靠手动维护检索靠文本搜索工具。有人会问怎么不用双链笔记、怎么不用数据库因为caveman式存储有一个无可替代的优势数据不锁死。所有内容都是可读的、可批处理的、可迁移的纯文本文件。换任何工具都能带走任何编辑器都能打开。即使我对某篇笔记的内容已毫无印象只要记得一个词就能在文件里搜到那次记录的全部上下文。它的缺点也明显当你需要所有2023年包含某标签但未完成的文章这种结构化查询时纯文件方式就力不从心了。我的经验是当查询复杂度超过五种固定模式时才值得引入数据库。在此之前文件系统加上一套好用的命名规范比任何花哨系统都更caveman、也更可靠。5. 什么时候必须放弃 Caveman 思维5.1 团队协作与多人维护约定价值超过极简价值Caveman式思路有一个致命弱点它高度依赖一个人能完整理解整个系统。当团队人数超过四个人左右问题就来了。别人不会像你一样清楚为什么这个函数放在这里为什么没有类型标注为什么异常处理这么潦草。你们必须靠显式的契约来协作包括接口定义、类型系统、文档、甚至标准化的提交信息。这不是说团队不能极简而是极简的对象要从代码结构转换成依赖数量和流程步骤。团队项目里我依然坚持依赖最小化但我会牺牲一部分代码形态上的自由。类型要写、接口要定、模块划分要明确这些约定是团队协作的润滑剂属于必要的复杂度。5.2 高频变化与并发要求的场景Caveman式方案适合长期稳定、低频变更、单线程直白的逻辑。一旦场景变成高并发任务、分布式状态、数据一致性要求它的简单性就反噬了。举个例子你用一个单文件脚本处理任务机器上跑着100个并发实例都往同一个目录写文件文件名冲突、并发写损坏、部分失败重试这些问题会一拥而上。此时caveman式直接操作文件的直觉方案远不如一个成熟的队列系统可靠。不是你的逻辑不行而是你正在用单线程的思路管理一个多线程的世界。在这种场景里果断放弃部分极简引入成熟的基础设施才是正确决策。5.3 我的三步决策框架每个项目开始之前我会用三个问题决定要不要采用caveman式思路。这三个问题后来几乎刻进了我的肌肉记忆第一问失败代价有多大如果工具出问题只是损失几分钟重跑一次放心用caveman。如果出问题会导致数据丢失、金钱损失、客户投诉立刻走向工程化。第二问维护者有多少、时间跨度多长只有我一人维护、项目预计生命周期在一年内caveman是最高效的选择。三到五人协作、计划维护三年以上需要更多规范和结构。第三问变更频率如何核心逻辑稳定、需求基本定型caveman省心可靠。如果需求还在快速探索期、每周都在改你可能需要更强的测试保障和更强的模块化意味着更多工程化。这个决策框架帮我处理过很多纠结有些项目我坚持用单文件脚本有些项目一上来就规规矩矩搭结构。关键不是哪一种更高级而是哪一种和实际情况更匹配。6. 三个 Caveman 式习惯我用到现在依然受用6.1 先给文件命名再写代码我会在写任何代码前先想清楚这个工具应该叫什么文件名比如这次是tidy.py下次可能是merge_pdf.py、dedupe_csv.py。文件名一旦定了项目的使命就定了。这个习惯看起来简单却能有效阻止项目失控扩展——一个叫tidy.py的文件你不太好意思在里面加顺便实现一个网页爬虫。6.2 把version 1写进文件头有人觉得用Git就不需要写版本注释了。但caveman式工具往往是散落在各个目录里的独立脚本并不都纳入版本管理。我在每个脚本文件头部留三行注释用途、最初创建日期、最后修改日期。这几行字在半年后重新捡起旧脚本时能省掉大量猜测时间。6.3 定期断舍离每月清一次项目我每个月会花半小时列出自己的所有项目问一个问题如果这个项目今天消失了我会不会在三个月内因为没了它而难受答案是不会就把它归档或者删除。这不是浪费这是给未来的自己减负。项目不是越多越好能维护的项目才是资产。caveman式思维最终指向的是对拥有这件事的克制。我自己在反复实践caveman式思路之后最大的收获不是代码变短了、依赖变少了而是对系统有了完整的掌控感。我清楚地知道每一条命令会触发什么、每一个文件在哪、每一个改动影响什么。真要说什么是caveman精神大概就是用最少的中间环节保住亲手做出东西的能力。 
长河君 · 2026/10/29 23:37:57 · 阅读 1.2k caveman式开发：用最小工具链解决真实问题的极简哲学
我最早听到caveman这个词不是从化石纪录片里而是自己的一个极简项目上线后同事看了一眼仓库说你就用这么朴素的方式做我说了一句嗯因为它是caveman——一个刻意保持原始的、只用最小工具链的项目代号。这个名字后来被我延伸成了一套做事的思路刻意把复杂度压到不能再低低到像穴居人一样只用最顺手的那几样东西却依然能解决真实问题。如果你也是一个人维护项目、在小团队里写代码、或者长期被现代工程最佳实践压得喘不过气这篇文章会很对你胃口。我会从一个真实工具的开发过程出发拆解caveman式工作法的三个底层原则、完整实现路径、在几个场景里的实战结果以及哪些情况你必须果断放弃它。全程不空谈理念只有可以直接复用的判断标准和操作方法。1. 项目背后caveman 到底在抵抗什么1.1 从一次连不上网就干不了活的经历说起我做过一个内部小工具功能不复杂把散乱的文件按命名规则批量分类。最初版本是现写的Python单文件大概400行没有任何第三方依赖。运行方式也简单python tidy.py --source ./downloads完事。后来我本着规范化的想法引入了配置管理、日志系统、参数校验库还接了一套构建脚本。结果有次出差在高铁上想临时改一下分类规则发现项目跑不起来了——因为那套工程化依赖需要从内部镜像拉包凭证过期了。我盯着终端里的报错突然意识到这个工具真正需要的就是单文件、Python标准库、一行命令。我花了整整一个下午把它的所有额外依赖全部删掉回到caveman状态。那次之后我明白一件事大多数工程复杂度不是一开始就需要的而是觉得迟早会需要才引入的。Caveman式思路抵抗的正是这种基于假设的复杂度。它要求你诚实回答如果没有这些工具我的核心流程到底会卡在哪里大多数时候答案是不会卡。1.2 所谓现代工程能力里有多少是真实需求你我心里都清楚今天的项目仓库里塞着多少防御性配置。我见过一个实际逻辑只有五百行的项目却配了ESLint、Prettier、Husky、Commitlint、Playwright、Docker、多环境变量文件、GitHub Actions。你说这些没用吗有但那是给十人团队、持续三年迭代、多人交接的场景准备的。如果项目是自己维护的小工具这些配置的实际效果只是把每次改动从五分钟拖成二十五分钟。Caveman式思路不是反技术、反工具。它只是把工具按需要而不是流行来做选择。一个判断标准我用了很久如果你去掉了某个环节项目的核心价值依然成立那它就不是必需品而是多余的护卫。真正的工程能力不是堆砌了多少现代工具是你知道在什么粒度上停下来。2. Caveman 的底层三原则依赖最小化、抽象随用随取、流程一眼看穿2.1 依赖是负债不是资产几乎每位工程师都经历过更新依赖后老代码跑不通的至暗时刻。第三方库在你引入那一刻就同时注入了三笔长期负债安全通告要跟进、API变化要适配、行为差异要排查。我给自己定了三条硬性规则每一次想引进新库之前都必须过一遍它省下的时间是否远大于它未来五年可能吃掉的时间它解决的是核心问题还是边角料如果明天卸载它我的改动量有多大举个例子。在Python里处理JSON很多人习惯引入pandas或requests这类重武器。但其实标准库json加上pathlib已经能覆盖八成需求。你要做的只是把JSON文件读进来、改几个字段、再写出去标准库干净利落还不用考虑pandas版本和Python版本的匹配问题。Caveman式依赖原则绝不是零依赖而是每一个依赖都要有明确的服役期。如果某个库只负责一个很小的功能你完全可以自己写那二十行代码把控制权留在自己手里。2.2 抽象延迟到第三次重复不要重复自己DRY是很多人从入行就听到的金科玉律但也正是它成就了大量过度设计。我见过有人为了两个地方共用一段差不多的逻辑提前造了一个配置驱动的抽象层结果三个月后需求一变那段抽象层成了唯一没人敢改的东西。Caveman式抽象原则很朴素第一次出现直接写第二次出现可以复制再小改直到第三次重复才抽取公共函数或组件。举个具体场景。我在做文件分类工具时最开始需要提取日期项目名这种命名模式分别在处理图片、文档、压缩包三个分支里用到。前两次我直接写了相近的逻辑等到第三个分支出现时我才抽出extract_meta(filename)这个函数。这时它的入参、返回结构和调用方式都已经经过真实场景验证抽象得恰到好处。如果一开始就抽我大概率会猜错参数设计。记住抽象必须要由真实重复驱动而不是由对重复的恐惧驱动。2.3 构建与运行流程要像点火一样简单Caveman项目有个直观特征跑起来的方式简单到不用看文档。通常就是一条命令或者直接执行一个脚本文件。我倾向于把事情拆成一个运行时最小集语言运行时、标准库、一个文本编辑器、一个终端。就这四样。不需要包管理器不可以用但要在项目真正开始依赖别人之前始终问一句我真的需要它吗。下面这个对比表是我在一次分享里列过的基本概括了我对两种方式的理解维度现代工程化方案Caveman方案运行环境Docker容器、云服务、多阶段构建本机语言运行时依赖数量数十个到数百个0到5个启动命令多步流水线、配置环境变量一条命令故障排查范围需要查依赖链、构建缓存、网络配置直接看代码和数据扩展方式加模块、加队列、加服务先加函数不行再加文件这不是说现代方案错了。它的复杂度大部分是响应规模化需求的必要成本。但caveman式的意义在于如果你不需要规模化就不要提前付这笔成本。一个运行流程如果要经过五步配置才能跑通那么出问题时你很难判断是代码问题还是环境问题。3. 用 Caveman 思维从零做出一个可用工具3.1 从需求的一句话描述开始Caveman式开发不是想到哪写到哪它有非常严格的收敛过程。第一步把所有模糊想法压成一句话。我当时的需求是这样写的输入是一个目录处理是将其中所有文件名按日期和类型重命名归类输出是整理后的目录结构失败时打印出未处理的文件名和原因。一句话里必须说清四件事输入是什么、处理做什么、输出是什么、失败怎么办。很多时候项目做歪是因为只定义了前两项根本没定义后两项。一旦你写出这句话你的项目边界就定了后面的所有代码都是在兑现这句话。然后把它扩展成可以验收的几条标准能处理至少两类文件图片类和文档类。重命名规则统一YYYY-MM-DD_projectname_type。无匹配规则的文件原样保留并在结束时列出来。整个操作可以一键撤销备份日志。有了这些我就可以把做得多豪华的冲动收起来了。3.2 物理边界单文件、单命令、单输出Caveman式工具最典型的形态是单文件。为什么强调物理边界因为单文件意味着你打开它就能看懂全部逻辑不需要在十几个模块之间跳转。Git跟踪、代码评审都很轻松diff一目了然。拷到任何一台有Python环境的机器上就能跑没有安装依赖一说。重构成本极低重写一版也就是半小时的事。我当时的结构是这样组织的tidy.py - main() - parse_args() - scan_files(source_dir) - extract_meta(filename) - resolve_conflict(target_name) - move_and_rename(file) - backup_log()每个函数负责一件具体的小事函数之间只用返回值传递数据不用类、不用全局状态。这样就算没有任何框架逻辑依然清晰。3.3 实现路径从第一行能跑的代码到可用我一直强调开发时不要试图一次写完美。用caveman式方法尤其要遵守这个节奏第一步先把主线跑通。忽略所有异常处理只做扫描目录、提取信息、重命名、移动文件这条最开心的路径。这一步能跑你心里就有底了。第二步加入失败路径。考虑文件不存在、目标重名、文件被占用、没有匹配规则。resolve_conflict()就是在这一步引入的如果发现目标文件已存在自动在文件名后追加_1、_2。第三步加入帮助说明。--help可读、参数名直观这是给未来的自己看的不是给用户看的。第四步用三个测试目录实测。一个乱序目录、一个含重名文件的目录、一个空目录每个都跑一遍记录输出和日志。整个过程中我没有引入任何一个第三方库。处理路径用pathlib移动文件用shutil解析参数用argparse全部是Python标准库。最后统计下来核心代码也就三百多行。3.4 验收标准与删代码清单验收阶段我只做两件事。第一对照之前写的验收标准逐条检查第二认真地删代码。删代码这件事很多人不会当回事。但在cavema式开发里删和写同等重要。我整理了一份删代码清单每次交付前都会过一遍有没有为未来可能用到写的配置项删掉。有没有为万一用户想这样定义但现在还没人用的参数删掉。有没有对称地实现了一个正向功能的反向功能比如有了归档就顺手写了取消归档但需求里根本没有后者删掉。有没有为了某个设计模式硬拗出来的接口层删掉。我在那次重构里删掉了大约一百五十行防御性代码。删完再跑一遍验收标准全部通过。那种感觉就是代码变得诚实了每一行都有存在的理由。4. 实战验证Caveman 方式在三个场景下的表现4.1 命令行批处理最大的坑是顺手引入的可靠性负担命令行批处理是caveman式思路最舒服的领域但它也藏着一个坑你以为引入一个库会让程序更可靠结果它反而带来了可靠性负担。我有一次处理日志数据要提取时间戳和错误码。本来用标准库re写个正则二十分钟搞定。但我当时顺手引入了一个名为dateutil的库来解析时间理由是规范。结果它和系统里的另一个包的版本冲突解析明明正确的格式却抛异常。那一刻出了问题都不在业务逻辑全在依赖关系上。那天之后我给自己立了一个规矩批处理脚本里能用标准库就绝不用外部库。脚本的生命周期通常很短短到不值得为它维护一份依赖清单。如果脚本真活过了一年到时再按需引入也不迟。4.2 极简前端页面不用构建工具时的边界有人可能觉得caveman式只适合后端脚本前端离了框架根本没法活。我实际做过一个内部报告页用的是纯HTML加CSS加原生JavaScript一个单文件没有构建工具没有框架甚至没有专门的服务端渲染。效果出乎意料地好。它的典型优点拷贝到任意一台电脑上用浏览器打开就能看不需要Node环境、不需要npm install、不需要处理跨域代理。对于一个每周自动生成一次、给三五个人看的数据报告这套方案的学习成本和维护成本都接近于零。但我也要诚实说说它的边界。当页面开始需要复杂状态管理、重复交互组件、多视图路由时原生方案的代码量会急剧膨胀可维护性开始崩坏。这时候引入一个轻量框架是合理决策。关键在于是按需引入而不是默认引入。Caveman式前端不是永远不用框架而是在不用框架也能解决问题的时候敢于不用。4.3 个人知识库文件优先而非数据库第三个场景可能出乎意料是个人知识库。我用了好几年纯Markdown文件的方式管理笔记、文章草稿和项目文档目录结构靠手动维护检索靠文本搜索工具。有人会问怎么不用双链笔记、怎么不用数据库因为caveman式存储有一个无可替代的优势数据不锁死。所有内容都是可读的、可批处理的、可迁移的纯文本文件。换任何工具都能带走任何编辑器都能打开。即使我对某篇笔记的内容已毫无印象只要记得一个词就能在文件里搜到那次记录的全部上下文。它的缺点也明显当你需要所有2023年包含某标签但未完成的文章这种结构化查询时纯文件方式就力不从心了。我的经验是当查询复杂度超过五种固定模式时才值得引入数据库。在此之前文件系统加上一套好用的命名规范比任何花哨系统都更caveman、也更可靠。5. 什么时候必须放弃 Caveman 思维5.1 团队协作与多人维护约定价值超过极简价值Caveman式思路有一个致命弱点它高度依赖一个人能完整理解整个系统。当团队人数超过四个人左右问题就来了。别人不会像你一样清楚为什么这个函数放在这里为什么没有类型标注为什么异常处理这么潦草。你们必须靠显式的契约来协作包括接口定义、类型系统、文档、甚至标准化的提交信息。这不是说团队不能极简而是极简的对象要从代码结构转换成依赖数量和流程步骤。团队项目里我依然坚持依赖最小化但我会牺牲一部分代码形态上的自由。类型要写、接口要定、模块划分要明确这些约定是团队协作的润滑剂属于必要的复杂度。5.2 高频变化与并发要求的场景Caveman式方案适合长期稳定、低频变更、单线程直白的逻辑。一旦场景变成高并发任务、分布式状态、数据一致性要求它的简单性就反噬了。举个例子你用一个单文件脚本处理任务机器上跑着100个并发实例都往同一个目录写文件文件名冲突、并发写损坏、部分失败重试这些问题会一拥而上。此时caveman式直接操作文件的直觉方案远不如一个成熟的队列系统可靠。不是你的逻辑不行而是你正在用单线程的思路管理一个多线程的世界。在这种场景里果断放弃部分极简引入成熟的基础设施才是正确决策。5.3 我的三步决策框架每个项目开始之前我会用三个问题决定要不要采用caveman式思路。这三个问题后来几乎刻进了我的肌肉记忆第一问失败代价有多大如果工具出问题只是损失几分钟重跑一次放心用caveman。如果出问题会导致数据丢失、金钱损失、客户投诉立刻走向工程化。第二问维护者有多少、时间跨度多长只有我一人维护、项目预计生命周期在一年内caveman是最高效的选择。三到五人协作、计划维护三年以上需要更多规范和结构。第三问变更频率如何核心逻辑稳定、需求基本定型caveman省心可靠。如果需求还在快速探索期、每周都在改你可能需要更强的测试保障和更强的模块化意味着更多工程化。这个决策框架帮我处理过很多纠结有些项目我坚持用单文件脚本有些项目一上来就规规矩矩搭结构。关键不是哪一种更高级而是哪一种和实际情况更匹配。6. 三个 Caveman 式习惯我用到现在依然受用6.1 先给文件命名再写代码我会在写任何代码前先想清楚这个工具应该叫什么文件名比如这次是tidy.py下次可能是merge_pdf.py、dedupe_csv.py。文件名一旦定了项目的使命就定了。这个习惯看起来简单却能有效阻止项目失控扩展——一个叫tidy.py的文件你不太好意思在里面加顺便实现一个网页爬虫。6.2 把version 1写进文件头有人觉得用Git就不需要写版本注释了。但caveman式工具往往是散落在各个目录里的独立脚本并不都纳入版本管理。我在每个脚本文件头部留三行注释用途、最初创建日期、最后修改日期。这几行字在半年后重新捡起旧脚本时能省掉大量猜测时间。6.3 定期断舍离每月清一次项目我每个月会花半小时列出自己的所有项目问一个问题如果这个项目今天消失了我会不会在三个月内因为没了它而难受答案是不会就把它归档或者删除。这不是浪费这是给未来的自己减负。项目不是越多越好能维护的项目才是资产。caveman式思维最终指向的是对拥有这件事的克制。我自己在反复实践caveman式思路之后最大的收获不是代码变短了、依赖变少了而是对系统有了完整的掌控感。我清楚地知道每一条命令会触发什么、每一个文件在哪、每一个改动影响什么。真要说什么是caveman精神大概就是用最少的中间环节保住亲手做出东西的能力。