MoreRSS

site icongtdstudy | 学无止境修改

喜欢用 Emacs 的非程序员。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

gtdstudy | 学无止境的 RSS 预览

用 AI 辅助开发的经验二三则(3)

2024-12-21 13:00:00

早两日,我发布了 org-supertag,一个新的 Emacs 第三方扩展包。本来这个项目,我计划是 3-5 天完成,结果花费的时间比预计要超出 3 倍有多。不禁让我想起了一个段子:不管下属报的时间期限多长,总之乘以 3 倍就对了。

多出来的时间花在哪儿了?

先简单介绍 org-supertag 是干嘛的,它借鉴了 Tana 强大的 Super Tag 功能,增强 Org-mode 原本的标签系统。强大这个描述,转换视角,往往意味着复杂。不过对于我来说,梳理 Tana 的功能,以及理清它概念之间的关系,并没有花我太长时间。

花费较多的时间的一个地方,是设计决策、测试设计。

囿于 Emacs 本身是独立的,它的图形表达能力,和交互方式都有自己的独特性,我花了不少时间在探索它们的边界上——我最终实现了一个配置 Tag 模板的可视化面板,操作倒不怎么麻烦,但开发量巨大,功能只是设定标签名字,以及定义属于它的属性段而已,代码行数突破 1k,很夸张。一想到以后还要维护这么一 堆代码,头皮发麻,果断放弃。

我最后回归使用底栏菜单 + 选项的方式。这种方式的优点上实现快,代码简单,但缺点也很明显,如果需要的操作较多,那么操作步骤会非常多,麻烦到我自己都不想用。我不得不绞尽脑汁,思考交互流程,一点一点的测试和改进。包括我刚才提到的,大大小小的测试方案,有差不多 5 种。不论是思考,还是实现,都花费不少时间。

另外花费较多的地方,是重构。

既不意外,又很意外的,意外总归会来。我之所以要放弃 Demo,是因为它完全以文件为储存,这种方式优点很多,但缺点是数据量一大,速度就会全方位的下滑,甚至到了一个人难以忍受的程度。不管是 Obisidan 还是 Emacs 上大名鼎鼎的 Org-roam,都存在这样的问题,用户的抱怨,我见过不少。基于这个理由重构,我觉得没问题。但之后的重构,多多少少我觉得有点乱来——我一共重构了 6 版……

刚才谈到 Demo,这算是第一版。然后我突然间迷信起 AI 能够搞定一切的狗屁说法来,我通过 NotebookLM 提炼 Tana 的功能特性,并总结成产品文档,然后让 Windsurf 帮我完整实现。果然没能达到预期,产生了一堆代码,但是无法通过实际测试。这花了 1 天时间。然后接下来,我又用 Cursor 用同样的流程,重复一次,也还是得到一堆无法正确执行的代码,又花了 1 天。

但我不觉得 Cursor 和 Windsurf 要为重构失败负上主要责任。最主要的责任还在自己身上。因为心浮气躁,想着赶工,根本就没有静下心来,认真阅读 AI 提交的代码,理顺其中的节点。有一点点 Bug,就想马上推倒重来,反而陷入不断重复实现基础功能的循环里,中间浪费的时间更多。

时至今日, 我们对论语的解读是如此单一

2024-11-10 09:53:00

在了解西方人如何解读《论语》,以及为什么认为《论语》是思想经典后。会发现,《论语》的内涵如此丰富,

我想《论语》之所以可以流传下来,绝非是因为它摘录了孔夫子的语录,而是学徒们觉得孔夫子这些话很重要,才摘录。

重要,就是信息密度,以及可解读的信息层次。

但上下五千年,对它的解读角度,却如此单一,一直延续到现在。不得不让人有一种历史的悲怆感。

制造轮回的,不光是别人,也包括了自己。以及那个看似强大,而实则脆弱的篱笆。

用 AI 辅助开发的经验二三则(2)

2024-11-07 14:00:00

最新发布的 org-zettel-ref-mode (以下简称 OZR)版本号从 0.3.3 跳到 0.4,在这一轮冲刺中,我实现了比之前更加复杂的功能,更多的代码行数,更加复杂的结构。而所花费的时间,是过去的三分之一,我认为自己取得了可喜的进步。

