From bb65c4b79803c9bd5b9004b11ff6e59bbeacf4fc Mon Sep 17 00:00:00 2001 From: eltrac Date: Wed, 28 Oct 2026 23:52:03 +0800 Subject: [publish] /article/note-dev --- content/article/note-dev.md | 66 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 60 insertions(+), 6 deletions(-) (limited to 'content/article/note-dev.md') diff --git a/content/article/note-dev.md b/content/article/note-dev.md index 0ff32dd3..ee2544cd 100644 --- a/content/article/note-dev.md +++ b/content/article/note-dev.md @@ -2,11 +2,12 @@ title = '像维护软件一样维护效率系统' subtitle = 'Notebook Engineering' slug = 'note-dev' -tags = [] +tags = ["效率","软件"] categories = '生产力报告' -date = 2026-10-27T20:18:36+08:00 -draft = true +date = 2026-10-28 23:49:02 +draft = false toc = true +fedi = 'https://akk.eltr.ac/objects/d5a94278-6b32-4092-9cd1-1126a360a7a8' +++ 标题可能会让人误以为我要介绍精密复杂的 PKM 体系，但实际上我[我不混“知识管理圈”](https://www.geedea.pro/en/article/i-am-sick-of-pkm/)很久了。我想我数次安装和卸载 Emacs，仍然用 Neovim 写代码和写文，*一部分*原因是 [Org Mode](https://orgmode.org/) 对我毫无吸引力，甚至有可能会害了我[^1]。 @@ -124,13 +125,60 @@ toc = true ## 原型开发和迭代 -## 编写用户手册 +我们其实还没有完成系统建模，这也是需求分析的一部分，但是一直纠结某个活动属于生命周期的哪个部分实在是太无聊了。不多言，直接来画状态机吧。（机什么？） -文档是软件的一部分，除了给开发人员看的技术文档，用户手册也是很重要的。 +前文反复提到「记录」和「标记」的概念，一条记录可以被标记为「搁置」，可以被「移动」，还可以被「删除」。状态的变更也是规则的。简单来说，可以给系统中的记录或者说事项规定以下状态： -## 持续集成，持续部署 +![事项可以从「待办」状态转变为「进行中」，由「进行中」转变为「完成」，也可以由「进行中」直接变成「完成」；此外还可以从「待办」变成「取消」「搁置」或「推迟」；还有名为 item（事项）和 note（笔记）的特殊标记](https://img.eltr.ac/geedeapro/article/note-dev/todo-state-machine.svg "事项的状态变化图，使用 Excalidraw 绘制") +{.dark:invert} +这张图里的方框代表待办（todo），画了一捺的方框代表正在进行（doing），打勾自然表示完成（done），删除或者说取消（cancelled）也应该是不言自明的。值得注意的是推迟（postponed）和搁置（suspended）的区别，推迟表示这件事情已经被移动到之后具体的某一天的计划里了，有了明确的去处，而搁置则与古希腊哲学的悬隔（Epoché，或者 suspension of judgement）有些关联，表示这件事情还没有去处，当下也不打算做出判断，不删也不做，应该移动到不定时间的大待办清单上。 +此外，还有两个不是方框的标记，分别是事项（item）和笔记（note），前者记录那些没有计划（也不需要计划）但是做了的事情，留档记录；后者记录需要今天或这周晚些时候回顾的事情，其实更像是备忘（memo）。这看似是方框和非方框的两种形式，但其实都是对记录（record）的标记（mark）而已。一条记录由标记和描述组成，就只有这么一种直观的形式。 + +嗯？你问我这么设计的依据是什么？是这样的，我们观察目标用户很久了，他的笔记本上用的就是这些记号。他以前也有过别的标记体系，但最终留下来的是这么一套，对他而言足够简单直观。这难道不比花里胡哨的理论和看似严密的逻辑，更具说服力吗？ + +噢等等，等等，架构师先生，请您冷静一下。我知道您的函数式技术倾向让您认为状态是邪恶的，但难道您不认为我们要开发的这套系统是事件驱动的，必须要关心状态变更吗？难道你要让任务一开始就单线地递归执行到底，就为了维持清晰的数据流吗？你不觉得我们的目标用户其实并没有像猴子一样多的精力吗？嗯？你问我为什么要像英美文学里的小说人物一样说话？好吧，先生，我想我只能告诉你，写这段话的人最近不务正业，看小说看得有点太多了。 + +如此一来功能需求其实也比较清晰了，那么来选择技术栈吧！架构师先生，您别纠结要用 Emacs Lisp 还是 Lua 写了，客户点名儿要用 Spring Boot。唉？唉唉唉！我开玩笑的，您别掐自己人中啊！害，您瞧瞧这事儿办的。其实业务需求里写得已经很清楚了，目标用户需要感官刺激可控的，也不喜欢电子设备，我觉得呀，纸和笔就够啦。至于尺寸，咱也就别用那 A4 大夹板，也别用 A5 大活页了，客户反馈说他连 A5Slim 都写不满，还嫌重呢！A6！A6 就够啦！哎呀，您就别问我说话为什么这么像北京人啦，你又不是不知道这写字儿的人整天都在发什么神经。 + +我们先来看看 MVP 的效果怎么样吧。 + +![](https://img.eltr.ac/geedeapro/article/note-dev/notebook.jpeg "我某两天的笔记页面") + +恕我直言，女士，这就是两页非常普通，谁都能涂涂画画写出来的纸！ + +可先生，客户反馈他用这套方法感觉自己比以前任何时候都觉得轻松，完成的事情也不少，这难道我不是更符合需求的系统吗？先生，恕我直言，我觉得是时候拿出这张图了。 + +![一个正态分布图，左侧是使用记事本的大脑萎缩之人，中间是使用 Notion、Anki、Roam Research、Obsidian、Readwise、Pocket、Google Doc、OneNote 等笔记软件形成复杂知识体系的人，而右边，是同样适用记事本的大智若愚者](https://img.eltr.ac/picgo/20241101194214.png "某知识管理圈子里流传的神秘迷因图") + +可是你看，那两页纸上还有很多不规范的地方，比如星号明明是用来标记笔记和备忘的，却也被用来给待办事项分区。笔记中间还有各种飘来飘去的箭头，根本不知道是什么意思！这系统未免有点混乱。 + +好问题，可这不正是让我们了解到了之前没能发现的需求吗？显然只定义记录和标记并没能解决目标用户的所有问题，他还有先前未发现的，给记录分区、分类的需求。至于那些箭头，很有可能也是我们需要建模在系统里的新要素。至于这会不会让系统变得过于复杂，难以拓展，留下技术债务，就是要进一步讨论的话题了。 + +## CI/CD 和文档 + +还记得软件装在盒子里售卖的年代吗？我没经历过那个年代，我开始接触编程的时候，人们就已经完全拥抱 Web 了（如今反倒有逐渐抛弃 Web 的趋势），一切都部署在服务器上。我记得不久前还有好多人说 PHP 是最好的语言呢，如今…… 呃，PHP2Shell 的确让整个互联网都见识到了 PHP 的强悍。 + +再新一点的概念应该是 CI/CD，也就是持续集成，持续部署，把软件的生命周期变得更灵活了一些。软件没必要打磨到完美才发售，因为软件不再装在盒子里了，更新的成本很低。如果完全部署在云上，配合自动化工作流，也能很快把新的版本编译、打包、部署到服务器上。我认为，速度并不是 CI/CD 以及与之相关的软件开发模式的最大优势，而是能够一边开发一边**收集反馈**，可以快速收集和验证需求，及时调整开发方向，避免在前期投入大量成本。 + +效率系统也是，即便是纸笔，也可以很灵活。前期可以用易于调整的活页本运行原型系统，试验一两周之后收集和整理反馈（自己问自己也是很重要的），发现问题后一条条列出来，然后一条条找到解决方案。而且，别忘了，有问题的大概率不会是用户，而是系统。所以，用到难用的软件要大大方方（但清楚有条理）地指出问题，效率系统执行不下去也不该责备自己。这种时候应该迭代一个新版本，编译后部署到自己的笔记本或者别的什么载体上。 + +文档是软件的一部分，大的架构决策应该要有 ADR（架构决策记录）背书，也方便后来者理解「为什么要这么做？」，系统的各个组件应该要有文档描述其内部结构。我还听过一个说法，每一行代码都是有文档的，因为每行代码提交时都有写 commit 信息（前提是你真的有好好写这个东西）。即便是自己一个人的项目，我也喜欢手写 Issues 和 Pull Request 信息，设置以计划发布的版本号命名的里程碑（Milestone），这能帮助我思考和规划，也能帮我在后来追溯当时的想法。 + +单独在本子的某个地方，或者别的载体（比如博客）上写清楚系统这么设计的前因后果，也有助于自己梳理思路。此外，无论是描述效率系统还是开发软件，写文档都能让我对自己的系统有新的认识，偶尔也会因此蹦出新的想法来。 + +当然，也要警惕，无论是沉溺与架构决策还是挖掘新需求，都有可能系统偏离原本的需求和目的，最重要的是，这样一定会忽略大量的细节问题，而细节与全局同样重要。我想 Vibe-coder 们是没有想过这些问题的，他们的软件大多是做完就丢的东西，持续时间不会很长。==一上来就把系统设计得庞大又复杂，就跟跑马拉松一上来就把配速拉到极限一样==。除非你根本就不打算跑马拉松，否则我建议你认真对待细节，尽可能消除危险的模糊性。 + +## 最后 + +嗯？你问我这套系统怎么检索？怎么和其他系统集成在一起？怎么一键导入 Anki 制作成记忆卡片，一键扫描归档进 Zettelkasten，怎么把涂画变成 Mermaid 流程图？——**为什么**需要那些东西？ + +不过话说回来，数字笔记的确有很多好处，我会在我真的**需要**检索、回顾和快速捕捉的场景下使用数字笔记，比方说我最近干运维的活儿[^6]比较多，为了帮助我记住自己在哪台服务器上改了哪个配置，把哪个文件放在了哪台机子上，某个服务应该用哪个端口访问，这个端口有没有被 `ufw` 或者 `fp`[^7] 挡住等等，我会在做了某些操作之后立刻在 Logseq 里留下一条记录。 + +选择 Logseq 的原因也很简单，写标签很快，后续索引也方便，大纲式笔记也很适合做事件记录。更何况 Logseq 自带日记功能，我要记录只需要打开界面，直接把某条记录写进日记页，打上标签以后就能检索到。另外，它是用 [Clojure](https://clojure.org/) 写的，我已经不知道是第几次提到这点了。[^8] + +就这样吧，祝你也迭代出适合自己的系统。 [^1]: 这仅仅是针对我自己的情况而言，详情请阅读后文。*我真的好害怕有 Emacs 用户跑过来教我 Emacs 和 Org Mode 的正确打开方式啊。* @@ -141,3 +189,9 @@ toc = true [^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)…… + +[^6]: 并不是公司的活儿，而是管理我自己的 VPS，我也把升级自己个人电脑的软件包当作运维工作。 + +[^7]: 分别是 Ubuntu 的 Uncomplicated Firewall，和 OpenBSD 的 Packet Filter。 + +[^8]: 至于缺点…… 他们仍然没有支持 XDG 基本目录规范，并且现在也包含 LLM 生成的代码，再者，ClojureScript 的性能真的不算好。 -- cgit v1.2.3