最近“caveman”这个词在中文互联网上突然成了热词——短视频里有人扮演原始人吐槽现代生活，社交平台上有人用两个字回应一切复杂问题。大家说“caveman”，大多是在调侃自己跟不上节奏、不想再应付那些弯弯绕绕的东西。但我在实际工作中发现，这个被当成段子用的词，其实藏着一套很值得认真对待的方法论。
我电脑里至今存着一个叫caveman.txt的文件，里面只有三行字：“先跑起来再优化”“打印日志永远比断点靠谱”“能用文本就别上数据库”。这个文件跟我换了三家公司，每次项目失控、系统出问题、团队陷入扯皮，我都把它翻出来对照一遍。今天这篇内容，就是想把这套“原始思维”掰开揉碎讲一遍：它是什么、在技术工作里怎么用、边界在哪里，以及我踩过的那些坑。
1. “caveman”成为热词之后，真正值得留下的是一种反复杂化的本能
1.1 热词只是表象，深处的情绪是“工具疲劳”
先说说这波热词是怎么来的。不管是哪个平台，只要有人用原始人形象配上“根本不需要那么复杂”的态度，评论区就一片叫好。为什么共鸣这么强？因为过去这些年，所有人都在被复杂度追着跑：手机上几百个应用、工作上几十个流程、工具链越装越厚、消息永远回不完。
我自己感受最深的是技术领域。过去十年，一个简单到只是“把A表的数据同步到B表”的需求，很多团队能给你整出消息队列、分布式任务调度、监控告警、重试机制、幂等设计、数据对账，全套拉满，光环境搭建就要一周。问题的复杂度本身是3，附加的复杂度硬生生被拉到30。这不是技术问题，是心理问题——大家都被“专业感”绑架了，你向领导汇报的时候敢说“我就用一个脚本跑”吗？大多数人不敢，怕被认为不上进、不正规。
caveman思维的核心，不是反对工具本身，而是强制自己先回答一个问题：这个东西最原始的形式是什么？把这个原始形式跑通了，再判断有没有必要加装任何东西。大多数时候你会发现，加装的东西里有一大半是伪需求。
1.2 退化可能是最被低估的抗风险能力
我有每年复盘故障记录的习惯，并把每个事故按根因分类。统计结果让我自己都意外：不是服务器宕机，不是网络波动，而是大约七成的事故，根因出在人为叠加出来的设施和环节上——配置错位、版本不匹配、依赖冲突、缓存不一致、权限纠缠。换句话说，我们辛辛苦苦搭起来的复杂度，本身就是最大的风险源。
原始方法为什么抗风险？因为链路短。链路越短，可断裂的节点越少。这个道理放到野外生存里特别好理解：你从城市搬一整套烹饪设备进山露营，和带一把刀、一只打火石纯靠手艺吃饭，哪个更可能吃得上热乎的？显然是后者。现代人太依赖环境提供的基础设施了，一旦基础设施出问题，很多人连最基本的替代方案都拿不出来。我见过最夸张的例子：某个服务依赖的配置中心一挂，整个团队直接瘫在那里，没人知道那些配置到底值什么、写在哪里、能不能手动改。这不是能力问题，是系统性退化。
2. 故障排查实录：为什么我的第一反应永远是“土办法”
2.1 一次断点调试打了败仗的线上故障
讲一个真实经历。去年有个线上接口偶发超时，服务端是Node.js。我的第一反应当然是上调试器，想看看那个接口内部到底发生了什么。于是开了远程调试端口，本地连上去打断点、单步跟进、翻遍中间件和拦截器。结果呢？本地单步走，代码逻辑从头到尾全部正常，数据库返回也正常。我又熬了两个多小时，把能想到的边界条件全试了一遍，一无所获。
最后同事路过扔了一句：“你直接加一行日志不就行了？”我加日志、压测、复现，前后三分钟就看到了真相——某次调用里，第三方SDK内部维护的连接池在特定并发量下会走一个退避逻辑，导致整个请求被卡住超过三秒。日志清晰地打出了“请求开始→SDK调用→（三秒空白）→返回”的时序。断点为什么看不出来？因为本地单步调试时，时序、网络延迟、并发状态全被拉伸变了形，让你人为地改变了现场，问题当然无法重现。
2.2 日志跟踪术的三个基本原则
开发圈有句老话：“不会用调试器等于不会写代码。”但我要说一个反直觉的结论：在线上环境、在并发场景、在有第三方依赖介入的场景，日志派比断点派靠谱得多。
原因并不玄乎：断点调试是干预式观察，日志是旁路式观察。断点会暂停进程、修改时序、改变变量生命周期，它本身就在改变你正在观察的对象，这和“观测改变系统”几乎是同一个道理。而日志记录的是系统真实运行时的轨迹，不干预、不暂停、不改时序——你看到的是现场留下的脚印，不是自己走进去之后的脚印。
当然，日志不是乱打的。我给自己定了三个原则：
- 在怀疑链路的每个节点打一条“进来/出去”的日志，并且带上唯一请求ID，保证能把一次完整调用串起来；
- 关键分支打关键变量，返回值、赋值结果都打，不要怕“日志太多”，日志是可以分级过滤的；
- 错误日志必须带上下文——只打一个
error.message等于没打，要把关键参数、调用来源、当时的输入数据一并打出来。
这套打法看起来土，但它救过我太多次。尤其是面对偶发故障，日志能告诉你的不是“哪一行出错了”，而是“系统的真实节奏是什么”，这一点调试器给不了。
2.3 最小复现：把故障压缩到只剩指纹
如果问题反复出现但原因不明，我的第三个武器叫“最小复现”。说通俗点：想办法在一个尽量简单的环境里，用尽量少的条件让bug稳定出现。然后持续削减变量，直到再也减不了为止。留下来的那组变量，几乎就是根因的指纹。
这个方法本质上是二分法，但它最可贵的地方在于“土”——不需要高级调试环境，一台机器、一个脚本、一组手工输入就够。我处理过最离谱的一个bug是前端滚动条偶发跳动，最终把复现条件一路削减到“窗口宽度恰好是880px”时，才发现问题出在一个CSS媒体查询断点上，两个样式规则在那里打架。你要是开着性能分析工具去抓内存快照、去做长任务分析，反而绕远了。
所以我现在排查问题的顺序非常固定：先加日志看时序，再缩小复现范围，最后才考虑上重型工具。大部分问题走到第二步就定位了，第三步往往用不上。
3. 技术选型判断法：能扔石头解决的问题，别急着造投石车
3.1 三条caveman标准过滤所有方案
这些年无论是自己做项目还是帮人做技术咨询，我习惯用三条“原始标准”过滤所有方案，非常好用。
第一条：把这个组件拔掉，系统还能正常运行吗？如果不能，它是不是真的在承担核心职责？如果是，值得保留；如果不是，它就是伪需求。举个例子，很多小团队一上来就铺Redis缓存，理由是“性能考虑”。但你问一句“把Redis拔了系统会不会崩”，答案往往是不会崩，只是慢一点。那你就该压个测，看看慢一点到底有多慢。如果QPS低到根本不需要缓存，那就是典型的造投石车。
第二条：一个实习生，或者三个月后的你，能在一小时内听懂这个方案吗？如果讲方案需要画三张图，这个方案的复杂度大概率已经超过了问题本身。caveman式架构应该三句话就讲完：前端连后端，后端连数据库，中间最多加一个队列处理异步任务。讲不清楚的架构，不是它高明，而是它冗余。
第三条：出问题时，能否在10分钟内定位到具体环节？原始思维架构天然满足这一点，因为环节少，你不需要链路追踪平台也能数得清数据经过哪里。这招在排障时尤其值钱。
3.2 文本文件当数据库的那一年
我参与过一个线下活动报名系统，峰值一天几千人报名，后端就是一台普通云服务器，数据存储用的是文本文件。你没看错，就是文本文件，每行一条记录，用Python写了个几十行的脚本处理写入和查询。后来有人接盘，第一句话就问“数据库在哪”，我说没有数据库，对方一脸震惊。
但我们回头算笔账：这个系统跑了一年多，零故障，备份方式就是每天凌晨把那个文件复制到另一个目录。同期公司另一个用MySQL加ORM加管理后台搭的相似系统，光“字段变更导致ORM映射报错”就折腾了好几周。我并不是主张永远别用数据库，而是想说：当数据量、并发量、一致性要求都还在“文本文件扛得住”的区间时，文本文件就是又原始又可靠的方案。等确实扛不住了，比如并发上千、需要事务和复杂查询了，再上数据库，迁移成本远比你想象的低——因为跑了一年的业务逻辑很简单，结构一目了然，导一次数据就行。
3.3 单体优先：别让团队规模替架构背锅
“先上微服务架构”这件事我已经劝退过很多人。微服务本质上解决的是组织沟通成本问题，不是纯技术问题。如果你的团队只有五个人，拆微服务的唯一结果就是每个人都得同时维护五套部署、五套日志、五套配置。这是投石车打蚊子。
单体应用在五个人甚至二十个人的阶段，依然是效率最优解。别拿“未来扩展性”骗自己——现在的业务都没跑通，谈未来没有意义。caveman思维在这里态度特别明确：先让整个系统在一台机器上跑通，再考虑横着拆还是竖着拆，而且每一次拆分都必须带着可量化的收益证明。没有收益证明的拆分，都是架构师的自嗨。
4. 协作流程重构：砍掉中间层之后，团队反而更快了
4.1 极简协作三件套
我观察过一个现象：团队越大，越多人在花时间“制造协作的痕迹”——写周报、填工单、更新看板、对齐进度、开同步会。这些动作本身不是坏事，但它们会悄悄从“帮助协作”变成“假装在协作”。
caveman式的做法是极限压缩协作成本。我后来只保留三样东西：一个共享的待办清单（早期就是一张Excel表，后来换成了在线表格），一个大家都能看的聊天群，每周一次最多30分钟的站会。就这三样。凡是没法归进这三样的协作流程，先停掉一个月，看看系统会不会崩。多数时候不仅不会崩，大家反而把省下来的时间用到了正事上。
这里有个真实对比。同一个外包项目，甲方要求每个需求都走“需求文档→评审会→排期→开发→验收文档→复盘会”的完整流程，一个需求从提出来到开工，短则两周。而我们内部做工具，需求直接在群里说清楚，三天上线，用一周验证效果，结果还真差不太多。我承认文档在信息复杂、人员流动大的时候必不可少，但在人数少、信任足、信息清晰时，流程的边际收益趋近于零，边际成本却很高。
4.2 最短路径原则：先做能跑的，再做好看的
caveman工作流的另一条支柱叫“最短路径原则”：在任何任务中，先找出“从当前状态到可用状态”的最短路径，然后立刻走这条路。可用状态的意思是：事情能被用起来、能被验证、能产生真实反馈。至于好不好看、完不完美、有没有冗余，都是后话。
举我自己的例子。前阵子我桌面堆了四十多个需要处理的文件。我的最短路径不是把文件分类归档——那是整理癖，不是工作。我的做法是快速扫一遍每个文件，判断“它还在不在我未来三个月会用到”，在的丢进一个文件夹，不在的直接删。四十分钟处理干净。如果按“好的归档习惯”来做，我得建十几类文件夹、定命名规范、打标签，一晚上就没了。分类归档是好看的，直接判断去留是能跑的。先用后者，再在需要的时候给真正重要的文件做精细归档。
这条原则在工作里太常用了：写周报先列干了什么，再润色措辞；做方案先写能执行的骨架，再补漂亮的图表；甚至开会也一样——先确认结论，再补讨论过程。永远让信息先流通起来，再追求形式。
5. 原始思维的边界：这四个场景请老老实实用复杂方案
5.1 安全合规是第一道红线
caveman思维很容易从一个极端滑向另一个极端，所以我必须把边界讲清楚。有四类场景，原始办法是明确不行的。
第一类是安全与合规。敏感数据的存储、传输、审计，绝不能靠“一个脚本加文本文件”来糊弄。密码不能明文存、操作必须有审计日志、权限必须能追溯，这些地方复杂度不是浪费，而是必须的防线。你在这些领域追求简单，等于把风险直接暴露出来。我见过一个小团队为了省事，把客户手机号直接放在业务日志里，结果一次日志泄露就收拾了很久。
5.2 事务、协作、平台类场景的“必要复杂度”
第二类是强一致性事务。涉及资金、订单、库存这些需要ACID事务的场景，文本文件、内存态管理这类方案想都不要想。数据库事务机制是几十年沉淀出来的基础设施，它不是复杂度，是安全垫。你省掉的每一步保障，都会在某个深夜变成故障单糊到你脸上。
第三类是多人协作的长期项目。当代码库超过一定规模、人员流动频繁时，“可读性、可维护性、约定规范”本身就是一种必要复杂度。这时主打“怎么简单怎么来”，反而会让后来人陷入混乱。简单并不等于好理解——一个没有任何分层、函数几千行的“简单”PHP文件，对后来者来说就是迷宫。
第四类是基础设施类平台。监控、日志、CI/CD这类支撑性系统，需要的是稳定、可扩展、有生态。你在这类系统上玩caveman，省下的开发时间很快会被运维时间加倍吐回去。比如有人图省事用cron脚本代替监控告警系统，脚本挂了没人知道，等于没监控。
5.3 怎么分辨“有效原始”和“偷懒退化”
我给自己设了三个“退化警报”，一旦触发，就说明当前不是caveman思维，而是纯懒：
- 我是不是在用“原始”来回避学习必要的新工具？
- 我是不是因为害怕变化，所以拒绝升级、拒绝重构？
- 我是不是把“不复杂”当成了“不做”的借口？
一个健康的caveman，会积极学tcpdump、strace、SQL执行计划分析这些工具，但不会为了显得专业而引入它们不需要的系统。原始不等于无知，原始是清楚知道每一步为什么存在之后，再从容选择的简。这和被迫简、无奈简是两回事。
6. 我的caveman行动清单：十条可以直接落地的准则
6.1 清单内容
最后把压箱底的东西拿出来。这些准则都是我踩过坑之后一条条攒出来的，你可以先直接抄走，放到下一个项目、下一次故障、下一次需求评审里试试。
- 01 先跑通再优化：任何功能的第一版本，目标只有一个——能跑。性能、优雅、扩展性全部靠后，没有运行的代码就没有讨论的意义。
- 02 能打印就不要断点：线上排查优先打日志，日志打不全再考虑调试器。先看真实时序，再介入系统。
- 03 一个文件能解决就别上数据库：数据量小、无事务需求时，文本文件或SQLite就是好方案，别被“正规”绑架。
- 04 一个服务能解决就别拆微服务：每次拆分都必须回答“收益是什么”，回答不上来就不要拆。
- 05 需求先做减法：不确定必须做的功能默认不做，等真实反馈来了再做。删除需求比新增需求难得多，所以要在源头卡住。
- 06 会议不超过30分钟且必须有结论：没有结论的会议是社交活动，不是工作。需要讨论的事群聊解决，需要大家知道的事发公告。
- 07 沟通走最短路径：能在群里说清楚的别开会，能当面说的别写长邮件。先把信息送达，再讲格式。
- 08 备份是最原始也最硬的保障：任何系统上线前先想备份，再想其他。不怕原始，就怕没有退路。
- 09 出问题先看现场再想理论：不要坐在那里推演各种原因，先去看日志、看数据、看时序。
- 10 每半年做一次复杂度审计：把系统里、流程里、协作里所有“不知道为什么要存在”的东西列出来，逐一干掉。
6.2 怎么让清单真正生效
有一个特别容易踩的误区：把清单当成教条。我刚开始拿这套准则要求自己和团队时，闹过不少笑话——有人为了践行“先跑通再优化”，把代码写成了屎山；有人为了“会议不超过30分钟”，该讨论清楚的事没讨论就拍板。
后来我才明白，caveman思维最终要练的不是背规则，而是对自己的系统和团队建立“最低可用复杂度”的直觉。规则只是入门拐杖，真正的功力在于判断：这个东西的复杂度，到底是解决问题必需的，还是为了显得专业硬加的？这个问题问多了，你自然就有手感了。
我个人这几年的体会是，越是复杂的局面，越要敢用简单的办法去破局。别怕被人说土，能把问题解决干净，本身就是最专业的表现。下一次当你面对一个越理越乱的问题时，不妨停下来问问自己：如果我是个原始人，我会怎么做？