OZR 新的版本,增加了一个新功能,用于管理引用来源文件的可视化面板。这句话看上去很简单,但背后的工作量并不小。前端改一个词,足以让后端跑断腿。出现产品经理被砍这样的新闻,也不必奇怪了。

可视化面板,是很多产品里常见的特性,它的功能就是,让用户更加舒服地查看、管理特定的对象。在 OZR 里,其管理对象是,一个个被充当引用来源的参考文件。

如果让你来设计这个面板,你觉得第一个问题会是什么?我一开始的反映是,文件应该以什么样的方式进行展示?但实际上,在我真正着手开发时,真正重要的问题是: 在面板里展示的数据源来自哪里? 在数据源发生了改动之后,如何确保原来的文件映射关系不变?

继续追问这两个问题,会发现,从工程上需要实现:

  1. 将原本非格式化的数据转换成格式化数据,保存到数据库中,面板访问数据库才能既快又好地展现文件信息
  2. 由于用户会在面板上编辑文件信息,因此面板上更新的数据,需要同步到数据库对应的字段中,进行信息层面的对齐,这样子才能确保面板在重新加载之后不会出现错误的信息

从这 2 个问题继续追问,就会出现大量需要实现的工程细节。但最重要的一个问题是,需要使用一个怎么样的数据库,才能够满足以上需求。再深挖这个问题,就是数据库应当使用什么结构,能够满足当前的业务需求?再追问这个问题,就会回到业务层面上,实际业务的情景是什么?

设计数据库之前需要先探明业务情景

在没弄清楚实际业务发生的情形之前,我所尝试的各种实现数据库的方法,都是错的,各种 Bug 层出不穷,按下葫芦浮起瓢。最后我冷静下来,深究原因——保存与存取,总是出现问题。我得感谢之前开发的经验里,让我牢牢记住一个原则:一个 Bug 如果修改 3 次都不成功,一定要转换思路,不要继续重复原来的方法。

所以,我和 AI 对话,对实际的业务情景进行分析,寻找最适合的数据库结构。这个问题决定了数据库的读写方法——

我: overview-id 一定对应一个 ref-id (必需关系) 也未必会有对应的一个 ref-id,因为有的 overview 文件不是从 ref 源文件夹中的文件创建。不过,从严格意义上来讲,一个 overview 文件,必须对应有一个 source 文件

AI: 明白了,让我重新梳理这个关系: 从数据库角度: ref-id 可以没有对应的 overview-id overview-id 可以没有对应的 ref-id 但如果存在映射,则是一对一的关系 从业务逻辑角度: overview 文件必须对应一个 source 文件(业务规则) 但这个对应关系可能还未在数据库中建立(数据状态) 映射关系的建立是一个渐进的过程 Map 表的职责: 记录已建立的映射关系 确保映射的一对一性 不强制要求所有实体都必须有映射 但提供检查机制发现"孤立"的 overview 这样的理解更准确了吗?

最小练习单位

2024-11-05 18:37:00

之前, 我发展了一个概念, 叫 “最小创造单位”. 它大概面对的情景是, 自己闲着, 不知道自己干点什么的时候, 想一想能够在很有限的时间里, 捣鼓点什么出来, 是一个无中生有的过程.

今天我想把 “最小单位” 这个概念, 再延伸一点, 叫 “最小练习单位”. 起因是, 每天需要学习的东西很多, 有时候会陷入犹豫, 在确定自己练习什么的时候, 太阳西下, 天色也昏沉. 此时惊觉, 一天已过.

“犹豫就会败北!” 所以, 我刻意地想提 “最小练习单位”, 将自己从踌躇不决的境地里拯救出来.

然后我观察了放多大牛的学习方式, 其中 Django 框架的作者(之一) Simon Willams 令我印象深刻.

他的博客内容量极大, 有好几个栏目, 可以从他自己制作的月报看到, 有包含观点的文章, 有记录自己新实验或者练习 TIL, 还有自己的开源项目的新版本更新等等. 这些还不止, 在博客的侧边栏, 还有他分享的, 自己每天看过觉得不错的网络文章.

