如何让笔记助力工作？高效工作笔记 SOP 分享

现在，试想一下，你手头有一份工作，与 3 个人对接，你会怎么处理与他们的交互？记笔记对吧？很自然地，你开始用笔在笔记本上或 A4 纸做各种零散的记录，通过不断地开会同步所有信息，终有一天，任务完成，效果非常好。到这里，一切都是好的。接下来，让我问你一个问题:

有一天，当你要在公司另一个部门做相同的工作时，你会怎么做？

可能你会把以上流程重新走一遍，起码会更快更有效率，这可能是大部分人的答案。 而我的答案不是这样，我会找到自己做好的项目笔记，以此为基础开始这份相同工作，我也会更快更有效率。如果我的记录是清晰有效的话，把它交给第三个人同样也可以做到差不多的效果。 这就是我的答案，我会让我的笔记为我工作，它是一种工作方式，也是一个不断迭代更新的工作 SOP。

这里大家心中可能会出现两个主要问题:

• 你的工作 SOP 是什么？
• 为什么它能助力你的工作？

这是我接下来要告诉你们的事情。

开始之前，给新观众朋友介绍介绍自己

hello

Hello 大家好，我是小卡。我热衷于探索各种效率工具和思维模式。如果你正在寻找有效的方法来提高工作效率或生活质量，记得关注我。我致力于为我的粉丝带来各种亲测有效的工具和思维方法，希望能帮助大家脱颖而出，祝你成为牛人。

工作 SOP 是什么？

我的工作 SOP 由三种笔记组成，仅就笔记性质的维度来说，分别是:

• 工作日记
• 任务记录
• 卡片笔记

工作日记: 是每天都会记录的笔记，这个笔记主要作用是对每天工作内容的记录，它包括 Meeting (Daily, Support tech)、Journal (Worker, Backlog etc.) etc 等。

2024-10-16-template-Emeria-work-today-meeting-journal-task-backlog

任务记录: 包括技术支持(support tech)记录、任务记录以及任务总结 (resume)，这个笔记会根据不同的任务需要按照不同的结构来编写，以便于日后的再利用。

2024-09-02-template-Obsidian-action-add History

卡片笔记: 是一个小知识点的记录，也可以是针对某个问题的一小个解决方案，它是在写任务记录的过程中自然而然会遇到的各种问题，选其中有价值的部分编写而成的小卡片。具有单一职能，一个卡片仅仅解决某一个点的问题或记录某一个点的知识内容。

2024-09-09-Card-Tech-Terraform-local vs varaible vs data

每一种笔记都会有固定的模板，并且这些模板依然会随着我的需要不断迭代 🔁。

工作 SOP 助力了什么？

工作 SOP 的好处简单来说是增加了效率。

快思考与慢思考

美国心理学家丹尼尔卡尼曼的著作《思考，开与慢》一书中提到，我们的大脑有系统 1 与系统 2 之分，系统 1 是快的直觉思考，系统 2 是慢的理性思考。当我们面对复杂的工作问题时，往往需要让系统 2 出马，来解决问题。

当我们写工作笔记的时候，你认为自己是用哪个系统去记录笔记？我想很多人会觉得记笔记是一件很复杂的事情，因为你既要思考自己需要写什么？怎么写？用什么案例来证明？边想边把内容写到笔记上，所以记笔记的全过程应该是复杂无比的。

但是我对开始书写打字写工作笔记这件事情，我认为是比较相对简单的。它来自于两方面？ 一、我在开始写之前，其实我的大脑就已经在处理复杂的事务，并且尝试得出一个结论。这个复杂的过程无疑是在头脑中演变的。当我们要把它输出到纸上的时候，其实它仅仅是抄写的过程，如果把记笔记这件事情变成写字以及写什么字两件事情的话，写字本身无遗是相对简单的。 二、为了更加简化写笔记这件事情，我会用准备好的笔记模版，直接将笔记结构与填入，让我不必把精力花费在笔记结构组织上，而是专注在头脑中的面临复杂问题信息的组织和分析。

模板、快捷键等使用方式，都是我提前准备好的，使用它们的方式则是我慢思考系统 2 的产物。我把这些方法变成了自己直觉的一部分，创建笔记的时候我不用费力本能地就会自动应用某个模板。整个过程就是我把慢思考的成果提炼成系统 1 通过直觉方式就可以使用的功能。这样我就能够把更多精力集中到我应该如何解决问题，而不是如何记录笔记。

用数学公式来看记笔记这件事情

如果用一个数学公示来表达我们工作完成度，我会这么写，如果我们把工作完成度与爬山类比，则可以说:

$$D = (V*\frac{100-diff}{100} + Vo)t + Do$$

• D 则是我们需要到达的高度
• V: 是我们行进速度
• diff: 是爬坡难度, [1-100)
• t: 是我们用的总时间
• Vo, Do: 都是预先设数值，分别是预设速度与预先完成度。

题目是，当我们爬山的高度是相同的情况下，我怎么花更少的时间？

答案是增加爬山的速度。

通过题目，D, t 已经确定，我们可以有以下选择

• V: 增加我们的行进速度，这个在于身体素质与合理的行程安排，我们可以通过提高体能、学习登山技巧等方式提高。
• diff: 减少爬坡难度，本来我们想要爬珠穆拉玛峰的，现在我们降低登山难度，爬 Mont blanc 行不行？
• Vo, Do 我们是不是已经做过某些工作，让我们已经对爬山这件事情有一定的经验和理解，比如我们找到了某些经常爬这座山的专业向导，他们带领我们走最近的爬山道路，避免白白踩别人以前犯过的错误，以此为登山这件事情本身提供一个 Vo。另外，山上是不是已经有一些补给站，我们为什么不直接从补给站 Do 出发，而不是自己从山脚下自己爬。

