【工程思维】 发刊词：同一类问题，工程早就解过了

这个专栏想讲一件很简单的事：工作、生活里遇到的很多问题，和工程师在系统里遇到的问题，其实是同一类问题。只是换了场景，换了主角，换了代价。而工程领域因为被反复验证了太多次，早就把这类问题的通用解法提炼成了成熟的概念——缓存、模板、工作流、队列、幂等、状态机、容灾、监控……这个专栏做的事情只有一件：把工程模式翻译成工作和生活里能用的东西。

先说我是什么时候意识到这件事的。

发现时刻

去年年底失业，一失业就是四个多月。那段时间我做了不少事：研究创业路子，试过自媒体，写过小说开头，认真研究过炒股，最后还考了个健身教练证。现在回头看，我当时其实一直在用同一套方法处理这些选择。

失业的头一个月，我给自己列了三种策略：上策是进 AI 或机器人行业的初创公司，接受高强度换薪资提升；中策是进传统企业或外企，接受降薪换时间，用业余时间探索副业；下策是进高强度高薪的公司，多攒资本，边干边找机会。后来市场行情很差，三套方案被现实一退再退，我始终没慌，因为手里始终有可执行的备选。这是方案对比，是决策树，是工程里被写烂了的"多方案评估"。

用 AI 写代码那段时间，我又碰到一个更典型的例子。项目做完了，但感觉自己没进步：一个会话拖太久，AI 聊到后面开始忘事；需求一开始想不清楚，做到一半又回头改。后来我想明白一件事——我不该依赖聊天记录，而应该依赖文件。把项目状态、决策、待办全部写进文件，每次新会话先读文件再干活。这其实是工程里一句老话：把状态放到持久化存储里，而不是放在内存里。内存会丢，磁盘不会。聊天记录会被压缩、被截断，文件不会。

这两个例子让我开始认真琢磨：我是不是早就在用工程的方式过日子，只是没意识到？

问题同构

如果抛开表面细节，工程里遇到的问题和工作、生活里的问题，结构上几乎是一样的：

输入是什么，期望的输出是什么？有哪些约束（时间、资源、成本）？中间有哪些不确定性和风险？失败之后能不能恢复，代价多大？

「用户想要一个稳定服务」和「我想保持稳定输出」是同构的；「系统缓存要设计过期策略」和「我的认知需要定期更新」是同构的；「接口要提前约定好契约」和「分工合作要先把边界说清楚」是同构的。

工程领域不一样的地方在于，它被高强度地验证了太久——一个模式不好用，很快会被淘汰，留下来的都是被反复证明过的东西。所以工程里积累的不是一堆技术名词，而是一套通用问题的解决方案库。

比如缓存机制。大脑记不住所有事，这是所有系统的共同约束。工程上的解法是：把高频使用、低变动的信息放到离使用者最近的存储里，并且设计好过期策略。翻译到生活里就是：那些要反复用、又不常变的东西——清单、SOP、模板——不该靠脑子记，要落到外部存储里；而过期策略就是定期复盘，防止认知过时了还在用。

比如模板策略。工程上从来不重复造轮子，同样的组件、同样的流程，永远先找现成的模板，再在模板上做少量定制。翻译到生活里就是：日报、周报、旅行打包、健身计划、会议议程——凡是会发生两次以上的事，就该有一份模板，每次只是更新增量，而不是从头开始。

比如工作流。工程上多步骤、有依赖、会出错的事，一定会被固化成流水线：每一步有明确的输入输出、有校验、有回滚点。翻译到生活里就是：搬家、离职交接、买房、办手续——这些事不该靠临场发挥，而该像一条流水线一样被设计好、被执行、被复盘。

这个专栏打算怎么写

三个约定，都是给自己定的规矩。

第一，每篇一个工程概念。缓存、模板、工作流、队列、状态机、幂等、容灾、监控、版本管理……讲清楚这个概念在工程里解决什么问题、长什么样，然后翻译到工作或生活的一个具体场景，给出能直接用的做法。

第二，只写真实场景。不写"假设你有一个问题"这种空中楼阁。每个翻译都要落在我自己遇到过的、正在遇到的、或者亲眼见过的麻烦上。概念是骨架，真实案例是血肉。

第三，承认模式的边界。不是所有问题都能套模式。感情没法做需求分析，缘分没法做灰度发布，有些问题没有最优解，有些决策做完就是不能回滚。工程模式是思考的起点，不是终点；该扔掉的时候要果断扔掉。

写在最后

写博客这件事，我最早是因为缺输出才开始的——读了很多东西，却说不出来自己的观点。写了几十篇之后，慢慢发现写作本身就是一种工程行为：把一个模糊的想法，通过一次次迭代，变成清晰、可验证、可被他人理解的东西。

这个专栏算是把这些年散落的尝试归了档。它不会解决你的人生问题，也不该指望它解决。它只是提供一个视角：当你面对一个麻烦的时候，可以试着退后一步，像工程师看一个系统那样看它——它在解决什么问题？工程里有没有人早就解过？那个解法的核心思路是什么？翻译过来，用在我的场景里，怎么落地？

如果你的生活里恰好也有这种时刻，欢迎一起聊。