如果说, 我想在现代社会里, 找到一个人, 像 Zettelkasten 发明人那么高产, 那么可能就是 Simon Willams 了.

在他的 TIL (就是 Today I Learned 的意思) 栏目里, 会看到他从不间断地练习记录 – 这些练习有的长, 有的很短. 在他繁忙的日常里, 他总会抽出一点时间出来, 去探索新鲜的玩意, 去掌握自己之前不知道的知识.

博客 = 人性的补完

2024-10-19 17:23:00

其实我很不愿意写关于博客本身的任何话题. 反复自证, 非我所好. 再说, 博客也断断续续, 写了老长一段时间, 即便是不写的那些日子里, 域名费也乖乖地交了.

博客, 于我而言, 是再自然不过的, 我无需为它解释什么, 更不用解释 “为什么写博客” 这种问题. 而且, 既然已经上线一个博客, 老是写关于博客的话题是有点奇怪的 – 一个自留地, 访客来去自如, 不必为流量烦扰. 毕竟, 博客的原始词义, 是线上日记本.

日记本, 就不是给外人看的. 保持这一份纯粹, 在一个越来越呈现 “繁荣性贫乏” 的互联网里, 反而难淂. 无所图, 必有获.

但我还是有强烈地冲动, 写下这一段文字. 是因为有一个念头, 老在脑海里转来转去, 不吐不快. 博客, 对于每一位作者而言, 可能都有着不同的价值. 我来谈谈我的版本.

我觉得阴阳学说, 是这个世界上最能体现本质运动规律的古代学说. 尽管我的理解未必正确 – 事物有正面, 则必有反面, 这个正反关系, 并非对立, 只是描述一个事物上存在两种矛盾特性的客观现象. 就如我们自己, 在工作生活中, 也存在着很多的方面. 就好想多棱镜一样, 不同角度的光照射, 会照应出不同的色彩.

正因为, 在社会公众生活中, 我们需要向社会妥协, 戴上不同的面具, 保护自己, 也保护他人. 然而, 就如阴阳理论所说, 如果这种戴面具的行为是 “阳”, 那么于个人而言, 则存在一个相反的 “阴” – 一个不戴面具, 更加纯粹的自我. 我们的心境, 往往在这一 “阴” 一 “阳” 之间摆动. 但, 只陷入某个极端, 都会有失偏颇.

最小创造单位

2024-10-18 20:47:00

很多事情都可视为「最小创造单位」:

认真的写一篇帖子
学习新的菜
散步时绕多一个弯,试一试不同的路线
随手拍一张自己觉得不错的照片
把衣服叠整齐放好
记录一个不成熟的灵感
记住一个今天新学习到的词,或者句子
研究一个今天才听说过的人
看一个之前完全没兴趣的电影或电视剧
看看最近流行的艺术形式
为今天的穿着想新的搭配
……

有一个豆瓣小组,叫《做一个具体的人》,我加入这个小组纯粹是被名字所吸引。我之前也不知道怎么做一个具体的人,像项飙所说的,当代人的生活在别处,不在此时,不在此地。在逐步探究这个问题的时候,愈发感觉到,自己主动、积极地创造生活,才能让自己作为一个人变得越来越具体。

而创造自己的生活,最小的落脚点,就是我刚才举例的「最小创造单位」。

生活不是线性叙事,它是一时一刻组成的。而我觉得,在正常的工作之余,用「最小创造单位」填满柴米油盐之外的时刻,可以一石三鸟:

为自己提供一个高创意的环境/心境,我相信心境也是环境要素之一
越实践「最小创造单位」,越能提高对自己的肯定,自信心大增
更多的创造,让自己拥有更多与别人分享的故事,经验,是提高自己社会价值的好方法
最后一点也是最重要的一点,能够让自己的生活有滋有味,心情开朗

最后一句话,让自己活得有意思,开开心心,我以为是对自己负责的最大体现,关于这一点,我坚信「最小创造单位」是最小基石。

注:豆瓣小组的正确名字是《「做具体的人」共进会》,之前凭印象名字写错了,但为了不影响原文的阅读,以备注的方式进行提醒。