V: 行进速度很难短时间提升，提高体能需要一段时间才会见效，也很难长时间维持一个很高的速度，这对身体负荷很大。 diff: 工作中并不是能够选择工作的难度，一件事情难不难也不是一开始我们就可以预测的；有些事情开始以为难，实际不难，有些事情开始以为不难，实际一点也不简单。 Vo, Do: 也就 Vo,Do 我们是可以做到，这里就类似于我们对于工作业务的经验。如果我们能够把工作业务的经验高保真地还原到笔记中，那么我们有可能可以重复使用其中的某些部分。

回到那个问题: 工作 SOP 助力了什么？

结合公式，对内部效率来说，记笔记的过程能够增加我对任务本身的理解(Vo), 第二个在笔记的开始的收集信息阶段做的越完善，将更有利于帮助我们提出更有效的创新 Solution。

对外部合作来说，减少了理解成本，在保证我们记录笔记是可被理解的前提下，我们可以直接分享已经写好的 pdf 文档，而避免多次开会的情况去同步多个人之间的交流沟通。另一点是可能获得可复制的成果经验，在满足第一点能看懂的情况下，另一个人拿到这个笔记，做类似的事情，是能够大大帮助他完成事务的。

如何助力一个 debug 工作？

接下来我们将走一遍 debug 任务的流程，并且我会在这个流程中提到我的笔记的应用。

一个标准的成功的 debug 工作流程是:

1. 确定 Bug 问题: 出现位置、频率；影响程度、范围；涉及人员；后果，原因
2. 提供解决方案
3. Do it, test if, fix it in dev -->|if OK ?| review it --> deploy on Prod
4. Monitor it in Prod -->|if OK ?| close to code
5. tidy doc like clean codes, 通知相关人员, close task
6. Revise task(why, how to prevent), resume task

确定 Bug

在这个阶段，我们会通过不断的搜集，分析，做小测试等方式，获得多种多样的信息，bug 出现的位置，出现的频率；bug 影响的范围和影响程度；涉及到哪些人员，可能的原因，出现的结果。

我的工作主要是查看信息，过滤掉与 bug 无关的内容，将它们记录到任务笔记中。通过不断整合关联有用的信息，慢慢的找到 bug 出现可能的原因或它会导致的结果。找到验证原因的方法，最终知道为什么 bug 会出现？是因为最近的某个改变，外部依赖的某个资源无法分了，还是因为一开始设计上忽略某个特殊情况等。

提供解决方案

知道发生 Bug 的原因后，我们需要为这个原因提供一些解决方案:

• 如果某个数值错了，则可以直接纠正它；
• 如果是某种情况未算进去，则增加一个判断条件；
• 如果是流程处理有问题，可以修改某个流程，替换某个流程等；

这些解决方案都可以记录到任务笔记中，需要讨论的时候，将它们展示出来。最终从几个方案中选择对当前任务来说的最优方案。

有时候我们在修复一个问题的时候，不仅仅提供当前问题的解决方案；如果有需要，我们再提供解决方案的过程中同样可以提供一些更基本更具创新的优化，这里可以是减少任务处理的维护成本，简化代码的处理逻辑。这里的创新并不意味着我们需要最出最大的改变，获得最好的结果，而是用最小的成本完成这件事情，而不至于出现为了坚持走某个方向而把路上的森林砍掉、把山移走，把海填平。想办法以小的修改获得大的好改变，用相对少的资源撬动复杂整体往简单处靠近。

info

卡片笔记的来源 在确定 Bug，提供解决方案的过程中，我们会看到很多新的东西，里面肯定有些知识点是我们希望以后能够重复看到，这时候就是创建卡片笔记的时候， 它们在未来的工作中会帮助我们快速的了解某个问题，某个技术，某个情况的分析，比如:

开发与验证阶段

无论是对于 Dev 环境 开发的过程，Dev 环境的验证手段，还是 merge 后在 Prod monitor 的需要，如果有需要的话，我都会把它们记录到笔记中，这样方便我下次再次遇到类似情况时候，可以直接重复使用相同的验证手段。

这些验证方法某种程度上是对经验的积累，你知道的验证方法越多，能够帮助你面对更多复杂的问题。

收尾、总结阶段

这个阶段验证并不需要做很多开发工作，因为你的工作成功已经部署到了 Prod。大家往往部署后便不再关注已经做完的事情。

与此不同的时候，每当一份任务做完之后，我都会额外花一些时间，对已经做好的任务做整理。这里的整理主要是让整个任务笔记变得更加清晰，并且可以让一个不了解此项任务的人也能够理解甚至上手，这里会包括流程图，架构图，测试步骤，测试方法，任务背景，任务设计人员，开过的会等。所以这并不仅仅是一个文件(虽然它经常是一个文件)，而是多个文件的组合。

根据不同的人可以分享不同的文件，例如，如果想了解整个项目的整体情况，可以查看 resume 文件，如果想了解某个细节，可以看正常的任务笔记等。

以下是一个例子:

结尾

好了，以上就是我想分享的所有内容。如果大家有什么问题，欢迎联系留言。

以下是我开源的 Obsidian 笔记库: https://github.com/xiaokatech/obsidian-notes

欢迎大家关注我的频道，我会为大家分享好用实在亲身践行的经验和知识。