path: root/content/article/note-dev.md

+++
title = '像维护软件一样维护效率系统'
subtitle = 'Notebook Engineering'
slug = 'note-dev'
tags = []
categories = '生产力报告'
date = 2026-10-27T20:18:36+08:00
draft = true
toc = true
+++

标题可能会让人误以为我要介绍精密复杂的 PKM 体系，但实际上我[我不混“知识管理圈”](https://www.geedea.pro/en/article/i-am-sick-of-pkm/)很久了。我想我数次安装和卸载 Emacs，仍然用 Neovim 写代码和写文，*一部分*原因是 [Org Mode](https://orgmode.org/) 对我毫无吸引力，甚至有可能会害了我[^1]。

好的软件不*总*是精巧复杂的，甚至大部分时候是简单的，或者说清晰明了，而且可拓展、可组合，在需要的时候不会因其形式或接口而派不上用场。比方说 `grep` 作为命令行工具，可以搜文件里的文本、可以搜目录里的文件名、可以搜终端历史里输入过的命令，也可以很轻易地集成到其他软件里搜别的东西。

这其实也不是我想谈的重点。实际上，即便是 `grep` 这样小巧简明的软件，在某些情况下也难以施展拳脚，比如面对完全不了解命令行界面的用户时。对他们而言，Raycast 和 Vicinae 等全局搜索框可能更好用，按下 `⌘ + 空格` 就可以搜索应用、文件和各种快捷命令并执行。把两个关联不大的软件放在一起比较可能不恰当，但至少能证明我下面要抛出的观点：

> 好的软件应该是符合需求的软件。

想象你年迈的奶奶一点也看不清楚手机上的小字，而你却在一旁抱怨软件开发者没能统一设计语言，竟然在界面上放这么大的字儿和这么老派的配色，还给了这么多乱七八糟的设置项，一点也不优雅——这可不是好事。

## 用户画像和需求获取

我有点不太理解为什么有人喜欢浏览各种花哨的 Notion 模板，就像我用不了现成的 Neovim 和 Emacs 配置一样，噪音太多了。有人试图说服我一点一点来，有些功能放在那里不用就好。然而「不管某些小细节」对我来说很难，我需要在大脑里自己起一个垃圾收集器，持续不断地消耗 CPU，就为了释放内存。貌似许多人的 GC[^3] 是编程语言自带的，甚至可能[像 Java 一样](/weekly/97/#java-其实是内存高效的)，大部分时候都不运行。

最近我意识到这可能是我的神经特异性导致的。我今年才开始正视自己的孤独症（Autism）[^2]特质。神经多样性好像已经变成玩笑话了，大家说「自己没点病都不好意思上网」，我厌恶甚至指责这种说辞。要指责的一方面是把神经特异当作「神经反常」「精神病」的陈旧思想，另一方面是，这种说辞看似在攻击无病呻吟者，实际上加剧了神经特异者的边缘化，因为这话背后的意思是：大部分说自己是 ADHD 或 ASD 的人都在装酷。那真正的 ADHD 和 ASD 还怎么敢站在公共面前呢？而且他们本来就更不善社交。

我跑题了。我想说的是，我的确有很多孤独症人群常见的特质，而且这些特质影响了我的日常生活，也影响了我对自我管理体系的*需求*。

首先，我对感官信号过于敏感，我希望系统本身的**感官刺激可控**且令我安心。这几天看了一期讲[孤独症人群感官体验](https://invidious.nerdvpn.de/watch?v=VW2ZYDw_kXk)的视频，频道主说自己睡觉的时候会觉得自己的心跳声像摇滚演唱会一样吵，我也是！我时常在半夜起身反复确认有没有地震，因为我的心跳好像震得我全身都在动一样。我和频道主一样，也会忧虑是不是自己的心脏有问题，然后为此辗转反侧。实际上就是我对某些信号太敏感了。

不只是自己的心跳，环境噪音也是。我不喜欢去酒吧这种吵的地方（清吧会好很多），因为要主动屏蔽杂乱的环境信息很累。就算是相对安静的环境，我也时常听到其他人没注意到的声响和小细节——这是一体两面的，对细节的关注在某些情况下是优势，但也是需要正视的劣势。

如果我的效率工具有太多不可控的感官刺激，我用起来会觉得很累。飞书的多维表格就是反例，它大体上是即时通信工具，我很难不被侧边栏的消息和表格各种花里胡哨的浮窗、工具栏分心。即便我并没有点击那些东西的欲望，我也会觉得要感官过载了。

我的情况可能还要再极端一点，我去年[全面抛弃了数字记录](/essays/我全面抛弃了数字记录/)，因为电子设备本身就是极大的感官干扰。即便全屏打开笔记编辑器，只运行一个应用，我的脑海中也会冒出数种可能性——这就不是感官刺激的范畴了，和注意力机制的关联更大。

之所以 Doom Emacs 里提前配置好的各种插件让我坐立难安，而 Clojure 标准库里丰富的函数并不会对我造成困扰，是因为函数在形式上是单一且确定的，只要当作接收参数然后返回特定值的黑箱就好，而 Emacs Mode 千千万，有的能收发邮件，有的能看 RSS 和 Hacker News，有的还能在 Matrix 上发消息，我永远也不知道下一个会以什么形式出现。[^4]

我希望系统的**形式足够简单**，简单到用几种甚至一种要素就能表示我想要表示的所有东西。就像 Lisp 只需要用 `s-expr` 就能表示所有的语言单元一样[^5]，我希望我在管理待办事项和备忘的时候，不需要频繁切换思维方式。

下一个需求有点矫情：我不喜欢有人教我做事。我至今没办法在别人看着我的情况下工作（不久前我的同事跟我交流工作的时候，盯着我写 Agent 的提示词，我感觉自己要爆炸了，原因很*复杂*）。我能接收批评指正，我不会把情绪带到工作上来，我也很少让情绪影响周围的人，但这意味着我要在大脑里另起一个线程，处理自己的胡思乱想。我当然不希望我自己的系统过于严格，让我没有喘息的机会，我希望我使用它的时候，心情是愉悦的，能立马感受到事情在我的掌控之内。

系统又不是主体，它怎么会教你做事？怎么会审判你？可很多时候就是这样。我错过了自己设置的截止日期，或者在安排要做某件事情的时间里提不起劲儿，我会责备自己太拖延、太懒惰。某个待办上写的事情我只做了一半，但当天已经结束了，我只能推迟到下一天——我知道给框框画勾很爽，但划掉框框再移动到下一页，糟糕的感觉也程度相当。

我还常常有这样的体验：做了某些事情之后（往往是逼自己做的），感觉身体很沉重，就算是做自己喜欢的事情也觉得累，根本不想动。这件事情有可能仅仅是跟指导老师发信息等回复而已。之前提到的那个视频里，频道主把这种现象比作「清醒的宿醉」。在这种情况下，若还有个严格的系统管制我，让我在自己的空间里也不得安宁，我只会想逃。效率系统的效果不应该是让人想逃避做事。

简单来说，我希望，就算我完全精神崩溃，生活糟糕得不能再糟，沉闷地过了几周甚至一个月之后，只要我决定再爬起来，我就可以立马打开我的笔记本，像什么事情都没发生一样做自己该做的事情。

所以，这样一套效率系统的业务需求是：==帮助易受感官刺激影响、注意力容易分散、精力波动大的用户，建立简单直接且容易管理的生活和工作计划，并且不会在执行过程中感到压力山大。==

## 需求分析和系统建模

业务需求已经确定，那么现在应该分析用户需求了。上个阶段的产物是对业务需求的整体描述，这个阶段的产物是具体的用例（Use cases）。

用例既描述了具体的用户需求，还界定了系统与外部实体的边界。谁在系统之内？谁在系统之外？谁与系统交互？做什么交互？系统最终要实现哪些交互背后的功能？这些问题都会通过规定用例得到解答。看起来做需求分析就该写用例呢。

但是我不。

软件需求工程的各种理论在我看来既有新学科的不成熟，又十分老派。比方说下面这个需求层次图，把软件需求分成业务需求、用户需求和功能需求（以及非功能需求和约束条件）的做法，其实相当局限。

![](https://img.eltr.ac/geedeapro/article/note-dev/11.png)

这张图片来自[这篇论文](https://www.researchgate.net/publication/307841807_Requirement_Analysis_Method_of_E-Commerce_Websites_Development_for_Small-Medium_Enterprises_Case_Study_Indonesia)，是有关为中小型企业开发的电商网站的需求分析方法的案例研究。很多需求工程方法论都是针对大型软件的，因为这些软件的需求很复杂、变动大，需要工程化的方法管理和维护。

这就是老派的点。至于为什么说不成熟，是因为这类方法论不仅实际应用不广，学究气息很重，而且很快就被新的软件开发模式替代了。比方说敏捷开发就可能认为，在前期制定过大的需求规格很有可能造成浪费，默认需求是持续变动的。还有不少软件团队不交付用例，而是交付用户故事（User story）。还有一种系统建模方式就叫作[故事驱动建模](https://en.wikipedia.org/wiki/Story-driven_modeling)，系统建模也是需求工程的一个环节。

话说回那些简单的软件工具。你要如何想象 `grep` 的需求规格说明书呢？如果现在有人要开发一个新的 Vim 编辑器，他们会怎么收集和整理需求呢？在用例里写这种东西吗？——“1. 用户输入文本；2. 用户保存文件；3. 用户查看文件。”

总之，应该根据实际需要开发的软件的类型和特质选定需求分析方法，我决定描述类似用户故事的使用场景来分析用户需求：

1. 用户需要规划一天的计划。
    1. 将前一天尚未完成或者主动推迟的事项移动到这一天；
    2. 从一个大的待办清单里挑选一些这天可以做的，放到这一天；
    3. 添加一些临时发生或一时兴起的事项；
    - 如何减轻第一步的心理压力？
2. 用户在一天的某个时刻，需要确定接下来做什么。
    1. 打开当天的计划并浏览未完成事项；
    2. 逐项评估用户当下做这件事情的意愿；
    3. 选择意愿最高的事项执行；
    - 如何评估意愿？
    - 所有事项的执行意愿都低下的边界情况怎么处理？
3. 用户突然收到通知、回忆起某件事情、产生了灵机一动的想法，或者发现了新鲜事物，需要处理。
    1. 评估事项的紧迫性和执行意愿：
        - 如果必须或十分想要立刻完成，先做记录，然后执行；
        - 如果不必立刻执行，先记录到当天的计划中但不执行；
    2. 继续之前的事项；
4. 用户在一天结束时需要回顾计划完成情况。
    1. 观察所有被记录但尚未执行完毕的计划；
    2. 评估短期内的执行意愿和执行的必要性：
        - 如果必须做，且执行意愿较高，标记为需要移动到下一天（等到情景 1 发生时处理）；
        - 如果必须做，但执行意愿不高，标记为搁置，移动到未定时间的大待办清单里；
        - 如果不必做，但执行意愿较高，标记为搁置，移动到未定时间的大待办清单里；
        - 如果不必做，且执行意愿不高，直接删除。
    - 同场景 1，如何减轻这个过程的心理压力？
5. 用户需要定期回顾不定日期的大待办清单，对于每个事项：
    1. 评估执行意愿和必要性，删除执行意愿不高且不必做的事项，留下其他事项；
    2. 评估事项的紧急性，将紧急事项插入到当天或者第二天的计划中；
    3. 对于余下的事项，如果有新的想法和细节补充，可以做备注。
    - 长期滞留在大待办清单里的事项要怎么办？

不难发现，在上述描述中，用户与系统的边界很模糊，有很多事情是需要用户参与决策的。用户也是系统的一部分，甚至说制定系统就难以避免教育用户以某种方式做事。再者，这些场景中也有些模糊和疑惑的点。

无妨，需求本身就难以捉摸。需求工程中还有一个步骤叫作需求验证，常见的方法是追踪需求的跟踪关系（也就是能不能通过功能需求倒推到具体的用户需求，用户需求能不能推到最初的业务需求）、同行评审和…… 找用户确认。

那么就让我问问自己，这些用户需求是否合理，其中的疑惑应该如何解决。

- 如何减轻处理推迟计划的心理压力？
    - “如果能专注「怎么把所有的未完成事项都通过某种方式消除」，不管是做完的、推迟的还是取消的都一视同仁，就能减轻负担。就像消消乐一样，无论是连线消除的还是用道具消除的，消完了都会觉得爽。”
    - “不过这的确把责任交给用户了，是不是好事，大概要按情况评估。上述做法对不少用户可能无用，如果能接受用户群体缩小或部分用户不满，也是可以做这个取舍的。我认为这个体现在项目理念和用户手册里就好了。”
- 如何评估意愿？
    - “啊，真是个刁钻的问题。想做就是想做，不想做就是不想做，这是很主观的体验欸。我认为主要问题是用户可能不会主动评估自己的意愿，习惯纠结事项本身的难易程度、紧急程度和重要程度，而很少听自己的想法。这类用户就是我们用户画像和业务需求里描述的那一类。”
    - “所以，与其尝试用另一个外在的指标量化「意愿」，不如在流程上**引导**用户自己做出判断。比如提问用户「从 0~5 打分，你觉得你自己有多想做这件事情？」或者「在事项 A 和 B 当中，你宁愿做哪个？」”
- 所有事项的执行意愿都低下的边界情况怎么处理？
    - “同理，总能选出更愿意做的事情。我想系统本身也提供了一个有限的选项池，让用户不至于在一两件不想做的事情和一大堆未知、模糊的可能性里做选择，在少数事项里选择更不讨厌的，可能更容易把执行意愿提上来一点。”
    - “另外，之前业务需求的分析里还提到，目标用户容易出现精力骤降的情况。如果执行意愿都很低，可能是临时的精力问题。我们的业务需求之一就是不让用户在执行过程中感到压力，这种情况下要允许用户不做某些事情。我认为这些事情都可以通过已有的回收和推迟机制解决，也就是把事项挪到第二天或者大清单里。”
- 长期滞留在大待办清单里的事项要怎么办？
    - “滞留会带来什么风险吗？我认为是没有的，就像系统回收站不清理，除了占用磁盘空间之外也没别的害处了，而磁盘空间可能并没有那么重要。”
    - “如果出现大量想做但短期内执行意愿不高的事项滞留，这确实是先前没有考虑过的场景，值得后续讨论。不过因为风险较低，现阶段可以先搁置，实现已有的需求就好。”
    
好了，已经收集完一波同行评审和用户反馈了——~~奇怪，回答问题这人怎么既是需求分析师，又是目标用户呢？~~ 不过，现有的方案如果贸然投入成本开发，可能不会满足需求，因为仍有不少待定的点。然而，这些点即便是在内部反复讨论，可能也不会有突破，貌似只有投入开发才能够收集到真实的数据和反馈啊。

那就投入较小成本，做个原型产品试试看吧！

## 原型开发和迭代

## 编写用户手册

文档是软件的一部分，除了给开发人员看的技术文档，用户手册也是很重要的。

## 持续集成，持续部署



[^1]: 这仅仅是针对我自己的情况而言，详情请阅读后文。*我真的好害怕有 Emacs 用户跑过来教我 Emacs 和 Org Mode 的正确打开方式啊。*

[^2]: 另称「自闭症」，也叫孤独症光谱障碍（Autism Spectrum Disorder, ASD）

[^3]: Garbage collector（垃圾收集器），指代清理废旧、过期数据的机制，一般指编程语言的内存回收。

[^4]: 求求 Emacs 用户不要过来告诉我很多 Emacs Mode 都可以把数据写成 Org Mode，放在一个 `.org` 文件里管理，形式上也很统一。 *One man's meat is another man's poison.*

[^5]: 我至今不能原谅 [cl-annot](https://github.com/m2ym/cl-annot)……