设计式工作：积累是目的，问题解决是副产品

发表于 分类于 本文字数： 2.2k 阅读时长 ≈ 4 分钟

大多数人认为工作的核心是解决问题——需求来了就做，Bug 来了就修，火来了就救。积累经验？那是顺便的事。

我的观点恰恰相反：积累是目的，问题解决只是副产品。

这不是文字游戏。这是两种完全不同的工作范式，决定了你是永远在救火，还是让问题不再成为问题。

这篇文章写的是工作方法，不绑某一门技术栈——做嵌入式、写工具、搭系统，都可以用同一套尺子量自己：是在救火，还是在积累。

两种范式

救火式（Reactive）

1
2
3
问题出现 → 解决问题 → 顺便积累点经验 → 下一个问题
    ↑                                      │
    └──────────────────────────────────────┘

特征：

  • 核心目标是“解决当前问题”
  • 大部分时间在响应
  • 价值是线性的：解决 N 个问题 = N 份价值
  • 长期结果：永远在救火，问题不会变少

设计式（Proactive）

1
2
3
4
5
持续积累上下文和经验
        ↓
构建框架、系统、设计能力
        ↓
问题被预防 / 问题被快速消解（副产品）

特征：

  • 核心目标是“积累与设计”
  • 大部分时间在理解和构建
  • 价值是指数的：好的设计预防 N 个问题
  • 长期结果：问题越来越少

为什么积累是目的？

1. 问题是无限的，时间是有限的

如果你的目标是解决问题，你永远解决不完。需求会源源不断，Bug 会层出不穷，火会一直烧。

但如果你的目标是积累——理解业务上下文、沉淀经验模式、构建框架——你在做的是改变问题产生的条件。

2. 救火不产生复利

你今天救的火，明天不会帮你更快救火。每次都是从头开始。

但积累会产生复利：

  • 你对业务的理解会加深
  • 你的框架会覆盖更多场景
  • 你的约束库会预防更多问题
  • 你的设计能力会让新问题更容易被消解

3. 通过设计解决问题，而不是通过响应

真正的高手不是救火最快的人，而是让火烧不起来的人。

1
2
3
普通工程师：这个 Bug 我修好了
资深工程师：这类 Bug 以后不会再出现了
架构师：这个系统的设计使得这类 Bug 不可能存在

工作的三层结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
┌─────────────────────────────────────┐
│  核心层：积累与设计                    │
│  ─────────────────                   │
│  · 业务上下文的深度理解                │
│  · 经验模式的持续沉淀                  │
│  · 框架/系统的设计构建                 │
│  · 约束库的持续完善                    │
└─────────────────────────────────────┘
            │
            │ 设计能力使能
            ▼
┌─────────────────────────────────────┐
│  结果层：问题消解（副产品）             │
│  ─────────────────                   │
│  · 问题被预防（设计时已考虑）           │
│  · 问题被快速解决（有框架支撑）         │
│  · 问题被系统性消除（根因已处理）        │
└─────────────────────────────────────┘
            │
            │ 自然产出
            ▼
┌─────────────────────────────────────┐
│  交付层：业务成果（副产品的副产品）      │
│  ─────────────────                   │
│  · 功能上线                           │
│  · 需求完成                           │
│  · 指标达成                           │
└─────────────────────────────────────┘

注意依赖方向：积累 → 设计 → 问题消解 → 业务成果

不是反过来。

副产品思维

既然积累是目的，那什么是我们真正要捕获的？

高价值副产品

类型 说明 示例
问题模式 这类问题怎么解决 “分布式事务的三种处理模式”
踩坑记录 哪些路走不通 “为什么我们放弃了方案 A”
决策权衡 为什么选 A 不选 B “选择 Redis 而非 Memcached 的原因”
上下文理解 业务为什么这样 “这个审批流程的历史由来”
框架抽象 可复用的解决方案 “支付系统的约束库”

副产品的特征

好的副产品应该是：

  • 自然涌现：解决问题过程中产生，而非刻意制造
  • 可复用：下次遇到类似情况能直接用
  • 可检索：需要时能找到
  • 可演进：随着理解加深不断完善

实践：如何转向设计式工作

1. 改变时间分配

1
2
救火式：80% 响应 + 20% 积累
设计式：40% 响应 + 60% 理解/设计/积累

这不意味着不交付。而是用更少的时间做响应式工作（因为设计减少了问题），用更多时间做有复利的事。

2. 每次问题后多问一步

1
2
3
4
5
6
救火式思维：问题解决了吗？→ 解决了 → 结束

设计式思维：问题解决了吗？→ 解决了
           → 这类问题以后还会出现吗？
           → 如何从设计上消除它？
           → 这个经验值得记录吗？

3. 建立个人知识系统

1
2
3
4
5
6
/knowledge/
  /context/      # 业务上下文理解
  /patterns/     # 问题解决模式
  /constraints/  # 约束和踩坑记录
  /decisions/    # 决策记录
  /frameworks/   # 框架和方法论

不需要完美，关键是持续积累。

4. 定期抽象提炼

每月花几小时回顾积累的内容：

  • 有没有重复出现的模式？
  • 能不能抽象成框架？
  • 哪些可以分享给团队？

一个检验标准

问自己：如果明天换一个项目/公司，我能带走什么？

  • 救火式工作者：只能带走“我做过 XX 项目”的经历
  • 设计式工作者：带走对领域的深度理解、解决问题的框架、可复用的方法论

后者才是真正的职业资本。

结语

不是解决问题后顺便积累，而是通过积累和设计，让问题不再成为问题。

解决问题是工作，积累是脚印，创造是把脚印连成路。

路修好了，问题自然被绕过。

这篇文章本身就是设计式工作的副产品——它源于对“工作本质”的一次深度讨论，而非为了写文章而写文章。