闭门造车想了一个改进版的笔记/发布工具,大家看看这玩意儿有没有搞头

最近一直在琢磨一个东西,越想越觉得有点意思,但也可能是我自己在自嗨。

我想要的工具是:先让记录顺手、整理清楚、写字时能专注在内容上(不被编辑器抖动、命令行、插件折腾打断),再自然衔接到发布——不是写完另找一套系统硬发。整套产品设计本身零依赖:不靠命令行、npm、插件生态或外部工具链拼凑,装完就能完整覆盖从写到发,不是「这个功能还得另装 XX」。

写出来,大家帮忙看看——这个东西如果做出来,你会想用吗?"没必要"这种大实话也欢迎。

先说说现在这些工具,我个人卡在哪

写笔记这块,主流是两条路:

  • Obsidian / Typora 这种"实时预览":打字的时候,**加粗** 会自动变成加粗效果,# 变成标题样式,看着很爽。但深究下去会发现,光标移进移出语法符号的瞬间,经常会有轻微的"抖一下"——文字左右挪位置,甚至因为符号显隐导致这一行突然换行。这个问题几乎是这条技术路线的通病。更让人不舒服的是:你会突然发现,编辑时看到的内容和预览时看到的对不上,那种"咦这段刚才不是这样的"的错愕感,比单纯的画面抖动更让人分心。
  • VS Code 这种"双栏并排":左边写右边看,稳是稳,但本质是给程序员用的工具,写东西的时候总感觉不够"沉浸",像在写代码不是写字。

发布这块,主流也是两条路:

  • Hugo / Jekyll / Zola 这类静态站点生成器:功能强大,免费开源,但对普通人来说门槛不低——要学模板语法、要会点命令行、要自己折腾部署。写笔记是个轻松的事,发布却变成了一个"工程项目"。
  • Notion / 语雀这类云笔记:发布是方便,一键分享。但数据在别人服务器上,不是本地文件,不能随身带走,也没有真正属于自己的版本历史。

这几类工具背后其实是同一个假设:写和发是两码事,各做各的就行。 Obsidian/Typora 把编辑体验做到极致,但发布基本靠插件硬凑;Hugo/Jekyll 把发布做扎实了,但写东西要先学模板、敲命令行;Notion 两头都图省事,但内容锁在别人服务器上。我觉得这个假设是错的——大部分人写东西的时候,脑子里同时装着"这段我自己留着"和"这段以后可能给人看"两种念头,工具却从来没把这两种念头当一回事对待过。

最卡我的一个问题:我很多时候想写点东西,一部分内容想留给自己看(比如一些没想清楚的碎碎念、真实吐槽、不打算公开的核心判断),另一部分想公开分享。现有工具里,这基本等于要么维护两份文件,要么装一堆插件七拼八凑,没有一个"顺手"的方案。而现在人人都离不开 AI 辅助创作——那些不打算公开的真实想法,恰恰是喂给 AI、让它更懂你意图的好材料,但这部分又不该暴露给读者。

我瞎琢磨的方案,大概是这么个思路

核心一句话:同一份文件,既是写给自己(和 AI)看的,也是随时能变成给别人看的——编辑器和发布系统不是两个独立功能,是同一份内容在"内部"和"外部"两种视角下的呈现。写在本地文件里,自己留着查;想分享的部分,随手就能发成网站,不用管什么模板和部署。

具体拆开是这几块:

1. 编辑器:常态预览,点击弹出编辑层 放弃"打字时文字实时变身"这个方向。常态就是预览态——毕竟大部分时间是在看、在找、在整理,不是在写。要点某处改字,弹出一个编辑弹层:尺寸合适,打开就能直接改;一定定位到你点的位置;弹层可以拖动改位置、调整大小,也可以最大化。改完关掉弹层,回到预览——切换是一次完整、明确的动作,不存在"编辑时看到的和预览时对不上"那种撕裂感。新建的空白文件例外,直接开编辑(反正也没什么可预览的)。编辑层里,语法符号(#**)常驻显示,但用样式弱化 + 给内容套上对应格式(标题就是大字号,加粗就是粗体),一眼能看懂结构,但没有任何文字会"消失/出现",也就没有抖动这回事。

2. 一份文件,两种用途(块级/文件级私有标签) 在文档里用标签把某段(或整篇)标成"私有"——不是删掉、不是另存一份,就是打个标签。这段内容永远留在文件里,你自己能看、AI 能读(专门用来喂给/约束 AI),但一旦这份文件要变成博客或者知识库页面,带标签的部分自动隐身,读者看不到。不用维护两份文件,也不用来回复制粘贴。

3. 写完直接发,不用碰模板 自带两套做好的模板:博客 + 书籍式知识库,覆盖现在最常见的两种发布形态。写完点发布就是一个像样的网站。只有想深度自定义的人,才需要去了解底层的模板系统——而且因为内容本来就是普通文件,想个性化时直接让 AI 帮你改样式就行,大多数人从头到尾不需要自己啃文档。

4. 一键部署到免费平台 发布目标是 Vercel / Netlify / Cloudflare 这类免费平台,一键上去,不用自己搭服务器。

5. 本地文件 + Git 管理数据版本 所有内容就是普通的 Markdown 文件,存在你自己电脑上,不锁定在某个 App 里。数据版本用 Git 管理(改了什么、什么时候改的),内置好用,不用你自己另外折腾命令行。

6. 双链、反向引用、全文搜索 写笔记之间可以互相链接跳转,打开一篇笔记也能看到"还有哪些内容提到过它",加上全文搜索——这块尽量对齐大家熟悉的 Obsidian 体验。

7. 富内容嵌入 Markdown 语法能表达的东西有限,所以支持像"卡片"一样嵌入音频、视频、下载按钮这类富内容,写起来也很轻量,一行代码的事。

说到底就是想让人把心思都花在「写」「发」「找」这三件事上,其他的都不该占用注意力。

想问问大家

写了这么多,其实就想问几个问题:

  1. "同一份内容,一部分留给自己/AI,一部分留给读者"这个需求,你日常会遇到吗? 还是说你的笔记和想发布的内容,本来就是两码事,压根不需要混在一起?私有内容"喂给 AI 但不给读者看",这个场景你有吗?
  2. "常态预览、点击弹出编辑层(可拖动/缩放/最大化,且定位到点击处)"这个交互,你觉得顺手还是别扭?
  3. 本地文件 + 自己发布网站这件事,对你来说是刚需,还是"听起来不错但其实我根本不会去用"?
  4. 如果这东西真做出来了,你会拿它取代 Obsidian、语雀,还是只会当个"发博客的工具",笔记还是习惯用回原来的?
  5. 这套设计听下来,是觉得东西真的被打通了,还是感觉还是几个功能堆在一起?有没有哪个点,你觉得"这不就是 XX 工具已经做过的吗,没必要重新造"?

想听听大实话,包括"这玩意儿没什么意思"这种反馈也完全欢迎。

共了2周的时间,搞了个比较完整的版本。有兴趣的可以把玩下。
DaoBox|道盒 测试
功能一览:https://meta.appinn.net/t/topic/90467/27?u=dayuway

这个方向我会关注,里面有几个点确实打中了我。

把“避免编辑器抖动”这个细节放在前面,让我相信你是一个有品味和要求的人,于是耐心看完了你的长文。

发布这块,我在用 Hugo,它已经算静态站点里比较简单的了,但写完一篇东西,要生成、部署,还是会觉得麻烦。

你提到的另一个需求,很有辨识度:

同一份内容里,有些话给自己和 AI 看,有些话给读者看。

这的确是个少有人注意到的痛点。

很多东西在形成文章之前,本来就混着判断、吐槽、上下文,还有一些没想成熟的东西。这些内容对自己有用,也有助于 AI 理解意图,但公开时又不适合出现。现在一般只能删掉或者另外维护一份。

如果私有块能成为文档本身的一等能力,我觉得这个点值得继续挖。相比之下,「双链、全文搜索」现在已经比较常见,反而是这个能力更容易让我记住产品。

编辑器这里,我对「常态预览,点击后弹出编辑层」的方案有兴趣,但暂时不敢说长期用起来一定舒服。这个交互挺有创意,要看连续编辑十几二十分钟后,会有什么感觉,甚至需要更长期的试用才有答案。

另外,关于避免markdown跳动的问题,可以参考一下我之前做的这个方案:https://k.appinn.me/calm/

我的思路还是保留源码模式和预览模式。编辑时处于源码模式,语法稳定显示,同时把图片、表格之类直接渲染出来;不编辑时再切回完整预览。目标其实差不多:编辑时稳定,阅读时干净。

你的弹层方案更激进,也可能更有意思。这块我觉得适合先做出原型,实际用一阵再判断。

发布部分还有一个我希望加上的东西:导出纯 HTML。

Vercel、Netlify、Cloudflare 一键部署都很好,但最好别把发布路径只绑定在这些平台上。有些人已经有服务器,也有人只是想生成一个目录直接上传。能导出干净的静态 HTML,发布方式会多很多,用户也不用担心以后被某个平台卡住。

如果按你现在描述的版本做出来,我大概率不会第一天就拿它完全替代现有笔记工具。我更可能先把它当成「写作 + 发布」的工具用。

决定我会不会慢慢把笔记也迁过去要看:

  • 软件是否轻量,流畅
  • 编辑体验能不能连续用几个小时还不烦。
  • 私有内容和公开内容混写,能不能真的做到非常舒服

我不会把它理解成「Obsidian 加博客发布」。

它发现和解决了

同一份内容,从还没成形的想法,到自己的长期笔记,再到最后公开出去整个流程中要考虑的问题

这个方向,我觉得有东西。

1 个赞
总结

目前我的大部分笔记都是给我自己用的。

最近玩 vibe,我会给 AI 留一个 # AI Document,让 AI 在这里面写,我在上面手写。

发布相关的需求,我经常考虑,但想来想去最后都是放弃了,不知道发布有什么用。

目前我上网还是纯瘾大,没有盈利目的,考虑过起号,但是太懒了。可能发布对我来说就是穷显摆吧…

关于 markdown 预览,我和楼上也交流过这个话题。

我最后的解决方法很“蠢”:少说废话,不用样式。

我的手写 markdown 中,几乎只有 heading 和无序列表两种样式,加粗等样式从来不用。

比起在一大段话中加粗重点,我选择说简单明了的话。(这个习惯也是不利于起号,字数太少)

如果这个东西是用来取代其他软件的,那我感觉它走错方向了。

obsidian 的理念是 file over app。

一份 markdown 文档可以用多个软件打开。

我现在剔除的是那种封闭的软件。(这个习惯也是不利于起号,没法接广了)

1 个赞

这个应该有需求,先搞个第一版,再来迭代更新!

很不错的想法,虽然我应该是用不着 分享一下我的习惯吧

我平时用obsidian写作,常年用源码模式,写完一段之后手动切到预览视图看效果,所以没有抖动的问题。

用特定标记来标识隐私内容我觉得有点意思,以我当前的习惯会分两份,反正发出来的和自己用的都在一个仓库里,来回切也不费劲。

然后就是最重要的部分——怎么发布。
我发布的渠道主要是自己手搓的博客,后端是纯PHP+SQLite,所以不需要每次都重新渲染一遍。
有专门的API接口接收格式化JSON数据并更新数据库,因此很方便写脚本。
再者我做了Pjax,内容和框架是完全解耦的。换言之框架只对应主题,内容是独立的,可以来自于数据库,也可以来自于本地文件。

总结一下就是我已经造了一套完整的写作→发布→展示流程,缺点是必须要有自己的服务器

你的方案自己使用也很不错了!

谢谢各位给我增加信心。

导出独立的静态站点是必须的,我一直比较推崇这种自由且依赖少的设计,未来趋势怎样,谁都不知道,希望到老再打开它时,还是那么的光亮如新。

同一个文件,不同的区块(按段落或者标题层级所属)按标签来控制输出,以后可能会有更多的场景。如果不是单纯的个人日记 ,以后免不了AI的参与。我自己使用下来的感受是,AI 很容易输出过多内容,看起来很全面,但冗余也不少,信息多了之后,就容易飘,如果文件有一个区域,用来锚定原始的输入,就会好很多。我现在除了放原始的想法,还会有,关于配图的提示词,每次变动的日志,针对各平台的提示词,如果缺少这些内容,AI经常打转。因此我猜想其它用户应该也会有同样痛点。

现在这个创想,就是完全基于本地 Markdown 文件,格式通用,这样才更利于 AI 加入。
借助 GIT (应该要封装下,对多数用户来说门槛不低)来管理版本,我认为已经很开放了,完全不用担心转移和其它应用的参与的问题。

关于笔记发布,我个人比较看好,现在平台不少,而各个平台都有自己的规则和喜好,我们不得不遵守,但同时我更喜欢百花齐放,百家争鸣的时代,并且不会有单点局限,我给他取名叫个人数字根据地,我们可以外出游玩,但应该有个根据地,那里只有自己的规则和个性,而不是这个或那个的平台味。如果国内再有一个类似 HackNews 一样的平台,将这些聚集一下,那就更好了。

最终我的愿景是,发展成为个人知识库,有包容,够开放,可伸缩。

我做了一个功能点的 MVP,大家可以看看体验如何?

越来越喜欢,一开始是预览效果,双击可修改的方式。
AI 盛行的今天,自己动手改的机会越来越少了,无论是知识库还是收藏,还是看的居多。

顺便加了几个快捷方式:

  1. 双击弹出修改
  2. Mod+Enter 提交修改
  3. 连按2次 ESC 取消修改
  4. Mod+E 直接进入修改。会记录最后一次未离开 viewport 的编辑位置。

其它功能可以忽略,没调教。

下载地址:DaoBox|道盒 测试

我身边只有 Mac , Windows/Linux 暂时无法测试,如有问题,请反馈给我。

能直接写完发hugo吗?

它是基于文件系统的,所以无任何障碍,喜欢什么就用什么。

产品定位是:一个基于本地文件系统的 Markdown 知识空间。

当前这个只是产品调研,截至到目前给出的仅是预览与编辑的交互改进 MVP,其它正在补充。

我再推荐下,和它无缝搭配的 everkm-publish , 比 hugo 更强更简单,有兴趣可以关注下。

主要几个比较主要的特点:

1.站点内容结构自由,常见的静态 Blog 生成器,只能走传统的 BLOG 结构。在 AI 盛行的今天,不受限制的版式,更能彰显个性。

  1. 除了常见的模板引擎,它支持 tsx 语法(注意仅是语法,不用考虑什么路由,状态管理),也就是说,JS语法都支持(写过模板的就知道有多舒服), 经过简单编译后直接可用,这对复杂站点来说,更好管理,尤其借助AI。可以 pull 官网的模板,让AI 参考写就可以了。

  2. 很方便的集成 algolia 搜索, 无缝在导出时提交索引,对一般流量来说够用了。

官方提供2个样式:

一个书籍知识库样式,另一个是经典 BLOG 版式

最大的缺点就是年轻了点儿,有兴趣可以关注下。

DaoBox-0.1.1-win-x64-portable.exe 初始化就一直失败

用打开目录,不要初始化,那个功能没做

打开目录会提示初始化,选择取消,打开了目录也是空的,而目录里有.md文件。

果然如你所说,我本地测试时,我是手动创建了一个。

你先在打开目录下手动创建一个目录名 __everkm ,就可以了。注意是双下划线。

可以了。

另外想请教一下,everkm-publish 和 Hugo 的区别是什么?

我初步看下来,感觉它在文档间链接和内容组织这块会更顺手一些,不知道这个理解是否准确。

除此之外,还有哪些也比较有差异化的功能或优势?

最开始的那个设想,经过逐步优化,已经可以解决,不用再忍受抖动带来的诧异感。
在看多写少的场景下,这种交互方式,我体验下来,感觉还是不错的。

下一步

  1. 接入 everkm-publish ,以实现站点自由导出
  2. 同一文件,不同的块可以独立打标签,满足不同的使用场景

Everkm Publish(毓知发布) 是 Everkm 生态下的 Markdown 静态站点生成器:写 Markdown,选主题,本地预览,导出 HTML,部署到任意静态托管。

与 Hugo、Jekyll、Zola 一样,它无需数据库、产出标准 HTML、支持 CDN / Nginx / Vercel / GitHub Pages。差异在于,我们面向长期积累的知识,而不只是「发一篇博客」:

一、一种工具,多种站点形态

博客、书籍文档站、知识库 / Wiki、产品官网——同一套 CLI 都能做。站点结构由 folders 目录配置定义,不锁死在「首页 → 分类 → 文章」的博客骨架。经典主题 youlog(文档 / 知识站)与 paper(博客)即为例证。

二、URL 与目录解耦,标题改了链接不断

磁盘目录与对外 URL 可分离;默认 URL 含稳定页面 ID(slug-id),改标题 / slug 后 ID 不变。导出元数据并生成 Nginx / Vercel 重定向配置,旧外链仍可到达同一篇内容。

三、毓知 Markdown:为互联而写的方言

在标准 Markdown 之上扩展内链 [[...]](支持 slug、相对路径、站点根路径、锚点、自定义文案等多种写法)、宏、dCard 卡片、区块 / 行内扩展属性、章节目录 _nav.md。站内页面互跳用内链;发布前 lint 检查坏链与歧义,守住知识网络。

四、主题双轨:Jinja2模板 与 TSX 并列

主题可用 Jinja2 语法模板,也可用 TSX / JS 渲染——二者并列、无主次,可按页面复杂度组合。TSX 推荐 SolidJS:比 React 轻量,只需 TSX 语法组织 HTML,无需路由、状态、响应式变量;编译后在生成期一次渲染出静态 HTML。主题可远程安装,站点通过 extend/ 覆盖。

五、导出贴近知识站,也可补全入口

默认从首页沿内链爬取导出;未被引用的页面不进 dist/。可用 --start-urls 追加遍历起点。未被正文引用的资源放 extend/assets/

六、搜索与构建期能力内建

Algolia 全文搜索可配置「导出即推送」;多站 / 多栏目用 site / channel 隔离。代码高亮、公式渲染可在生成阶段完成,减少浏览器负担。

详细了解 Everkm Publish 与 Hugo / Jekyll / Zola 的差异 | Everkm Publish

DaoBox 的小窗编辑模式

  • 优点:速度快,定位准,滚动流畅。
  • 几个问题
    1. 源码宋体(非衬线字体)在Windows上笔画较为纤细。
    2. 修改文本的判定有点问题,编辑的时候打一个字,然后删除,实际上原文档相当于没修改,但是会被判定为文档被修改了,一定要用户保存一下,否则,快捷键双击 ESC 退出,就会提示是否忽略修改,每次弹。
    3. 保存当前设置的按键组合为 Ctrl+回车。一般是左手按 Ctrl,右手按回车;也可以直接用右手按回车。问题在于当前交互功能是“浏览为主”这时候用户大概率在用鼠标。当右手放在鼠标上时,如果要使用回车按键,右手就必须离开鼠标;不管是左右手配合,还是纯右手操作,都需要右手离开鼠标。建议改为能左手单手完成的组合键,比如ctrl+s
  • 整体使用感受:对于以浏览为主的使用状态,使用体验还行。但如果是编辑、创作为主状态,这种方式就有些繁琐了。因此建议将此模式作为支持的多种编辑模式之一,不建议作为唯一的编辑模式。

everkm-publish

看起来好像不错,考虑用一下

看得出,你也是个细节控呀。

字体和保存问题,还未来得及完善。

左手保存并关闭,是十分必要的。
会留出经典的左右栏交互,一边编辑,一边预览。

你这个方案 一份文件,两种用途
感觉使用起来更麻烦了

可能每个人的习惯不一样吧。

我是在使用过程中,发现和AI配合时,或者需要对外发布时,经常性输入和输出是有选择性的,所以才有这个构想。也有可能你还没有这样干过,或者有自己熟悉的工作流,总之适合自己的就是好的。